From wagner at elegosoft.com Wed Apr 1 00:03:50 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 01 Apr 2009 00:03:50 +0200 Subject: [M3devel] m3 CVS? In-Reply-To: <47E57322-28FD-4C9E-B1FE-12761C6F32AB@cs.purdue.edu> References: <20090325135234.GA16351@topoi.pooq.com> <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> <20090325144505.GA16526@topoi.pooq.com> <20090325225421.GB17118@topoi.pooq.com> <20090330131918.GA6921@topoi.pooq.com> <20090331133910.flci659jockgo04c@mail.elegosoft.com> <20090331135610.GA9539@topoi.pooq.com> <20090331161908.3pferzf9c08oso40@mail.elegosoft.com> <20090331144252.GA9624@topoi.pooq.com> <20090331173542.60xixsbl4w4kcsgs@mail.elegosoft.com> <47E57322-28FD-4C9E-B1FE-12761C6F32AB@cs.purdue.edu> Message-ID: <20090401000350.9ulc6eobpk44coo0@mail.elegosoft.com> Quoting Tony Hosking : > Both PM3 and CM3 forked from SRC M3. Yes, the releases both built on the SRC source, but as far as I know there was never one repository where the history was combined. Olaf > On 1 Apr 2009, at 02:35, Olaf Wagner wrote: > >> Quoting hendrik at topoi.pooq.com: >> >>> Speaking of ancient history -- Are cm3 and pm3 both in one CVS so that >>> they share history? Or are they in separate CVS's? >> >> CM3 and PM3 are two separate repositories. SRC never used CVS for M3 >> version control (don't exactly know how they did managed the sources). >> PM3 was created by Michel Dagenais as an open source continuation of >> SRC M3, while CM3 started as a commercial product and was later open >> sourced. >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Wed Apr 1 00:38:59 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 31 Mar 2009 18:38:59 -0400 Subject: [M3devel] m3 CVS? In-Reply-To: <20090401000350.9ulc6eobpk44coo0@mail.elegosoft.com> References: <20090325225421.GB17118@topoi.pooq.com> <20090330131918.GA6921@topoi.pooq.com> <20090331133910.flci659jockgo04c@mail.elegosoft.com> <20090331135610.GA9539@topoi.pooq.com> <20090331161908.3pferzf9c08oso40@mail.elegosoft.com> <20090331144252.GA9624@topoi.pooq.com> <20090331173542.60xixsbl4w4kcsgs@mail.elegosoft.com> <47E57322-28FD-4C9E-B1FE-12761C6F32AB@cs.purdue.edu> <20090401000350.9ulc6eobpk44coo0@mail.elegosoft.com> Message-ID: <20090331223859.GC10145@topoi.pooq.com> On Wed, Apr 01, 2009 at 12:03:50AM +0200, Olaf Wagner wrote: > Quoting Tony Hosking : > > >Both PM3 and CM3 forked from SRC M3. > > Yes, the releases both built on the SRC source, but as far as I know > there was never one repository where the history was combined. > > Olaf I suspect combining them would be more work than it's worth. And only feasible if the SRC source both forked from is still in existence. But tempting. -- hendrik From jay.krell at cornell.edu Wed Apr 1 00:41:42 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 31 Mar 2009 22:41:42 +0000 Subject: [M3devel] m3 CVS? In-Reply-To: <20090331161908.3pferzf9c08oso40@mail.elegosoft.com> References: <20090325083158.hkinn8yjkksocw4c@mail.elegosoft.com> <20090325135234.GA16351@topoi.pooq.com> <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> <20090325144505.GA16526@topoi.pooq.com> <20090325225421.GB17118@topoi.pooq.com> <20090330131918.GA6921@topoi.pooq.com> <20090331133910.flci659jockgo04c@mail.elegosoft.com> <20090331135610.GA9539@topoi.pooq.com> <20090331161908.3pferzf9c08oso40@mail.elegosoft.com> Message-ID: Also, presumably you can copy the entire CVS repository with little CPU use and then do the monotone work locally. I doubt it is all that large, can tell you later.. (ssh in and du /usr/cvs) - Jay > Date: Tue, 31 Mar 2009 16:19:08 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > CC: manderson at elego.de > Subject: Re: [M3devel] m3 CVS? > > Quoting hendrik at topoi.pooq.com: > > > On Tue, Mar 31, 2009 at 01:39:10PM +0200, Olaf Wagner wrote: > >> Quoting hendrik at topoi.pooq.com: > >> > >> >Is CVS back up yet? Completely? I've been delaying trying the > >> >monotone conversion because it would be nice to have only one set > >> >of problems to look into. > >> > >> CVS is up and no history should be lost, but tinderbox is still not > >> working and several archives are missing. Michael is working on it > >> (but he's got some other tasks, too). > > > > So the current source is available, but not the tools to investigate > > their status on-line. And the other archives? What are they? Are they > > more source code? Should they be subject to revision control too? Are > > they ancient prehistory that should be grafted into the revision tree > > except that it may not be technically feasible? > > Mostly all the old installation archives and snapshots are still missing. > I'm not sure what's the status of the re-installation of tinderbox. > > > Ah. I have too many questions. > > > > By the way, rumours are that monotone's cvs pull command is quite > > demanding on the cvs server, but that sync operation isn't bad at all > > after that. Getting really old versions of files requires CVS to chain > > back through a lot of reverse differences. And I don't know if it > > caches any of that in case it is asked to cough up another really old > > version. > > > > If there are any scheduling considerations I'd like to hear them. I > > don't know if I'll flatten your system, but if I do there are probably > > better and worse times to do it. (I may saturate ny DSL link first, but > > you never know until you try it.) > > > > By the way, what's the total size of Modula 3's CVS archive? > > I've got no access from here (can only check later tonight); please > ask Michael Anderson directly for administrative topics. > > Olaf > > PS: I don't think you can bring the server down a one external CVS > client; the syncing will just take a long time. Unless lots of parallel > requests are started... > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 1 00:43:41 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 31 Mar 2009 22:43:41 +0000 Subject: [M3devel] m3 CVS? In-Reply-To: <20090331223859.GC10145@topoi.pooq.com> References: <20090325225421.GB17118@topoi.pooq.com> <20090330131918.GA6921@topoi.pooq.com> <20090331133910.flci659jockgo04c@mail.elegosoft.com> <20090331135610.GA9539@topoi.pooq.com> <20090331161908.3pferzf9c08oso40@mail.elegosoft.com> <20090331144252.GA9624@topoi.pooq.com> <20090331173542.60xixsbl4w4kcsgs@mail.elegosoft.com> <47E57322-28FD-4C9E-B1FE-12761C6F32AB@cs.purdue.edu> <20090401000350.9ulc6eobpk44coo0@mail.elegosoft.com> <20090331223859.GC10145@topoi.pooq.com> Message-ID: > And only feasible if the SRC source both forked from is still in existence. The SRC 3.6 release is certainly available, not sure if that is what they forked from. I do wonder: - Does PM3 have anything we should salvage? Unknown. - Does ezm3? - Is CM3 the one true Modula-3? I guess not. Or at least the "best" by far and the only one worth working on? I think so. - Jay > Date: Tue, 31 Mar 2009 18:38:59 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3 CVS? > > On Wed, Apr 01, 2009 at 12:03:50AM +0200, Olaf Wagner wrote: > > Quoting Tony Hosking : > > > > >Both PM3 and CM3 forked from SRC M3. > > > > Yes, the releases both built on the SRC source, but as far as I know > > there was never one repository where the history was combined. > > > > Olaf > > I suspect combining them would be more work than it's worth. And only > feasible if the SRC source both forked from is still in existence. > > But tempting. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 1 00:38:35 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 31 Mar 2009 22:38:35 +0000 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: <49D2807D.7010100@bellsouth.net> References: <200903311842.n2VIg6LS046075@camembert.async.caltech.edu> <49D2807D.7010100@bellsouth.net> Message-ID: http://modula3.elegosoft.com/cm3/uploaded-archives ? I can make another later this week. All you need is a working cm3 on any system. >From there you can build the whole system, targeting any system. As long as that cm3 understands LONGINT and your target system. And it is easier, but not necessary, if you have Python. :) - Jay > Date: Tue, 31 Mar 2009 15:43:41 -0500 > From: martinbishop at bellsouth.net > To: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Help finding CM3 compiler for Linux? > > Not sure if this helps, but on my linux system: > > Critical Mass Modula-3 version d5.7.0 > last updated: 2008-03-16 > compiled: 2008-08-14 00:56:14 > configuration: /usr/local/cm3/bin/cm3.cfg > > Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 > i686 GNU/Linux > > > I don't have the cm3 tarball, but I do have the sources in cm3/ still. > > Mika Nystrom wrote: > > Hello everyone, > > > > This is, for me, a most unfortunate time for the CM3 servers to > > have crashed. I'm teaching a class using Modula-3, and we need a > > compiler... here's the uname of the system I'm trying to use: > > > > Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Linux > > > > The most recent archives I have for Linux are: > > > > cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz > > > > And they don't seem to work on this system: I can compile a program > > but when I try to run it, it says "Segmentation fault". Can anyone > > help? (My understanding is that I need 5.5.1 or later...) > > > > Mika > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Apr 1 00:46:59 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 31 Mar 2009 15:46:59 -0700 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: Your message of "Tue, 31 Mar 2009 22:38:35 -0000." Message-ID: <200903312246.n2VMkxml055400@camembert.async.caltech.edu> Aaaah it works now.. or was I looking in the wrong place earlier? (I was getting only broken links.) Thanks to everyone who offered to help! Jay writes: >--_806446ae-8d10-4d74-8eea-51aa365e9204_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > http://modula3.elegosoft.com/cm3/uploaded-archives > >? > >=20 > >I can make another later this week. > >=20 > >All you need is a working cm3 on any system. > >>From there you can build the whole system=2C targeting any system. > >As long as that cm3 understands LONGINT and your target system. > >And it is easier=2C but not necessary=2C if you have Python. :) > >=20 > > - Jay > >=20 >> Date: Tue=2C 31 Mar 2009 15:43:41 -0500 >> From: martinbishop at bellsouth.net >> To: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >>=20 >> Not sure if this helps=2C but on my linux system: >>=20 >> Critical Mass Modula-3 version d5.7.0 >> last updated: 2008-03-16 >> compiled: 2008-08-14 00:56:14 >> configuration: /usr/local/cm3/bin/cm3.cfg >>=20 >> Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 >> i686 GNU/Linux >>=20 >>=20 >> I don't have the cm3 tarball=2C but I do have the sources in cm3/ still. >>=20 >> Mika Nystrom wrote: >> > Hello everyone=2C >> >=20 >> > This is=2C for me=2C a most unfortunate time for the CM3 servers to >> > have crashed. I'm teaching a class using Modula-3=2C and we need a >> > compiler... here's the uname of the system I'm trying to use: >> >=20 >> > Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Lin= >ux >> >=20 >> > The most recent archives I have for Linux are: >> >=20 >> > cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=20 >> >=20 >> > And they don't seem to work on this system: I can compile a program >> > but when I try to run it=2C it says "Segmentation fault". Can anyone >> > help? (My understanding is that I need 5.5.1 or later...) >> >=20 >> > Mika >> >=20 >>=20 > >--_806446ae-8d10-4d74-8eea-51aa365e9204_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > > =3Bet=3D_blank>http://modula3.elegosoft.com/cm3/uploaded= >-archives
>?
> =3B
>I can make another later this week.
> =3B
>All you need is a working cm3 on any system.
>>From there you can build the whole system=2C targeting any system.
>As long as that cm3 understands LONGINT and your target system.
>And it is easier=2C but not necessary=2C if you have Python. :)
> =3B
> =3B- Jay

 =3B
>=3B Date: Tue=2C 31 Mar 2009 15:43:41 -= >0500
>=3B From: martinbishop at bellsouth.net
>=3B To: mika at async.ca= >ltech.edu
>=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3dev= >el] Help finding CM3 compiler for Linux?
>=3B
>=3B Not sure if t= >his helps=2C but on my linux system:
>=3B
>=3B Critical Mass Mod= >ula-3 version d5.7.0
>=3B last updated: 2008-03-16
>=3B compiled:= > 2008-08-14 00:56:14
>=3B configuration: /usr/local/cm3/bin/cm3.cfg>>=3B
>=3B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24= >:39 UTC 2009
>=3B i686 GNU/Linux
>=3B
>=3B
>=3B I don= >'t have the cm3 tarball=2C but I do have the sources in cm3/ still.
>= >=3B
>=3B Mika Nystrom wrote:
>=3B >=3B Hello everyone=2C
&g= >t=3B >=3B
>=3B >=3B This is=2C for me=2C a most unfortunate time = >for the CM3 servers to
>=3B >=3B have crashed. I'm teaching a class = >using Modula-3=2C and we need a
>=3B >=3B compiler... here's the una= >me of the system I'm trying to use:
>=3B >=3B
>=3B >=3B Linu= >x lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Linux
&g= >t=3B >=3B
>=3B >=3B The most recent archives I have for Linux are= >:
>=3B >=3B
>=3B >=3B cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3= >-src-all-5.4.0.tgz
>=3B >=3B
>=3B >=3B And they don't seem = >to work on this system: I can compile a program
>=3B >=3B but when I= > try to run it=2C it says "Segmentation fault". Can anyone
>=3B >=3B= > help? (My understanding is that I need 5.5.1 or later...)
>=3B >=3B= >
>=3B >=3B Mika
>=3B >=3B
>=3B
>= > >--_806446ae-8d10-4d74-8eea-51aa365e9204_-- From hendrik at topoi.pooq.com Wed Apr 1 01:05:07 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 31 Mar 2009 19:05:07 -0400 Subject: [M3devel] m3 CVS? In-Reply-To: References: <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> <20090325144505.GA16526@topoi.pooq.com> <20090325225421.GB17118@topoi.pooq.com> <20090330131918.GA6921@topoi.pooq.com> <20090331133910.flci659jockgo04c@mail.elegosoft.com> <20090331135610.GA9539@topoi.pooq.com> <20090331161908.3pferzf9c08oso40@mail.elegosoft.com> Message-ID: <20090331230507.GA10261@topoi.pooq.com> On Tue, Mar 31, 2009 at 10:41:42PM +0000, Jay wrote: > > Also, presumably you can copy the entire CVS repository with little CPU use and then do the monotone work locally. I doubt it is all that large, can tell you later.. (ssh in and du /usr/cvs) That might be the way to go. My LAN is a hundred times faster than my connexion with the outside world. Not mention putting it on localhost or getting monotone to look at the cvs files directly (whichever it turns out to like). -- hendrik From hendrik at topoi.pooq.com Wed Apr 1 01:08:28 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 31 Mar 2009 19:08:28 -0400 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: <200903312259.n2VMxIQk055916@camembert.async.caltech.edu> References: <20090331214921.GA10145@topoi.pooq.com> <200903312259.n2VMxIQk055916@camembert.async.caltech.edu> Message-ID: <20090331230828.GB10261@topoi.pooq.com> On Tue, Mar 31, 2009 at 03:59:18PM -0700, Mika Nystrom wrote: > Yes you could try sending it to me somehow? Sorry.. I had an anon > ftp site but it seems to have succumbed to some sort of bit rot. > (If it's too big a hassle for you to send in an attachment or via > the web, let me know and I'll configure something...) > > You could also try uploading it to "rapidshare.com"? > > Any help is appreciated! > > Mika For the time being, there's a link to a copy of cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz near the bottonm of the web page http://hendrik.pooq.com/ -- hendrik From hosking at cs.purdue.edu Wed Apr 1 03:15:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 1 Apr 2009 12:15:29 +1100 Subject: [M3devel] m3 CVS? In-Reply-To: References: <20090325225421.GB17118@topoi.pooq.com> <20090330131918.GA6921@topoi.pooq.com> <20090331133910.flci659jockgo04c@mail.elegosoft.com> <20090331135610.GA9539@topoi.pooq.com> <20090331161908.3pferzf9c08oso40@mail.elegosoft.com> <20090331144252.GA9624@topoi.pooq.com> <20090331173542.60xixsbl4w4kcsgs@mail.elegosoft.com> <47E57322-28FD-4C9E-B1FE-12761C6F32AB@cs.purdue.edu> <20090401000350.9ulc6eobpk44coo0@mail.elegosoft.com> <20090331223859.GC10145@topoi.pooq.com> Message-ID: <51447406-6C71-4CC2-AEAB-EFFFAA139555@cs.purdue.edu> CM3 has evolved significantly beyond PM3. I switched over because PM3 was getting a little crusty. 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 1 Apr 2009, at 09:43, Jay wrote: > > And only feasible if the SRC source both forked from is still in > existence. > > The SRC 3.6 release is certainly available, not sure if that is what > they forked from. > > I do wonder: > - Does PM3 have anything we should salvage? Unknown. > - Does ezm3? > - Is CM3 the one true Modula-3? I guess not. > Or at least the "best" by far and the only one worth working > on? I think so. > > - Jay > > > > Date: Tue, 31 Mar 2009 18:38:59 -0400 > > From: hendrik at topoi.pooq.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] m3 CVS? > > > > On Wed, Apr 01, 2009 at 12:03:50AM +0200, Olaf Wagner wrote: > > > Quoting Tony Hosking : > > > > > > >Both PM3 and CM3 forked from SRC M3. > > > > > > Yes, the releases both built on the SRC source, but as far as I > know > > > there was never one repository where the history was combined. > > > > > > Olaf > > > > I suspect combining them would be more work than it's worth. And > only > > feasible if the SRC source both forked from is still in existence. > > > > But tempting. > > > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Apr 1 07:59:18 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 31 Mar 2009 22:59:18 -0700 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: Your message of "Wed, 01 Apr 2009 04:31:27 -0000." Message-ID: <200904010559.n315xIBx071256@camembert.async.caltech.edu> Is there any documentation for this format beyond what you just wrote? Where? terpsichore-14: cm3 --- building in ../LINUXLIBC6 --- new source -> compiling Main.m3 "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common", line 169: quake runtime error: undefined variable: ROOT --procedure-- -line- -file--- GetM3Back 169 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common _IsM3BackFlagSupported 181 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common IsM3BackFlagSupported 193 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common GetM3BackFlag 197 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common m3_backend 62 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common program -- 6 /afs/.ugcs.caltech.edu/user/mika/test/LINUXLIBC6/m3make.args Fatal Error: procedure "m3_backend" defined in "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3.cfg" failed. Jay writes: >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >These archives do have a different format=2C yes. > >But it isn't a bad format. > >cminstall is pretty worthless imho. > >Extract=2C rename=2C set PATH and LD_LIBRARY_PATH. > >=20 > > - Jay > >=20 >> To: jay.krell at cornell.edu >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux?=20 >> Date: Tue=2C 31 Mar 2009 15:56:11 -0700 >> From: mika at async.caltech.edu >>=20 >> No=2C I'm sorry... >>=20 >> the archives do not have the usual format. I'm expecting to unpack >> and run "cminstall" and then unpack the big source tar on top and=20 >> build that. But there's no cminstall in the archive on this page. >> This is "the normal procedure" for installing CM3=2C no? It's what >> the instructions say to do=2C as well... >>=20 >> And the link from the "Download" page is broken (to -d5.5.0.tgz). >>=20 >> Mika >>=20 >> Jay writes: >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> > http://modula3.elegosoft.com/cm3/uploaded-archives >> > >> >? >> > >> >=3D20 >> > >> >I can make another later this week. >> > >> >=3D20 >> > >> >All you need is a working cm3 on any system. >> > >> >>From there you can build the whole system=3D2C targeting any system. >> > >> >As long as that cm3 understands LONGINT and your target system. >> > >> >And it is easier=3D2C but not necessary=3D2C if you have Python. :) >> > >> >=3D20 >> > >> > - Jay >> > >> >=3D20 >> >> Date: Tue=3D2C 31 Mar 2009 15:43:41 -0500 >> >> From: martinbishop at bellsouth.net >> >> To: mika at async.caltech.edu >> >> CC: m3devel at elegosoft.com >> >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >> >>=3D20 >> >> Not sure if this helps=3D2C but on my linux system: >> >>=3D20 >> >> Critical Mass Modula-3 version d5.7.0 >> >> last updated: 2008-03-16 >> >> compiled: 2008-08-14 00:56:14 >> >> configuration: /usr/local/cm3/bin/cm3.cfg >> >>=3D20 >> >> Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 >> >> i686 GNU/Linux >> >>=3D20 >> >>=3D20 >> >> I don't have the cm3 tarball=3D2C but I do have the sources in cm3/ st= >ill. >> >>=3D20 >> >> Mika Nystrom wrote: >> >> > Hello everyone=3D2C >> >> >=3D20 >> >> > This is=3D2C for me=3D2C a most unfortunate time for the CM3 servers= > to >> >> > have crashed. I'm teaching a class using Modula-3=3D2C and we need a >> >> > compiler... here's the uname of the system I'm trying to use: >> >> >=3D20 >> >> > Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/= >Lin=3D >> >ux >> >> >=3D20 >> >> > The most recent archives I have for Linux are: >> >> >=3D20 >> >> > cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D20 >> >> >=3D20 >> >> > And they don't seem to work on this system: I can compile a program >> >> > but when I try to run it=3D2C it says "Segmentation fault". Can anyo= >ne >> >> > help? (My understanding is that I need 5.5.1 or later...) >> >> >=3D20 >> >> > Mika >> >> >=3D20 >> >>=3D20 >> > >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ >> >Content-Type: text/html=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> > >> > >> > >> > >> > =3D3Bs" targ=3D >> >et=3D3D_blank>http://modula3.elegosoft.com/cm3/u= >ploaded=3D >> >-archives
>> >?
>> > =3D3B
>> >I can make another later this week.
>> > =3D3B
>> >All you need is a working cm3 on any system.
>> >>From there you can build the whole system=3D2C targeting any system.> >> >As long as that cm3 understands LONGINT and your target system.
>> >And it is easier=3D2C but not necessary=3D2C if you have Python. :)
>> > =3D3B
>> > =3D3B- Jay

 =3D3B
>=3D3B Date: Tue=3D2C 31 Mar 2009= > 15:43:41 -=3D >> >0500
>=3D3B From: martinbishop at bellsouth.net
>=3D3B To: mika at a= >sync.ca=3D >> >ltech.edu
>=3D3B CC: m3devel at elegosoft.com
>=3D3B Subject: Re:= > [M3dev=3D >> >el] Help finding CM3 compiler for Linux?
>=3D3B
>=3D3B Not su= >re if t=3D >> >his helps=3D2C but on my linux system:
>=3D3B
>=3D3B Critical= > Mass Mod=3D >> >ula-3 version d5.7.0
>=3D3B last updated: 2008-03-16
>=3D3B co= >mpiled:=3D >> > 2008-08-14 00:56:14
>=3D3B configuration: /usr/local/cm3/bin/cm3.c= >fg> >>>=3D3B
>=3D3B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 2= >9 19:24=3D >> >:39 UTC 2009
>=3D3B i686 GNU/Linux
>=3D3B
>=3D3B
>= >=3D3B I don=3D >> >'t have the cm3 tarball=3D2C but I do have the sources in cm3/ still.>>=3D >> >=3D3B
>=3D3B Mika Nystrom wrote:
>=3D3B >=3D3B Hello everyo= >ne=3D2C
&g=3D >> >t=3D3B >=3D3B
>=3D3B >=3D3B This is=3D2C for me=3D2C a most un= >fortunate time =3D >> >for the CM3 servers to
>=3D3B >=3D3B have crashed. I'm teaching a= > class =3D >> >using Modula-3=3D2C and we need a
>=3D3B >=3D3B compiler... here'= >s the una=3D >> >me of the system I'm trying to use:
>=3D3B >=3D3B
>=3D3B &g= >t=3D3B Linu=3D >> >x lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Linux>&g=3D >> >t=3D3B >=3D3B
>=3D3B >=3D3B The most recent archives I have fo= >r Linux are=3D >> >:
>=3D3B >=3D3B
>=3D3B >=3D3B cm3-min-POSIX-LINUXLIBC6-5.= >4.0.tgz cm3=3D >> >-src-all-5.4.0.tgz
>=3D3B >=3D3B
>=3D3B >=3D3B And they = >don't seem =3D >> >to work on this system: I can compile a program
>=3D3B >=3D3B but= > when I=3D >> > try to run it=3D2C it says "Segmentation fault". Can anyone
>=3D3B= > >=3D3B=3D >> > help? (My understanding is that I need 5.5.1 or later...)
>=3D3B &= >gt=3D3B=3D >> >
>=3D3B >=3D3B Mika
>=3D3B >=3D3B
>=3D3B
> >> >=3D >> > >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_-- > >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >These archives do have a different format=2C yes.
>But it isn't a bad format.
>cminstall is pretty worthless imho.
>Extract=2C rename=2C set PATH and LD_LIBRARY_PATH.
> =3B
> =3B- Jay

 =3B
>=3B To: jay.krell at cornell.edu
>=3B= > Subject: Re: [M3devel] Help finding CM3 compiler for Linux?
>=3B Dat= >e: Tue=2C 31 Mar 2009 15:56:11 -0700
>=3B From: mika at async.caltech.edu= >
>=3B
>=3B No=2C I'm sorry...
>=3B
>=3B the archives = >do not have the usual format. I'm expecting to unpack
>=3B and run "cm= >install" and then unpack the big source tar on top and
>=3B build tha= >t. But there's no cminstall in the archive on this page.
>=3B This is = >"the normal procedure" for installing CM3=2C no? It's what
>=3B the in= >structions say to do=2C as well...
>=3B
>=3B And the link from t= >he "Download" page is broken (to -d5.5.0.tgz).
>=3B
>=3B Mika>>=3B
>=3B Jay writes:
>=3B >=3B--_806446ae-8d10-4d74-8eea-5= >1aa365e9204_
>=3B >=3BContent-Type: text/plain=3B charset=3D"iso-885= >9-1"
>=3B >=3BContent-Transfer-Encoding: quoted-printable
>=3B = >>=3B
>=3B >=3B
>=3B >=3B http://modula3.elegosoft.com/cm3/u= >ploaded-archives
>=3B >=3B
>=3B >=3B?
>=3B >=3B
>= >=3B >=3B=3D20
>=3B >=3B
>=3B >=3BI can make another later t= >his week.
>=3B >=3B
>=3B >=3B=3D20
>=3B >=3B
>=3B= > >=3BAll you need is a working cm3 on any system.
>=3B >=3B
>= >=3B >=3B>=3BFrom there you can build the whole system=3D2C targeting an= >y system.
>=3B >=3B
>=3B >=3BAs long as that cm3 understands = >LONGINT and your target system.
>=3B >=3B
>=3B >=3BAnd it is = >easier=3D2C but not necessary=3D2C if you have Python. :)
>=3B >=3B<= >BR>>=3B >=3B=3D20
>=3B >=3B
>=3B >=3B - Jay
>=3B >= >=3B
>=3B >=3B=3D20
>=3B >=3B>=3B Date: Tue=3D2C 31 Mar 2009= > 15:43:41 -0500
>=3B >=3B>=3B From: martinbishop at bellsouth.net
= >>=3B >=3B>=3B To: mika at async.caltech.edu
>=3B >=3B>=3B CC: m= >3devel at elegosoft.com
>=3B >=3B>=3B Subject: Re: [M3devel] Help fin= >ding CM3 compiler for Linux?
>=3B >=3B>=3B=3D20
>=3B >=3B&g= >t=3B Not sure if this helps=3D2C but on my linux system:
>=3B >=3B&g= >t=3B=3D20
>=3B >=3B>=3B Critical Mass Modula-3 version d5.7.0
&= >gt=3B >=3B>=3B last updated: 2008-03-16
>=3B >=3B>=3B compiled= >: 2008-08-14 00:56:14
>=3B >=3B>=3B configuration: /usr/local/cm3/= >bin/cm3.cfg
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B Linux thinkp= >ad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009
>=3B >=3B&g= >t=3B i686 GNU/Linux
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B=3D20= >
>=3B >=3B>=3B I don't have the cm3 tarball=3D2C but I do have the= > sources in cm3/ still.
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B = >Mika Nystrom wrote:
>=3B >=3B>=3B >=3B Hello everyone=3D2C
&g= >t=3B >=3B>=3B >=3B=3D20
>=3B >=3B>=3B >=3B This is=3D2C fo= >r me=3D2C a most unfortunate time for the CM3 servers to
>=3B >=3B&g= >t=3B >=3B have crashed. I'm teaching a class using Modula-3=3D2C and we n= >eed a
>=3B >=3B>=3B >=3B compiler... here's the uname of the sys= >tem I'm trying to use:
>=3B >=3B>=3B >=3B=3D20
>=3B >=3B&= >gt=3B >=3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i68= >6 GNU/Lin=3D
>=3B >=3Bux
>=3B >=3B>=3B >=3B=3D20
>= >=3B >=3B>=3B >=3B The most recent archives I have for Linux are:
&= >gt=3B >=3B>=3B >=3B=3D20
>=3B >=3B>=3B >=3B cm3-min-POSIX-= >LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D20
>=3B >=3B>=3B >= >=3B=3D20
>=3B >=3B>=3B >=3B And they don't seem to work on this = >system: I can compile a program
>=3B >=3B>=3B >=3B but when I tr= >y to run it=3D2C it says "Segmentation fault". Can anyone
>=3B >=3B&= >gt=3B >=3B help? (My understanding is that I need 5.5.1 or later...)
&= >gt=3B >=3B>=3B >=3B=3D20
>=3B >=3B>=3B >=3B Mika
>=3B= > >=3B>=3B >=3B=3D20
>=3B >=3B>=3B=3D20
>=3B >=3B
&= >gt=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>=3B >=3BConten= >t-Type: text/html=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfe= >r-Encoding: quoted-printable
>=3B >=3B
>=3B >=3B<=3Bhtml>= >=3B
>=3B >=3B<=3Bhead>=3B
>=3B >=3B<=3Bstyle>=3B
&= >gt=3B >=3B.hmmessage P
>=3B >=3B{
>=3B >=3Bmargin:0px=3D3B<= >BR>>=3B >=3Bpadding:0px
>=3B >=3B}
>=3B >=3Bbody.hmmessag= >e
>=3B >=3B{
>=3B >=3Bfont-size: 10pt=3D3B
>=3B >=3Bfo= >nt-family:Verdana
>=3B >=3B}
>=3B >=3B<=3B/style>=3B
&= >gt=3B >=3B<=3B/head>=3B
>=3B >=3B<=3Bbody class=3D3D'hmmessa= >ge'>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BA href=3D3D"http://modula3.= >elegosoft.com/cm3/uploaded-archives" targ=3D
>=3B >=3Bet=3D3D_blank&= >gt=3B<=3BFONT color=3D3D#0068cf>=3Bhttp://modula3.elegosoft.com/cm3/upl= >oaded=3D
>=3B >=3B-archives<=3B/FONT>=3B<=3B/A>=3B<=3BBR&g= >t=3B
>=3B >=3B?<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3B= >BR>=3B
>=3B >=3BI can make another later this week.<=3BBR>=3B<= >BR>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BAll you need= > is a working cm3 on any system.<=3BBR>=3B
>=3B >=3B>=3BFrom t= >here you can build the whole system=3D2C targeting any system.<=3BBR>= >=3B
>=3B >=3BAs long as that cm3 understands LONGINT and your target= > system.<=3BBR>=3B
>=3B >=3BAnd it is easier=3D2C but not necess= >ary=3D2C if you have Python. :)<=3BBR>=3B
>=3B >=3B&=3Bnbsp= >=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B- Jay<=3BBR>=3B<= >=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3B&=3Bgt=3D3B Date: Tue=3D2C 31 M= >ar 2009 15:43:41 -=3D
>=3B >=3B0500<=3BBR>=3B&=3Bgt=3D3B From= >: martinbishop at bellsouth.net<=3BBR>=3B&=3Bgt=3D3B To: mika at async.ca= >=3D
>=3B >=3Bltech.edu<=3BBR>=3B&=3Bgt=3D3B CC: m3devel at elego= >soft.com<=3BBR>=3B&=3Bgt=3D3B Subject: Re: [M3dev=3D
>=3B >= >=3Bel] Help finding CM3 compiler for Linux?<=3BBR>=3B&=3Bgt=3D3B <= >=3BBR>=3B&=3Bgt=3D3B Not sure if t=3D
>=3B >=3Bhis helps=3D2C b= >ut on my linux system:<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt= >=3D3B Critical Mass Mod=3D
>=3B >=3Bula-3 version d5.7.0<=3BBR>= >=3B&=3Bgt=3D3B last updated: 2008-03-16<=3BBR>=3B&=3Bgt=3D3B comp= >iled:=3D
>=3B >=3B 2008-08-14 00:56:14<=3BBR>=3B&=3Bgt=3D3B c= >onfiguration: /usr/local/cm3/bin/cm3.cfg<=3BBR=3D
>=3B >=3B>=3B&= >amp=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Linux thinkpad 2.6.27-11-generic= > #1 SMP Thu Jan 29 19:24=3D
>=3B >=3B:39 UTC 2009<=3BBR>=3B&= >=3Bgt=3D3B i686 GNU/Linux<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3B= >gt=3D3B <=3BBR>=3B&=3Bgt=3D3B I don=3D
>=3B >=3B't have the c= >m3 tarball=3D2C but I do have the sources in cm3/ still.<=3BBR>=3B&= >=3Bgt=3D
>=3B >=3B=3D3B <=3BBR>=3B&=3Bgt=3D3B Mika Nystrom wr= >ote:<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B Hello everyone=3D2C<=3BBR= >>=3B&=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B <=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B This is=3D2C for me=3D2C a most unfortunate time = >=3D
>=3B >=3Bfor the CM3 servers to<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B have crashed. I'm teaching a class =3D
>=3B >=3Busing Mod= >ula-3=3D2C and we need a<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B compile= >r... here's the una=3D
>=3B >=3Bme of the system I'm trying to use:&= >lt=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B &am= >p=3Bgt=3D3B Linu=3D
>=3B >=3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10= >:53:03 PST 2008 i686 GNU/Linux<=3BBR>=3B&=3Bg=3D
>=3B >=3Bt= >=3D3B &=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B The most r= >ecent archives I have for Linux are=3D
>=3B >=3B:<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B cm3-m= >in-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D
>=3B >=3B-src-all-5.4.0.tgz <= =3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B And they don't seem =3D
>=3B >=3Bto work on this system: = >I can compile a program<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B but when= > I=3D
>=3B >=3B try to run it=3D2C it says "Segmentation fault". Can= > anyone<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D
>=3B >=3B help= >? (My understanding is that I need 5.5.1 or later...)<=3BBR>=3B&=3Bg= >t=3D3B &=3Bgt=3D3B=3D
>=3B >=3B <=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B Mika<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B <=3BBR>=3B&a= >mp=3Bgt=3D3B <=3BBR>=3B<=3B/body>=3B
>=3B >=3B<=3B/html>= >=3B=3D
>=3B >=3B
>=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e= >9204_--
>= > >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_-- From jay.krell at cornell.edu Wed Apr 1 08:13:00 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Apr 2009 06:13:00 +0000 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: <200904010559.n315xIBx071256@camembert.async.caltech.edu> References: Your message of "Wed, 01 Apr 2009 04:31:27 -0000." <200904010559.n315xIBx071256@camembert.async.caltech.edu> Message-ID: Maybe not. Hm. That is bug. There is use with a cvs tree, and use without. I must have broken use without. Try this: export CM3_ROOT=root of cm3 cvs (for me this is /dev2/cm3, for you, maybe $HOME/cm3?) rm $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6 # *Common and *common in one command rm $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/*ommon cp root of cm3 cvs/m3-sys/cminstall/src/config/cm3.cfg $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin The .cfg will delegate out to the cvs tree. I don't like having two copies of files..having to keep them in sync.. Though the archives are meant to work standalone, without CVS. But I don't test that so much oops sorry. That /might/ not be the right file, but it is close. - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Help finding CM3 compiler for Linux? > Date: Tue, 31 Mar 2009 22:59:18 -0700 > From: mika at async.caltech.edu > > > Is there any documentation for this format beyond what you just > wrote? Where? > > terpsichore-14: cm3 > --- building in ../LINUXLIBC6 --- > > new source -> compiling Main.m3 > "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common", line 169: quake runtime error: undefined variable: ROOT > > --procedure-- -line- -file--- > GetM3Back 169 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common > _IsM3BackFlagSupported 181 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common > IsM3BackFlagSupported 193 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common > GetM3BackFlag 197 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common > m3_backend 62 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common > program -- > 6 /afs/.ugcs.caltech.edu/user/mika/test/LINUXLIBC6/m3make.args > > > Fatal Error: procedure "m3_backend" defined in "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3.cfg" failed. > > Jay writes: > >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >These archives do have a different format=2C yes. > > > >But it isn't a bad format. > > > >cminstall is pretty worthless imho. > > > >Extract=2C rename=2C set PATH and LD_LIBRARY_PATH. > > > >=20 > > > > - Jay > > > >=20 > >> To: jay.krell at cornell.edu > >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux?=20 > >> Date: Tue=2C 31 Mar 2009 15:56:11 -0700 > >> From: mika at async.caltech.edu > >>=20 > >> No=2C I'm sorry... > >>=20 > >> the archives do not have the usual format. I'm expecting to unpack > >> and run "cminstall" and then unpack the big source tar on top and=20 > >> build that. But there's no cminstall in the archive on this page. > >> This is "the normal procedure" for installing CM3=2C no? It's what > >> the instructions say to do=2C as well... > >>=20 > >> And the link from the "Download" page is broken (to -d5.5.0.tgz). > >>=20 > >> Mika > >>=20 > >> Jay writes: > >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ > >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> > http://modula3.elegosoft.com/cm3/uploaded-archives > >> > > >> >? > >> > > >> >=3D20 > >> > > >> >I can make another later this week. > >> > > >> >=3D20 > >> > > >> >All you need is a working cm3 on any system. > >> > > >> >>From there you can build the whole system=3D2C targeting any system. > >> > > >> >As long as that cm3 understands LONGINT and your target system. > >> > > >> >And it is easier=3D2C but not necessary=3D2C if you have Python. :) > >> > > >> >=3D20 > >> > > >> > - Jay > >> > > >> >=3D20 > >> >> Date: Tue=3D2C 31 Mar 2009 15:43:41 -0500 > >> >> From: martinbishop at bellsouth.net > >> >> To: mika at async.caltech.edu > >> >> CC: m3devel at elegosoft.com > >> >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? > >> >>=3D20 > >> >> Not sure if this helps=3D2C but on my linux system: > >> >>=3D20 > >> >> Critical Mass Modula-3 version d5.7.0 > >> >> last updated: 2008-03-16 > >> >> compiled: 2008-08-14 00:56:14 > >> >> configuration: /usr/local/cm3/bin/cm3.cfg > >> >>=3D20 > >> >> Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 > >> >> i686 GNU/Linux > >> >>=3D20 > >> >>=3D20 > >> >> I don't have the cm3 tarball=3D2C but I do have the sources in cm3/ st= > >ill. > >> >>=3D20 > >> >> Mika Nystrom wrote: > >> >> > Hello everyone=3D2C > >> >> >=3D20 > >> >> > This is=3D2C for me=3D2C a most unfortunate time for the CM3 servers= > > to > >> >> > have crashed. I'm teaching a class using Modula-3=3D2C and we need a > >> >> > compiler... here's the uname of the system I'm trying to use: > >> >> >=3D20 > >> >> > Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/= > >Lin=3D > >> >ux > >> >> >=3D20 > >> >> > The most recent archives I have for Linux are: > >> >> >=3D20 > >> >> > cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D20 > >> >> >=3D20 > >> >> > And they don't seem to work on this system: I can compile a program > >> >> > but when I try to run it=3D2C it says "Segmentation fault". Can anyo= > >ne > >> >> > help? (My understanding is that I need 5.5.1 or later...) > >> >> >=3D20 > >> >> > Mika > >> >> >=3D20 > >> >>=3D20 > >> > > >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ > >> >Content-Type: text/html=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> > > >> > > >> > > >> > > >> > =3D3B >s" targ=3D > >> >et=3D3D_blank>http://modula3.elegosoft.com/cm3/u= > >ploaded=3D > >> >-archives
> >> >?
> >> > =3D3B
> >> >I can make another later this week.
> >> > =3D3B
> >> >All you need is a working cm3 on any system.
> >> >>From there you can build the whole system=3D2C targeting any system. >> > >> >As long as that cm3 understands LONGINT and your target system.
> >> >And it is easier=3D2C but not necessary=3D2C if you have Python. :)
> >> > =3D3B
> >> > =3D3B- Jay

 =3D3B
>=3D3B Date: Tue=3D2C 31 Mar 2009= > > 15:43:41 -=3D > >> >0500
>=3D3B From: martinbishop at bellsouth.net
>=3D3B To: mika at a= > >sync.ca=3D > >> >ltech.edu
>=3D3B CC: m3devel at elegosoft.com
>=3D3B Subject: Re:= > > [M3dev=3D > >> >el] Help finding CM3 compiler for Linux?
>=3D3B
>=3D3B Not su= > >re if t=3D > >> >his helps=3D2C but on my linux system:
>=3D3B
>=3D3B Critical= > > Mass Mod=3D > >> >ula-3 version d5.7.0
>=3D3B last updated: 2008-03-16
>=3D3B co= > >mpiled:=3D > >> > 2008-08-14 00:56:14
>=3D3B configuration: /usr/local/cm3/bin/cm3.c= > >fg >> >>>=3D3B
>=3D3B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 2= > >9 19:24=3D > >> >:39 UTC 2009
>=3D3B i686 GNU/Linux
>=3D3B
>=3D3B
>= > >=3D3B I don=3D > >> >'t have the cm3 tarball=3D2C but I do have the sources in cm3/ still. >>>=3D > >> >=3D3B
>=3D3B Mika Nystrom wrote:
>=3D3B >=3D3B Hello everyo= > >ne=3D2C
&g=3D > >> >t=3D3B >=3D3B
>=3D3B >=3D3B This is=3D2C for me=3D2C a most un= > >fortunate time =3D > >> >for the CM3 servers to
>=3D3B >=3D3B have crashed. I'm teaching a= > > class =3D > >> >using Modula-3=3D2C and we need a
>=3D3B >=3D3B compiler... here'= > >s the una=3D > >> >me of the system I'm trying to use:
>=3D3B >=3D3B
>=3D3B &g= > >t=3D3B Linu=3D > >> >x lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Linux >>&g=3D > >> >t=3D3B >=3D3B
>=3D3B >=3D3B The most recent archives I have fo= > >r Linux are=3D > >> >:
>=3D3B >=3D3B
>=3D3B >=3D3B cm3-min-POSIX-LINUXLIBC6-5.= > >4.0.tgz cm3=3D > >> >-src-all-5.4.0.tgz
>=3D3B >=3D3B
>=3D3B >=3D3B And they = > >don't seem =3D > >> >to work on this system: I can compile a program
>=3D3B >=3D3B but= > > when I=3D > >> > try to run it=3D2C it says "Segmentation fault". Can anyone
>=3D3B= > > >=3D3B=3D > >> > help? (My understanding is that I need 5.5.1 or later...)
>=3D3B &= > >gt=3D3B=3D > >> >
>=3D3B >=3D3B Mika
>=3D3B >=3D3B
>=3D3B
>> > >> >=3D > >> > > >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_-- > > > >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >These archives do have a different format=2C yes.
> >But it isn't a bad format.
> >cminstall is pretty worthless imho.
> >Extract=2C rename=2C set PATH and LD_LIBRARY_PATH.
> > =3B
> > =3B- Jay

 =3B
>=3B To: jay.krell at cornell.edu
>=3B= > > Subject: Re: [M3devel] Help finding CM3 compiler for Linux?
>=3B Dat= > >e: Tue=2C 31 Mar 2009 15:56:11 -0700
>=3B From: mika at async.caltech.edu= > >
>=3B
>=3B No=2C I'm sorry...
>=3B
>=3B the archives = > >do not have the usual format. I'm expecting to unpack
>=3B and run "cm= > >install" and then unpack the big source tar on top and
>=3B build tha= > >t. But there's no cminstall in the archive on this page.
>=3B This is = > >"the normal procedure" for installing CM3=2C no? It's what
>=3B the in= > >structions say to do=2C as well...
>=3B
>=3B And the link from t= > >he "Download" page is broken (to -d5.5.0.tgz).
>=3B
>=3B Mika >>>=3B
>=3B Jay writes:
>=3B >=3B--_806446ae-8d10-4d74-8eea-5= > >1aa365e9204_
>=3B >=3BContent-Type: text/plain=3B charset=3D"iso-885= > >9-1"
>=3B >=3BContent-Transfer-Encoding: quoted-printable
>=3B = > >>=3B
>=3B >=3B
>=3B >=3B http://modula3.elegosoft.com/cm3/u= > >ploaded-archives
>=3B >=3B
>=3B >=3B?
>=3B >=3B
>= > >=3B >=3B=3D20
>=3B >=3B
>=3B >=3BI can make another later t= > >his week.
>=3B >=3B
>=3B >=3B=3D20
>=3B >=3B
>=3B= > > >=3BAll you need is a working cm3 on any system.
>=3B >=3B
>= > >=3B >=3B>=3BFrom there you can build the whole system=3D2C targeting an= > >y system.
>=3B >=3B
>=3B >=3BAs long as that cm3 understands = > >LONGINT and your target system.
>=3B >=3B
>=3B >=3BAnd it is = > >easier=3D2C but not necessary=3D2C if you have Python. :)
>=3B >=3B<= > >BR>>=3B >=3B=3D20
>=3B >=3B
>=3B >=3B - Jay
>=3B >= > >=3B
>=3B >=3B=3D20
>=3B >=3B>=3B Date: Tue=3D2C 31 Mar 2009= > > 15:43:41 -0500
>=3B >=3B>=3B From: martinbishop at bellsouth.net
= > >>=3B >=3B>=3B To: mika at async.caltech.edu
>=3B >=3B>=3B CC: m= > >3devel at elegosoft.com
>=3B >=3B>=3B Subject: Re: [M3devel] Help fin= > >ding CM3 compiler for Linux?
>=3B >=3B>=3B=3D20
>=3B >=3B&g= > >t=3B Not sure if this helps=3D2C but on my linux system:
>=3B >=3B&g= > >t=3B=3D20
>=3B >=3B>=3B Critical Mass Modula-3 version d5.7.0
&= > >gt=3B >=3B>=3B last updated: 2008-03-16
>=3B >=3B>=3B compiled= > >: 2008-08-14 00:56:14
>=3B >=3B>=3B configuration: /usr/local/cm3/= > >bin/cm3.cfg
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B Linux thinkp= > >ad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009
>=3B >=3B&g= > >t=3B i686 GNU/Linux
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B=3D20= > >
>=3B >=3B>=3B I don't have the cm3 tarball=3D2C but I do have the= > > sources in cm3/ still.
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B = > >Mika Nystrom wrote:
>=3B >=3B>=3B >=3B Hello everyone=3D2C
&g= > >t=3B >=3B>=3B >=3B=3D20
>=3B >=3B>=3B >=3B This is=3D2C fo= > >r me=3D2C a most unfortunate time for the CM3 servers to
>=3B >=3B&g= > >t=3B >=3B have crashed. I'm teaching a class using Modula-3=3D2C and we n= > >eed a
>=3B >=3B>=3B >=3B compiler... here's the uname of the sys= > >tem I'm trying to use:
>=3B >=3B>=3B >=3B=3D20
>=3B >=3B&= > >gt=3B >=3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i68= > >6 GNU/Lin=3D
>=3B >=3Bux
>=3B >=3B>=3B >=3B=3D20
>= > >=3B >=3B>=3B >=3B The most recent archives I have for Linux are:
&= > >gt=3B >=3B>=3B >=3B=3D20
>=3B >=3B>=3B >=3B cm3-min-POSIX-= > >LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D20
>=3B >=3B>=3B >= > >=3B=3D20
>=3B >=3B>=3B >=3B And they don't seem to work on this = > >system: I can compile a program
>=3B >=3B>=3B >=3B but when I tr= > >y to run it=3D2C it says "Segmentation fault". Can anyone
>=3B >=3B&= > >gt=3B >=3B help? (My understanding is that I need 5.5.1 or later...)
&= > >gt=3B >=3B>=3B >=3B=3D20
>=3B >=3B>=3B >=3B Mika
>=3B= > > >=3B>=3B >=3B=3D20
>=3B >=3B>=3B=3D20
>=3B >=3B
&= > >gt=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>=3B >=3BConten= > >t-Type: text/html=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfe= > >r-Encoding: quoted-printable
>=3B >=3B
>=3B >=3B<=3Bhtml>= > >=3B
>=3B >=3B<=3Bhead>=3B
>=3B >=3B<=3Bstyle>=3B
&= > >gt=3B >=3B.hmmessage P
>=3B >=3B{
>=3B >=3Bmargin:0px=3D3B<= > >BR>>=3B >=3Bpadding:0px
>=3B >=3B}
>=3B >=3Bbody.hmmessag= > >e
>=3B >=3B{
>=3B >=3Bfont-size: 10pt=3D3B
>=3B >=3Bfo= > >nt-family:Verdana
>=3B >=3B}
>=3B >=3B<=3B/style>=3B
&= > >gt=3B >=3B<=3B/head>=3B
>=3B >=3B<=3Bbody class=3D3D'hmmessa= > >ge'>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BA href=3D3D"http://modula3.= > >elegosoft.com/cm3/uploaded-archives" targ=3D
>=3B >=3Bet=3D3D_blank&= > >gt=3B<=3BFONT color=3D3D#0068cf>=3Bhttp://modula3.elegosoft.com/cm3/upl= > >oaded=3D
>=3B >=3B-archives<=3B/FONT>=3B<=3B/A>=3B<=3BBR&g= > >t=3B
>=3B >=3B?<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3B= > >BR>=3B
>=3B >=3BI can make another later this week.<=3BBR>=3B<= > >BR>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BAll you need= > > is a working cm3 on any system.<=3BBR>=3B
>=3B >=3B>=3BFrom t= > >here you can build the whole system=3D2C targeting any system.<=3BBR>= > >=3B
>=3B >=3BAs long as that cm3 understands LONGINT and your target= > > system.<=3BBR>=3B
>=3B >=3BAnd it is easier=3D2C but not necess= > >ary=3D2C if you have Python. :)<=3BBR>=3B
>=3B >=3B&=3Bnbsp= > >=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B- Jay<=3BBR>=3B<= > >=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3B&=3Bgt=3D3B Date: Tue=3D2C 31 M= > >ar 2009 15:43:41 -=3D
>=3B >=3B0500<=3BBR>=3B&=3Bgt=3D3B From= > >: martinbishop at bellsouth.net<=3BBR>=3B&=3Bgt=3D3B To: mika at async.ca= > >=3D
>=3B >=3Bltech.edu<=3BBR>=3B&=3Bgt=3D3B CC: m3devel at elego= > >soft.com<=3BBR>=3B&=3Bgt=3D3B Subject: Re: [M3dev=3D
>=3B >= > >=3Bel] Help finding CM3 compiler for Linux?<=3BBR>=3B&=3Bgt=3D3B <= > >=3BBR>=3B&=3Bgt=3D3B Not sure if t=3D
>=3B >=3Bhis helps=3D2C b= > >ut on my linux system:<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt= > >=3D3B Critical Mass Mod=3D
>=3B >=3Bula-3 version d5.7.0<=3BBR>= > >=3B&=3Bgt=3D3B last updated: 2008-03-16<=3BBR>=3B&=3Bgt=3D3B comp= > >iled:=3D
>=3B >=3B 2008-08-14 00:56:14<=3BBR>=3B&=3Bgt=3D3B c= > >onfiguration: /usr/local/cm3/bin/cm3.cfg<=3BBR=3D
>=3B >=3B>=3B&= > >amp=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Linux thinkpad 2.6.27-11-generic= > > #1 SMP Thu Jan 29 19:24=3D
>=3B >=3B:39 UTC 2009<=3BBR>=3B&= > >=3Bgt=3D3B i686 GNU/Linux<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3B= > >gt=3D3B <=3BBR>=3B&=3Bgt=3D3B I don=3D
>=3B >=3B't have the c= > >m3 tarball=3D2C but I do have the sources in cm3/ still.<=3BBR>=3B&= > >=3Bgt=3D
>=3B >=3B=3D3B <=3BBR>=3B&=3Bgt=3D3B Mika Nystrom wr= > >ote:<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B Hello everyone=3D2C<=3BBR= > >>=3B&=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B <=3BBR>=3B&= > >=3Bgt=3D3B &=3Bgt=3D3B This is=3D2C for me=3D2C a most unfortunate time = > >=3D
>=3B >=3Bfor the CM3 servers to<=3BBR>=3B&=3Bgt=3D3B &= > >=3Bgt=3D3B have crashed. I'm teaching a class =3D
>=3B >=3Busing Mod= > >ula-3=3D2C and we need a<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B compile= > >r... here's the una=3D
>=3B >=3Bme of the system I'm trying to use:&= > >lt=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B &am= > >p=3Bgt=3D3B Linu=3D
>=3B >=3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10= > >:53:03 PST 2008 i686 GNU/Linux<=3BBR>=3B&=3Bg=3D
>=3B >=3Bt= > >=3D3B &=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B The most r= > >ecent archives I have for Linux are=3D
>=3B >=3B:<=3BBR>=3B&= > >=3Bgt=3D3B &=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B cm3-m= > >in-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D
>=3B >=3B-src-all-5.4.0.tgz <= > =3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B &= > >=3Bgt=3D3B And they don't seem =3D
>=3B >=3Bto work on this system: = > >I can compile a program<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B but when= > > I=3D
>=3B >=3B try to run it=3D2C it says "Segmentation fault". Can= > > anyone<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D
>=3B >=3B help= > >? (My understanding is that I need 5.5.1 or later...)<=3BBR>=3B&=3Bg= > >t=3D3B &=3Bgt=3D3B=3D
>=3B >=3B <=3BBR>=3B&=3Bgt=3D3B &= > >=3Bgt=3D3B Mika<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B <=3BBR>=3B&a= > >mp=3Bgt=3D3B <=3BBR>=3B<=3B/body>=3B
>=3B >=3B<=3B/html>= > >=3B=3D
>=3B >=3B
>=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e= > >9204_--
> >= > > > >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Apr 1 08:27:22 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 31 Mar 2009 23:27:22 -0700 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: Your message of "Wed, 01 Apr 2009 06:13:00 -0000." Message-ID: <200904010627.n316RM55072294@camembert.async.caltech.edu> Hmm, I'm not sure what you mean? "root of cm3 cvs"? I have lots of Modula-3 installations on my own machines, but I'm just trying to get a system installed for student use on the student systems (which are different)... A working binary dist for Linux is exactly what I'm looking for and this is what you seem to have directed me to, but I don't have a CVS repository... I don't have "m3-sys/cminstall/" etc. Do I need to unpack both the min and std before doing these things? What I'm *used to* is that I unpack the binary distribution, then unpack the sources (or CVS if you like) on top of that, and then compile everything. Which works about 1 time in 3. I think Modula-3 is almost impossible to install if you don't know exactly what to do! (I'm sure I can figure this out with some work.. but is it really meant to be hard to do? I guess it keeps the riff-raff off the M3 mailing lists!) Mika Jay writes: >--_55339e45-8c85-4ab6-9440-0d2131bbad69_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Maybe not. > >Hm. That is bug. There is use with a cvs tree=2C and use without. > >I must have broken use without. > >=20 > >Try this: > >export CM3_ROOT=3Droot of cm3 cvs (for me this is /dev2/cm3=2C > >for you=2C maybe $HOME/cm3?) > >rm $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6 > ># *Common and *common in one command >rm $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/*ommon >cp root of cm3 cvs/m3-sys/cminstall/src/config/cm3.cfg $HOME/cm3/cm3-min-LI= >NUXLIBC6-d5.7.0/bin > >=20 > >The .cfg will delegate out to the cvs tree. > >I don't like having two copies of files..having to keep them in sync.. > > Though the archives are meant to work standalone=2C without CVS. > > But I don't test that so much oops sorry. > >That /might/ not be the right file=2C but it is close. > >=20 > > - Jay > >=20 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux?=20 >> Date: Tue=2C 31 Mar 2009 22:59:18 -0700 >> From: mika at async.caltech.edu >>=20 >>=20 >> Is there any documentation for this format beyond what you just >> wrote? Where? >>=20 >> terpsichore-14: cm3 >> --- building in ../LINUXLIBC6 --- >>=20 >> new source -> compiling Main.m3 >> "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common"=2C= > line 169: quake runtime error: undefined variable: ROOT >>=20 >> --procedure-- -line- -file--- >> GetM3Back 169 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3c= >fg.common >> _IsM3BackFlagSupported 181 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5= >.7.0/bin/Unix.common >> IsM3BackFlagSupported 193 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.= >7.0/bin/Unix.common >> GetM3BackFlag 197 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/= >Unix.common >> m3_backend 62 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix= >.common >> program -- >> 6 /afs/.ugcs.caltech.edu/user/mika/test/LINUXLIBC6/m3make.args >>=20 >>=20 >> Fatal Error: procedure "m3_backend" defined in "/afs/.ugcs/user/mika/cm3/= >cm3-min-LINUXLIBC6-d5.7.0/bin/cm3.cfg" failed. >>=20 >> Jay writes: >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> >These archives do have a different format=3D2C yes. >> > >> >But it isn't a bad format. >> > >> >cminstall is pretty worthless imho. >> > >> >Extract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH. >> > >> >=3D20 >> > >> > - Jay >> > >> >=3D20 >> >> To: jay.krell at cornell.edu >> >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux?=3D20 >> >> Date: Tue=3D2C 31 Mar 2009 15:56:11 -0700 >> >> From: mika at async.caltech.edu >> >>=3D20 >> >> No=3D2C I'm sorry... >> >>=3D20 >> >> the archives do not have the usual format. I'm expecting to unpack >> >> and run "cminstall" and then unpack the big source tar on top and=3D20 >> >> build that. But there's no cminstall in the archive on this page. >> >> This is "the normal procedure" for installing CM3=3D2C no? It's what >> >> the instructions say to do=3D2C as well... >> >>=3D20 >> >> And the link from the "Download" page is broken (to -d5.5.0.tgz). >> >>=3D20 >> >> Mika >> >>=3D20 >> >> Jay writes: >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ >> >> >Content-Type: text/plain=3D3B charset=3D3D"iso-8859-1" >> >> >Content-Transfer-Encoding: quoted-printable >> >> > >> >> > >> >> > http://modula3.elegosoft.com/cm3/uploaded-archives >> >> > >> >> >? >> >> > >> >> >=3D3D20 >> >> > >> >> >I can make another later this week. >> >> > >> >> >=3D3D20 >> >> > >> >> >All you need is a working cm3 on any system. >> >> > >> >> >>From there you can build the whole system=3D3D2C targeting any syste= >m. >> >> > >> >> >As long as that cm3 understands LONGINT and your target system. >> >> > >> >> >And it is easier=3D3D2C but not necessary=3D3D2C if you have Python. = >:) >> >> > >> >> >=3D3D20 >> >> > >> >> > - Jay >> >> > >> >> >=3D3D20 >> >> >> Date: Tue=3D3D2C 31 Mar 2009 15:43:41 -0500 >> >> >> From: martinbishop at bellsouth.net >> >> >> To: mika at async.caltech.edu >> >> >> CC: m3devel at elegosoft.com >> >> >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >> >> >>=3D3D20 >> >> >> Not sure if this helps=3D3D2C but on my linux system: >> >> >>=3D3D20 >> >> >> Critical Mass Modula-3 version d5.7.0 >> >> >> last updated: 2008-03-16 >> >> >> compiled: 2008-08-14 00:56:14 >> >> >> configuration: /usr/local/cm3/bin/cm3.cfg >> >> >>=3D3D20 >> >> >> Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 200= >9 >> >> >> i686 GNU/Linux >> >> >>=3D3D20 >> >> >>=3D3D20 >> >> >> I don't have the cm3 tarball=3D3D2C but I do have the sources in cm= >3/ st=3D >> >ill. >> >> >>=3D3D20 >> >> >> Mika Nystrom wrote: >> >> >> > Hello everyone=3D3D2C >> >> >> >=3D3D20 >> >> >> > This is=3D3D2C for me=3D3D2C a most unfortunate time for the CM3 = >servers=3D >> > to >> >> >> > have crashed. I'm teaching a class using Modula-3=3D3D2C and we n= >eed a >> >> >> > compiler... here's the uname of the system I'm trying to use: >> >> >> >=3D3D20 >> >> >> > Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 G= >NU/=3D >> >Lin=3D3D >> >> >ux >> >> >> >=3D3D20 >> >> >> > The most recent archives I have for Linux are: >> >> >> >=3D3D20 >> >> >> > cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D3D20 >> >> >> >=3D3D20 >> >> >> > And they don't seem to work on this system: I can compile a progr= >am >> >> >> > but when I try to run it=3D3D2C it says "Segmentation fault". Can= > anyo=3D >> >ne >> >> >> > help? (My understanding is that I need 5.5.1 or later...) >> >> >> >=3D3D20 >> >> >> > Mika >> >> >> >=3D3D20 >> >> >>=3D3D20 >> >> > >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ >> >> >Content-Type: text/html=3D3B charset=3D3D"iso-8859-1" >> >> >Content-Transfer-Encoding: quoted-printable >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > =3D3D3Barchive=3D >> >s" targ=3D3D >> >> >et=3D3D3D_blank>http://modula3.elegosoft.co= >m/cm3/u=3D >> >ploaded=3D3D >> >> >-archives
>> >> >?
>> >> > =3D3D3B
>> >> >I can make another later this week.
>> >> > =3D3D3B
>> >> >All you need is a working cm3 on any system.
>> >> >>From there you can build the whole system=3D3D2C targeting any syste= >m.> >> >> >> >As long as that cm3 understands LONGINT and your target system.
>> >> >And it is easier=3D3D2C but not necessary=3D3D2C if you have Python. = >:)
>> >> > =3D3D3B
>> >> > =3D3D3B- Jay

 =3D3D3B
>=3D3D3B Date: Tue=3D3D2C = >31 Mar 2009=3D >> > 15:43:41 -=3D3D >> >> >0500
>=3D3D3B From: martinbishop at bellsouth.net
>=3D3D3B To:= > mika at a=3D >> >sync.ca=3D3D >> >> >ltech.edu
>=3D3D3B CC: m3devel at elegosoft.com
>=3D3D3B Subje= >ct: Re:=3D >> > [M3dev=3D3D >> >> >el] Help finding CM3 compiler for Linux?
>=3D3D3B
>=3D3D3B= > Not su=3D >> >re if t=3D3D >> >> >his helps=3D3D2C but on my linux system:
>=3D3D3B
>=3D3D3B= > Critical=3D >> > Mass Mod=3D3D >> >> >ula-3 version d5.7.0
>=3D3D3B last updated: 2008-03-16
>=3D= >3D3B co=3D >> >mpiled:=3D3D >> >> > 2008-08-14 00:56:14
>=3D3D3B configuration: /usr/local/cm3/bin/= >cm3.c=3D >> >fg> >> >>>=3D3D3B
>=3D3D3B Linux thinkpad 2.6.27-11-generic #1 SMP Th= >u Jan 2=3D >> >9 19:24=3D3D >> >> >:39 UTC 2009
>=3D3D3B i686 GNU/Linux
>=3D3D3B
>=3D3D3= >B
>=3D >> >=3D3D3B I don=3D3D >> >> >'t have the cm3 tarball=3D3D2C but I do have the sources in cm3/ stil= >l.> >>>=3D3D >> >> >=3D3D3B
>=3D3D3B Mika Nystrom wrote:
>=3D3D3B >=3D3D3B H= >ello everyo=3D >> >ne=3D3D2C
&g=3D3D >> >> >t=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B This is=3D3D2C for me= >=3D3D2C a most un=3D >> >fortunate time =3D3D >> >> >for the CM3 servers to
>=3D3D3B >=3D3D3B have crashed. I'm tea= >ching a=3D >> > class =3D3D >> >> >using Modula-3=3D3D2C and we need a
>=3D3D3B >=3D3D3B compiler= >... here'=3D >> >s the una=3D3D >> >> >me of the system I'm trying to use:
>=3D3D3B >=3D3D3B
>= >=3D3D3B &g=3D >> >t=3D3D3B Linu=3D3D >> >> >x lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Linux= >> >>&g=3D3D >> >> >t=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B The most recent archive= >s I have fo=3D >> >r Linux are=3D3D >> >> >:
>=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B cm3-min-POSIX-LI= >NUXLIBC6-5.=3D >> >4.0.tgz cm3=3D3D >> >> >-src-all-5.4.0.tgz
>=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3= >B And they =3D >> >don't seem =3D3D >> >> >to work on this system: I can compile a program
>=3D3D3B >=3D3= >D3B but=3D >> > when I=3D3D >> >> > try to run it=3D3D2C it says "Segmentation fault". Can anyone
>= >=3D3D3B=3D >> > >=3D3D3B=3D3D >> >> > help? (My understanding is that I need 5.5.1 or later...)
>=3D3= >D3B &=3D >> >gt=3D3D3B=3D3D >> >> >
>=3D3D3B >=3D3D3B Mika
>=3D3D3B >=3D3D3B
>=3D3D= >3B
> >> >> >> >=3D3D >> >> > >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_-- >> > >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ >> >Content-Type: text/html=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> > >> > >> > >> > >> >These archives do have a different format=3D2C yes.
>> >But it isn't a bad format.
>> >cminstall is pretty worthless imho.
>> >Extract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.
>> > =3D3B
>> > =3D3B- Jay

 =3D3B
>=3D3B To: jay.krell at cornell.edu<= >BR>>=3D3B=3D >> > Subject: Re: [M3devel] Help finding CM3 compiler for Linux?
>=3D3= >B Dat=3D >> >e: Tue=3D2C 31 Mar 2009 15:56:11 -0700
>=3D3B From: mika at async.calt= >ech.edu=3D >> >
>=3D3B
>=3D3B No=3D2C I'm sorry...
>=3D3B
>=3D3B = >the archives =3D >> >do not have the usual format. I'm expecting to unpack
>=3D3B and ru= >n "cm=3D >> >install" and then unpack the big source tar on top and
>=3D3B buil= >d tha=3D >> >t. But there's no cminstall in the archive on this page.
>=3D3B Thi= >s is =3D >> >"the normal procedure" for installing CM3=3D2C no? It's what
>=3D3B= > the in=3D >> >structions say to do=3D2C as well...
>=3D3B
>=3D3B And the li= >nk from t=3D >> >he "Download" page is broken (to -d5.5.0.tgz).
>=3D3B
>=3D3B = >Mika> >>>=3D3B
>=3D3B Jay writes:
>=3D3B >=3D3B--_806446ae-8d10-= >4d74-8eea-5=3D >> >1aa365e9204_
>=3D3B >=3D3BContent-Type: text/plain=3D3B charset= >=3D3D"iso-885=3D >> >9-1"
>=3D3B >=3D3BContent-Transfer-Encoding: quoted-printable
= >>=3D3B =3D >> >>=3D3B
>=3D3B >=3D3B
>=3D3B >=3D3B http://modula3.elegos= >oft.com/cm3/u=3D >> >ploaded-archives
>=3D3B >=3D3B
>=3D3B >=3D3B?
>=3D3B = >>=3D3B
>=3D >> >=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B
>=3D3B >=3D3BI can mak= >e another later t=3D >> >his week.
>=3D3B >=3D3B
>=3D3B >=3D3B=3D3D20
>=3D3B &= >gt=3D3B
>=3D3B=3D >> > >=3D3BAll you need is a working cm3 on any system.
>=3D3B >=3D= >3B
>=3D >> >=3D3B >=3D3B>=3D3BFrom there you can build the whole system=3D3D2C t= >argeting an=3D >> >y system.
>=3D3B >=3D3B
>=3D3B >=3D3BAs long as that cm3 u= >nderstands =3D >> >LONGINT and your target system.
>=3D3B >=3D3B
>=3D3B >=3D3= >BAnd it is =3D >> >easier=3D3D2C but not necessary=3D3D2C if you have Python. :)
>=3D3= >B >=3D3B<=3D >> >BR>>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B
>=3D3B >=3D3B - = >Jay
>=3D3B >=3D >> >=3D3B
>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B Date: Tue= >=3D3D2C 31 Mar 2009=3D >> > 15:43:41 -0500
>=3D3B >=3D3B>=3D3B From: martinbishop at bellsout= >h.net
=3D >> >>=3D3B >=3D3B>=3D3B To: mika at async.caltech.edu
>=3D3B >=3D3= >B>=3D3B CC: m=3D >> >3devel at elegosoft.com
>=3D3B >=3D3B>=3D3B Subject: Re: [M3devel]= > Help fin=3D >> >ding CM3 compiler for Linux?
>=3D3B >=3D3B>=3D3B=3D3D20
>= >=3D3B >=3D3B&g=3D >> >t=3D3B Not sure if this helps=3D3D2C but on my linux system:
>=3D3B= > >=3D3B&g=3D >> >t=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B Critical Mass Modula-3 versio= >n d5.7.0
&=3D >> >gt=3D3B >=3D3B>=3D3B last updated: 2008-03-16
>=3D3B >=3D3B&g= >t=3D3B compiled=3D >> >: 2008-08-14 00:56:14
>=3D3B >=3D3B>=3D3B configuration: /usr/l= >ocal/cm3/=3D >> >bin/cm3.cfg
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B >=3D3B>= >=3D3B Linux thinkp=3D >> >ad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009
>=3D3B >= >=3D3B&g=3D >> >t=3D3B i686 GNU/Linux
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B &g= >t=3D3B>=3D3B=3D3D20=3D >> >
>=3D3B >=3D3B>=3D3B I don't have the cm3 tarball=3D3D2C but I = >do have the=3D >> > sources in cm3/ still.
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B = >>=3D3B>=3D3B =3D >> >Mika Nystrom wrote:
>=3D3B >=3D3B>=3D3B >=3D3B Hello everyone= >=3D3D2C
&g=3D >> >t=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B >= >=3D3B This is=3D3D2C fo=3D >> >r me=3D3D2C a most unfortunate time for the CM3 servers to
>=3D3B &= >gt=3D3B&g=3D >> >t=3D3B >=3D3B have crashed. I'm teaching a class using Modula-3=3D3D2C= > and we n=3D >> >eed a
>=3D3B >=3D3B>=3D3B >=3D3B compiler... here's the uname= > of the sys=3D >> >tem I'm trying to use:
>=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
&= >gt=3D3B >=3D3B&=3D >> >gt=3D3B >=3D3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2= >008 i68=3D >> >6 GNU/Lin=3D3D
>=3D3B >=3D3Bux
>=3D3B >=3D3B>=3D3B >= >=3D3B=3D3D20
>=3D >> >=3D3B >=3D3B>=3D3B >=3D3B The most recent archives I have for Linu= >x are:
&=3D >> >gt=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B &g= >t=3D3B cm3-min-POSIX-=3D >> >LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D3D20
>=3D3B >=3D3B&g= >t=3D3B >=3D >> >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B >=3D3B And they don't seem t= >o work on this =3D >> >system: I can compile a program
>=3D3B >=3D3B>=3D3B >=3D3B bu= >t when I tr=3D >> >y to run it=3D3D2C it says "Segmentation fault". Can anyone
>=3D3B = >>=3D3B&=3D >> >gt=3D3B >=3D3B help? (My understanding is that I need 5.5.1 or later..= >.)
&=3D >> >gt=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B &g= >t=3D3B Mika
>=3D3B=3D >> > >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B=3D3D20>>=3D3B >=3D3B
&=3D >> >gt=3D3B >=3D3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>=3D3B >= >=3D3BConten=3D >> >t-Type: text/html=3D3B charset=3D3D"iso-8859-1"
>=3D3B >=3D3BCont= >ent-Transfe=3D >> >r-Encoding: quoted-printable
>=3D3B >=3D3B
>=3D3B >=3D3B&l= >t=3D3Bhtml>=3D >> >=3D3B
>=3D3B >=3D3B<=3D3Bhead>=3D3B
>=3D3B >=3D3B<= >=3D3Bstyle>=3D3B
&=3D >> >gt=3D3B >=3D3B.hmmessage P
>=3D3B >=3D3B{
>=3D3B >=3D3Bm= >argin:0px=3D3D3B<=3D >> >BR>>=3D3B >=3D3Bpadding:0px
>=3D3B >=3D3B}
>=3D3B >=3D= >3Bbody.hmmessag=3D >> >e
>=3D3B >=3D3B{
>=3D3B >=3D3Bfont-size: 10pt=3D3D3B
&g= >t=3D3B >=3D3Bfo=3D >> >nt-family:Verdana
>=3D3B >=3D3B}
>=3D3B >=3D3B<=3D3B/sty= >le>=3D3B
&=3D >> >gt=3D3B >=3D3B<=3D3B/head>=3D3B
>=3D3B >=3D3B<=3D3Bbody c= >lass=3D3D3D'hmmessa=3D >> >ge'>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BA href=3D3D3= >D"http://modula3.=3D >> >elegosoft.com/cm3/uploaded-archives" targ=3D3D
>=3D3B >=3D3Bet=3D= >3D3D_blank&=3D >> >gt=3D3B<=3D3BFONT color=3D3D3D#0068cf>=3D3Bhttp://modula3.elegosoft.= >com/cm3/upl=3D >> >oaded=3D3D
>=3D3B >=3D3B-archives<=3D3B/FONT>=3D3B<=3D3B/A&= >gt=3D3B<=3D3BBR&g=3D >> >t=3D3B
>=3D3B >=3D3B?<=3D3BBR>=3D3B
>=3D3B >=3D3B&= >=3D3Bnbsp=3D3D3B<=3D3B=3D >> >BR>=3D3B
>=3D3B >=3D3BI can make another later this week.<=3D= >3BBR>=3D3B<=3D >> >BR>>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
>=3D3B &= >gt=3D3BAll you need=3D >> > is a working cm3 on any system.<=3D3BBR>=3D3B
>=3D3B >=3D3B&= >gt=3D3BFrom t=3D >> >here you can build the whole system=3D3D2C targeting any system.<=3D3B= >BR>=3D >> >=3D3B
>=3D3B >=3D3BAs long as that cm3 understands LONGINT and yo= >ur target=3D >> > system.<=3D3BBR>=3D3B
>=3D3B >=3D3BAnd it is easier=3D3D2C b= >ut not necess=3D >> >ary=3D3D2C if you have Python. :)<=3D3BBR>=3D3B
>=3D3B >=3D3B= >&=3D3Bnbsp=3D >> >=3D3D3B<=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B- Jay&= >lt=3D3BBR>=3D3B<=3D >> >=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B = >Date: Tue=3D3D2C 31 M=3D >> >ar 2009 15:43:41 -=3D3D
>=3D3B >=3D3B0500<=3D3BBR>=3D3B&= >=3D3Bgt=3D3D3B From=3D >> >: martinbishop at bellsouth.net<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B To: mik= >a at async.ca=3D >> >=3D3D
>=3D3B >=3D3Bltech.edu<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B = >CC: m3devel at elego=3D >> >soft.com<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Subject: Re: [M3dev=3D3D>>=3D3B >=3D >> >=3D3Bel] Help finding CM3 compiler for Linux?<=3D3BBR>=3D3B&=3D3B= >gt=3D3D3B <=3D >> >=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Not sure if t=3D3D
>=3D3B >=3D3= >Bhis helps=3D3D2C b=3D >> >ut on my linux system:<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B <=3D3BBR>= >=3D3B&=3D3Bgt=3D >> >=3D3D3B Critical Mass Mod=3D3D
>=3D3B >=3D3Bula-3 version d5.7.0&= >lt=3D3BBR>=3D >> >=3D3B&=3D3Bgt=3D3D3B last updated: 2008-03-16<=3D3BBR>=3D3B&= >=3D3Bgt=3D3D3B comp=3D >> >iled:=3D3D
>=3D3B >=3D3B 2008-08-14 00:56:14<=3D3BBR>=3D3B&am= >p=3D3Bgt=3D3D3B c=3D >> >onfiguration: /usr/local/cm3/bin/cm3.cfg<=3D3BBR=3D3D
>=3D3B >= >=3D3B>=3D3B&=3D >> >amp=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Linux thinkpad 2.= >6.27-11-generic=3D >> > #1 SMP Thu Jan 29 19:24=3D3D
>=3D3B >=3D3B:39 UTC 2009<=3D3BBR= >>=3D3B&=3D >> >=3D3Bgt=3D3D3B i686 GNU/Linux<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B <=3D= >3BBR>=3D3B&=3D3B=3D >> >gt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B I don=3D3D
>=3D3B &g= >t=3D3B't have the c=3D >> >m3 tarball=3D3D2C but I do have the sources in cm3/ still.<=3D3BBR>= >=3D3B&=3D >> >=3D3Bgt=3D3D
>=3D3B >=3D3B=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt= >=3D3D3B Mika Nystrom wr=3D >> >ote:<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B Hello everyo= >ne=3D3D2C<=3D3BBR=3D >> >>=3D3B&=3D3Bg=3D3D
>=3D3B >=3D3Bt=3D3D3B &=3D3Bgt=3D3D3B = ><=3D3BBR>=3D3B&=3D >> >=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B This is=3D3D2C for me=3D3D2C a most un= >fortunate time =3D >> >=3D3D
>=3D3B >=3D3Bfor the CM3 servers to<=3D3BBR>=3D3B&= >=3D3Bgt=3D3D3B &=3D >> >=3D3Bgt=3D3D3B have crashed. I'm teaching a class =3D3D
>=3D3B >= >=3D3Busing Mod=3D >> >ula-3=3D3D2C and we need a<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3B= >gt=3D3D3B compile=3D >> >r... here's the una=3D3D
>=3D3B >=3D3Bme of the system I'm trying= > to use:&=3D >> >lt=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3= >B&=3D3Bgt=3D3D3B &am=3D >> >p=3D3Bgt=3D3D3B Linu=3D3D
>=3D3B >=3D3Bx lara 2.6.24ugcs1 #4 SMP = >Mon Feb 11 10=3D >> >:53:03 PST 2008 i686 GNU/Linux<=3D3BBR>=3D3B&=3D3Bg=3D3D
>= >=3D3B >=3D3Bt=3D >> >=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3= >Bgt=3D3D3B The most r=3D >> >ecent archives I have for Linux are=3D3D
>=3D3B >=3D3B:<=3D3BBR= >>=3D3B&=3D >> >=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &= >amp=3D3Bgt=3D3D3B cm3-m=3D >> >in-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D3D
>=3D3B >=3D3B-src-all-5.4.= >0.tgz <=3D >> =3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&a= >mp=3D3Bgt=3D3D3B &=3D >> >=3D3Bgt=3D3D3B And they don't seem =3D3D
>=3D3B >=3D3Bto work on = >this system: =3D >> >I can compile a program<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt= >=3D3D3B but when=3D >> > I=3D3D
>=3D3B >=3D3B try to run it=3D3D2C it says "Segmentation = >fault". Can=3D >> > anyone<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B=3D3D
&= >gt=3D3B >=3D3B help=3D >> >? (My understanding is that I need 5.5.1 or later...)<=3D3BBR>=3D3B&= >amp=3D3Bg=3D >> >t=3D3D3B &=3D3Bgt=3D3D3B=3D3D
>=3D3B >=3D3B <=3D3BBR>=3D3B= >&=3D3Bgt=3D3D3B &=3D >> >=3D3Bgt=3D3D3B Mika<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D= >3B <=3D3BBR>=3D3B&a=3D >> >mp=3D3Bgt=3D3D3B <=3D3BBR>=3D3B<=3D3B/body>=3D3B
>=3D3B >= >=3D3B<=3D3B/html>=3D >> >=3D3B=3D3D
>=3D3B >=3D3B
>=3D3B >=3D3B--_806446ae-8d10-4d7= >4-8eea-51aa365e=3D >> >9204_--
>> >=3D >> > >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_-- > >--_55339e45-8c85-4ab6-9440-0d2131bbad69_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Maybe not.
>Hm. That is bug. There is use with a cvs tree=2C and use without.
>I must have broken use without.
> =3B
>Try this:
>export CM3_ROOT=3Droot of cm3 cvs (for me this is /dev2/cm3=2C
>for you=2C maybe $HOME/cm3?)
>rm =3B$HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6
># *Common and *common in one command
rm =3B$HOME/cm3/cm3-min-LINUXLI= >BC6-d5.7.0/bin/*ommon
cp root of cm3 cvs/m3-sys/cminstall/src/config/cm3= >.cfg $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin
> =3B
>The .cfg will delegate out to the cvs tree.
>I don't like having two copies of files..having to keep them in sync..
> =3BThough the archives are meant to work standalone=2C without CVS.> > =3B But I don't test that so much oops sorry.
>That /might/ not be the right file=2C but it is close.
> =3B
> =3B- Jay

 =3B
>=3B To: jay.krell at cornell.edu
>=3B= > CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] Help finding CM= >3 compiler for Linux?
>=3B Date: Tue=2C 31 Mar 2009 22:59:18 -0700>>=3B From: mika at async.caltech.edu
>=3B
>=3B
>=3B Is the= >re any documentation for this format beyond what you just
>=3B wrote? = >Where?
>=3B
>=3B terpsichore-14: cm3
>=3B --- building in .= >./LINUXLIBC6 ---
>=3B
>=3B new source ->=3B compiling Main.m3<= >BR>>=3B "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.co= >mmon"=2C line 169: quake runtime error: undefined variable: ROOT
>=3B = >
>=3B --procedure-- -line- -file---
>=3B GetM3Back 169 /afs/.ugcs= >/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common
>=3B _IsM3B= >ackFlagSupported 181 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin= >/Unix.common
>=3B IsM3BackFlagSupported 193 /afs/.ugcs/user/mika/cm3/c= >m3-min-LINUXLIBC6-d5.7.0/bin/Unix.common
>=3B GetM3BackFlag 197 /afs/.= >ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common
>=3B m3_b= >ackend 62 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.commo= >n
>=3B program -- <=3Bbuiltin>=3B
>=3B 6 /afs/.ugcs.caltech.e= >du/user/mika/test/LINUXLIBC6/m3make.args
>=3B
>=3B
>=3B Fa= >tal Error: procedure "m3_backend" defined in "/afs/.ugcs/user/mika/cm3/cm3-= >min-LINUXLIBC6-d5.7.0/bin/cm3.cfg" failed.
>=3B
>=3B Jay writes:= >
>=3B >=3B--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_
>=3B >=3BC= >ontent-Type: text/plain=3B charset=3D"iso-8859-1"
>=3B >=3BContent-T= >ransfer-Encoding: quoted-printable
>=3B >=3B
>=3B >=3B
>= >=3B >=3BThese archives do have a different format=3D2C yes.
>=3B >= >=3B
>=3B >=3BBut it isn't a bad format.
>=3B >=3B
>=3B &= >gt=3Bcminstall is pretty worthless imho.
>=3B >=3B
>=3B >=3BE= >xtract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.
>=3B >=3B
&= >gt=3B >=3B=3D20
>=3B >=3B
>=3B >=3B - Jay
>=3B >=3B<= >BR>>=3B >=3B=3D20
>=3B >=3B>=3B To: jay.krell at cornell.edu
&= >gt=3B >=3B>=3B Subject: Re: [M3devel] Help finding CM3 compiler for Lin= >ux?=3D20
>=3B >=3B>=3B Date: Tue=3D2C 31 Mar 2009 15:56:11 -0700R>>=3B >=3B>=3B From: mika at async.caltech.edu
>=3B >=3B>=3B= >=3D20
>=3B >=3B>=3B No=3D2C I'm sorry...
>=3B >=3B>=3B=3D= >20
>=3B >=3B>=3B the archives do not have the usual format. I'm ex= >pecting to unpack
>=3B >=3B>=3B and run "cminstall" and then unpac= >k the big source tar on top and=3D20
>=3B >=3B>=3B build that. But= > there's no cminstall in the archive on this page.
>=3B >=3B>=3B T= >his is "the normal procedure" for installing CM3=3D2C no? It's what
>= >=3B >=3B>=3B the instructions say to do=3D2C as well...
>=3B >= >=3B>=3B=3D20
>=3B >=3B>=3B And the link from the "Download" page= > is broken (to -d5.5.0.tgz).
>=3B >=3B>=3B=3D20
>=3B >=3B&g= >t=3B Mika
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B Jay writes:>>=3B >=3B>=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>= >=3B >=3B>=3B >=3BContent-Type: text/plain=3D3B charset=3D3D"iso-8859-= >1"
>=3B >=3B>=3B >=3BContent-Transfer-Encoding: quoted-printable= >
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B
>=3B >= >=3B>=3B >=3B http://modula3.elegosoft.com/cm3/uploaded-archives
>= >=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B?
>=3B >=3B>= >=3B >=3B
>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >= >=3B
>=3B >=3B>=3B >=3BI can make another later this week.
>= >=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B=3D3D20
>=3B >= >=3B>=3B >=3B
>=3B >=3B>=3B >=3BAll you need is a working cm3= > on any system.
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B= >>=3BFrom there you can build the whole system=3D3D2C targeting any system= >.
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3BAs long as tha= >t cm3 understands LONGINT and your target system.
>=3B >=3B>=3B &g= >t=3B
>=3B >=3B>=3B >=3BAnd it is easier=3D3D2C but not necessary= >=3D3D2C if you have Python. :)
>=3B >=3B>=3B >=3B
>=3B >= >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B
>=3B >=3B>= >=3B >=3B - Jay
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >= >=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Date: Tue=3D3D2C 31 Mar 2009= > 15:43:41 -0500
>=3B >=3B>=3B >=3B>=3B From: martinbishop at bell= >south.net
>=3B >=3B>=3B >=3B>=3B To: mika at async.caltech.edu>>=3B >=3B>=3B >=3B>=3B CC: m3devel at elegosoft.com
>=3B >= >=3B>=3B >=3B>=3B Subject: Re: [M3devel] Help finding CM3 compiler for= > Linux?
>=3B >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B &= >gt=3B>=3B Not sure if this helps=3D3D2C but on my linux system:
>=3B= > >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Criti= >cal Mass Modula-3 version d5.7.0
>=3B >=3B>=3B >=3B>=3B last u= >pdated: 2008-03-16
>=3B >=3B>=3B >=3B>=3B compiled: 2008-08-14= > 00:56:14
>=3B >=3B>=3B >=3B>=3B configuration: /usr/local/cm3= >/bin/cm3.cfg
>=3B >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>= >=3B >=3B>=3B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:3= >9 UTC 2009
>=3B >=3B>=3B >=3B>=3B i686 GNU/Linux
>=3B >= >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B=3D3D20>>=3B >=3B>=3B >=3B>=3B I don't have the cm3 tarball=3D3D2C but I= > do have the sources in cm3/ st=3D
>=3B >=3Bill.
>=3B >=3B>= >=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Mika Nystrom wr= >ote:
>=3B >=3B>=3B >=3B>=3B >=3B Hello everyone=3D3D2C
&g= >t=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B&= >gt=3B >=3B This is=3D3D2C for me=3D3D2C a most unfortunate time for the C= >M3 servers=3D
>=3B >=3B to
>=3B >=3B>=3B >=3B>=3B >= >=3B have crashed. I'm teaching a class using Modula-3=3D3D2C and we need a<= >BR>>=3B >=3B>=3B >=3B>=3B >=3B compiler... here's the uname of = >the system I'm trying to use:
>=3B >=3B>=3B >=3B>=3B >=3B=3D= >3D20
>=3B >=3B>=3B >=3B>=3B >=3B Linux lara 2.6.24ugcs1 #4 S= >MP Mon Feb 11 10:53:03 PST 2008 i686 GNU/=3D
>=3B >=3BLin=3D3D
&g= >t=3B >=3B>=3B >=3Bux
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D2= >0
>=3B >=3B>=3B >=3B>=3B >=3B The most recent archives I hav= >e for Linux are:
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>= >=3B >=3B>=3B >=3B>=3B >=3B cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3= >-src-all-5.4.0.tgz=3D3D20
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20= >
>=3B >=3B>=3B >=3B>=3B >=3B And they don't seem to work on = >this system: I can compile a program
>=3B >=3B>=3B >=3B>=3B &g= >t=3B but when I try to run it=3D3D2C it says "Segmentation fault". Can anyo= >=3D
>=3B >=3Bne
>=3B >=3B>=3B >=3B>=3B >=3B help? (My= > understanding is that I need 5.5.1 or later...)
>=3B >=3B>=3B >= >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B >=3B Mika
= >>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >= >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >= >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>=3B >=3B>=3B >=3BCo= >ntent-Type: text/html=3D3B charset=3D3D"iso-8859-1"
>=3B >=3B>=3B = >>=3BContent-Transfer-Encoding: quoted-printable
>=3B >=3B>=3B &g= >t=3B
>=3B >=3B>=3B >=3B<=3Bhtml>=3B
>=3B >=3B>=3B &= >gt=3B<=3Bhead>=3B
>=3B >=3B>=3B >=3B<=3Bstyle>=3B
>= >=3B >=3B>=3B >=3B.hmmessage P
>=3B >=3B>=3B >=3B{
>= >=3B >=3B>=3B >=3Bmargin:0px=3D3D3B
>=3B >=3B>=3B >=3Bpaddi= >ng:0px
>=3B >=3B>=3B >=3B}
>=3B >=3B>=3B >=3Bbody.hmm= >essage
>=3B >=3B>=3B >=3B{
>=3B >=3B>=3B >=3Bfont-siz= e: 10pt=3D3D3B
>=3B >=3B>=3B >=3Bfont-family:Verdana
>=3B &= >gt=3B>=3B >=3B}
>=3B >=3B>=3B >=3B<=3B/style>=3B
>= >=3B >=3B>=3B >=3B<=3B/head>=3B
>=3B >=3B>=3B >=3B<= >=3Bbody class=3D3D3D'hmmessage'>=3B
>=3B >=3B>=3B >=3B&=3Bn= >bsp=3D3D3B<=3BA href=3D3D3D"http://modula3.elegosoft.com/cm3/uploaded-arc= >hive=3D
>=3B >=3Bs" targ=3D3D
>=3B >=3B>=3B >=3Bet=3D3D3D= >_blank>=3B<=3BFONT color=3D3D3D#0068cf>=3Bhttp://modula3.elegosoft.co= >m/cm3/u=3D
>=3B >=3Bploaded=3D3D
>=3B >=3B>=3B >=3B-archi= >ves<=3B/FONT>=3B<=3B/A>=3B<=3BBR>=3B
>=3B >=3B>=3B >= >=3B?<=3BBR>=3B
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR&= >gt=3B
>=3B >=3B>=3B >=3BI can make another later this week.<= >=3BBR>=3B
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3BR>>=3B >=3B>=3B >=3BAll you need is a working cm3 on any system.<= >=3BBR>=3B
>=3B >=3B>=3B >=3B>=3BFrom there you can build the= > whole system=3D3D2C targeting any system.<=3BBR=3D
>=3B >=3B>= >=3B
>=3B >=3B>=3B >=3BAs long as that cm3 understands LONGINT an= >d your target system.<=3BBR>=3B
>=3B >=3B>=3B >=3BAnd it is = >easier=3D3D2C but not necessary=3D3D2C if you have Python. :)<=3BBR>=3B= >
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B
>=3B &g= >t=3B>=3B >=3B&=3Bnbsp=3D3D3B- Jay<=3BBR>=3B<=3BBR>=3B&=3B= >nbsp=3D3D3B<=3BBR>=3B&=3Bgt=3D3D3B Date: Tue=3D3D2C 31 Mar 2009=3DR>>=3B >=3B 15:43:41 -=3D3D
>=3B >=3B>=3B >=3B0500<=3BBR&g= >t=3B&=3Bgt=3D3D3B From: martinbishop at bellsouth.net<=3BBR>=3B&=3Bg= >t=3D3D3B To: mika at a=3D
>=3B >=3Bsync.ca=3D3D
>=3B >=3B>=3B = >>=3Bltech.edu<=3BBR>=3B&=3Bgt=3D3D3B CC: m3devel at elegosoft.com<= >=3BBR>=3B&=3Bgt=3D3D3B Subject: Re:=3D
>=3B >=3B [M3dev=3D3D>>=3B >=3B>=3B >=3Bel] Help finding CM3 compiler for Linux?<=3BBR= >>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B Not su=3D
>=3B &= >gt=3Bre if t=3D3D
>=3B >=3B>=3B >=3Bhis helps=3D3D2C but on my l= >inux system:<=3BBR>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B C= >ritical=3D
>=3B >=3B Mass Mod=3D3D
>=3B >=3B>=3B >=3Bula-= >3 version d5.7.0<=3BBR>=3B&=3Bgt=3D3D3B last updated: 2008-03-16<= >=3BBR>=3B&=3Bgt=3D3D3B co=3D
>=3B >=3Bmpiled:=3D3D
>=3B &g= >t=3B>=3B >=3B 2008-08-14 00:56:14<=3BBR>=3B&=3Bgt=3D3D3B configu= >ration: /usr/local/cm3/bin/cm3.c=3D
>=3B >=3Bfg<=3BBR=3D3D
>= >=3B >=3B>=3B >=3B>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3= >B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 2=3D
>=3B >=3B9 19= >:24=3D3D
>=3B >=3B>=3B >=3B:39 UTC 2009<=3BBR>=3B&=3Bgt= >=3D3D3B i686 GNU/Linux<=3BBR>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bg= >t=3D3D3B <=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3D3B I don=3D3D
&= >gt=3B >=3B>=3B >=3B't have the cm3 tarball=3D3D2C but I do have the s= >ources in cm3/ still.<=3BBR=3D
>=3B >=3B>=3B&=3Bgt=3D3D
&g= >t=3B >=3B>=3B >=3B=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B Mika Nystrom= > wrote:<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B Hello everyo=3D
&= >gt=3B >=3Bne=3D3D2C<=3BBR>=3B&=3Bg=3D3D
>=3B >=3B>=3B >= >=3Bt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3= >B This is=3D3D2C for me=3D3D2C a most un=3D
>=3B >=3Bfortunate time = >=3D3D
>=3B >=3B>=3B >=3Bfor the CM3 servers to<=3BBR>=3B&= >=3Bgt=3D3D3B &=3Bgt=3D3D3B have crashed. I'm teaching a=3D
>=3B >= >=3B class =3D3D
>=3B >=3B>=3B >=3Busing Modula-3=3D3D2C and we n= >eed a<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B compiler... here'=3DR>>=3B >=3Bs the una=3D3D
>=3B >=3B>=3B >=3Bme of the system= > I'm trying to use:<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B <=3BBR= >>=3B&=3Bgt=3D3D3B &=3Bg=3D
>=3B >=3Bt=3D3D3B Linu=3D3D
&g= >t=3B >=3B>=3B >=3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2= >008 i686 GNU/Linux<=3BBR=3D
>=3B >=3B>=3B&=3Bg=3D3D
>=3B= > >=3B>=3B >=3Bt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3= >B &=3Bgt=3D3D3B The most recent archives I have fo=3D
>=3B >=3Br = >Linux are=3D3D
>=3B >=3B>=3B >=3B:<=3BBR>=3B&=3Bgt=3D3D3B= > &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B cm3-min-P= OSIX-LINUXLIBC6-5.=3D
>=3B >=3B4.0.tgz cm3=3D3D
>=3B >=3B>= >=3B >=3B-src-all-5.4.0.tgz <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3= >B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B And they =3D
>=3B &g= >t=3Bdon't seem =3D3D
>=3B >=3B>=3B >=3Bto work on this system: I= > can compile a program<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B but= >=3D
>=3B >=3B when I=3D3D
>=3B >=3B>=3B >=3B try to run i= >t=3D3D2C it says "Segmentation fault". Can anyone<=3BBR>=3B&=3Bgt=3D= >3D3B=3D
>=3B >=3B &=3Bgt=3D3D3B=3D3D
>=3B >=3B>=3B >= >=3B help? (My understanding is that I need 5.5.1 or later...)<=3BBR>=3B= >&=3Bgt=3D3D3B &=3B=3D
>=3B >=3Bgt=3D3D3B=3D3D
>=3B >=3B= >>=3B >=3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B Mika<=3BBR&= >gt=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B <= >=3BBR>=3B<=3B/body=3D
>=3B >=3B>=3B
>=3B >=3B>=3B >= >=3B<=3B/html>=3B=3D3D
>=3B >=3B>=3B >=3B
>=3B >=3B>= >=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_--
>=3B >=3B
&g= >t=3B >=3B--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_
>=3B >=3BContent= >-Type: text/html=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer= >-Encoding: quoted-printable
>=3B >=3B
>=3B >=3B<=3Bhtml>= >=3B
>=3B >=3B<=3Bhead>=3B
>=3B >=3B<=3Bstyle>=3B
&= >gt=3B >=3B.hmmessage P
>=3B >=3B{
>=3B >=3Bmargin:0px=3D3B<= >BR>>=3B >=3Bpadding:0px
>=3B >=3B}
>=3B >=3Bbody.hmmessag= >e
>=3B >=3B{
>=3B >=3Bfont-size: 10pt=3D3B
>=3B >=3Bfo= >nt-family:Verdana
>=3B >=3B}
>=3B >=3B<=3B/style>=3B
&= >gt=3B >=3B<=3B/head>=3B
>=3B >=3B<=3Bbody class=3D3D'hmmessa= >ge'>=3B
>=3B >=3BThese archives do have a different format=3D2C ye= >s.<=3BBR>=3B
>=3B >=3BBut it isn't a bad format.<=3BBR>=3BR>>=3B >=3Bcminstall is pretty worthless imho.<=3BBR>=3B
>=3B = >>=3BExtract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.<=3BBR>=3B<= >BR>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp= >=3D3B- Jay<=3BBR>=3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3B&=3B= >gt=3D3B To: jay.krell at cornell.edu<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B = >>=3B Subject: Re: [M3devel] Help finding CM3 compiler for Linux? <=3BBR= >>=3B&=3Bgt=3D3B Dat=3D
>=3B >=3Be: Tue=3D2C 31 Mar 2009 15:56:1= >1 -0700<=3BBR>=3B&=3Bgt=3D3B From: mika at async.caltech.edu=3D
>= >=3B >=3B<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B No=3D2C= > I'm sorry...<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B the = >archives =3D
>=3B >=3Bdo not have the usual format. I'm expecting to= > unpack<=3BBR>=3B&=3Bgt=3D3B and run "cm=3D
>=3B >=3Binstall"= > and then unpack the big source tar on top and <=3BBR>=3B&=3Bgt=3D3B= > build tha=3D
>=3B >=3Bt. But there's no cminstall in the archive on= > this page.<=3BBR>=3B&=3Bgt=3D3B This is =3D
>=3B >=3B"the no= >rmal procedure" for installing CM3=3D2C no? It's what<=3BBR>=3B&=3Bg= >t=3D3B the in=3D
>=3B >=3Bstructions say to do=3D2C as well...<=3B= >BR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B And the link from t=3D<= >BR>>=3B >=3Bhe "Download" page is broken (to -d5.5.0.tgz).<=3BBR>= >=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Mika<=3BBR=3D
>=3B &g= >t=3B>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Jay writes:<=3BBR&g= >t=3B&=3Bgt=3D3B &=3Bgt=3D3B--_806446ae-8d10-4d74-8eea-5=3D
>=3B = >>=3B1aa365e9204_<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BContent-Type: = >text/plain=3D3B charset=3D3D"iso-885=3D
>=3B >=3B9-1"<=3BBR>=3B&= >amp=3Bgt=3D3B &=3Bgt=3D3BContent-Transfer-Encoding: quoted-printable<= >=3BBR>=3B&=3Bgt=3D3B =3D
>=3B >=3B&=3Bgt=3D3B<=3BBR>=3B&= >amp=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B htt= >p://modula3.elegosoft.com/cm3/u=3D
>=3B >=3Bploaded-archives<=3BBR= >>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3B?<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D= >
>=3B >=3B=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &a= >mp=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BI can make another l= >ater t=3D
>=3B >=3Bhis week.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >=3B &= >amp=3Bgt=3D3BAll you need is a working cm3 on any system.<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &= >amp=3Bgt=3D3B&=3Bgt=3D3BFrom there you can build the whole system=3D3D2C= > targeting an=3D
>=3B >=3By system.<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAs long as that cm3 un= >derstands =3D
>=3B >=3BLONGINT and your target system.<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAnd= > it is =3D
>=3B >=3Beasier=3D3D2C but not necessary=3D3D2C if you ha= >ve Python. :)<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3B=3D
>=3B= > >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt= >=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B - Jay<=3B= >BR>=3B&=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B= >&=3Bgt=3D3B Date: Tue=3D3D2C 31 Mar 2009=3D
>=3B >=3B 15:43:41 -0= >500<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B From: martinbi= >shop at bellsouth.net<=3BBR>=3B=3D
>=3B >=3B&=3Bgt=3D3B &=3Bg= >t=3D3B&=3Bgt=3D3B To: mika at async.caltech.edu<=3BBR>=3B&=3Bgt=3D3B= > &=3Bgt=3D3B&=3Bgt=3D3B CC: m=3D
>=3B >=3B3devel at elegosoft.com= ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B Subject: Re: [M3d= >evel] Help fin=3D
>=3B >=3Bding CM3 compiler for Linux?<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bg= >t=3D3B &=3Bgt=3D3B&=3Bg=3D
>=3B >=3Bt=3D3B Not sure if this he= >lps=3D3D2C but on my linux system:<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3B&=3Bg=3D
>=3B >=3Bt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &am= >p=3Bgt=3D3B&=3Bgt=3D3B Critical Mass Modula-3 version d5.7.0<=3BBR>= >=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B last upd= >ated: 2008-03-16<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B c= >ompiled=3D
>=3B >=3B: 2008-08-14 00:56:14<=3BBR>=3B&=3Bgt=3D3= >B &=3Bgt=3D3B&=3Bgt=3D3B configuration: /usr/local/cm3/=3D
>=3B = >>=3Bbin/cm3.cfg<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B= >=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B Linux thin= >kp=3D
>=3B >=3Bad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2= >009<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bg=3D
>=3B >=3Bt= >=3D3B i686 GNU/Linux<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D= >3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20= >=3D
>=3B >=3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D= >3B I don't have the cm3 tarball=3D3D2C but I do have the=3D
>=3B >= >=3B sources in cm3/ still.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B = >=3D
>=3B >=3BMika Nystrom wrote:<=3BBR>=3B&=3Bgt=3D3B &=3B= >gt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B Hello everyone=3D3D2C<=3BBR>=3B&am= >p=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B= >=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt= >=3D3B This is=3D3D2C fo=3D
>=3B >=3Br me=3D3D2C a most unfortunate t= >ime for the CM3 servers to<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B have crashed. I'm teaching a = >class using Modula-3=3D3D2C and we n=3D
>=3B >=3Beed a<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B compiler... here= >'s the uname of the sys=3D
>=3B >=3Btem I'm trying to use:<=3BBR&g= >t=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3B= >BR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3B=3D
>=3B >=3Bgt=3D3B &am= >p=3Bgt=3D3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i68= >=3D
>=3B >=3B6 GNU/Lin=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3Bux<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3= >B=3D3D20<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &=3Bgt=3D3B&= >=3Bgt=3D3B &=3Bgt=3D3B The most recent archives I have for Linux are:<= >=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B = >&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt= >=3D3B &=3Bgt=3D3B cm3-min-POSIX-=3D
>=3B >=3BLINUXLIBC6-5.4.0.tgz= > cm3-src-all-5.4.0.tgz=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&am= >p=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B=3D3D20<=3BBR>=3B&=3Bg= >t=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B And they don't seem to w= >ork on this =3D
>=3B >=3Bsystem: I can compile a program<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B but when I tr= >=3D
>=3B >=3By to run it=3D3D2C it says "Segmentation fault". Can an= >yone<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3B=3D
>=3B >=3Bg= >t=3D3B &=3Bgt=3D3B help? (My understanding is that I need 5.5.1 or later= >...)<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bg= >t=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Bgt=3D3B &=3Bgt=3D3B Mika<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >= >=3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3B= >gt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &am= >p=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B-= >-_806446ae-8d10-4d74-8eea-51aa365e9204_<=3BBR>=3B&=3Bgt=3D3B &=3B= >gt=3D3BConten=3D
>=3B >=3Bt-Type: text/html=3D3B charset=3D3D"iso-88= >59-1"<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BContent-Transfe=3D
>= >=3B >=3Br-Encoding: quoted-printable<=3BBR>=3B&=3Bgt=3D3B &=3Bg= >t=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3Bhtml&=3Bg= >t=3D
>=3B >=3B=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Blt=3D3Bhead&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Blt=3D3Bstyle&=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D= >3B &=3Bgt=3D3B.hmmessage P<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B{&l= >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bmargin:0px=3D3D3B<=3B=3D
>= >=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bpadding:0px<=3BBR>=3B&am= >p=3Bgt=3D3B &=3Bgt=3D3B}<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bbody.= >hmmessag=3D
>=3B >=3Be<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B{&l= >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfont-size: 10pt=3D3D3B<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3Bfo=3D
>=3B >=3Bnt-family:Verdana<= >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B}<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B&=3Blt=3D3B/style&=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>= >=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3B/head&=3Bgt=3D3B<=3BBR&g= >t=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3Bbody class=3D3D3D'hmmessa=3D= >
>=3B >=3Bge'&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BA href=3D3D3D"http://modula3.=3D<= >BR>>=3B >=3Belegosoft.com/cm3/uploaded-archives" targ=3D3D<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3Bet=3D3D3D_blank&=3B=3D
>=3B >=3Bg= >t=3D3B&=3Blt=3D3BFONT color=3D3D3D#0068cf&=3Bgt=3D3Bhttp://modula3.el= >egosoft.com/cm3/upl=3D
>=3B >=3Boaded=3D3D<=3BBR>=3B&=3Bgt=3D= >3B &=3Bgt=3D3B-archives&=3Blt=3D3B/FONT&=3Bgt=3D3B&=3Blt=3D3B/A= >&=3Bgt=3D3B&=3Blt=3D3BBR&=3Bg=3D
>=3B >=3Bt=3D3B<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3B?&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3B=3D= >
>=3B >=3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3= >BI can make another later this week.&=3Blt=3D3BBR&=3Bgt=3D3B<=3B=3D= >
>=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp= >=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3BAll you need=3D
>=3B >=3B is a working cm3 on any system.&= >=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Bgt=3D3BFrom t=3D
>=3B >=3Bhere you can build the whole system=3D3= >D2C targeting any system.&=3Blt=3D3BBR&=3Bgt=3D
>=3B >=3B=3D3B= ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAs long as that cm3 understands = >LONGINT and your target=3D
>=3B >=3B system.&=3Blt=3D3BBR&=3Bg= >t=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAnd it is easier=3D3D2C bu= >t not necess=3D
>=3B >=3Bary=3D3D2C if you have Python. :)&=3Blt= >=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp= >=3D3Bnbsp=3D
>=3B >=3B=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR&= >gt=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B- Jay&=3Blt= >=3D3BBR&=3Bgt=3D3B&=3Blt=3D
>=3B >=3B=3D3BBR&=3Bgt=3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3= >B Date: Tue=3D3D2C 31 M=3D
>=3B >=3Bar 2009 15:43:41 -=3D3D<=3BBR&= >gt=3B&=3Bgt=3D3B &=3Bgt=3D3B0500&=3Blt=3D3BBR&=3Bgt=3D3B&=3B= >amp=3D3Bgt=3D3D3B From=3D
>=3B >=3B: martinbishop at bellsouth.net&= >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B To: mika at async.ca=3D
= >>=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bltech.edu&= >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B CC: m3devel at elego=3D
= >>=3B >=3Bsoft.com&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B= > Subject: Re: [M3dev=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D
>= >=3B >=3B=3D3Bel] Help finding CM3 compiler for Linux?&=3Blt=3D3BBR&= >=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D
>=3B >=3B=3D3BBR&= >=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B Not sure if t=3D3D<=3BBR>=3B&=3Bg= >t=3D3B &=3Bgt=3D3Bhis helps=3D3D2C b=3D
>=3B >=3But on my linux s= >ystem:&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3B= >BR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D
>=3B >=3B=3D3D3B Critical Mass = >Mod=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bula-3 version d5.7.0&= >=3Blt=3D3BBR&=3Bgt=3D
>=3B >=3B=3D3B&=3Bamp=3D3Bgt=3D3D3B last= > updated: 2008-03-16&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B = >comp=3D
>=3B >=3Biled:=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3B 2008-08-14 00:56:14&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3= >B c=3D
>=3B >=3Bonfiguration: /usr/local/cm3/bin/cm3.cfg&=3Blt=3D= >3BBR=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B&=3B= >=3D
>=3B >=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3B= >amp=3D3Bgt=3D3D3B Linux thinkpad 2.6.27-11-generic=3D
>=3B >=3B #1 S= >MP Thu Jan 29 19:24=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B:39 UTC = >2009&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3= >D3B i686 GNU/Linux&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &a= >mp=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3B=3D
>=3B >=3Bgt=3D3D3B &a= >mp=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B I don=3D3D<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3B't have the c=3D
>=3B >=3Bm3 tarball= >=3D3D2C but I do have the sources in cm3/ still.&=3Blt=3D3BBR&=3Bgt= >=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D<=3BBR>=3B&=3Bgt=3D3B= > &=3Bgt=3D3B=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D= >3B Mika Nystrom wr=3D
>=3B >=3Bote:&=3Blt=3D3BBR&=3Bgt=3D3B&am= >p=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B Hello everyone=3D3D2C&=3B= >lt=3D3BBR=3D
>=3B >=3B&=3Bgt=3D3B&=3Bamp=3D3Bg=3D3D<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3Bt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt= >=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D3B &=3Bam= >p=3D3Bgt=3D3D3B This is=3D3D2C for me=3D3D2C a most unfortunate time =3D>>=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfor the CM3 s= >ervers to&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp= >=3D
>=3B >=3B=3D3Bgt=3D3D3B have crashed. I'm teaching a class =3D3D= ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Busing Mod=3D
>=3B >=3Bula= >-3=3D3D2C and we need a&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D= >3B &=3Bamp=3D3Bgt=3D3D3B compile=3D
>=3B >=3Br... here's the una= >=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bme of the system I'm trying= > to use:&=3B=3D
>=3B >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt= >=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp= >=3D3Bgt=3D3D3B &=3Bam=3D
>=3B >=3Bp=3D3Bgt=3D3D3B Linu=3D3D<=3B= >BR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 1= >0=3D
>=3B >=3B:53:03 PST 2008 i686 GNU/Linux&=3Blt=3D3BBR&=3Bg= >t=3D3B&=3Bamp=3D3Bg=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bt=3D<= >BR>>=3B >=3B=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt= >=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B The most r=3D
>= >=3B >=3Becent archives I have for Linux are=3D3D<=3BBR>=3B&=3Bgt= >=3D3B &=3Bgt=3D3B:&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B = >>=3B=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3= >B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B cm3-m=3D
>=3B >= >=3Bin-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D3D<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B-src-all-5.4.0.tgz &=3Blt=3D
>=3B =3D3BBR&=3Bgt=3D3B&a= >mp=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt= >=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D3B = >And they don't seem =3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bto work= > on this system: =3D
>=3B >=3BI can compile a program&=3Blt=3D3BB= >R&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B but when= >=3D
>=3B >=3B I=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B try = >to run it=3D3D2C it says "Segmentation fault". Can=3D
>=3B >=3B anyo= >ne&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt= >=3D3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B help=3D
>=3B &= >gt=3B? (My understanding is that I need 5.5.1 or later...)&=3Blt=3D3BBR&= >amp=3Bgt=3D3B&=3Bamp=3D3Bg=3D
>=3B >=3Bt=3D3D3B &=3Bamp=3D3Bgt= >=3D3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B &=3Blt=3D3BBR&am= >p=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D
>=3B >=3B=3D3Bgt= >=3D3D3B Mika&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Ba= >mp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Ba=3D
>=3B >=3B= >mp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Blt=3D3B/body&=3Bgt= >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3B/html&=3Bg= >t=3D
>=3B >=3B=3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >lt=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B--_806446ae-8d10-4d74-8eea-51aa36= >5e=3D
>=3B >=3B9204_--<=3BBR>=3B<=3B/body>=3B
>=3B >= >=3B<=3B/html>=3B=3D
>=3B >=3B
>=3B >=3B--_777fdc4e-3c29-4= >0b4-a3dd-e6243f796cee_--
>= > >--_55339e45-8c85-4ab6-9440-0d2131bbad69_-- From mika at async.caltech.edu Wed Apr 1 08:53:38 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 31 Mar 2009 23:53:38 -0700 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: Your message of "Wed, 01 Apr 2009 06:13:00 -0000." Message-ID: <200904010653.n316rcZs073236@camembert.async.caltech.edu> To be honest, I'm not so sure what's intended. I either get this: "/home/mika/cm3/cm3-std-LINUXLIBC6-d5.7.0/bin/cm3.cfg", line 125: quake runtime error: unable to find a configuration file for (/home/mika/cm3/cm3-std-LINUXLIBC6-d5.7.0/bin/.., /afs/.ugcs/user/mika/cm3/cm3-std-LINUXLIBC6-d5.7.0, LINUXLIBC6) or, if I put back the LINUXLIBC6 file you had me delete: "/home/mika/cm3/cm3-std-LINUXLIBC6-d5.7.0/bin/cm3.cfg", line 128: quake runtime error: /home/mika/cm3/cm3-std-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6, line 61: syntax error: missing: <*EOF*> (found: ) which refers to the following (which looks like cminstall stuff to me): INITIAL_REACTOR_EDITOR = BEGIN_CONFIG "What should be the default text editor for new Reactor users?" <--- this line 10 "EDITOR" 0 "emacsclient" 0 "emacs" 0 "vi" 0 "textedit" 0 "xedit" 6 "/usr/local/emacs/bin" "emacsclient" 6 "/usr/local/bin" "emacsclient" 6 "/usr/local/emacs/bin" "emacs" 6 "/usr/local/bin" "emacs" 6 "/usr/bin" "vi" 6 "/usr/local/X11R5/bin" "xedit" 6 "/usr/openwin/bin" "textedit" Jay writes: >--_55339e45-8c85-4ab6-9440-0d2131bbad69_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Maybe not. > >Hm. That is bug. There is use with a cvs tree=2C and use without. > >I must have broken use without. > >=20 > >Try this: > >export CM3_ROOT=3Droot of cm3 cvs (for me this is /dev2/cm3=2C > >for you=2C maybe $HOME/cm3?) > >rm $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6 > ># *Common and *common in one command >rm $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/*ommon >cp root of cm3 cvs/m3-sys/cminstall/src/config/cm3.cfg $HOME/cm3/cm3-min-LI= >NUXLIBC6-d5.7.0/bin > >=20 > >The .cfg will delegate out to the cvs tree. > >I don't like having two copies of files..having to keep them in sync.. > > Though the archives are meant to work standalone=2C without CVS. > > But I don't test that so much oops sorry. > >That /might/ not be the right file=2C but it is close. > >=20 > > - Jay > >=20 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux?=20 >> Date: Tue=2C 31 Mar 2009 22:59:18 -0700 >> From: mika at async.caltech.edu >>=20 >>=20 >> Is there any documentation for this format beyond what you just >> wrote? Where? >>=20 >> terpsichore-14: cm3 >> --- building in ../LINUXLIBC6 --- >>=20 >> new source -> compiling Main.m3 >> "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common"=2C= > line 169: quake runtime error: undefined variable: ROOT >>=20 >> --procedure-- -line- -file--- >> GetM3Back 169 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3c= >fg.common >> _IsM3BackFlagSupported 181 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5= >.7.0/bin/Unix.common >> IsM3BackFlagSupported 193 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.= >7.0/bin/Unix.common >> GetM3BackFlag 197 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/= >Unix.common >> m3_backend 62 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix= >.common >> program -- >> 6 /afs/.ugcs.caltech.edu/user/mika/test/LINUXLIBC6/m3make.args >>=20 >>=20 >> Fatal Error: procedure "m3_backend" defined in "/afs/.ugcs/user/mika/cm3/= >cm3-min-LINUXLIBC6-d5.7.0/bin/cm3.cfg" failed. >>=20 >> Jay writes: >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> >These archives do have a different format=3D2C yes. >> > >> >But it isn't a bad format. >> > >> >cminstall is pretty worthless imho. >> > >> >Extract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH. >> > >> >=3D20 >> > >> > - Jay >> > >> >=3D20 >> >> To: jay.krell at cornell.edu >> >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux?=3D20 >> >> Date: Tue=3D2C 31 Mar 2009 15:56:11 -0700 >> >> From: mika at async.caltech.edu >> >>=3D20 >> >> No=3D2C I'm sorry... >> >>=3D20 >> >> the archives do not have the usual format. I'm expecting to unpack >> >> and run "cminstall" and then unpack the big source tar on top and=3D20 >> >> build that. But there's no cminstall in the archive on this page. >> >> This is "the normal procedure" for installing CM3=3D2C no? It's what >> >> the instructions say to do=3D2C as well... >> >>=3D20 >> >> And the link from the "Download" page is broken (to -d5.5.0.tgz). >> >>=3D20 >> >> Mika >> >>=3D20 >> >> Jay writes: >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ >> >> >Content-Type: text/plain=3D3B charset=3D3D"iso-8859-1" >> >> >Content-Transfer-Encoding: quoted-printable >> >> > >> >> > >> >> > http://modula3.elegosoft.com/cm3/uploaded-archives >> >> > >> >> >? >> >> > >> >> >=3D3D20 >> >> > >> >> >I can make another later this week. >> >> > >> >> >=3D3D20 >> >> > >> >> >All you need is a working cm3 on any system. >> >> > >> >> >>From there you can build the whole system=3D3D2C targeting any syste= >m. >> >> > >> >> >As long as that cm3 understands LONGINT and your target system. >> >> > >> >> >And it is easier=3D3D2C but not necessary=3D3D2C if you have Python. = >:) >> >> > >> >> >=3D3D20 >> >> > >> >> > - Jay >> >> > >> >> >=3D3D20 >> >> >> Date: Tue=3D3D2C 31 Mar 2009 15:43:41 -0500 >> >> >> From: martinbishop at bellsouth.net >> >> >> To: mika at async.caltech.edu >> >> >> CC: m3devel at elegosoft.com >> >> >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >> >> >>=3D3D20 >> >> >> Not sure if this helps=3D3D2C but on my linux system: >> >> >>=3D3D20 >> >> >> Critical Mass Modula-3 version d5.7.0 >> >> >> last updated: 2008-03-16 >> >> >> compiled: 2008-08-14 00:56:14 >> >> >> configuration: /usr/local/cm3/bin/cm3.cfg >> >> >>=3D3D20 >> >> >> Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 200= >9 >> >> >> i686 GNU/Linux >> >> >>=3D3D20 >> >> >>=3D3D20 >> >> >> I don't have the cm3 tarball=3D3D2C but I do have the sources in cm= >3/ st=3D >> >ill. >> >> >>=3D3D20 >> >> >> Mika Nystrom wrote: >> >> >> > Hello everyone=3D3D2C >> >> >> >=3D3D20 >> >> >> > This is=3D3D2C for me=3D3D2C a most unfortunate time for the CM3 = >servers=3D >> > to >> >> >> > have crashed. I'm teaching a class using Modula-3=3D3D2C and we n= >eed a >> >> >> > compiler... here's the uname of the system I'm trying to use: >> >> >> >=3D3D20 >> >> >> > Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 G= >NU/=3D >> >Lin=3D3D >> >> >ux >> >> >> >=3D3D20 >> >> >> > The most recent archives I have for Linux are: >> >> >> >=3D3D20 >> >> >> > cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D3D20 >> >> >> >=3D3D20 >> >> >> > And they don't seem to work on this system: I can compile a progr= >am >> >> >> > but when I try to run it=3D3D2C it says "Segmentation fault". Can= > anyo=3D >> >ne >> >> >> > help? (My understanding is that I need 5.5.1 or later...) >> >> >> >=3D3D20 >> >> >> > Mika >> >> >> >=3D3D20 >> >> >>=3D3D20 >> >> > >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ >> >> >Content-Type: text/html=3D3B charset=3D3D"iso-8859-1" >> >> >Content-Transfer-Encoding: quoted-printable >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > =3D3D3Barchive=3D >> >s" targ=3D3D >> >> >et=3D3D3D_blank>http://modula3.elegosoft.co= >m/cm3/u=3D >> >ploaded=3D3D >> >> >-archives
>> >> >?
>> >> > =3D3D3B
>> >> >I can make another later this week.
>> >> > =3D3D3B
>> >> >All you need is a working cm3 on any system.
>> >> >>From there you can build the whole system=3D3D2C targeting any syste= >m.> >> >> >> >As long as that cm3 understands LONGINT and your target system.
>> >> >And it is easier=3D3D2C but not necessary=3D3D2C if you have Python. = >:)
>> >> > =3D3D3B
>> >> > =3D3D3B- Jay

 =3D3D3B
>=3D3D3B Date: Tue=3D3D2C = >31 Mar 2009=3D >> > 15:43:41 -=3D3D >> >> >0500
>=3D3D3B From: martinbishop at bellsouth.net
>=3D3D3B To:= > mika at a=3D >> >sync.ca=3D3D >> >> >ltech.edu
>=3D3D3B CC: m3devel at elegosoft.com
>=3D3D3B Subje= >ct: Re:=3D >> > [M3dev=3D3D >> >> >el] Help finding CM3 compiler for Linux?
>=3D3D3B
>=3D3D3B= > Not su=3D >> >re if t=3D3D >> >> >his helps=3D3D2C but on my linux system:
>=3D3D3B
>=3D3D3B= > Critical=3D >> > Mass Mod=3D3D >> >> >ula-3 version d5.7.0
>=3D3D3B last updated: 2008-03-16
>=3D= >3D3B co=3D >> >mpiled:=3D3D >> >> > 2008-08-14 00:56:14
>=3D3D3B configuration: /usr/local/cm3/bin/= >cm3.c=3D >> >fg> >> >>>=3D3D3B
>=3D3D3B Linux thinkpad 2.6.27-11-generic #1 SMP Th= >u Jan 2=3D >> >9 19:24=3D3D >> >> >:39 UTC 2009
>=3D3D3B i686 GNU/Linux
>=3D3D3B
>=3D3D3= >B
>=3D >> >=3D3D3B I don=3D3D >> >> >'t have the cm3 tarball=3D3D2C but I do have the sources in cm3/ stil= >l.> >>>=3D3D >> >> >=3D3D3B
>=3D3D3B Mika Nystrom wrote:
>=3D3D3B >=3D3D3B H= >ello everyo=3D >> >ne=3D3D2C
&g=3D3D >> >> >t=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B This is=3D3D2C for me= >=3D3D2C a most un=3D >> >fortunate time =3D3D >> >> >for the CM3 servers to
>=3D3D3B >=3D3D3B have crashed. I'm tea= >ching a=3D >> > class =3D3D >> >> >using Modula-3=3D3D2C and we need a
>=3D3D3B >=3D3D3B compiler= >... here'=3D >> >s the una=3D3D >> >> >me of the system I'm trying to use:
>=3D3D3B >=3D3D3B
>= >=3D3D3B &g=3D >> >t=3D3D3B Linu=3D3D >> >> >x lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Linux= >> >>&g=3D3D >> >> >t=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B The most recent archive= >s I have fo=3D >> >r Linux are=3D3D >> >> >:
>=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B cm3-min-POSIX-LI= >NUXLIBC6-5.=3D >> >4.0.tgz cm3=3D3D >> >> >-src-all-5.4.0.tgz
>=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3= >B And they =3D >> >don't seem =3D3D >> >> >to work on this system: I can compile a program
>=3D3D3B >=3D3= >D3B but=3D >> > when I=3D3D >> >> > try to run it=3D3D2C it says "Segmentation fault". Can anyone
>= >=3D3D3B=3D >> > >=3D3D3B=3D3D >> >> > help? (My understanding is that I need 5.5.1 or later...)
>=3D3= >D3B &=3D >> >gt=3D3D3B=3D3D >> >> >
>=3D3D3B >=3D3D3B Mika
>=3D3D3B >=3D3D3B
>=3D3D= >3B
> >> >> >> >=3D3D >> >> > >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_-- >> > >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ >> >Content-Type: text/html=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> > >> > >> > >> > >> >These archives do have a different format=3D2C yes.
>> >But it isn't a bad format.
>> >cminstall is pretty worthless imho.
>> >Extract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.
>> > =3D3B
>> > =3D3B- Jay

 =3D3B
>=3D3B To: jay.krell at cornell.edu<= >BR>>=3D3B=3D >> > Subject: Re: [M3devel] Help finding CM3 compiler for Linux?
>=3D3= >B Dat=3D >> >e: Tue=3D2C 31 Mar 2009 15:56:11 -0700
>=3D3B From: mika at async.calt= >ech.edu=3D >> >
>=3D3B
>=3D3B No=3D2C I'm sorry...
>=3D3B
>=3D3B = >the archives =3D >> >do not have the usual format. I'm expecting to unpack
>=3D3B and ru= >n "cm=3D >> >install" and then unpack the big source tar on top and
>=3D3B buil= >d tha=3D >> >t. But there's no cminstall in the archive on this page.
>=3D3B Thi= >s is =3D >> >"the normal procedure" for installing CM3=3D2C no? It's what
>=3D3B= > the in=3D >> >structions say to do=3D2C as well...
>=3D3B
>=3D3B And the li= >nk from t=3D >> >he "Download" page is broken (to -d5.5.0.tgz).
>=3D3B
>=3D3B = >Mika> >>>=3D3B
>=3D3B Jay writes:
>=3D3B >=3D3B--_806446ae-8d10-= >4d74-8eea-5=3D >> >1aa365e9204_
>=3D3B >=3D3BContent-Type: text/plain=3D3B charset= >=3D3D"iso-885=3D >> >9-1"
>=3D3B >=3D3BContent-Transfer-Encoding: quoted-printable
= >>=3D3B =3D >> >>=3D3B
>=3D3B >=3D3B
>=3D3B >=3D3B http://modula3.elegos= >oft.com/cm3/u=3D >> >ploaded-archives
>=3D3B >=3D3B
>=3D3B >=3D3B?
>=3D3B = >>=3D3B
>=3D >> >=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B
>=3D3B >=3D3BI can mak= >e another later t=3D >> >his week.
>=3D3B >=3D3B
>=3D3B >=3D3B=3D3D20
>=3D3B &= >gt=3D3B
>=3D3B=3D >> > >=3D3BAll you need is a working cm3 on any system.
>=3D3B >=3D= >3B
>=3D >> >=3D3B >=3D3B>=3D3BFrom there you can build the whole system=3D3D2C t= >argeting an=3D >> >y system.
>=3D3B >=3D3B
>=3D3B >=3D3BAs long as that cm3 u= >nderstands =3D >> >LONGINT and your target system.
>=3D3B >=3D3B
>=3D3B >=3D3= >BAnd it is =3D >> >easier=3D3D2C but not necessary=3D3D2C if you have Python. :)
>=3D3= >B >=3D3B<=3D >> >BR>>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B
>=3D3B >=3D3B - = >Jay
>=3D3B >=3D >> >=3D3B
>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B Date: Tue= >=3D3D2C 31 Mar 2009=3D >> > 15:43:41 -0500
>=3D3B >=3D3B>=3D3B From: martinbishop at bellsout= >h.net
=3D >> >>=3D3B >=3D3B>=3D3B To: mika at async.caltech.edu
>=3D3B >=3D3= >B>=3D3B CC: m=3D >> >3devel at elegosoft.com
>=3D3B >=3D3B>=3D3B Subject: Re: [M3devel]= > Help fin=3D >> >ding CM3 compiler for Linux?
>=3D3B >=3D3B>=3D3B=3D3D20
>= >=3D3B >=3D3B&g=3D >> >t=3D3B Not sure if this helps=3D3D2C but on my linux system:
>=3D3B= > >=3D3B&g=3D >> >t=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B Critical Mass Modula-3 versio= >n d5.7.0
&=3D >> >gt=3D3B >=3D3B>=3D3B last updated: 2008-03-16
>=3D3B >=3D3B&g= >t=3D3B compiled=3D >> >: 2008-08-14 00:56:14
>=3D3B >=3D3B>=3D3B configuration: /usr/l= >ocal/cm3/=3D >> >bin/cm3.cfg
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B >=3D3B>= >=3D3B Linux thinkp=3D >> >ad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009
>=3D3B >= >=3D3B&g=3D >> >t=3D3B i686 GNU/Linux
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B &g= >t=3D3B>=3D3B=3D3D20=3D >> >
>=3D3B >=3D3B>=3D3B I don't have the cm3 tarball=3D3D2C but I = >do have the=3D >> > sources in cm3/ still.
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B = >>=3D3B>=3D3B =3D >> >Mika Nystrom wrote:
>=3D3B >=3D3B>=3D3B >=3D3B Hello everyone= >=3D3D2C
&g=3D >> >t=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B >= >=3D3B This is=3D3D2C fo=3D >> >r me=3D3D2C a most unfortunate time for the CM3 servers to
>=3D3B &= >gt=3D3B&g=3D >> >t=3D3B >=3D3B have crashed. I'm teaching a class using Modula-3=3D3D2C= > and we n=3D >> >eed a
>=3D3B >=3D3B>=3D3B >=3D3B compiler... here's the uname= > of the sys=3D >> >tem I'm trying to use:
>=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
&= >gt=3D3B >=3D3B&=3D >> >gt=3D3B >=3D3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2= >008 i68=3D >> >6 GNU/Lin=3D3D
>=3D3B >=3D3Bux
>=3D3B >=3D3B>=3D3B >= >=3D3B=3D3D20
>=3D >> >=3D3B >=3D3B>=3D3B >=3D3B The most recent archives I have for Linu= >x are:
&=3D >> >gt=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B &g= >t=3D3B cm3-min-POSIX-=3D >> >LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D3D20
>=3D3B >=3D3B&g= >t=3D3B >=3D >> >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B >=3D3B And they don't seem t= >o work on this =3D >> >system: I can compile a program
>=3D3B >=3D3B>=3D3B >=3D3B bu= >t when I tr=3D >> >y to run it=3D3D2C it says "Segmentation fault". Can anyone
>=3D3B = >>=3D3B&=3D >> >gt=3D3B >=3D3B help? (My understanding is that I need 5.5.1 or later..= >.)
&=3D >> >gt=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B &g= >t=3D3B Mika
>=3D3B=3D >> > >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B=3D3D20>>=3D3B >=3D3B
&=3D >> >gt=3D3B >=3D3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>=3D3B >= >=3D3BConten=3D >> >t-Type: text/html=3D3B charset=3D3D"iso-8859-1"
>=3D3B >=3D3BCont= >ent-Transfe=3D >> >r-Encoding: quoted-printable
>=3D3B >=3D3B
>=3D3B >=3D3B&l= >t=3D3Bhtml>=3D >> >=3D3B
>=3D3B >=3D3B<=3D3Bhead>=3D3B
>=3D3B >=3D3B<= >=3D3Bstyle>=3D3B
&=3D >> >gt=3D3B >=3D3B.hmmessage P
>=3D3B >=3D3B{
>=3D3B >=3D3Bm= >argin:0px=3D3D3B<=3D >> >BR>>=3D3B >=3D3Bpadding:0px
>=3D3B >=3D3B}
>=3D3B >=3D= >3Bbody.hmmessag=3D >> >e
>=3D3B >=3D3B{
>=3D3B >=3D3Bfont-size: 10pt=3D3D3B
&g= >t=3D3B >=3D3Bfo=3D >> >nt-family:Verdana
>=3D3B >=3D3B}
>=3D3B >=3D3B<=3D3B/sty= >le>=3D3B
&=3D >> >gt=3D3B >=3D3B<=3D3B/head>=3D3B
>=3D3B >=3D3B<=3D3Bbody c= >lass=3D3D3D'hmmessa=3D >> >ge'>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BA href=3D3D3= >D"http://modula3.=3D >> >elegosoft.com/cm3/uploaded-archives" targ=3D3D
>=3D3B >=3D3Bet=3D= >3D3D_blank&=3D >> >gt=3D3B<=3D3BFONT color=3D3D3D#0068cf>=3D3Bhttp://modula3.elegosoft.= >com/cm3/upl=3D >> >oaded=3D3D
>=3D3B >=3D3B-archives<=3D3B/FONT>=3D3B<=3D3B/A&= >gt=3D3B<=3D3BBR&g=3D >> >t=3D3B
>=3D3B >=3D3B?<=3D3BBR>=3D3B
>=3D3B >=3D3B&= >=3D3Bnbsp=3D3D3B<=3D3B=3D >> >BR>=3D3B
>=3D3B >=3D3BI can make another later this week.<=3D= >3BBR>=3D3B<=3D >> >BR>>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
>=3D3B &= >gt=3D3BAll you need=3D >> > is a working cm3 on any system.<=3D3BBR>=3D3B
>=3D3B >=3D3B&= >gt=3D3BFrom t=3D >> >here you can build the whole system=3D3D2C targeting any system.<=3D3B= >BR>=3D >> >=3D3B
>=3D3B >=3D3BAs long as that cm3 understands LONGINT and yo= >ur target=3D >> > system.<=3D3BBR>=3D3B
>=3D3B >=3D3BAnd it is easier=3D3D2C b= >ut not necess=3D >> >ary=3D3D2C if you have Python. :)<=3D3BBR>=3D3B
>=3D3B >=3D3B= >&=3D3Bnbsp=3D >> >=3D3D3B<=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B- Jay&= >lt=3D3BBR>=3D3B<=3D >> >=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B = >Date: Tue=3D3D2C 31 M=3D >> >ar 2009 15:43:41 -=3D3D
>=3D3B >=3D3B0500<=3D3BBR>=3D3B&= >=3D3Bgt=3D3D3B From=3D >> >: martinbishop at bellsouth.net<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B To: mik= >a at async.ca=3D >> >=3D3D
>=3D3B >=3D3Bltech.edu<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B = >CC: m3devel at elego=3D >> >soft.com<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Subject: Re: [M3dev=3D3D>>=3D3B >=3D >> >=3D3Bel] Help finding CM3 compiler for Linux?<=3D3BBR>=3D3B&=3D3B= >gt=3D3D3B <=3D >> >=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Not sure if t=3D3D
>=3D3B >=3D3= >Bhis helps=3D3D2C b=3D >> >ut on my linux system:<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B <=3D3BBR>= >=3D3B&=3D3Bgt=3D >> >=3D3D3B Critical Mass Mod=3D3D
>=3D3B >=3D3Bula-3 version d5.7.0&= >lt=3D3BBR>=3D >> >=3D3B&=3D3Bgt=3D3D3B last updated: 2008-03-16<=3D3BBR>=3D3B&= >=3D3Bgt=3D3D3B comp=3D >> >iled:=3D3D
>=3D3B >=3D3B 2008-08-14 00:56:14<=3D3BBR>=3D3B&am= >p=3D3Bgt=3D3D3B c=3D >> >onfiguration: /usr/local/cm3/bin/cm3.cfg<=3D3BBR=3D3D
>=3D3B >= >=3D3B>=3D3B&=3D >> >amp=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Linux thinkpad 2.= >6.27-11-generic=3D >> > #1 SMP Thu Jan 29 19:24=3D3D
>=3D3B >=3D3B:39 UTC 2009<=3D3BBR= >>=3D3B&=3D >> >=3D3Bgt=3D3D3B i686 GNU/Linux<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B <=3D= >3BBR>=3D3B&=3D3B=3D >> >gt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B I don=3D3D
>=3D3B &g= >t=3D3B't have the c=3D >> >m3 tarball=3D3D2C but I do have the sources in cm3/ still.<=3D3BBR>= >=3D3B&=3D >> >=3D3Bgt=3D3D
>=3D3B >=3D3B=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt= >=3D3D3B Mika Nystrom wr=3D >> >ote:<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B Hello everyo= >ne=3D3D2C<=3D3BBR=3D >> >>=3D3B&=3D3Bg=3D3D
>=3D3B >=3D3Bt=3D3D3B &=3D3Bgt=3D3D3B = ><=3D3BBR>=3D3B&=3D >> >=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B This is=3D3D2C for me=3D3D2C a most un= >fortunate time =3D >> >=3D3D
>=3D3B >=3D3Bfor the CM3 servers to<=3D3BBR>=3D3B&= >=3D3Bgt=3D3D3B &=3D >> >=3D3Bgt=3D3D3B have crashed. I'm teaching a class =3D3D
>=3D3B >= >=3D3Busing Mod=3D >> >ula-3=3D3D2C and we need a<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3B= >gt=3D3D3B compile=3D >> >r... here's the una=3D3D
>=3D3B >=3D3Bme of the system I'm trying= > to use:&=3D >> >lt=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3= >B&=3D3Bgt=3D3D3B &am=3D >> >p=3D3Bgt=3D3D3B Linu=3D3D
>=3D3B >=3D3Bx lara 2.6.24ugcs1 #4 SMP = >Mon Feb 11 10=3D >> >:53:03 PST 2008 i686 GNU/Linux<=3D3BBR>=3D3B&=3D3Bg=3D3D
>= >=3D3B >=3D3Bt=3D >> >=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3= >Bgt=3D3D3B The most r=3D >> >ecent archives I have for Linux are=3D3D
>=3D3B >=3D3B:<=3D3BBR= >>=3D3B&=3D >> >=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &= >amp=3D3Bgt=3D3D3B cm3-m=3D >> >in-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D3D
>=3D3B >=3D3B-src-all-5.4.= >0.tgz <=3D >> =3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&a= >mp=3D3Bgt=3D3D3B &=3D >> >=3D3Bgt=3D3D3B And they don't seem =3D3D
>=3D3B >=3D3Bto work on = >this system: =3D >> >I can compile a program<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt= >=3D3D3B but when=3D >> > I=3D3D
>=3D3B >=3D3B try to run it=3D3D2C it says "Segmentation = >fault". Can=3D >> > anyone<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B=3D3D
&= >gt=3D3B >=3D3B help=3D >> >? (My understanding is that I need 5.5.1 or later...)<=3D3BBR>=3D3B&= >amp=3D3Bg=3D >> >t=3D3D3B &=3D3Bgt=3D3D3B=3D3D
>=3D3B >=3D3B <=3D3BBR>=3D3B= >&=3D3Bgt=3D3D3B &=3D >> >=3D3Bgt=3D3D3B Mika<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D= >3B <=3D3BBR>=3D3B&a=3D >> >mp=3D3Bgt=3D3D3B <=3D3BBR>=3D3B<=3D3B/body>=3D3B
>=3D3B >= >=3D3B<=3D3B/html>=3D >> >=3D3B=3D3D
>=3D3B >=3D3B
>=3D3B >=3D3B--_806446ae-8d10-4d7= >4-8eea-51aa365e=3D >> >9204_--
>> >=3D >> > >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_-- > >--_55339e45-8c85-4ab6-9440-0d2131bbad69_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Maybe not.
>Hm. That is bug. There is use with a cvs tree=2C and use without.
>I must have broken use without.
> =3B
>Try this:
>export CM3_ROOT=3Droot of cm3 cvs (for me this is /dev2/cm3=2C
>for you=2C maybe $HOME/cm3?)
>rm =3B$HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6
># *Common and *common in one command
rm =3B$HOME/cm3/cm3-min-LINUXLI= >BC6-d5.7.0/bin/*ommon
cp root of cm3 cvs/m3-sys/cminstall/src/config/cm3= >.cfg $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin
> =3B
>The .cfg will delegate out to the cvs tree.
>I don't like having two copies of files..having to keep them in sync..
> =3BThough the archives are meant to work standalone=2C without CVS.> > =3B But I don't test that so much oops sorry.
>That /might/ not be the right file=2C but it is close.
> =3B
> =3B- Jay

 =3B
>=3B To: jay.krell at cornell.edu
>=3B= > CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] Help finding CM= >3 compiler for Linux?
>=3B Date: Tue=2C 31 Mar 2009 22:59:18 -0700>>=3B From: mika at async.caltech.edu
>=3B
>=3B
>=3B Is the= >re any documentation for this format beyond what you just
>=3B wrote? = >Where?
>=3B
>=3B terpsichore-14: cm3
>=3B --- building in .= >./LINUXLIBC6 ---
>=3B
>=3B new source ->=3B compiling Main.m3<= >BR>>=3B "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.co= >mmon"=2C line 169: quake runtime error: undefined variable: ROOT
>=3B = >
>=3B --procedure-- -line- -file---
>=3B GetM3Back 169 /afs/.ugcs= >/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common
>=3B _IsM3B= >ackFlagSupported 181 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin= >/Unix.common
>=3B IsM3BackFlagSupported 193 /afs/.ugcs/user/mika/cm3/c= >m3-min-LINUXLIBC6-d5.7.0/bin/Unix.common
>=3B GetM3BackFlag 197 /afs/.= >ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common
>=3B m3_b= >ackend 62 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.commo= >n
>=3B program -- <=3Bbuiltin>=3B
>=3B 6 /afs/.ugcs.caltech.e= >du/user/mika/test/LINUXLIBC6/m3make.args
>=3B
>=3B
>=3B Fa= >tal Error: procedure "m3_backend" defined in "/afs/.ugcs/user/mika/cm3/cm3-= >min-LINUXLIBC6-d5.7.0/bin/cm3.cfg" failed.
>=3B
>=3B Jay writes:= >
>=3B >=3B--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_
>=3B >=3BC= >ontent-Type: text/plain=3B charset=3D"iso-8859-1"
>=3B >=3BContent-T= >ransfer-Encoding: quoted-printable
>=3B >=3B
>=3B >=3B
>= >=3B >=3BThese archives do have a different format=3D2C yes.
>=3B >= >=3B
>=3B >=3BBut it isn't a bad format.
>=3B >=3B
>=3B &= >gt=3Bcminstall is pretty worthless imho.
>=3B >=3B
>=3B >=3BE= >xtract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.
>=3B >=3B
&= >gt=3B >=3B=3D20
>=3B >=3B
>=3B >=3B - Jay
>=3B >=3B<= >BR>>=3B >=3B=3D20
>=3B >=3B>=3B To: jay.krell at cornell.edu
&= >gt=3B >=3B>=3B Subject: Re: [M3devel] Help finding CM3 compiler for Lin= >ux?=3D20
>=3B >=3B>=3B Date: Tue=3D2C 31 Mar 2009 15:56:11 -0700R>>=3B >=3B>=3B From: mika at async.caltech.edu
>=3B >=3B>=3B= >=3D20
>=3B >=3B>=3B No=3D2C I'm sorry...
>=3B >=3B>=3B=3D= >20
>=3B >=3B>=3B the archives do not have the usual format. I'm ex= >pecting to unpack
>=3B >=3B>=3B and run "cminstall" and then unpac= >k the big source tar on top and=3D20
>=3B >=3B>=3B build that. But= > there's no cminstall in the archive on this page.
>=3B >=3B>=3B T= >his is "the normal procedure" for installing CM3=3D2C no? It's what
>= >=3B >=3B>=3B the instructions say to do=3D2C as well...
>=3B >= >=3B>=3B=3D20
>=3B >=3B>=3B And the link from the "Download" page= > is broken (to -d5.5.0.tgz).
>=3B >=3B>=3B=3D20
>=3B >=3B&g= >t=3B Mika
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B Jay writes:>>=3B >=3B>=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>= >=3B >=3B>=3B >=3BContent-Type: text/plain=3D3B charset=3D3D"iso-8859-= >1"
>=3B >=3B>=3B >=3BContent-Transfer-Encoding: quoted-printable= >
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B
>=3B >= >=3B>=3B >=3B http://modula3.elegosoft.com/cm3/uploaded-archives
>= >=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B?
>=3B >=3B>= >=3B >=3B
>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >= >=3B
>=3B >=3B>=3B >=3BI can make another later this week.
>= >=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B=3D3D20
>=3B >= >=3B>=3B >=3B
>=3B >=3B>=3B >=3BAll you need is a working cm3= > on any system.
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B= >>=3BFrom there you can build the whole system=3D3D2C targeting any system= >.
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3BAs long as tha= >t cm3 understands LONGINT and your target system.
>=3B >=3B>=3B &g= >t=3B
>=3B >=3B>=3B >=3BAnd it is easier=3D3D2C but not necessary= >=3D3D2C if you have Python. :)
>=3B >=3B>=3B >=3B
>=3B >= >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B
>=3B >=3B>= >=3B >=3B - Jay
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >= >=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Date: Tue=3D3D2C 31 Mar 2009= > 15:43:41 -0500
>=3B >=3B>=3B >=3B>=3B From: martinbishop at bell= >south.net
>=3B >=3B>=3B >=3B>=3B To: mika at async.caltech.edu>>=3B >=3B>=3B >=3B>=3B CC: m3devel at elegosoft.com
>=3B >= >=3B>=3B >=3B>=3B Subject: Re: [M3devel] Help finding CM3 compiler for= > Linux?
>=3B >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B &= >gt=3B>=3B Not sure if this helps=3D3D2C but on my linux system:
>=3B= > >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Criti= >cal Mass Modula-3 version d5.7.0
>=3B >=3B>=3B >=3B>=3B last u= >pdated: 2008-03-16
>=3B >=3B>=3B >=3B>=3B compiled: 2008-08-14= > 00:56:14
>=3B >=3B>=3B >=3B>=3B configuration: /usr/local/cm3= >/bin/cm3.cfg
>=3B >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>= >=3B >=3B>=3B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:3= >9 UTC 2009
>=3B >=3B>=3B >=3B>=3B i686 GNU/Linux
>=3B >= >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B=3D3D20>>=3B >=3B>=3B >=3B>=3B I don't have the cm3 tarball=3D3D2C but I= > do have the sources in cm3/ st=3D
>=3B >=3Bill.
>=3B >=3B>= >=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Mika Nystrom wr= >ote:
>=3B >=3B>=3B >=3B>=3B >=3B Hello everyone=3D3D2C
&g= >t=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B&= >gt=3B >=3B This is=3D3D2C for me=3D3D2C a most unfortunate time for the C= >M3 servers=3D
>=3B >=3B to
>=3B >=3B>=3B >=3B>=3B >= >=3B have crashed. I'm teaching a class using Modula-3=3D3D2C and we need a<= >BR>>=3B >=3B>=3B >=3B>=3B >=3B compiler... here's the uname of = >the system I'm trying to use:
>=3B >=3B>=3B >=3B>=3B >=3B=3D= >3D20
>=3B >=3B>=3B >=3B>=3B >=3B Linux lara 2.6.24ugcs1 #4 S= >MP Mon Feb 11 10:53:03 PST 2008 i686 GNU/=3D
>=3B >=3BLin=3D3D
&g= >t=3B >=3B>=3B >=3Bux
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D2= >0
>=3B >=3B>=3B >=3B>=3B >=3B The most recent archives I hav= >e for Linux are:
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>= >=3B >=3B>=3B >=3B>=3B >=3B cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3= >-src-all-5.4.0.tgz=3D3D20
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20= >
>=3B >=3B>=3B >=3B>=3B >=3B And they don't seem to work on = >this system: I can compile a program
>=3B >=3B>=3B >=3B>=3B &g= >t=3B but when I try to run it=3D3D2C it says "Segmentation fault". Can anyo= >=3D
>=3B >=3Bne
>=3B >=3B>=3B >=3B>=3B >=3B help? (My= > understanding is that I need 5.5.1 or later...)
>=3B >=3B>=3B >= >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B >=3B Mika
= >>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >= >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >= >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>=3B >=3B>=3B >=3BCo= >ntent-Type: text/html=3D3B charset=3D3D"iso-8859-1"
>=3B >=3B>=3B = >>=3BContent-Transfer-Encoding: quoted-printable
>=3B >=3B>=3B &g= >t=3B
>=3B >=3B>=3B >=3B<=3Bhtml>=3B
>=3B >=3B>=3B &= >gt=3B<=3Bhead>=3B
>=3B >=3B>=3B >=3B<=3Bstyle>=3B
>= >=3B >=3B>=3B >=3B.hmmessage P
>=3B >=3B>=3B >=3B{
>= >=3B >=3B>=3B >=3Bmargin:0px=3D3D3B
>=3B >=3B>=3B >=3Bpaddi= >ng:0px
>=3B >=3B>=3B >=3B}
>=3B >=3B>=3B >=3Bbody.hmm= >essage
>=3B >=3B>=3B >=3B{
>=3B >=3B>=3B >=3Bfont-siz= e: 10pt=3D3D3B
>=3B >=3B>=3B >=3Bfont-family:Verdana
>=3B &= >gt=3B>=3B >=3B}
>=3B >=3B>=3B >=3B<=3B/style>=3B
>= >=3B >=3B>=3B >=3B<=3B/head>=3B
>=3B >=3B>=3B >=3B<= >=3Bbody class=3D3D3D'hmmessage'>=3B
>=3B >=3B>=3B >=3B&=3Bn= >bsp=3D3D3B<=3BA href=3D3D3D"http://modula3.elegosoft.com/cm3/uploaded-arc= >hive=3D
>=3B >=3Bs" targ=3D3D
>=3B >=3B>=3B >=3Bet=3D3D3D= >_blank>=3B<=3BFONT color=3D3D3D#0068cf>=3Bhttp://modula3.elegosoft.co= >m/cm3/u=3D
>=3B >=3Bploaded=3D3D
>=3B >=3B>=3B >=3B-archi= >ves<=3B/FONT>=3B<=3B/A>=3B<=3BBR>=3B
>=3B >=3B>=3B >= >=3B?<=3BBR>=3B
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR&= >gt=3B
>=3B >=3B>=3B >=3BI can make another later this week.<= >=3BBR>=3B
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3BR>>=3B >=3B>=3B >=3BAll you need is a working cm3 on any system.<= >=3BBR>=3B
>=3B >=3B>=3B >=3B>=3BFrom there you can build the= > whole system=3D3D2C targeting any system.<=3BBR=3D
>=3B >=3B>= >=3B
>=3B >=3B>=3B >=3BAs long as that cm3 understands LONGINT an= >d your target system.<=3BBR>=3B
>=3B >=3B>=3B >=3BAnd it is = >easier=3D3D2C but not necessary=3D3D2C if you have Python. :)<=3BBR>=3B= >
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B
>=3B &g= >t=3B>=3B >=3B&=3Bnbsp=3D3D3B- Jay<=3BBR>=3B<=3BBR>=3B&=3B= >nbsp=3D3D3B<=3BBR>=3B&=3Bgt=3D3D3B Date: Tue=3D3D2C 31 Mar 2009=3DR>>=3B >=3B 15:43:41 -=3D3D
>=3B >=3B>=3B >=3B0500<=3BBR&g= >t=3B&=3Bgt=3D3D3B From: martinbishop at bellsouth.net<=3BBR>=3B&=3Bg= >t=3D3D3B To: mika at a=3D
>=3B >=3Bsync.ca=3D3D
>=3B >=3B>=3B = >>=3Bltech.edu<=3BBR>=3B&=3Bgt=3D3D3B CC: m3devel at elegosoft.com<= >=3BBR>=3B&=3Bgt=3D3D3B Subject: Re:=3D
>=3B >=3B [M3dev=3D3D>>=3B >=3B>=3B >=3Bel] Help finding CM3 compiler for Linux?<=3BBR= >>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B Not su=3D
>=3B &= >gt=3Bre if t=3D3D
>=3B >=3B>=3B >=3Bhis helps=3D3D2C but on my l= >inux system:<=3BBR>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B C= >ritical=3D
>=3B >=3B Mass Mod=3D3D
>=3B >=3B>=3B >=3Bula-= >3 version d5.7.0<=3BBR>=3B&=3Bgt=3D3D3B last updated: 2008-03-16<= >=3BBR>=3B&=3Bgt=3D3D3B co=3D
>=3B >=3Bmpiled:=3D3D
>=3B &g= >t=3B>=3B >=3B 2008-08-14 00:56:14<=3BBR>=3B&=3Bgt=3D3D3B configu= >ration: /usr/local/cm3/bin/cm3.c=3D
>=3B >=3Bfg<=3BBR=3D3D
>= >=3B >=3B>=3B >=3B>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3= >B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 2=3D
>=3B >=3B9 19= >:24=3D3D
>=3B >=3B>=3B >=3B:39 UTC 2009<=3BBR>=3B&=3Bgt= >=3D3D3B i686 GNU/Linux<=3BBR>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bg= >t=3D3D3B <=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3D3B I don=3D3D
&= >gt=3B >=3B>=3B >=3B't have the cm3 tarball=3D3D2C but I do have the s= >ources in cm3/ still.<=3BBR=3D
>=3B >=3B>=3B&=3Bgt=3D3D
&g= >t=3B >=3B>=3B >=3B=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B Mika Nystrom= > wrote:<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B Hello everyo=3D
&= >gt=3B >=3Bne=3D3D2C<=3BBR>=3B&=3Bg=3D3D
>=3B >=3B>=3B >= >=3Bt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3= >B This is=3D3D2C for me=3D3D2C a most un=3D
>=3B >=3Bfortunate time = >=3D3D
>=3B >=3B>=3B >=3Bfor the CM3 servers to<=3BBR>=3B&= >=3Bgt=3D3D3B &=3Bgt=3D3D3B have crashed. I'm teaching a=3D
>=3B >= >=3B class =3D3D
>=3B >=3B>=3B >=3Busing Modula-3=3D3D2C and we n= >eed a<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B compiler... here'=3DR>>=3B >=3Bs the una=3D3D
>=3B >=3B>=3B >=3Bme of the system= > I'm trying to use:<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B <=3BBR= >>=3B&=3Bgt=3D3D3B &=3Bg=3D
>=3B >=3Bt=3D3D3B Linu=3D3D
&g= >t=3B >=3B>=3B >=3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2= >008 i686 GNU/Linux<=3BBR=3D
>=3B >=3B>=3B&=3Bg=3D3D
>=3B= > >=3B>=3B >=3Bt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3= >B &=3Bgt=3D3D3B The most recent archives I have fo=3D
>=3B >=3Br = >Linux are=3D3D
>=3B >=3B>=3B >=3B:<=3BBR>=3B&=3Bgt=3D3D3B= > &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B cm3-min-P= OSIX-LINUXLIBC6-5.=3D
>=3B >=3B4.0.tgz cm3=3D3D
>=3B >=3B>= >=3B >=3B-src-all-5.4.0.tgz <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3= >B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B And they =3D
>=3B &g= >t=3Bdon't seem =3D3D
>=3B >=3B>=3B >=3Bto work on this system: I= > can compile a program<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B but= >=3D
>=3B >=3B when I=3D3D
>=3B >=3B>=3B >=3B try to run i= >t=3D3D2C it says "Segmentation fault". Can anyone<=3BBR>=3B&=3Bgt=3D= >3D3B=3D
>=3B >=3B &=3Bgt=3D3D3B=3D3D
>=3B >=3B>=3B >= >=3B help? (My understanding is that I need 5.5.1 or later...)<=3BBR>=3B= >&=3Bgt=3D3D3B &=3B=3D
>=3B >=3Bgt=3D3D3B=3D3D
>=3B >=3B= >>=3B >=3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B Mika<=3BBR&= >gt=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B <= >=3BBR>=3B<=3B/body=3D
>=3B >=3B>=3B
>=3B >=3B>=3B >= >=3B<=3B/html>=3B=3D3D
>=3B >=3B>=3B >=3B
>=3B >=3B>= >=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_--
>=3B >=3B
&g= >t=3B >=3B--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_
>=3B >=3BContent= >-Type: text/html=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer= >-Encoding: quoted-printable
>=3B >=3B
>=3B >=3B<=3Bhtml>= >=3B
>=3B >=3B<=3Bhead>=3B
>=3B >=3B<=3Bstyle>=3B
&= >gt=3B >=3B.hmmessage P
>=3B >=3B{
>=3B >=3Bmargin:0px=3D3B<= >BR>>=3B >=3Bpadding:0px
>=3B >=3B}
>=3B >=3Bbody.hmmessag= >e
>=3B >=3B{
>=3B >=3Bfont-size: 10pt=3D3B
>=3B >=3Bfo= >nt-family:Verdana
>=3B >=3B}
>=3B >=3B<=3B/style>=3B
&= >gt=3B >=3B<=3B/head>=3B
>=3B >=3B<=3Bbody class=3D3D'hmmessa= >ge'>=3B
>=3B >=3BThese archives do have a different format=3D2C ye= >s.<=3BBR>=3B
>=3B >=3BBut it isn't a bad format.<=3BBR>=3BR>>=3B >=3Bcminstall is pretty worthless imho.<=3BBR>=3B
>=3B = >>=3BExtract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.<=3BBR>=3B<= >BR>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp= >=3D3B- Jay<=3BBR>=3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3B&=3B= >gt=3D3B To: jay.krell at cornell.edu<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B = >>=3B Subject: Re: [M3devel] Help finding CM3 compiler for Linux? <=3BBR= >>=3B&=3Bgt=3D3B Dat=3D
>=3B >=3Be: Tue=3D2C 31 Mar 2009 15:56:1= >1 -0700<=3BBR>=3B&=3Bgt=3D3B From: mika at async.caltech.edu=3D
>= >=3B >=3B<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B No=3D2C= > I'm sorry...<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B the = >archives =3D
>=3B >=3Bdo not have the usual format. I'm expecting to= > unpack<=3BBR>=3B&=3Bgt=3D3B and run "cm=3D
>=3B >=3Binstall"= > and then unpack the big source tar on top and <=3BBR>=3B&=3Bgt=3D3B= > build tha=3D
>=3B >=3Bt. But there's no cminstall in the archive on= > this page.<=3BBR>=3B&=3Bgt=3D3B This is =3D
>=3B >=3B"the no= >rmal procedure" for installing CM3=3D2C no? It's what<=3BBR>=3B&=3Bg= >t=3D3B the in=3D
>=3B >=3Bstructions say to do=3D2C as well...<=3B= >BR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B And the link from t=3D<= >BR>>=3B >=3Bhe "Download" page is broken (to -d5.5.0.tgz).<=3BBR>= >=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Mika<=3BBR=3D
>=3B &g= >t=3B>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Jay writes:<=3BBR&g= >t=3B&=3Bgt=3D3B &=3Bgt=3D3B--_806446ae-8d10-4d74-8eea-5=3D
>=3B = >>=3B1aa365e9204_<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BContent-Type: = >text/plain=3D3B charset=3D3D"iso-885=3D
>=3B >=3B9-1"<=3BBR>=3B&= >amp=3Bgt=3D3B &=3Bgt=3D3BContent-Transfer-Encoding: quoted-printable<= >=3BBR>=3B&=3Bgt=3D3B =3D
>=3B >=3B&=3Bgt=3D3B<=3BBR>=3B&= >amp=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B htt= >p://modula3.elegosoft.com/cm3/u=3D
>=3B >=3Bploaded-archives<=3BBR= >>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3B?<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D= >
>=3B >=3B=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &a= >mp=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BI can make another l= >ater t=3D
>=3B >=3Bhis week.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >=3B &= >amp=3Bgt=3D3BAll you need is a working cm3 on any system.<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &= >amp=3Bgt=3D3B&=3Bgt=3D3BFrom there you can build the whole system=3D3D2C= > targeting an=3D
>=3B >=3By system.<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAs long as that cm3 un= >derstands =3D
>=3B >=3BLONGINT and your target system.<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAnd= > it is =3D
>=3B >=3Beasier=3D3D2C but not necessary=3D3D2C if you ha= >ve Python. :)<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3B=3D
>=3B= > >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt= >=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B - Jay<=3B= >BR>=3B&=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B= >&=3Bgt=3D3B Date: Tue=3D3D2C 31 Mar 2009=3D
>=3B >=3B 15:43:41 -0= >500<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B From: martinbi= >shop at bellsouth.net<=3BBR>=3B=3D
>=3B >=3B&=3Bgt=3D3B &=3Bg= >t=3D3B&=3Bgt=3D3B To: mika at async.caltech.edu<=3BBR>=3B&=3Bgt=3D3B= > &=3Bgt=3D3B&=3Bgt=3D3B CC: m=3D
>=3B >=3B3devel at elegosoft.com= ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B Subject: Re: [M3d= >evel] Help fin=3D
>=3B >=3Bding CM3 compiler for Linux?<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bg= >t=3D3B &=3Bgt=3D3B&=3Bg=3D
>=3B >=3Bt=3D3B Not sure if this he= >lps=3D3D2C but on my linux system:<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3B&=3Bg=3D
>=3B >=3Bt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &am= >p=3Bgt=3D3B&=3Bgt=3D3B Critical Mass Modula-3 version d5.7.0<=3BBR>= >=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B last upd= >ated: 2008-03-16<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B c= >ompiled=3D
>=3B >=3B: 2008-08-14 00:56:14<=3BBR>=3B&=3Bgt=3D3= >B &=3Bgt=3D3B&=3Bgt=3D3B configuration: /usr/local/cm3/=3D
>=3B = >>=3Bbin/cm3.cfg<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B= >=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B Linux thin= >kp=3D
>=3B >=3Bad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2= >009<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bg=3D
>=3B >=3Bt= >=3D3B i686 GNU/Linux<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D= >3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20= >=3D
>=3B >=3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D= >3B I don't have the cm3 tarball=3D3D2C but I do have the=3D
>=3B >= >=3B sources in cm3/ still.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B = >=3D
>=3B >=3BMika Nystrom wrote:<=3BBR>=3B&=3Bgt=3D3B &=3B= >gt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B Hello everyone=3D3D2C<=3BBR>=3B&am= >p=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B= >=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt= >=3D3B This is=3D3D2C fo=3D
>=3B >=3Br me=3D3D2C a most unfortunate t= >ime for the CM3 servers to<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B have crashed. I'm teaching a = >class using Modula-3=3D3D2C and we n=3D
>=3B >=3Beed a<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B compiler... here= >'s the uname of the sys=3D
>=3B >=3Btem I'm trying to use:<=3BBR&g= >t=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3B= >BR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3B=3D
>=3B >=3Bgt=3D3B &am= >p=3Bgt=3D3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i68= >=3D
>=3B >=3B6 GNU/Lin=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3Bux<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3= >B=3D3D20<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &=3Bgt=3D3B&= >=3Bgt=3D3B &=3Bgt=3D3B The most recent archives I have for Linux are:<= >=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B = >&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt= >=3D3B &=3Bgt=3D3B cm3-min-POSIX-=3D
>=3B >=3BLINUXLIBC6-5.4.0.tgz= > cm3-src-all-5.4.0.tgz=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&am= >p=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B=3D3D20<=3BBR>=3B&=3Bg= >t=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B And they don't seem to w= >ork on this =3D
>=3B >=3Bsystem: I can compile a program<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B but when I tr= >=3D
>=3B >=3By to run it=3D3D2C it says "Segmentation fault". Can an= >yone<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3B=3D
>=3B >=3Bg= >t=3D3B &=3Bgt=3D3B help? (My understanding is that I need 5.5.1 or later= >...)<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bg= >t=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Bgt=3D3B &=3Bgt=3D3B Mika<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >= >=3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3B= >gt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &am= >p=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B-= >-_806446ae-8d10-4d74-8eea-51aa365e9204_<=3BBR>=3B&=3Bgt=3D3B &=3B= >gt=3D3BConten=3D
>=3B >=3Bt-Type: text/html=3D3B charset=3D3D"iso-88= >59-1"<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BContent-Transfe=3D
>= >=3B >=3Br-Encoding: quoted-printable<=3BBR>=3B&=3Bgt=3D3B &=3Bg= >t=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3Bhtml&=3Bg= >t=3D
>=3B >=3B=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Blt=3D3Bhead&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Blt=3D3Bstyle&=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D= >3B &=3Bgt=3D3B.hmmessage P<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B{&l= >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bmargin:0px=3D3D3B<=3B=3D
>= >=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bpadding:0px<=3BBR>=3B&am= >p=3Bgt=3D3B &=3Bgt=3D3B}<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bbody.= >hmmessag=3D
>=3B >=3Be<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B{&l= >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfont-size: 10pt=3D3D3B<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3Bfo=3D
>=3B >=3Bnt-family:Verdana<= >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B}<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B&=3Blt=3D3B/style&=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>= >=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3B/head&=3Bgt=3D3B<=3BBR&g= >t=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3Bbody class=3D3D3D'hmmessa=3D= >
>=3B >=3Bge'&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BA href=3D3D3D"http://modula3.=3D<= >BR>>=3B >=3Belegosoft.com/cm3/uploaded-archives" targ=3D3D<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3Bet=3D3D3D_blank&=3B=3D
>=3B >=3Bg= >t=3D3B&=3Blt=3D3BFONT color=3D3D3D#0068cf&=3Bgt=3D3Bhttp://modula3.el= >egosoft.com/cm3/upl=3D
>=3B >=3Boaded=3D3D<=3BBR>=3B&=3Bgt=3D= >3B &=3Bgt=3D3B-archives&=3Blt=3D3B/FONT&=3Bgt=3D3B&=3Blt=3D3B/A= >&=3Bgt=3D3B&=3Blt=3D3BBR&=3Bg=3D
>=3B >=3Bt=3D3B<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3B?&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3B=3D= >
>=3B >=3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3= >BI can make another later this week.&=3Blt=3D3BBR&=3Bgt=3D3B<=3B=3D= >
>=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp= >=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3BAll you need=3D
>=3B >=3B is a working cm3 on any system.&= >=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Bgt=3D3BFrom t=3D
>=3B >=3Bhere you can build the whole system=3D3= >D2C targeting any system.&=3Blt=3D3BBR&=3Bgt=3D
>=3B >=3B=3D3B= ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAs long as that cm3 understands = >LONGINT and your target=3D
>=3B >=3B system.&=3Blt=3D3BBR&=3Bg= >t=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAnd it is easier=3D3D2C bu= >t not necess=3D
>=3B >=3Bary=3D3D2C if you have Python. :)&=3Blt= >=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp= >=3D3Bnbsp=3D
>=3B >=3B=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR&= >gt=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B- Jay&=3Blt= >=3D3BBR&=3Bgt=3D3B&=3Blt=3D
>=3B >=3B=3D3BBR&=3Bgt=3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3= >B Date: Tue=3D3D2C 31 M=3D
>=3B >=3Bar 2009 15:43:41 -=3D3D<=3BBR&= >gt=3B&=3Bgt=3D3B &=3Bgt=3D3B0500&=3Blt=3D3BBR&=3Bgt=3D3B&=3B= >amp=3D3Bgt=3D3D3B From=3D
>=3B >=3B: martinbishop at bellsouth.net&= >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B To: mika at async.ca=3D
= >>=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bltech.edu&= >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B CC: m3devel at elego=3D
= >>=3B >=3Bsoft.com&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B= > Subject: Re: [M3dev=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D
>= >=3B >=3B=3D3Bel] Help finding CM3 compiler for Linux?&=3Blt=3D3BBR&= >=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D
>=3B >=3B=3D3BBR&= >=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B Not sure if t=3D3D<=3BBR>=3B&=3Bg= >t=3D3B &=3Bgt=3D3Bhis helps=3D3D2C b=3D
>=3B >=3But on my linux s= >ystem:&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3B= >BR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D
>=3B >=3B=3D3D3B Critical Mass = >Mod=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bula-3 version d5.7.0&= >=3Blt=3D3BBR&=3Bgt=3D
>=3B >=3B=3D3B&=3Bamp=3D3Bgt=3D3D3B last= > updated: 2008-03-16&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B = >comp=3D
>=3B >=3Biled:=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3B 2008-08-14 00:56:14&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3= >B c=3D
>=3B >=3Bonfiguration: /usr/local/cm3/bin/cm3.cfg&=3Blt=3D= >3BBR=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B&=3B= >=3D
>=3B >=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3B= >amp=3D3Bgt=3D3D3B Linux thinkpad 2.6.27-11-generic=3D
>=3B >=3B #1 S= >MP Thu Jan 29 19:24=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B:39 UTC = >2009&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3= >D3B i686 GNU/Linux&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &a= >mp=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3B=3D
>=3B >=3Bgt=3D3D3B &a= >mp=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B I don=3D3D<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3B't have the c=3D
>=3B >=3Bm3 tarball= >=3D3D2C but I do have the sources in cm3/ still.&=3Blt=3D3BBR&=3Bgt= >=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D<=3BBR>=3B&=3Bgt=3D3B= > &=3Bgt=3D3B=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D= >3B Mika Nystrom wr=3D
>=3B >=3Bote:&=3Blt=3D3BBR&=3Bgt=3D3B&am= >p=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B Hello everyone=3D3D2C&=3B= >lt=3D3BBR=3D
>=3B >=3B&=3Bgt=3D3B&=3Bamp=3D3Bg=3D3D<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3Bt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt= >=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D3B &=3Bam= >p=3D3Bgt=3D3D3B This is=3D3D2C for me=3D3D2C a most unfortunate time =3D>>=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfor the CM3 s= >ervers to&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp= >=3D
>=3B >=3B=3D3Bgt=3D3D3B have crashed. I'm teaching a class =3D3D= ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Busing Mod=3D
>=3B >=3Bula= >-3=3D3D2C and we need a&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D= >3B &=3Bamp=3D3Bgt=3D3D3B compile=3D
>=3B >=3Br... here's the una= >=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bme of the system I'm trying= > to use:&=3B=3D
>=3B >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt= >=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp= >=3D3Bgt=3D3D3B &=3Bam=3D
>=3B >=3Bp=3D3Bgt=3D3D3B Linu=3D3D<=3B= >BR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 1= >0=3D
>=3B >=3B:53:03 PST 2008 i686 GNU/Linux&=3Blt=3D3BBR&=3Bg= >t=3D3B&=3Bamp=3D3Bg=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bt=3D<= >BR>>=3B >=3B=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt= >=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B The most r=3D
>= >=3B >=3Becent archives I have for Linux are=3D3D<=3BBR>=3B&=3Bgt= >=3D3B &=3Bgt=3D3B:&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B = >>=3B=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3= >B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B cm3-m=3D
>=3B >= >=3Bin-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D3D<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B-src-all-5.4.0.tgz &=3Blt=3D
>=3B =3D3BBR&=3Bgt=3D3B&a= >mp=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt= >=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D3B = >And they don't seem =3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bto work= > on this system: =3D
>=3B >=3BI can compile a program&=3Blt=3D3BB= >R&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B but when= >=3D
>=3B >=3B I=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B try = >to run it=3D3D2C it says "Segmentation fault". Can=3D
>=3B >=3B anyo= >ne&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt= >=3D3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B help=3D
>=3B &= >gt=3B? (My understanding is that I need 5.5.1 or later...)&=3Blt=3D3BBR&= >amp=3Bgt=3D3B&=3Bamp=3D3Bg=3D
>=3B >=3Bt=3D3D3B &=3Bamp=3D3Bgt= >=3D3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B &=3Blt=3D3BBR&am= >p=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D
>=3B >=3B=3D3Bgt= >=3D3D3B Mika&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Ba= >mp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Ba=3D
>=3B >=3B= >mp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Blt=3D3B/body&=3Bgt= >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3B/html&=3Bg= >t=3D
>=3B >=3B=3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >lt=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B--_806446ae-8d10-4d74-8eea-51aa36= >5e=3D
>=3B >=3B9204_--<=3BBR>=3B<=3B/body>=3B
>=3B >= >=3B<=3B/html>=3B=3D
>=3B >=3B
>=3B >=3B--_777fdc4e-3c29-4= >0b4-a3dd-e6243f796cee_--
>= > >--_55339e45-8c85-4ab6-9440-0d2131bbad69_-- From jay.krell at cornell.edu Wed Apr 1 08:56:45 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Apr 2009 06:56:45 +0000 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: <200904010627.n316RM55072294@camembert.async.caltech.edu> References: Your message of "Wed, 01 Apr 2009 06:13:00 -0000." <200904010627.n316RM55072294@camembert.async.caltech.edu> Message-ID: Sorry it is meant to be a little easier. I'll see about putting an "install" or "readme" file in. "root of cm3 cvs" is the root of a cvs checkout, not a "repository". But it isn't meant to be required...it is just the way I always work.. Similar to your "extracting the source tarball", though that isn't supposed to be necessary either. Here is another avenue..roundabout, but.. You had a kind of working install from 5.4 and running its cminstall. cm3 ran but produced crashing binaries. Take the cm3.cfg file from it and put it at. $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3.cfg That might work. I'll test this out more later and maybe make an updated archive. "this" being "not having any source tree", just the extracted archive + set $PATH and $LD_LIBRARY_PATH. It should be a small fix, if it isn't fixed already, and easy to patch up existing extracted archives -- you might just try a current cm3cfg.common from the source tree, but..the "shoe" is kind of on my "foot" at this point. - Jay > To: jay.krell at cornell.edu > Date: Tue, 31 Mar 2009 23:27:22 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Help finding CM3 compiler for Linux? > > Hmm, I'm not sure what you mean? "root of cm3 cvs"? > > I have lots of Modula-3 installations on my own machines, but I'm > just trying to get a system installed for student use on the student > systems (which are different)... A working binary dist for Linux > is exactly what I'm looking for and this is what you seem to have > directed me to, but I don't have a CVS repository... > > I don't have "m3-sys/cminstall/" etc. Do I need to unpack both > the min and std before doing these things? > > What I'm *used to* is that I unpack the binary distribution, then > unpack the sources (or CVS if you like) on top of that, and > then compile everything. Which works about 1 time in 3. > > I think Modula-3 is almost impossible to install if you don't know > exactly what to do! (I'm sure I can figure this out with some > work.. but is it really meant to be hard to do? I guess it keeps > the riff-raff off the M3 mailing lists!) > > Mika > > Jay writes: > >--_55339e45-8c85-4ab6-9440-0d2131bbad69_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Maybe not. > > > >Hm. That is bug. There is use with a cvs tree=2C and use without. > > > >I must have broken use without. > > > >=20 > > > >Try this: > > > >export CM3_ROOT=3Droot of cm3 cvs (for me this is /dev2/cm3=2C > > > >for you=2C maybe $HOME/cm3?) > > > >rm $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6 > > > ># *Common and *common in one command > >rm $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/*ommon > >cp root of cm3 cvs/m3-sys/cminstall/src/config/cm3.cfg $HOME/cm3/cm3-min-LI= > >NUXLIBC6-d5.7.0/bin > > > >=20 > > > >The .cfg will delegate out to the cvs tree. > > > >I don't like having two copies of files..having to keep them in sync.. > > > > Though the archives are meant to work standalone=2C without CVS. > > > > But I don't test that so much oops sorry. > > > >That /might/ not be the right file=2C but it is close. > > > >=20 > > > > - Jay > > > >=20 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux?=20 > >> Date: Tue=2C 31 Mar 2009 22:59:18 -0700 > >> From: mika at async.caltech.edu > >>=20 > >>=20 > >> Is there any documentation for this format beyond what you just > >> wrote? Where? > >>=20 > >> terpsichore-14: cm3 > >> --- building in ../LINUXLIBC6 --- > >>=20 > >> new source -> compiling Main.m3 > >> "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common"=2C= > > line 169: quake runtime error: undefined variable: ROOT > >>=20 > >> --procedure-- -line- -file--- > >> GetM3Back 169 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3c= > >fg.common > >> _IsM3BackFlagSupported 181 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5= > >.7.0/bin/Unix.common > >> IsM3BackFlagSupported 193 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.= > >7.0/bin/Unix.common > >> GetM3BackFlag 197 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/= > >Unix.common > >> m3_backend 62 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix= > >.common > >> program -- > >> 6 /afs/.ugcs.caltech.edu/user/mika/test/LINUXLIBC6/m3make.args > >>=20 > >>=20 > >> Fatal Error: procedure "m3_backend" defined in "/afs/.ugcs/user/mika/cm3/= > >cm3-min-LINUXLIBC6-d5.7.0/bin/cm3.cfg" failed. > >>=20 > >> Jay writes: > >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ > >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> >These archives do have a different format=3D2C yes. > >> > > >> >But it isn't a bad format. > >> > > >> >cminstall is pretty worthless imho. > >> > > >> >Extract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH. > >> > > >> >=3D20 > >> > > >> > - Jay > >> > > >> >=3D20 > >> >> To: jay.krell at cornell.edu > >> >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux?=3D20 > >> >> Date: Tue=3D2C 31 Mar 2009 15:56:11 -0700 > >> >> From: mika at async.caltech.edu > >> >>=3D20 > >> >> No=3D2C I'm sorry... > >> >>=3D20 > >> >> the archives do not have the usual format. I'm expecting to unpack > >> >> and run "cminstall" and then unpack the big source tar on top and=3D20 > >> >> build that. But there's no cminstall in the archive on this page. > >> >> This is "the normal procedure" for installing CM3=3D2C no? It's what > >> >> the instructions say to do=3D2C as well... > >> >>=3D20 > >> >> And the link from the "Download" page is broken (to -d5.5.0.tgz). > >> >>=3D20 > >> >> Mika > >> >>=3D20 > >> >> Jay writes: > >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ > >> >> >Content-Type: text/plain=3D3B charset=3D3D"iso-8859-1" > >> >> >Content-Transfer-Encoding: quoted-printable > >> >> > > >> >> > > >> >> > http://modula3.elegosoft.com/cm3/uploaded-archives > >> >> > > >> >> >? > >> >> > > >> >> >=3D3D20 > >> >> > > >> >> >I can make another later this week. > >> >> > > >> >> >=3D3D20 > >> >> > > >> >> >All you need is a working cm3 on any system. > >> >> > > >> >> >>From there you can build the whole system=3D3D2C targeting any syste= > >m. > >> >> > > >> >> >As long as that cm3 understands LONGINT and your target system. > >> >> > > >> >> >And it is easier=3D3D2C but not necessary=3D3D2C if you have Python. = > >:) > >> >> > > >> >> >=3D3D20 > >> >> > > >> >> > - Jay > >> >> > > >> >> >=3D3D20 > >> >> >> Date: Tue=3D3D2C 31 Mar 2009 15:43:41 -0500 > >> >> >> From: martinbishop at bellsouth.net > >> >> >> To: mika at async.caltech.edu > >> >> >> CC: m3devel at elegosoft.com > >> >> >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? > >> >> >>=3D3D20 > >> >> >> Not sure if this helps=3D3D2C but on my linux system: > >> >> >>=3D3D20 > >> >> >> Critical Mass Modula-3 version d5.7.0 > >> >> >> last updated: 2008-03-16 > >> >> >> compiled: 2008-08-14 00:56:14 > >> >> >> configuration: /usr/local/cm3/bin/cm3.cfg > >> >> >>=3D3D20 > >> >> >> Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 200= > >9 > >> >> >> i686 GNU/Linux > >> >> >>=3D3D20 > >> >> >>=3D3D20 > >> >> >> I don't have the cm3 tarball=3D3D2C but I do have the sources in cm= > >3/ st=3D > >> >ill. > >> >> >>=3D3D20 > >> >> >> Mika Nystrom wrote: > >> >> >> > Hello everyone=3D3D2C > >> >> >> >=3D3D20 > >> >> >> > This is=3D3D2C for me=3D3D2C a most unfortunate time for the CM3 = > >servers=3D > >> > to > >> >> >> > have crashed. I'm teaching a class using Modula-3=3D3D2C and we n= > >eed a > >> >> >> > compiler... here's the uname of the system I'm trying to use: > >> >> >> >=3D3D20 > >> >> >> > Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 G= > >NU/=3D > >> >Lin=3D3D > >> >> >ux > >> >> >> >=3D3D20 > >> >> >> > The most recent archives I have for Linux are: > >> >> >> >=3D3D20 > >> >> >> > cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D3D20 > >> >> >> >=3D3D20 > >> >> >> > And they don't seem to work on this system: I can compile a progr= > >am > >> >> >> > but when I try to run it=3D3D2C it says "Segmentation fault". Can= > > anyo=3D > >> >ne > >> >> >> > help? (My understanding is that I need 5.5.1 or later...) > >> >> >> >=3D3D20 > >> >> >> > Mika > >> >> >> >=3D3D20 > >> >> >>=3D3D20 > >> >> > > >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ > >> >> >Content-Type: text/html=3D3B charset=3D3D"iso-8859-1" > >> >> >Content-Transfer-Encoding: quoted-printable > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > =3D3D3B >archive=3D > >> >s" targ=3D3D > >> >> >et=3D3D3D_blank>http://modula3.elegosoft.co= > >m/cm3/u=3D > >> >ploaded=3D3D > >> >> >-archives
> >> >> >?
> >> >> > =3D3D3B
> >> >> >I can make another later this week.
> >> >> > =3D3D3B
> >> >> >All you need is a working cm3 on any system.
> >> >> >>From there you can build the whole system=3D3D2C targeting any syste= > >m. >> >> > >> >> >As long as that cm3 understands LONGINT and your target system.
> >> >> >And it is easier=3D3D2C but not necessary=3D3D2C if you have Python. = > >:)
> >> >> > =3D3D3B
> >> >> > =3D3D3B- Jay

 =3D3D3B
>=3D3D3B Date: Tue=3D3D2C = > >31 Mar 2009=3D > >> > 15:43:41 -=3D3D > >> >> >0500
>=3D3D3B From: martinbishop at bellsouth.net
>=3D3D3B To:= > > mika at a=3D > >> >sync.ca=3D3D > >> >> >ltech.edu
>=3D3D3B CC: m3devel at elegosoft.com
>=3D3D3B Subje= > >ct: Re:=3D > >> > [M3dev=3D3D > >> >> >el] Help finding CM3 compiler for Linux?
>=3D3D3B
>=3D3D3B= > > Not su=3D > >> >re if t=3D3D > >> >> >his helps=3D3D2C but on my linux system:
>=3D3D3B
>=3D3D3B= > > Critical=3D > >> > Mass Mod=3D3D > >> >> >ula-3 version d5.7.0
>=3D3D3B last updated: 2008-03-16
>=3D= > >3D3B co=3D > >> >mpiled:=3D3D > >> >> > 2008-08-14 00:56:14
>=3D3D3B configuration: /usr/local/cm3/bin/= > >cm3.c=3D > >> >fg >> >> >>>=3D3D3B
>=3D3D3B Linux thinkpad 2.6.27-11-generic #1 SMP Th= > >u Jan 2=3D > >> >9 19:24=3D3D > >> >> >:39 UTC 2009
>=3D3D3B i686 GNU/Linux
>=3D3D3B
>=3D3D3= > >B
>=3D > >> >=3D3D3B I don=3D3D > >> >> >'t have the cm3 tarball=3D3D2C but I do have the sources in cm3/ stil= > >l. >> >>>=3D3D > >> >> >=3D3D3B
>=3D3D3B Mika Nystrom wrote:
>=3D3D3B >=3D3D3B H= > >ello everyo=3D > >> >ne=3D3D2C
&g=3D3D > >> >> >t=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B This is=3D3D2C for me= > >=3D3D2C a most un=3D > >> >fortunate time =3D3D > >> >> >for the CM3 servers to
>=3D3D3B >=3D3D3B have crashed. I'm tea= > >ching a=3D > >> > class =3D3D > >> >> >using Modula-3=3D3D2C and we need a
>=3D3D3B >=3D3D3B compiler= > >... here'=3D > >> >s the una=3D3D > >> >> >me of the system I'm trying to use:
>=3D3D3B >=3D3D3B
>= > >=3D3D3B &g=3D > >> >t=3D3D3B Linu=3D3D > >> >> >x lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Linux= > > >> >>&g=3D3D > >> >> >t=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B The most recent archive= > >s I have fo=3D > >> >r Linux are=3D3D > >> >> >:
>=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B cm3-min-POSIX-LI= > >NUXLIBC6-5.=3D > >> >4.0.tgz cm3=3D3D > >> >> >-src-all-5.4.0.tgz
>=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3= > >B And they =3D > >> >don't seem =3D3D > >> >> >to work on this system: I can compile a program
>=3D3D3B >=3D3= > >D3B but=3D > >> > when I=3D3D > >> >> > try to run it=3D3D2C it says "Segmentation fault". Can anyone
>= > >=3D3D3B=3D > >> > >=3D3D3B=3D3D > >> >> > help? (My understanding is that I need 5.5.1 or later...)
>=3D3= > >D3B &=3D > >> >gt=3D3D3B=3D3D > >> >> >
>=3D3D3B >=3D3D3B Mika
>=3D3D3B >=3D3D3B
>=3D3D= > >3B
>> >> > >> >> >=3D3D > >> >> > > >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_-- > >> > > >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ > >> >Content-Type: text/html=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> > > >> > > >> > > >> > > >> >These archives do have a different format=3D2C yes.
> >> >But it isn't a bad format.
> >> >cminstall is pretty worthless imho.
> >> >Extract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.
> >> > =3D3B
> >> > =3D3B- Jay

 =3D3B
>=3D3B To: jay.krell at cornell.edu<= > >BR>>=3D3B=3D > >> > Subject: Re: [M3devel] Help finding CM3 compiler for Linux?
>=3D3= > >B Dat=3D > >> >e: Tue=3D2C 31 Mar 2009 15:56:11 -0700
>=3D3B From: mika at async.calt= > >ech.edu=3D > >> >
>=3D3B
>=3D3B No=3D2C I'm sorry...
>=3D3B
>=3D3B = > >the archives =3D > >> >do not have the usual format. I'm expecting to unpack
>=3D3B and ru= > >n "cm=3D > >> >install" and then unpack the big source tar on top and
>=3D3B buil= > >d tha=3D > >> >t. But there's no cminstall in the archive on this page.
>=3D3B Thi= > >s is =3D > >> >"the normal procedure" for installing CM3=3D2C no? It's what
>=3D3B= > > the in=3D > >> >structions say to do=3D2C as well...
>=3D3B
>=3D3B And the li= > >nk from t=3D > >> >he "Download" page is broken (to -d5.5.0.tgz).
>=3D3B
>=3D3B = > >Mika >> >>>=3D3B
>=3D3B Jay writes:
>=3D3B >=3D3B--_806446ae-8d10-= > >4d74-8eea-5=3D > >> >1aa365e9204_
>=3D3B >=3D3BContent-Type: text/plain=3D3B charset= > >=3D3D"iso-885=3D > >> >9-1"
>=3D3B >=3D3BContent-Transfer-Encoding: quoted-printable
= > >>=3D3B =3D > >> >>=3D3B
>=3D3B >=3D3B
>=3D3B >=3D3B http://modula3.elegos= > >oft.com/cm3/u=3D > >> >ploaded-archives
>=3D3B >=3D3B
>=3D3B >=3D3B?
>=3D3B = > >>=3D3B
>=3D > >> >=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B
>=3D3B >=3D3BI can mak= > >e another later t=3D > >> >his week.
>=3D3B >=3D3B
>=3D3B >=3D3B=3D3D20
>=3D3B &= > >gt=3D3B
>=3D3B=3D > >> > >=3D3BAll you need is a working cm3 on any system.
>=3D3B >=3D= > >3B
>=3D > >> >=3D3B >=3D3B>=3D3BFrom there you can build the whole system=3D3D2C t= > >argeting an=3D > >> >y system.
>=3D3B >=3D3B
>=3D3B >=3D3BAs long as that cm3 u= > >nderstands =3D > >> >LONGINT and your target system.
>=3D3B >=3D3B
>=3D3B >=3D3= > >BAnd it is =3D > >> >easier=3D3D2C but not necessary=3D3D2C if you have Python. :)
>=3D3= > >B >=3D3B<=3D > >> >BR>>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B
>=3D3B >=3D3B - = > >Jay
>=3D3B >=3D > >> >=3D3B
>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B Date: Tue= > >=3D3D2C 31 Mar 2009=3D > >> > 15:43:41 -0500
>=3D3B >=3D3B>=3D3B From: martinbishop at bellsout= > >h.net
=3D > >> >>=3D3B >=3D3B>=3D3B To: mika at async.caltech.edu
>=3D3B >=3D3= > >B>=3D3B CC: m=3D > >> >3devel at elegosoft.com
>=3D3B >=3D3B>=3D3B Subject: Re: [M3devel]= > > Help fin=3D > >> >ding CM3 compiler for Linux?
>=3D3B >=3D3B>=3D3B=3D3D20
>= > >=3D3B >=3D3B&g=3D > >> >t=3D3B Not sure if this helps=3D3D2C but on my linux system:
>=3D3B= > > >=3D3B&g=3D > >> >t=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B Critical Mass Modula-3 versio= > >n d5.7.0
&=3D > >> >gt=3D3B >=3D3B>=3D3B last updated: 2008-03-16
>=3D3B >=3D3B&g= > >t=3D3B compiled=3D > >> >: 2008-08-14 00:56:14
>=3D3B >=3D3B>=3D3B configuration: /usr/l= > >ocal/cm3/=3D > >> >bin/cm3.cfg
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B >=3D3B>= > >=3D3B Linux thinkp=3D > >> >ad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009
>=3D3B >= > >=3D3B&g=3D > >> >t=3D3B i686 GNU/Linux
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B &g= > >t=3D3B>=3D3B=3D3D20=3D > >> >
>=3D3B >=3D3B>=3D3B I don't have the cm3 tarball=3D3D2C but I = > >do have the=3D > >> > sources in cm3/ still.
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B = > >>=3D3B>=3D3B =3D > >> >Mika Nystrom wrote:
>=3D3B >=3D3B>=3D3B >=3D3B Hello everyone= > >=3D3D2C
&g=3D > >> >t=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B >= > >=3D3B This is=3D3D2C fo=3D > >> >r me=3D3D2C a most unfortunate time for the CM3 servers to
>=3D3B &= > >gt=3D3B&g=3D > >> >t=3D3B >=3D3B have crashed. I'm teaching a class using Modula-3=3D3D2C= > > and we n=3D > >> >eed a
>=3D3B >=3D3B>=3D3B >=3D3B compiler... here's the uname= > > of the sys=3D > >> >tem I'm trying to use:
>=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
&= > >gt=3D3B >=3D3B&=3D > >> >gt=3D3B >=3D3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2= > >008 i68=3D > >> >6 GNU/Lin=3D3D
>=3D3B >=3D3Bux
>=3D3B >=3D3B>=3D3B >= > >=3D3B=3D3D20
>=3D > >> >=3D3B >=3D3B>=3D3B >=3D3B The most recent archives I have for Linu= > >x are:
&=3D > >> >gt=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B &g= > >t=3D3B cm3-min-POSIX-=3D > >> >LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D3D20
>=3D3B >=3D3B&g= > >t=3D3B >=3D > >> >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B >=3D3B And they don't seem t= > >o work on this =3D > >> >system: I can compile a program
>=3D3B >=3D3B>=3D3B >=3D3B bu= > >t when I tr=3D > >> >y to run it=3D3D2C it says "Segmentation fault". Can anyone
>=3D3B = > >>=3D3B&=3D > >> >gt=3D3B >=3D3B help? (My understanding is that I need 5.5.1 or later..= > >.)
&=3D > >> >gt=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B &g= > >t=3D3B Mika
>=3D3B=3D > >> > >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B=3D3D20 >>>=3D3B >=3D3B
&=3D > >> >gt=3D3B >=3D3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>=3D3B >= > >=3D3BConten=3D > >> >t-Type: text/html=3D3B charset=3D3D"iso-8859-1"
>=3D3B >=3D3BCont= > >ent-Transfe=3D > >> >r-Encoding: quoted-printable
>=3D3B >=3D3B
>=3D3B >=3D3B&l= > >t=3D3Bhtml>=3D > >> >=3D3B
>=3D3B >=3D3B<=3D3Bhead>=3D3B
>=3D3B >=3D3B<= > >=3D3Bstyle>=3D3B
&=3D > >> >gt=3D3B >=3D3B.hmmessage P
>=3D3B >=3D3B{
>=3D3B >=3D3Bm= > >argin:0px=3D3D3B<=3D > >> >BR>>=3D3B >=3D3Bpadding:0px
>=3D3B >=3D3B}
>=3D3B >=3D= > >3Bbody.hmmessag=3D > >> >e
>=3D3B >=3D3B{
>=3D3B >=3D3Bfont-size: 10pt=3D3D3B
&g= > >t=3D3B >=3D3Bfo=3D > >> >nt-family:Verdana
>=3D3B >=3D3B}
>=3D3B >=3D3B<=3D3B/sty= > >le>=3D3B
&=3D > >> >gt=3D3B >=3D3B<=3D3B/head>=3D3B
>=3D3B >=3D3B<=3D3Bbody c= > >lass=3D3D3D'hmmessa=3D > >> >ge'>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BA href=3D3D3= > >D"http://modula3.=3D > >> >elegosoft.com/cm3/uploaded-archives" targ=3D3D
>=3D3B >=3D3Bet=3D= > >3D3D_blank&=3D > >> >gt=3D3B<=3D3BFONT color=3D3D3D#0068cf>=3D3Bhttp://modula3.elegosoft.= > >com/cm3/upl=3D > >> >oaded=3D3D
>=3D3B >=3D3B-archives<=3D3B/FONT>=3D3B<=3D3B/A&= > >gt=3D3B<=3D3BBR&g=3D > >> >t=3D3B
>=3D3B >=3D3B?<=3D3BBR>=3D3B
>=3D3B >=3D3B&= > >=3D3Bnbsp=3D3D3B<=3D3B=3D > >> >BR>=3D3B
>=3D3B >=3D3BI can make another later this week.<=3D= > >3BBR>=3D3B<=3D > >> >BR>>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
>=3D3B &= > >gt=3D3BAll you need=3D > >> > is a working cm3 on any system.<=3D3BBR>=3D3B
>=3D3B >=3D3B&= > >gt=3D3BFrom t=3D > >> >here you can build the whole system=3D3D2C targeting any system.<=3D3B= > >BR>=3D > >> >=3D3B
>=3D3B >=3D3BAs long as that cm3 understands LONGINT and yo= > >ur target=3D > >> > system.<=3D3BBR>=3D3B
>=3D3B >=3D3BAnd it is easier=3D3D2C b= > >ut not necess=3D > >> >ary=3D3D2C if you have Python. :)<=3D3BBR>=3D3B
>=3D3B >=3D3B= > >&=3D3Bnbsp=3D > >> >=3D3D3B<=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B- Jay&= > >lt=3D3BBR>=3D3B<=3D > >> >=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B = > >Date: Tue=3D3D2C 31 M=3D > >> >ar 2009 15:43:41 -=3D3D
>=3D3B >=3D3B0500<=3D3BBR>=3D3B&= > >=3D3Bgt=3D3D3B From=3D > >> >: martinbishop at bellsouth.net<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B To: mik= > >a at async.ca=3D > >> >=3D3D
>=3D3B >=3D3Bltech.edu<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B = > >CC: m3devel at elego=3D > >> >soft.com<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Subject: Re: [M3dev=3D3D >>>=3D3B >=3D > >> >=3D3Bel] Help finding CM3 compiler for Linux?<=3D3BBR>=3D3B&=3D3B= > >gt=3D3D3B <=3D > >> >=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Not sure if t=3D3D
>=3D3B >=3D3= > >Bhis helps=3D3D2C b=3D > >> >ut on my linux system:<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B <=3D3BBR>= > >=3D3B&=3D3Bgt=3D > >> >=3D3D3B Critical Mass Mod=3D3D
>=3D3B >=3D3Bula-3 version d5.7.0&= > >lt=3D3BBR>=3D > >> >=3D3B&=3D3Bgt=3D3D3B last updated: 2008-03-16<=3D3BBR>=3D3B&= > >=3D3Bgt=3D3D3B comp=3D > >> >iled:=3D3D
>=3D3B >=3D3B 2008-08-14 00:56:14<=3D3BBR>=3D3B&am= > >p=3D3Bgt=3D3D3B c=3D > >> >onfiguration: /usr/local/cm3/bin/cm3.cfg<=3D3BBR=3D3D
>=3D3B >= > >=3D3B>=3D3B&=3D > >> >amp=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Linux thinkpad 2.= > >6.27-11-generic=3D > >> > #1 SMP Thu Jan 29 19:24=3D3D
>=3D3B >=3D3B:39 UTC 2009<=3D3BBR= > >>=3D3B&=3D > >> >=3D3Bgt=3D3D3B i686 GNU/Linux<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B <=3D= > >3BBR>=3D3B&=3D3B=3D > >> >gt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B I don=3D3D
>=3D3B &g= > >t=3D3B't have the c=3D > >> >m3 tarball=3D3D2C but I do have the sources in cm3/ still.<=3D3BBR>= > >=3D3B&=3D > >> >=3D3Bgt=3D3D
>=3D3B >=3D3B=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt= > >=3D3D3B Mika Nystrom wr=3D > >> >ote:<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B Hello everyo= > >ne=3D3D2C<=3D3BBR=3D > >> >>=3D3B&=3D3Bg=3D3D
>=3D3B >=3D3Bt=3D3D3B &=3D3Bgt=3D3D3B = > ><=3D3BBR>=3D3B&=3D > >> >=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B This is=3D3D2C for me=3D3D2C a most un= > >fortunate time =3D > >> >=3D3D
>=3D3B >=3D3Bfor the CM3 servers to<=3D3BBR>=3D3B&= > >=3D3Bgt=3D3D3B &=3D > >> >=3D3Bgt=3D3D3B have crashed. I'm teaching a class =3D3D
>=3D3B >= > >=3D3Busing Mod=3D > >> >ula-3=3D3D2C and we need a<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3B= > >gt=3D3D3B compile=3D > >> >r... here's the una=3D3D
>=3D3B >=3D3Bme of the system I'm trying= > > to use:&=3D > >> >lt=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3= > >B&=3D3Bgt=3D3D3B &am=3D > >> >p=3D3Bgt=3D3D3B Linu=3D3D
>=3D3B >=3D3Bx lara 2.6.24ugcs1 #4 SMP = > >Mon Feb 11 10=3D > >> >:53:03 PST 2008 i686 GNU/Linux<=3D3BBR>=3D3B&=3D3Bg=3D3D
>= > >=3D3B >=3D3Bt=3D > >> >=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3= > >Bgt=3D3D3B The most r=3D > >> >ecent archives I have for Linux are=3D3D
>=3D3B >=3D3B:<=3D3BBR= > >>=3D3B&=3D > >> >=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &= > >amp=3D3Bgt=3D3D3B cm3-m=3D > >> >in-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D3D
>=3D3B >=3D3B-src-all-5.4.= > >0.tgz <=3D > >> =3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&a= > >mp=3D3Bgt=3D3D3B &=3D > >> >=3D3Bgt=3D3D3B And they don't seem =3D3D
>=3D3B >=3D3Bto work on = > >this system: =3D > >> >I can compile a program<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt= > >=3D3D3B but when=3D > >> > I=3D3D
>=3D3B >=3D3B try to run it=3D3D2C it says "Segmentation = > >fault". Can=3D > >> > anyone<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B=3D3D
&= > >gt=3D3B >=3D3B help=3D > >> >? (My understanding is that I need 5.5.1 or later...)<=3D3BBR>=3D3B&= > >amp=3D3Bg=3D > >> >t=3D3D3B &=3D3Bgt=3D3D3B=3D3D
>=3D3B >=3D3B <=3D3BBR>=3D3B= > >&=3D3Bgt=3D3D3B &=3D > >> >=3D3Bgt=3D3D3B Mika<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D= > >3B <=3D3BBR>=3D3B&a=3D > >> >mp=3D3Bgt=3D3D3B <=3D3BBR>=3D3B<=3D3B/body>=3D3B
>=3D3B >= > >=3D3B<=3D3B/html>=3D > >> >=3D3B=3D3D
>=3D3B >=3D3B
>=3D3B >=3D3B--_806446ae-8d10-4d7= > >4-8eea-51aa365e=3D > >> >9204_--
> >> >=3D > >> > > >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_-- > > > >--_55339e45-8c85-4ab6-9440-0d2131bbad69_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >Maybe not.
> >Hm. That is bug. There is use with a cvs tree=2C and use without.
> >I must have broken use without.
> > =3B
> >Try this:
> >export CM3_ROOT=3Droot of cm3 cvs (for me this is /dev2/cm3=2C
> >for you=2C maybe $HOME/cm3?)
> >rm =3B$HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6
> ># *Common and *common in one command
rm =3B$HOME/cm3/cm3-min-LINUXLI= > >BC6-d5.7.0/bin/*ommon
cp root of cm3 cvs/m3-sys/cminstall/src/config/cm3= > >.cfg $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin
> > =3B
> >The .cfg will delegate out to the cvs tree.
> >I don't like having two copies of files..having to keep them in sync..
> > =3BThough the archives are meant to work standalone=2C without CVS. >> > > =3B But I don't test that so much oops sorry.
> >That /might/ not be the right file=2C but it is close.
> > =3B
> > =3B- Jay

 =3B
>=3B To: jay.krell at cornell.edu
>=3B= > > CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] Help finding CM= > >3 compiler for Linux?
>=3B Date: Tue=2C 31 Mar 2009 22:59:18 -0700 >>>=3B From: mika at async.caltech.edu
>=3B
>=3B
>=3B Is the= > >re any documentation for this format beyond what you just
>=3B wrote? = > >Where?
>=3B
>=3B terpsichore-14: cm3
>=3B --- building in .= > >./LINUXLIBC6 ---
>=3B
>=3B new source ->=3B compiling Main.m3<= > >BR>>=3B "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.co= > >mmon"=2C line 169: quake runtime error: undefined variable: ROOT
>=3B = > >
>=3B --procedure-- -line- -file---
>=3B GetM3Back 169 /afs/.ugcs= > >/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common
>=3B _IsM3B= > >ackFlagSupported 181 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin= > >/Unix.common
>=3B IsM3BackFlagSupported 193 /afs/.ugcs/user/mika/cm3/c= > >m3-min-LINUXLIBC6-d5.7.0/bin/Unix.common
>=3B GetM3BackFlag 197 /afs/.= > >ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common
>=3B m3_b= > >ackend 62 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.commo= > >n
>=3B program -- <=3Bbuiltin>=3B
>=3B 6 /afs/.ugcs.caltech.e= > >du/user/mika/test/LINUXLIBC6/m3make.args
>=3B
>=3B
>=3B Fa= > >tal Error: procedure "m3_backend" defined in "/afs/.ugcs/user/mika/cm3/cm3-= > >min-LINUXLIBC6-d5.7.0/bin/cm3.cfg" failed.
>=3B
>=3B Jay writes:= > >
>=3B >=3B--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_
>=3B >=3BC= > >ontent-Type: text/plain=3B charset=3D"iso-8859-1"
>=3B >=3BContent-T= > >ransfer-Encoding: quoted-printable
>=3B >=3B
>=3B >=3B
>= > >=3B >=3BThese archives do have a different format=3D2C yes.
>=3B >= > >=3B
>=3B >=3BBut it isn't a bad format.
>=3B >=3B
>=3B &= > >gt=3Bcminstall is pretty worthless imho.
>=3B >=3B
>=3B >=3BE= > >xtract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.
>=3B >=3B
&= > >gt=3B >=3B=3D20
>=3B >=3B
>=3B >=3B - Jay
>=3B >=3B<= > >BR>>=3B >=3B=3D20
>=3B >=3B>=3B To: jay.krell at cornell.edu
&= > >gt=3B >=3B>=3B Subject: Re: [M3devel] Help finding CM3 compiler for Lin= > >ux?=3D20
>=3B >=3B>=3B Date: Tue=3D2C 31 Mar 2009 15:56:11 -0700 >R>>=3B >=3B>=3B From: mika at async.caltech.edu
>=3B >=3B>=3B= > >=3D20
>=3B >=3B>=3B No=3D2C I'm sorry...
>=3B >=3B>=3B=3D= > >20
>=3B >=3B>=3B the archives do not have the usual format. I'm ex= > >pecting to unpack
>=3B >=3B>=3B and run "cminstall" and then unpac= > >k the big source tar on top and=3D20
>=3B >=3B>=3B build that. But= > > there's no cminstall in the archive on this page.
>=3B >=3B>=3B T= > >his is "the normal procedure" for installing CM3=3D2C no? It's what
>= > >=3B >=3B>=3B the instructions say to do=3D2C as well...
>=3B >= > >=3B>=3B=3D20
>=3B >=3B>=3B And the link from the "Download" page= > > is broken (to -d5.5.0.tgz).
>=3B >=3B>=3B=3D20
>=3B >=3B&g= > >t=3B Mika
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B Jay writes: >>>=3B >=3B>=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>= > >=3B >=3B>=3B >=3BContent-Type: text/plain=3D3B charset=3D3D"iso-8859-= > >1"
>=3B >=3B>=3B >=3BContent-Transfer-Encoding: quoted-printable= > >
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B
>=3B >= > >=3B>=3B >=3B http://modula3.elegosoft.com/cm3/uploaded-archives
>= > >=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B?
>=3B >=3B>= > >=3B >=3B
>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >= > >=3B
>=3B >=3B>=3B >=3BI can make another later this week.
>= > >=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B=3D3D20
>=3B >= > >=3B>=3B >=3B
>=3B >=3B>=3B >=3BAll you need is a working cm3= > > on any system.
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B= > >>=3BFrom there you can build the whole system=3D3D2C targeting any system= > >.
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3BAs long as tha= > >t cm3 understands LONGINT and your target system.
>=3B >=3B>=3B &g= > >t=3B
>=3B >=3B>=3B >=3BAnd it is easier=3D3D2C but not necessary= > >=3D3D2C if you have Python. :)
>=3B >=3B>=3B >=3B
>=3B >= > >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B
>=3B >=3B>= > >=3B >=3B - Jay
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >= > >=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Date: Tue=3D3D2C 31 Mar 2009= > > 15:43:41 -0500
>=3B >=3B>=3B >=3B>=3B From: martinbishop at bell= > >south.net
>=3B >=3B>=3B >=3B>=3B To: mika at async.caltech.edu >>>=3B >=3B>=3B >=3B>=3B CC: m3devel at elegosoft.com
>=3B >= > >=3B>=3B >=3B>=3B Subject: Re: [M3devel] Help finding CM3 compiler for= > > Linux?
>=3B >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B &= > >gt=3B>=3B Not sure if this helps=3D3D2C but on my linux system:
>=3B= > > >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Criti= > >cal Mass Modula-3 version d5.7.0
>=3B >=3B>=3B >=3B>=3B last u= > >pdated: 2008-03-16
>=3B >=3B>=3B >=3B>=3B compiled: 2008-08-14= > > 00:56:14
>=3B >=3B>=3B >=3B>=3B configuration: /usr/local/cm3= > >/bin/cm3.cfg
>=3B >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>= > >=3B >=3B>=3B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:3= > >9 UTC 2009
>=3B >=3B>=3B >=3B>=3B i686 GNU/Linux
>=3B >= > >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B=3D3D20 >>>=3B >=3B>=3B >=3B>=3B I don't have the cm3 tarball=3D3D2C but I= > > do have the sources in cm3/ st=3D
>=3B >=3Bill.
>=3B >=3B>= > >=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Mika Nystrom wr= > >ote:
>=3B >=3B>=3B >=3B>=3B >=3B Hello everyone=3D3D2C
&g= > >t=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B&= > >gt=3B >=3B This is=3D3D2C for me=3D3D2C a most unfortunate time for the C= > >M3 servers=3D
>=3B >=3B to
>=3B >=3B>=3B >=3B>=3B >= > >=3B have crashed. I'm teaching a class using Modula-3=3D3D2C and we need a<= > >BR>>=3B >=3B>=3B >=3B>=3B >=3B compiler... here's the uname of = > >the system I'm trying to use:
>=3B >=3B>=3B >=3B>=3B >=3B=3D= > >3D20
>=3B >=3B>=3B >=3B>=3B >=3B Linux lara 2.6.24ugcs1 #4 S= > >MP Mon Feb 11 10:53:03 PST 2008 i686 GNU/=3D
>=3B >=3BLin=3D3D
&g= > >t=3B >=3B>=3B >=3Bux
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D2= > >0
>=3B >=3B>=3B >=3B>=3B >=3B The most recent archives I hav= > >e for Linux are:
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>= > >=3B >=3B>=3B >=3B>=3B >=3B cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3= > >-src-all-5.4.0.tgz=3D3D20
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20= > >
>=3B >=3B>=3B >=3B>=3B >=3B And they don't seem to work on = > >this system: I can compile a program
>=3B >=3B>=3B >=3B>=3B &g= > >t=3B but when I try to run it=3D3D2C it says "Segmentation fault". Can anyo= > >=3D
>=3B >=3Bne
>=3B >=3B>=3B >=3B>=3B >=3B help? (My= > > understanding is that I need 5.5.1 or later...)
>=3B >=3B>=3B >= > >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B >=3B Mika
= > >>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >= > >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >= > >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>=3B >=3B>=3B >=3BCo= > >ntent-Type: text/html=3D3B charset=3D3D"iso-8859-1"
>=3B >=3B>=3B = > >>=3BContent-Transfer-Encoding: quoted-printable
>=3B >=3B>=3B &g= > >t=3B
>=3B >=3B>=3B >=3B<=3Bhtml>=3B
>=3B >=3B>=3B &= > >gt=3B<=3Bhead>=3B
>=3B >=3B>=3B >=3B<=3Bstyle>=3B
>= > >=3B >=3B>=3B >=3B.hmmessage P
>=3B >=3B>=3B >=3B{
>= > >=3B >=3B>=3B >=3Bmargin:0px=3D3D3B
>=3B >=3B>=3B >=3Bpaddi= > >ng:0px
>=3B >=3B>=3B >=3B}
>=3B >=3B>=3B >=3Bbody.hmm= > >essage
>=3B >=3B>=3B >=3B{
>=3B >=3B>=3B >=3Bfont-siz= > e: 10pt=3D3D3B
>=3B >=3B>=3B >=3Bfont-family:Verdana
>=3B &= > >gt=3B>=3B >=3B}
>=3B >=3B>=3B >=3B<=3B/style>=3B
>= > >=3B >=3B>=3B >=3B<=3B/head>=3B
>=3B >=3B>=3B >=3B<= > >=3Bbody class=3D3D3D'hmmessage'>=3B
>=3B >=3B>=3B >=3B&=3Bn= > >bsp=3D3D3B<=3BA href=3D3D3D"http://modula3.elegosoft.com/cm3/uploaded-arc= > >hive=3D
>=3B >=3Bs" targ=3D3D
>=3B >=3B>=3B >=3Bet=3D3D3D= > >_blank>=3B<=3BFONT color=3D3D3D#0068cf>=3Bhttp://modula3.elegosoft.co= > >m/cm3/u=3D
>=3B >=3Bploaded=3D3D
>=3B >=3B>=3B >=3B-archi= > >ves<=3B/FONT>=3B<=3B/A>=3B<=3BBR>=3B
>=3B >=3B>=3B >= > >=3B?<=3BBR>=3B
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR&= > >gt=3B
>=3B >=3B>=3B >=3BI can make another later this week.<= > >=3BBR>=3B
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B >R>>=3B >=3B>=3B >=3BAll you need is a working cm3 on any system.<= > >=3BBR>=3B
>=3B >=3B>=3B >=3B>=3BFrom there you can build the= > > whole system=3D3D2C targeting any system.<=3BBR=3D
>=3B >=3B>= > >=3B
>=3B >=3B>=3B >=3BAs long as that cm3 understands LONGINT an= > >d your target system.<=3BBR>=3B
>=3B >=3B>=3B >=3BAnd it is = > >easier=3D3D2C but not necessary=3D3D2C if you have Python. :)<=3BBR>=3B= > >
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B
>=3B &g= > >t=3B>=3B >=3B&=3Bnbsp=3D3D3B- Jay<=3BBR>=3B<=3BBR>=3B&=3B= > >nbsp=3D3D3B<=3BBR>=3B&=3Bgt=3D3D3B Date: Tue=3D3D2C 31 Mar 2009=3D >R>>=3B >=3B 15:43:41 -=3D3D
>=3B >=3B>=3B >=3B0500<=3BBR&g= > >t=3B&=3Bgt=3D3D3B From: martinbishop at bellsouth.net<=3BBR>=3B&=3Bg= > >t=3D3D3B To: mika at a=3D
>=3B >=3Bsync.ca=3D3D
>=3B >=3B>=3B = > >>=3Bltech.edu<=3BBR>=3B&=3Bgt=3D3D3B CC: m3devel at elegosoft.com<= > >=3BBR>=3B&=3Bgt=3D3D3B Subject: Re:=3D
>=3B >=3B [M3dev=3D3D >>>=3B >=3B>=3B >=3Bel] Help finding CM3 compiler for Linux?<=3BBR= > >>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B Not su=3D
>=3B &= > >gt=3Bre if t=3D3D
>=3B >=3B>=3B >=3Bhis helps=3D3D2C but on my l= > >inux system:<=3BBR>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B C= > >ritical=3D
>=3B >=3B Mass Mod=3D3D
>=3B >=3B>=3B >=3Bula-= > >3 version d5.7.0<=3BBR>=3B&=3Bgt=3D3D3B last updated: 2008-03-16<= > >=3BBR>=3B&=3Bgt=3D3D3B co=3D
>=3B >=3Bmpiled:=3D3D
>=3B &g= > >t=3B>=3B >=3B 2008-08-14 00:56:14<=3BBR>=3B&=3Bgt=3D3D3B configu= > >ration: /usr/local/cm3/bin/cm3.c=3D
>=3B >=3Bfg<=3BBR=3D3D
>= > >=3B >=3B>=3B >=3B>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3= > >B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 2=3D
>=3B >=3B9 19= > >:24=3D3D
>=3B >=3B>=3B >=3B:39 UTC 2009<=3BBR>=3B&=3Bgt= > >=3D3D3B i686 GNU/Linux<=3BBR>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bg= > >t=3D3D3B <=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3D3B I don=3D3D
&= > >gt=3B >=3B>=3B >=3B't have the cm3 tarball=3D3D2C but I do have the s= > >ources in cm3/ still.<=3BBR=3D
>=3B >=3B>=3B&=3Bgt=3D3D
&g= > >t=3B >=3B>=3B >=3B=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B Mika Nystrom= > > wrote:<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B Hello everyo=3D
&= > >gt=3B >=3Bne=3D3D2C<=3BBR>=3B&=3Bg=3D3D
>=3B >=3B>=3B >= > >=3Bt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3= > >B This is=3D3D2C for me=3D3D2C a most un=3D
>=3B >=3Bfortunate time = > >=3D3D
>=3B >=3B>=3B >=3Bfor the CM3 servers to<=3BBR>=3B&= > >=3Bgt=3D3D3B &=3Bgt=3D3D3B have crashed. I'm teaching a=3D
>=3B >= > >=3B class =3D3D
>=3B >=3B>=3B >=3Busing Modula-3=3D3D2C and we n= > >eed a<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B compiler... here'=3D >R>>=3B >=3Bs the una=3D3D
>=3B >=3B>=3B >=3Bme of the system= > > I'm trying to use:<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B <=3BBR= > >>=3B&=3Bgt=3D3D3B &=3Bg=3D
>=3B >=3Bt=3D3D3B Linu=3D3D
&g= > >t=3B >=3B>=3B >=3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2= > >008 i686 GNU/Linux<=3BBR=3D
>=3B >=3B>=3B&=3Bg=3D3D
>=3B= > > >=3B>=3B >=3Bt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3= > >B &=3Bgt=3D3D3B The most recent archives I have fo=3D
>=3B >=3Br = > >Linux are=3D3D
>=3B >=3B>=3B >=3B:<=3BBR>=3B&=3Bgt=3D3D3B= > > &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B cm3-min-P= > OSIX-LINUXLIBC6-5.=3D
>=3B >=3B4.0.tgz cm3=3D3D
>=3B >=3B>= > >=3B >=3B-src-all-5.4.0.tgz <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3= > >B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B And they =3D
>=3B &g= > >t=3Bdon't seem =3D3D
>=3B >=3B>=3B >=3Bto work on this system: I= > > can compile a program<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B but= > >=3D
>=3B >=3B when I=3D3D
>=3B >=3B>=3B >=3B try to run i= > >t=3D3D2C it says "Segmentation fault". Can anyone<=3BBR>=3B&=3Bgt=3D= > >3D3B=3D
>=3B >=3B &=3Bgt=3D3D3B=3D3D
>=3B >=3B>=3B >= > >=3B help? (My understanding is that I need 5.5.1 or later...)<=3BBR>=3B= > >&=3Bgt=3D3D3B &=3B=3D
>=3B >=3Bgt=3D3D3B=3D3D
>=3B >=3B= > >>=3B >=3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B Mika<=3BBR&= > >gt=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B <= > >=3BBR>=3B<=3B/body=3D
>=3B >=3B>=3B
>=3B >=3B>=3B >= > >=3B<=3B/html>=3B=3D3D
>=3B >=3B>=3B >=3B
>=3B >=3B>= > >=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_--
>=3B >=3B
&g= > >t=3B >=3B--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_
>=3B >=3BContent= > >-Type: text/html=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer= > >-Encoding: quoted-printable
>=3B >=3B
>=3B >=3B<=3Bhtml>= > >=3B
>=3B >=3B<=3Bhead>=3B
>=3B >=3B<=3Bstyle>=3B
&= > >gt=3B >=3B.hmmessage P
>=3B >=3B{
>=3B >=3Bmargin:0px=3D3B<= > >BR>>=3B >=3Bpadding:0px
>=3B >=3B}
>=3B >=3Bbody.hmmessag= > >e
>=3B >=3B{
>=3B >=3Bfont-size: 10pt=3D3B
>=3B >=3Bfo= > >nt-family:Verdana
>=3B >=3B}
>=3B >=3B<=3B/style>=3B
&= > >gt=3B >=3B<=3B/head>=3B
>=3B >=3B<=3Bbody class=3D3D'hmmessa= > >ge'>=3B
>=3B >=3BThese archives do have a different format=3D2C ye= > >s.<=3BBR>=3B
>=3B >=3BBut it isn't a bad format.<=3BBR>=3B >R>>=3B >=3Bcminstall is pretty worthless imho.<=3BBR>=3B
>=3B = > >>=3BExtract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.<=3BBR>=3B<= > >BR>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp= > >=3D3B- Jay<=3BBR>=3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3B&=3B= > >gt=3D3B To: jay.krell at cornell.edu<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B = > >>=3B Subject: Re: [M3devel] Help finding CM3 compiler for Linux? <=3BBR= > >>=3B&=3Bgt=3D3B Dat=3D
>=3B >=3Be: Tue=3D2C 31 Mar 2009 15:56:1= > >1 -0700<=3BBR>=3B&=3Bgt=3D3B From: mika at async.caltech.edu=3D
>= > >=3B >=3B<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B No=3D2C= > > I'm sorry...<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B the = > >archives =3D
>=3B >=3Bdo not have the usual format. I'm expecting to= > > unpack<=3BBR>=3B&=3Bgt=3D3B and run "cm=3D
>=3B >=3Binstall"= > > and then unpack the big source tar on top and <=3BBR>=3B&=3Bgt=3D3B= > > build tha=3D
>=3B >=3Bt. But there's no cminstall in the archive on= > > this page.<=3BBR>=3B&=3Bgt=3D3B This is =3D
>=3B >=3B"the no= > >rmal procedure" for installing CM3=3D2C no? It's what<=3BBR>=3B&=3Bg= > >t=3D3B the in=3D
>=3B >=3Bstructions say to do=3D2C as well...<=3B= > >BR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B And the link from t=3D<= > >BR>>=3B >=3Bhe "Download" page is broken (to -d5.5.0.tgz).<=3BBR>= > >=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Mika<=3BBR=3D
>=3B &g= > >t=3B>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Jay writes:<=3BBR&g= > >t=3B&=3Bgt=3D3B &=3Bgt=3D3B--_806446ae-8d10-4d74-8eea-5=3D
>=3B = > >>=3B1aa365e9204_<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BContent-Type: = > >text/plain=3D3B charset=3D3D"iso-885=3D
>=3B >=3B9-1"<=3BBR>=3B&= > >amp=3Bgt=3D3B &=3Bgt=3D3BContent-Transfer-Encoding: quoted-printable<= > >=3BBR>=3B&=3Bgt=3D3B =3D
>=3B >=3B&=3Bgt=3D3B<=3BBR>=3B&= > >amp=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B htt= > >p://modula3.elegosoft.com/cm3/u=3D
>=3B >=3Bploaded-archives<=3BBR= > >>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= > >=3D3B?<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D= > >
>=3B >=3B=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &a= > >mp=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BI can make another l= > >ater t=3D
>=3B >=3Bhis week.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= > >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&= > >=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >=3B &= > >amp=3Bgt=3D3BAll you need is a working cm3 on any system.<=3BBR>=3B&= > >=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &= > >amp=3Bgt=3D3B&=3Bgt=3D3BFrom there you can build the whole system=3D3D2C= > > targeting an=3D
>=3B >=3By system.<=3BBR>=3B&=3Bgt=3D3B &= > >=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAs long as that cm3 un= > >derstands =3D
>=3B >=3BLONGINT and your target system.<=3BBR>=3B= > >&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAnd= > > it is =3D
>=3B >=3Beasier=3D3D2C but not necessary=3D3D2C if you ha= > >ve Python. :)<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3B=3D
>=3B= > > >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt= > >=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B - Jay<=3B= > >BR>=3B&=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B<=3BBR>=3B&= > >=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B= > >&=3Bgt=3D3B Date: Tue=3D3D2C 31 Mar 2009=3D
>=3B >=3B 15:43:41 -0= > >500<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B From: martinbi= > >shop at bellsouth.net<=3BBR>=3B=3D
>=3B >=3B&=3Bgt=3D3B &=3Bg= > >t=3D3B&=3Bgt=3D3B To: mika at async.caltech.edu<=3BBR>=3B&=3Bgt=3D3B= > > &=3Bgt=3D3B&=3Bgt=3D3B CC: m=3D
>=3B >=3B3devel at elegosoft.com= > ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B Subject: Re: [M3d= > >evel] Help fin=3D
>=3B >=3Bding CM3 compiler for Linux?<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bg= > >t=3D3B &=3Bgt=3D3B&=3Bg=3D
>=3B >=3Bt=3D3B Not sure if this he= > >lps=3D3D2C but on my linux system:<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= > >3B&=3Bg=3D
>=3B >=3Bt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &am= > >p=3Bgt=3D3B&=3Bgt=3D3B Critical Mass Modula-3 version d5.7.0<=3BBR>= > >=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B last upd= > >ated: 2008-03-16<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B c= > >ompiled=3D
>=3B >=3B: 2008-08-14 00:56:14<=3BBR>=3B&=3Bgt=3D3= > >B &=3Bgt=3D3B&=3Bgt=3D3B configuration: /usr/local/cm3/=3D
>=3B = > >>=3Bbin/cm3.cfg<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B= > >=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B Linux thin= > >kp=3D
>=3B >=3Bad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2= > >009<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bg=3D
>=3B >=3Bt= > >=3D3B i686 GNU/Linux<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D= > >3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20= > >=3D
>=3B >=3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D= > >3B I don't have the cm3 tarball=3D3D2C but I do have the=3D
>=3B >= > >=3B sources in cm3/ still.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B = > >=3D
>=3B >=3BMika Nystrom wrote:<=3BBR>=3B&=3Bgt=3D3B &=3B= > >gt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B Hello everyone=3D3D2C<=3BBR>=3B&am= > >p=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B= > >=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt= > >=3D3B This is=3D3D2C fo=3D
>=3B >=3Br me=3D3D2C a most unfortunate t= > >ime for the CM3 servers to<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B have crashed. I'm teaching a = > >class using Modula-3=3D3D2C and we n=3D
>=3B >=3Beed a<=3BBR>=3B= > >&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B compiler... here= > >'s the uname of the sys=3D
>=3B >=3Btem I'm trying to use:<=3BBR&g= > >t=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3B= > >BR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3B=3D
>=3B >=3Bgt=3D3B &am= > >p=3Bgt=3D3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i68= > >=3D
>=3B >=3B6 GNU/Lin=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= > >3Bux<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3= > >B=3D3D20<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &=3Bgt=3D3B&= > >=3Bgt=3D3B &=3Bgt=3D3B The most recent archives I have for Linux are:<= > >=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B = > >&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt= > >=3D3B &=3Bgt=3D3B cm3-min-POSIX-=3D
>=3B >=3BLINUXLIBC6-5.4.0.tgz= > > cm3-src-all-5.4.0.tgz=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&am= > >p=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B=3D3D20<=3BBR>=3B&=3Bg= > >t=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B And they don't seem to w= > >ork on this =3D
>=3B >=3Bsystem: I can compile a program<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B but when I tr= > >=3D
>=3B >=3By to run it=3D3D2C it says "Segmentation fault". Can an= > >yone<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3B=3D
>=3B >=3Bg= > >t=3D3B &=3Bgt=3D3B help? (My understanding is that I need 5.5.1 or later= > >...)<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bg= > >t=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Bgt=3D3B &=3Bgt=3D3B Mika<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >= > >=3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3B= > >gt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &am= > >p=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B-= > >-_806446ae-8d10-4d74-8eea-51aa365e9204_<=3BBR>=3B&=3Bgt=3D3B &=3B= > >gt=3D3BConten=3D
>=3B >=3Bt-Type: text/html=3D3B charset=3D3D"iso-88= > >59-1"<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BContent-Transfe=3D
>= > >=3B >=3Br-Encoding: quoted-printable<=3BBR>=3B&=3Bgt=3D3B &=3Bg= > >t=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3Bhtml&=3Bg= > >t=3D
>=3B >=3B=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Blt=3D3Bhead&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Blt=3D3Bstyle&=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D= > >3B &=3Bgt=3D3B.hmmessage P<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B{&l= > >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bmargin:0px=3D3D3B<=3B=3D
>= > >=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bpadding:0px<=3BBR>=3B&am= > >p=3Bgt=3D3B &=3Bgt=3D3B}<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bbody.= > >hmmessag=3D
>=3B >=3Be<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B{&l= > >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfont-size: 10pt=3D3D3B<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3Bfo=3D
>=3B >=3Bnt-family:Verdana<= > >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B}<=3BBR>=3B&=3Bgt=3D3B &= > >=3Bgt=3D3B&=3Blt=3D3B/style&=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>= > >=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3B/head&=3Bgt=3D3B<=3BBR&g= > >t=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3Bbody class=3D3D3D'hmmessa=3D= > >
>=3B >=3Bge'&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= > >3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BA href=3D3D3D"http://modula3.=3D<= > >BR>>=3B >=3Belegosoft.com/cm3/uploaded-archives" targ=3D3D<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3Bet=3D3D3D_blank&=3B=3D
>=3B >=3Bg= > >t=3D3B&=3Blt=3D3BFONT color=3D3D3D#0068cf&=3Bgt=3D3Bhttp://modula3.el= > >egosoft.com/cm3/upl=3D
>=3B >=3Boaded=3D3D<=3BBR>=3B&=3Bgt=3D= > >3B &=3Bgt=3D3B-archives&=3Blt=3D3B/FONT&=3Bgt=3D3B&=3Blt=3D3B/A= > >&=3Bgt=3D3B&=3Blt=3D3BBR&=3Bg=3D
>=3B >=3Bt=3D3B<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3B?&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3B=3D= > >
>=3B >=3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3= > >BI can make another later this week.&=3Blt=3D3BBR&=3Bgt=3D3B<=3B=3D= > >
>=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp= > >=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= > >=3D3BAll you need=3D
>=3B >=3B is a working cm3 on any system.&= > >=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Bgt=3D3BFrom t=3D
>=3B >=3Bhere you can build the whole system=3D3= > >D2C targeting any system.&=3Blt=3D3BBR&=3Bgt=3D
>=3B >=3B=3D3B= > ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAs long as that cm3 understands = > >LONGINT and your target=3D
>=3B >=3B system.&=3Blt=3D3BBR&=3Bg= > >t=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAnd it is easier=3D3D2C bu= > >t not necess=3D
>=3B >=3Bary=3D3D2C if you have Python. :)&=3Blt= > >=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp= > >=3D3Bnbsp=3D
>=3B >=3B=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR&= > >gt=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B- Jay&=3Blt= > >=3D3BBR&=3Bgt=3D3B&=3Blt=3D
>=3B >=3B=3D3BBR&=3Bgt=3D3B&= > >=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3= > >B Date: Tue=3D3D2C 31 M=3D
>=3B >=3Bar 2009 15:43:41 -=3D3D<=3BBR&= > >gt=3B&=3Bgt=3D3B &=3Bgt=3D3B0500&=3Blt=3D3BBR&=3Bgt=3D3B&=3B= > >amp=3D3Bgt=3D3D3B From=3D
>=3B >=3B: martinbishop at bellsouth.net&= > >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B To: mika at async.ca=3D
= > >>=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bltech.edu&= > >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B CC: m3devel at elego=3D
= > >>=3B >=3Bsoft.com&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B= > > Subject: Re: [M3dev=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D
>= > >=3B >=3B=3D3Bel] Help finding CM3 compiler for Linux?&=3Blt=3D3BBR&= > >=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D
>=3B >=3B=3D3BBR&= > >=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B Not sure if t=3D3D<=3BBR>=3B&=3Bg= > >t=3D3B &=3Bgt=3D3Bhis helps=3D3D2C b=3D
>=3B >=3But on my linux s= > >ystem:&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3B= > >BR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D
>=3B >=3B=3D3D3B Critical Mass = > >Mod=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bula-3 version d5.7.0&= > >=3Blt=3D3BBR&=3Bgt=3D
>=3B >=3B=3D3B&=3Bamp=3D3Bgt=3D3D3B last= > > updated: 2008-03-16&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B = > >comp=3D
>=3B >=3Biled:=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= > >3B 2008-08-14 00:56:14&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3= > >B c=3D
>=3B >=3Bonfiguration: /usr/local/cm3/bin/cm3.cfg&=3Blt=3D= > >3BBR=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B&=3B= > >=3D
>=3B >=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3B= > >amp=3D3Bgt=3D3D3B Linux thinkpad 2.6.27-11-generic=3D
>=3B >=3B #1 S= > >MP Thu Jan 29 19:24=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B:39 UTC = > >2009&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3= > >D3B i686 GNU/Linux&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &a= > >mp=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3B=3D
>=3B >=3Bgt=3D3D3B &a= > >mp=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B I don=3D3D<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3B't have the c=3D
>=3B >=3Bm3 tarball= > >=3D3D2C but I do have the sources in cm3/ still.&=3Blt=3D3BBR&=3Bgt= > >=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D<=3BBR>=3B&=3Bgt=3D3B= > > &=3Bgt=3D3B=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D= > >3B Mika Nystrom wr=3D
>=3B >=3Bote:&=3Blt=3D3BBR&=3Bgt=3D3B&am= > >p=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B Hello everyone=3D3D2C&=3B= > >lt=3D3BBR=3D
>=3B >=3B&=3Bgt=3D3B&=3Bamp=3D3Bg=3D3D<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3Bt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt= > >=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D3B &=3Bam= > >p=3D3Bgt=3D3D3B This is=3D3D2C for me=3D3D2C a most unfortunate time =3D >>>=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfor the CM3 s= > >ervers to&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp= > >=3D
>=3B >=3B=3D3Bgt=3D3D3B have crashed. I'm teaching a class =3D3D= > ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Busing Mod=3D
>=3B >=3Bula= > >-3=3D3D2C and we need a&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D= > >3B &=3Bamp=3D3Bgt=3D3D3B compile=3D
>=3B >=3Br... here's the una= > >=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bme of the system I'm trying= > > to use:&=3B=3D
>=3B >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt= > >=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp= > >=3D3Bgt=3D3D3B &=3Bam=3D
>=3B >=3Bp=3D3Bgt=3D3D3B Linu=3D3D<=3B= > >BR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 1= > >0=3D
>=3B >=3B:53:03 PST 2008 i686 GNU/Linux&=3Blt=3D3BBR&=3Bg= > >t=3D3B&=3Bamp=3D3Bg=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bt=3D<= > >BR>>=3B >=3B=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt= > >=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B The most r=3D
>= > >=3B >=3Becent archives I have for Linux are=3D3D<=3BBR>=3B&=3Bgt= > >=3D3B &=3Bgt=3D3B:&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B = > >>=3B=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3= > >B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B cm3-m=3D
>=3B >= > >=3Bin-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D3D<=3BBR>=3B&=3Bgt=3D3B &= > >=3Bgt=3D3B-src-all-5.4.0.tgz &=3Blt=3D
>=3B =3D3BBR&=3Bgt=3D3B&a= > >mp=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt= > >=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D3B = > >And they don't seem =3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bto work= > > on this system: =3D
>=3B >=3BI can compile a program&=3Blt=3D3BB= > >R&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B but when= > >=3D
>=3B >=3B I=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B try = > >to run it=3D3D2C it says "Segmentation fault". Can=3D
>=3B >=3B anyo= > >ne&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt= > >=3D3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B help=3D
>=3B &= > >gt=3B? (My understanding is that I need 5.5.1 or later...)&=3Blt=3D3BBR&= > >amp=3Bgt=3D3B&=3Bamp=3D3Bg=3D
>=3B >=3Bt=3D3D3B &=3Bamp=3D3Bgt= > >=3D3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B &=3Blt=3D3BBR&am= > >p=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D
>=3B >=3B=3D3Bgt= > >=3D3D3B Mika&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Ba= > >mp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Ba=3D
>=3B >=3B= > >mp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Blt=3D3B/body&=3Bgt= > >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3B/html&=3Bg= > >t=3D
>=3B >=3B=3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >lt=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B--_806446ae-8d10-4d74-8eea-51aa36= > >5e=3D
>=3B >=3B9204_--<=3BBR>=3B<=3B/body>=3B
>=3B >= > >=3B<=3B/html>=3B=3D
>=3B >=3B
>=3B >=3B--_777fdc4e-3c29-4= > >0b4-a3dd-e6243f796cee_--
> >= > > > >--_55339e45-8c85-4ab6-9440-0d2131bbad69_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 1 08:58:19 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Apr 2009 06:58:19 +0000 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: <200904010653.n316rcZs073236@camembert.async.caltech.edu> References: Your message of "Wed, 01 Apr 2009 06:13:00 -0000." <200904010653.n316rcZs073236@camembert.async.caltech.edu> Message-ID: For the first part, do you have CM3_ROOT set to the root of your cvs checkout? It should use that to find a current set of config files. For the second part, wrong file, my fault. That is an "unconfigured" file -- one that cminstall hasn't munged. How about m3-sys/cminstall/src/config-no-install/cm3.cfg? - Jay > To: jay.krell at cornell.edu > Date: Tue, 31 Mar 2009 23:53:38 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Help finding CM3 compiler for Linux? > > To be honest, I'm not so sure what's intended. > > I either get this: > > "/home/mika/cm3/cm3-std-LINUXLIBC6-d5.7.0/bin/cm3.cfg", line 125: quake runtime error: unable to find a configuration file for (/home/mika/cm3/cm3-std-LINUXLIBC6-d5.7.0/bin/.., /afs/.ugcs/user/mika/cm3/cm3-std-LINUXLIBC6-d5.7.0, LINUXLIBC6) > > or, if I put back the LINUXLIBC6 file you had me delete: > > "/home/mika/cm3/cm3-std-LINUXLIBC6-d5.7.0/bin/cm3.cfg", line 128: quake runtime error: /home/mika/cm3/cm3-std-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6, line 61: syntax error: missing: <*EOF*> (found: ) > > which refers to the following (which looks like cminstall stuff to me): > > INITIAL_REACTOR_EDITOR = BEGIN_CONFIG > "What should be the default text editor for new Reactor users?" <--- this line > 10 "EDITOR" > 0 "emacsclient" > 0 "emacs" > 0 "vi" > 0 "textedit" > 0 "xedit" > 6 "/usr/local/emacs/bin" "emacsclient" > 6 "/usr/local/bin" "emacsclient" > 6 "/usr/local/emacs/bin" "emacs" > 6 "/usr/local/bin" "emacs" > 6 "/usr/bin" "vi" > 6 "/usr/local/X11R5/bin" "xedit" > 6 "/usr/openwin/bin" "textedit" > > Jay writes: > >--_55339e45-8c85-4ab6-9440-0d2131bbad69_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Maybe not. > > > >Hm. That is bug. There is use with a cvs tree=2C and use without. > > > >I must have broken use without. > > > >=20 > > > >Try this: > > > >export CM3_ROOT=3Droot of cm3 cvs (for me this is /dev2/cm3=2C > > > >for you=2C maybe $HOME/cm3?) > > > >rm $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6 > > > ># *Common and *common in one command > >rm $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/*ommon > >cp root of cm3 cvs/m3-sys/cminstall/src/config/cm3.cfg $HOME/cm3/cm3-min-LI= > >NUXLIBC6-d5.7.0/bin > > > >=20 > > > >The .cfg will delegate out to the cvs tree. > > > >I don't like having two copies of files..having to keep them in sync.. > > > > Though the archives are meant to work standalone=2C without CVS. > > > > But I don't test that so much oops sorry. > > > >That /might/ not be the right file=2C but it is close. > > > >=20 > > > > - Jay > > > >=20 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux?=20 > >> Date: Tue=2C 31 Mar 2009 22:59:18 -0700 > >> From: mika at async.caltech.edu > >>=20 > >>=20 > >> Is there any documentation for this format beyond what you just > >> wrote? Where? > >>=20 > >> terpsichore-14: cm3 > >> --- building in ../LINUXLIBC6 --- > >>=20 > >> new source -> compiling Main.m3 > >> "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common"=2C= > > line 169: quake runtime error: undefined variable: ROOT > >>=20 > >> --procedure-- -line- -file--- > >> GetM3Back 169 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3c= > >fg.common > >> _IsM3BackFlagSupported 181 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5= > >.7.0/bin/Unix.common > >> IsM3BackFlagSupported 193 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.= > >7.0/bin/Unix.common > >> GetM3BackFlag 197 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/= > >Unix.common > >> m3_backend 62 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix= > >.common > >> program -- > >> 6 /afs/.ugcs.caltech.edu/user/mika/test/LINUXLIBC6/m3make.args > >>=20 > >>=20 > >> Fatal Error: procedure "m3_backend" defined in "/afs/.ugcs/user/mika/cm3/= > >cm3-min-LINUXLIBC6-d5.7.0/bin/cm3.cfg" failed. > >>=20 > >> Jay writes: > >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ > >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> >These archives do have a different format=3D2C yes. > >> > > >> >But it isn't a bad format. > >> > > >> >cminstall is pretty worthless imho. > >> > > >> >Extract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH. > >> > > >> >=3D20 > >> > > >> > - Jay > >> > > >> >=3D20 > >> >> To: jay.krell at cornell.edu > >> >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux?=3D20 > >> >> Date: Tue=3D2C 31 Mar 2009 15:56:11 -0700 > >> >> From: mika at async.caltech.edu > >> >>=3D20 > >> >> No=3D2C I'm sorry... > >> >>=3D20 > >> >> the archives do not have the usual format. I'm expecting to unpack > >> >> and run "cminstall" and then unpack the big source tar on top and=3D20 > >> >> build that. But there's no cminstall in the archive on this page. > >> >> This is "the normal procedure" for installing CM3=3D2C no? It's what > >> >> the instructions say to do=3D2C as well... > >> >>=3D20 > >> >> And the link from the "Download" page is broken (to -d5.5.0.tgz). > >> >>=3D20 > >> >> Mika > >> >>=3D20 > >> >> Jay writes: > >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ > >> >> >Content-Type: text/plain=3D3B charset=3D3D"iso-8859-1" > >> >> >Content-Transfer-Encoding: quoted-printable > >> >> > > >> >> > > >> >> > http://modula3.elegosoft.com/cm3/uploaded-archives > >> >> > > >> >> >? > >> >> > > >> >> >=3D3D20 > >> >> > > >> >> >I can make another later this week. > >> >> > > >> >> >=3D3D20 > >> >> > > >> >> >All you need is a working cm3 on any system. > >> >> > > >> >> >>From there you can build the whole system=3D3D2C targeting any syste= > >m. > >> >> > > >> >> >As long as that cm3 understands LONGINT and your target system. > >> >> > > >> >> >And it is easier=3D3D2C but not necessary=3D3D2C if you have Python. = > >:) > >> >> > > >> >> >=3D3D20 > >> >> > > >> >> > - Jay > >> >> > > >> >> >=3D3D20 > >> >> >> Date: Tue=3D3D2C 31 Mar 2009 15:43:41 -0500 > >> >> >> From: martinbishop at bellsouth.net > >> >> >> To: mika at async.caltech.edu > >> >> >> CC: m3devel at elegosoft.com > >> >> >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? > >> >> >>=3D3D20 > >> >> >> Not sure if this helps=3D3D2C but on my linux system: > >> >> >>=3D3D20 > >> >> >> Critical Mass Modula-3 version d5.7.0 > >> >> >> last updated: 2008-03-16 > >> >> >> compiled: 2008-08-14 00:56:14 > >> >> >> configuration: /usr/local/cm3/bin/cm3.cfg > >> >> >>=3D3D20 > >> >> >> Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 200= > >9 > >> >> >> i686 GNU/Linux > >> >> >>=3D3D20 > >> >> >>=3D3D20 > >> >> >> I don't have the cm3 tarball=3D3D2C but I do have the sources in cm= > >3/ st=3D > >> >ill. > >> >> >>=3D3D20 > >> >> >> Mika Nystrom wrote: > >> >> >> > Hello everyone=3D3D2C > >> >> >> >=3D3D20 > >> >> >> > This is=3D3D2C for me=3D3D2C a most unfortunate time for the CM3 = > >servers=3D > >> > to > >> >> >> > have crashed. I'm teaching a class using Modula-3=3D3D2C and we n= > >eed a > >> >> >> > compiler... here's the uname of the system I'm trying to use: > >> >> >> >=3D3D20 > >> >> >> > Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 G= > >NU/=3D > >> >Lin=3D3D > >> >> >ux > >> >> >> >=3D3D20 > >> >> >> > The most recent archives I have for Linux are: > >> >> >> >=3D3D20 > >> >> >> > cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D3D20 > >> >> >> >=3D3D20 > >> >> >> > And they don't seem to work on this system: I can compile a progr= > >am > >> >> >> > but when I try to run it=3D3D2C it says "Segmentation fault". Can= > > anyo=3D > >> >ne > >> >> >> > help? (My understanding is that I need 5.5.1 or later...) > >> >> >> >=3D3D20 > >> >> >> > Mika > >> >> >> >=3D3D20 > >> >> >>=3D3D20 > >> >> > > >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ > >> >> >Content-Type: text/html=3D3B charset=3D3D"iso-8859-1" > >> >> >Content-Transfer-Encoding: quoted-printable > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > =3D3D3B >archive=3D > >> >s" targ=3D3D > >> >> >et=3D3D3D_blank>http://modula3.elegosoft.co= > >m/cm3/u=3D > >> >ploaded=3D3D > >> >> >-archives
> >> >> >?
> >> >> > =3D3D3B
> >> >> >I can make another later this week.
> >> >> > =3D3D3B
> >> >> >All you need is a working cm3 on any system.
> >> >> >>From there you can build the whole system=3D3D2C targeting any syste= > >m. >> >> > >> >> >As long as that cm3 understands LONGINT and your target system.
> >> >> >And it is easier=3D3D2C but not necessary=3D3D2C if you have Python. = > >:)
> >> >> > =3D3D3B
> >> >> > =3D3D3B- Jay

 =3D3D3B
>=3D3D3B Date: Tue=3D3D2C = > >31 Mar 2009=3D > >> > 15:43:41 -=3D3D > >> >> >0500
>=3D3D3B From: martinbishop at bellsouth.net
>=3D3D3B To:= > > mika at a=3D > >> >sync.ca=3D3D > >> >> >ltech.edu
>=3D3D3B CC: m3devel at elegosoft.com
>=3D3D3B Subje= > >ct: Re:=3D > >> > [M3dev=3D3D > >> >> >el] Help finding CM3 compiler for Linux?
>=3D3D3B
>=3D3D3B= > > Not su=3D > >> >re if t=3D3D > >> >> >his helps=3D3D2C but on my linux system:
>=3D3D3B
>=3D3D3B= > > Critical=3D > >> > Mass Mod=3D3D > >> >> >ula-3 version d5.7.0
>=3D3D3B last updated: 2008-03-16
>=3D= > >3D3B co=3D > >> >mpiled:=3D3D > >> >> > 2008-08-14 00:56:14
>=3D3D3B configuration: /usr/local/cm3/bin/= > >cm3.c=3D > >> >fg >> >> >>>=3D3D3B
>=3D3D3B Linux thinkpad 2.6.27-11-generic #1 SMP Th= > >u Jan 2=3D > >> >9 19:24=3D3D > >> >> >:39 UTC 2009
>=3D3D3B i686 GNU/Linux
>=3D3D3B
>=3D3D3= > >B
>=3D > >> >=3D3D3B I don=3D3D > >> >> >'t have the cm3 tarball=3D3D2C but I do have the sources in cm3/ stil= > >l. >> >>>=3D3D > >> >> >=3D3D3B
>=3D3D3B Mika Nystrom wrote:
>=3D3D3B >=3D3D3B H= > >ello everyo=3D > >> >ne=3D3D2C
&g=3D3D > >> >> >t=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B This is=3D3D2C for me= > >=3D3D2C a most un=3D > >> >fortunate time =3D3D > >> >> >for the CM3 servers to
>=3D3D3B >=3D3D3B have crashed. I'm tea= > >ching a=3D > >> > class =3D3D > >> >> >using Modula-3=3D3D2C and we need a
>=3D3D3B >=3D3D3B compiler= > >... here'=3D > >> >s the una=3D3D > >> >> >me of the system I'm trying to use:
>=3D3D3B >=3D3D3B
>= > >=3D3D3B &g=3D > >> >t=3D3D3B Linu=3D3D > >> >> >x lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Linux= > > >> >>&g=3D3D > >> >> >t=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B The most recent archive= > >s I have fo=3D > >> >r Linux are=3D3D > >> >> >:
>=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B cm3-min-POSIX-LI= > >NUXLIBC6-5.=3D > >> >4.0.tgz cm3=3D3D > >> >> >-src-all-5.4.0.tgz
>=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3= > >B And they =3D > >> >don't seem =3D3D > >> >> >to work on this system: I can compile a program
>=3D3D3B >=3D3= > >D3B but=3D > >> > when I=3D3D > >> >> > try to run it=3D3D2C it says "Segmentation fault". Can anyone
>= > >=3D3D3B=3D > >> > >=3D3D3B=3D3D > >> >> > help? (My understanding is that I need 5.5.1 or later...)
>=3D3= > >D3B &=3D > >> >gt=3D3D3B=3D3D > >> >> >
>=3D3D3B >=3D3D3B Mika
>=3D3D3B >=3D3D3B
>=3D3D= > >3B
>> >> > >> >> >=3D3D > >> >> > > >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_-- > >> > > >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ > >> >Content-Type: text/html=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> > > >> > > >> > > >> > > >> >These archives do have a different format=3D2C yes.
> >> >But it isn't a bad format.
> >> >cminstall is pretty worthless imho.
> >> >Extract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.
> >> > =3D3B
> >> > =3D3B- Jay

 =3D3B
>=3D3B To: jay.krell at cornell.edu<= > >BR>>=3D3B=3D > >> > Subject: Re: [M3devel] Help finding CM3 compiler for Linux?
>=3D3= > >B Dat=3D > >> >e: Tue=3D2C 31 Mar 2009 15:56:11 -0700
>=3D3B From: mika at async.calt= > >ech.edu=3D > >> >
>=3D3B
>=3D3B No=3D2C I'm sorry...
>=3D3B
>=3D3B = > >the archives =3D > >> >do not have the usual format. I'm expecting to unpack
>=3D3B and ru= > >n "cm=3D > >> >install" and then unpack the big source tar on top and
>=3D3B buil= > >d tha=3D > >> >t. But there's no cminstall in the archive on this page.
>=3D3B Thi= > >s is =3D > >> >"the normal procedure" for installing CM3=3D2C no? It's what
>=3D3B= > > the in=3D > >> >structions say to do=3D2C as well...
>=3D3B
>=3D3B And the li= > >nk from t=3D > >> >he "Download" page is broken (to -d5.5.0.tgz).
>=3D3B
>=3D3B = > >Mika >> >>>=3D3B
>=3D3B Jay writes:
>=3D3B >=3D3B--_806446ae-8d10-= > >4d74-8eea-5=3D > >> >1aa365e9204_
>=3D3B >=3D3BContent-Type: text/plain=3D3B charset= > >=3D3D"iso-885=3D > >> >9-1"
>=3D3B >=3D3BContent-Transfer-Encoding: quoted-printable
= > >>=3D3B =3D > >> >>=3D3B
>=3D3B >=3D3B
>=3D3B >=3D3B http://modula3.elegos= > >oft.com/cm3/u=3D > >> >ploaded-archives
>=3D3B >=3D3B
>=3D3B >=3D3B?
>=3D3B = > >>=3D3B
>=3D > >> >=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B
>=3D3B >=3D3BI can mak= > >e another later t=3D > >> >his week.
>=3D3B >=3D3B
>=3D3B >=3D3B=3D3D20
>=3D3B &= > >gt=3D3B
>=3D3B=3D > >> > >=3D3BAll you need is a working cm3 on any system.
>=3D3B >=3D= > >3B
>=3D > >> >=3D3B >=3D3B>=3D3BFrom there you can build the whole system=3D3D2C t= > >argeting an=3D > >> >y system.
>=3D3B >=3D3B
>=3D3B >=3D3BAs long as that cm3 u= > >nderstands =3D > >> >LONGINT and your target system.
>=3D3B >=3D3B
>=3D3B >=3D3= > >BAnd it is =3D > >> >easier=3D3D2C but not necessary=3D3D2C if you have Python. :)
>=3D3= > >B >=3D3B<=3D > >> >BR>>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B
>=3D3B >=3D3B - = > >Jay
>=3D3B >=3D > >> >=3D3B
>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B Date: Tue= > >=3D3D2C 31 Mar 2009=3D > >> > 15:43:41 -0500
>=3D3B >=3D3B>=3D3B From: martinbishop at bellsout= > >h.net
=3D > >> >>=3D3B >=3D3B>=3D3B To: mika at async.caltech.edu
>=3D3B >=3D3= > >B>=3D3B CC: m=3D > >> >3devel at elegosoft.com
>=3D3B >=3D3B>=3D3B Subject: Re: [M3devel]= > > Help fin=3D > >> >ding CM3 compiler for Linux?
>=3D3B >=3D3B>=3D3B=3D3D20
>= > >=3D3B >=3D3B&g=3D > >> >t=3D3B Not sure if this helps=3D3D2C but on my linux system:
>=3D3B= > > >=3D3B&g=3D > >> >t=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B Critical Mass Modula-3 versio= > >n d5.7.0
&=3D > >> >gt=3D3B >=3D3B>=3D3B last updated: 2008-03-16
>=3D3B >=3D3B&g= > >t=3D3B compiled=3D > >> >: 2008-08-14 00:56:14
>=3D3B >=3D3B>=3D3B configuration: /usr/l= > >ocal/cm3/=3D > >> >bin/cm3.cfg
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B >=3D3B>= > >=3D3B Linux thinkp=3D > >> >ad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009
>=3D3B >= > >=3D3B&g=3D > >> >t=3D3B i686 GNU/Linux
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B &g= > >t=3D3B>=3D3B=3D3D20=3D > >> >
>=3D3B >=3D3B>=3D3B I don't have the cm3 tarball=3D3D2C but I = > >do have the=3D > >> > sources in cm3/ still.
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B = > >>=3D3B>=3D3B =3D > >> >Mika Nystrom wrote:
>=3D3B >=3D3B>=3D3B >=3D3B Hello everyone= > >=3D3D2C
&g=3D > >> >t=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B >= > >=3D3B This is=3D3D2C fo=3D > >> >r me=3D3D2C a most unfortunate time for the CM3 servers to
>=3D3B &= > >gt=3D3B&g=3D > >> >t=3D3B >=3D3B have crashed. I'm teaching a class using Modula-3=3D3D2C= > > and we n=3D > >> >eed a
>=3D3B >=3D3B>=3D3B >=3D3B compiler... here's the uname= > > of the sys=3D > >> >tem I'm trying to use:
>=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
&= > >gt=3D3B >=3D3B&=3D > >> >gt=3D3B >=3D3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2= > >008 i68=3D > >> >6 GNU/Lin=3D3D
>=3D3B >=3D3Bux
>=3D3B >=3D3B>=3D3B >= > >=3D3B=3D3D20
>=3D > >> >=3D3B >=3D3B>=3D3B >=3D3B The most recent archives I have for Linu= > >x are:
&=3D > >> >gt=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B &g= > >t=3D3B cm3-min-POSIX-=3D > >> >LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D3D20
>=3D3B >=3D3B&g= > >t=3D3B >=3D > >> >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B >=3D3B And they don't seem t= > >o work on this =3D > >> >system: I can compile a program
>=3D3B >=3D3B>=3D3B >=3D3B bu= > >t when I tr=3D > >> >y to run it=3D3D2C it says "Segmentation fault". Can anyone
>=3D3B = > >>=3D3B&=3D > >> >gt=3D3B >=3D3B help? (My understanding is that I need 5.5.1 or later..= > >.)
&=3D > >> >gt=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B &g= > >t=3D3B Mika
>=3D3B=3D > >> > >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B=3D3D20 >>>=3D3B >=3D3B
&=3D > >> >gt=3D3B >=3D3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>=3D3B >= > >=3D3BConten=3D > >> >t-Type: text/html=3D3B charset=3D3D"iso-8859-1"
>=3D3B >=3D3BCont= > >ent-Transfe=3D > >> >r-Encoding: quoted-printable
>=3D3B >=3D3B
>=3D3B >=3D3B&l= > >t=3D3Bhtml>=3D > >> >=3D3B
>=3D3B >=3D3B<=3D3Bhead>=3D3B
>=3D3B >=3D3B<= > >=3D3Bstyle>=3D3B
&=3D > >> >gt=3D3B >=3D3B.hmmessage P
>=3D3B >=3D3B{
>=3D3B >=3D3Bm= > >argin:0px=3D3D3B<=3D > >> >BR>>=3D3B >=3D3Bpadding:0px
>=3D3B >=3D3B}
>=3D3B >=3D= > >3Bbody.hmmessag=3D > >> >e
>=3D3B >=3D3B{
>=3D3B >=3D3Bfont-size: 10pt=3D3D3B
&g= > >t=3D3B >=3D3Bfo=3D > >> >nt-family:Verdana
>=3D3B >=3D3B}
>=3D3B >=3D3B<=3D3B/sty= > >le>=3D3B
&=3D > >> >gt=3D3B >=3D3B<=3D3B/head>=3D3B
>=3D3B >=3D3B<=3D3Bbody c= > >lass=3D3D3D'hmmessa=3D > >> >ge'>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BA href=3D3D3= > >D"http://modula3.=3D > >> >elegosoft.com/cm3/uploaded-archives" targ=3D3D
>=3D3B >=3D3Bet=3D= > >3D3D_blank&=3D > >> >gt=3D3B<=3D3BFONT color=3D3D3D#0068cf>=3D3Bhttp://modula3.elegosoft.= > >com/cm3/upl=3D > >> >oaded=3D3D
>=3D3B >=3D3B-archives<=3D3B/FONT>=3D3B<=3D3B/A&= > >gt=3D3B<=3D3BBR&g=3D > >> >t=3D3B
>=3D3B >=3D3B?<=3D3BBR>=3D3B
>=3D3B >=3D3B&= > >=3D3Bnbsp=3D3D3B<=3D3B=3D > >> >BR>=3D3B
>=3D3B >=3D3BI can make another later this week.<=3D= > >3BBR>=3D3B<=3D > >> >BR>>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
>=3D3B &= > >gt=3D3BAll you need=3D > >> > is a working cm3 on any system.<=3D3BBR>=3D3B
>=3D3B >=3D3B&= > >gt=3D3BFrom t=3D > >> >here you can build the whole system=3D3D2C targeting any system.<=3D3B= > >BR>=3D > >> >=3D3B
>=3D3B >=3D3BAs long as that cm3 understands LONGINT and yo= > >ur target=3D > >> > system.<=3D3BBR>=3D3B
>=3D3B >=3D3BAnd it is easier=3D3D2C b= > >ut not necess=3D > >> >ary=3D3D2C if you have Python. :)<=3D3BBR>=3D3B
>=3D3B >=3D3B= > >&=3D3Bnbsp=3D > >> >=3D3D3B<=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B- Jay&= > >lt=3D3BBR>=3D3B<=3D > >> >=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B = > >Date: Tue=3D3D2C 31 M=3D > >> >ar 2009 15:43:41 -=3D3D
>=3D3B >=3D3B0500<=3D3BBR>=3D3B&= > >=3D3Bgt=3D3D3B From=3D > >> >: martinbishop at bellsouth.net<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B To: mik= > >a at async.ca=3D > >> >=3D3D
>=3D3B >=3D3Bltech.edu<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B = > >CC: m3devel at elego=3D > >> >soft.com<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Subject: Re: [M3dev=3D3D >>>=3D3B >=3D > >> >=3D3Bel] Help finding CM3 compiler for Linux?<=3D3BBR>=3D3B&=3D3B= > >gt=3D3D3B <=3D > >> >=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Not sure if t=3D3D
>=3D3B >=3D3= > >Bhis helps=3D3D2C b=3D > >> >ut on my linux system:<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B <=3D3BBR>= > >=3D3B&=3D3Bgt=3D > >> >=3D3D3B Critical Mass Mod=3D3D
>=3D3B >=3D3Bula-3 version d5.7.0&= > >lt=3D3BBR>=3D > >> >=3D3B&=3D3Bgt=3D3D3B last updated: 2008-03-16<=3D3BBR>=3D3B&= > >=3D3Bgt=3D3D3B comp=3D > >> >iled:=3D3D
>=3D3B >=3D3B 2008-08-14 00:56:14<=3D3BBR>=3D3B&am= > >p=3D3Bgt=3D3D3B c=3D > >> >onfiguration: /usr/local/cm3/bin/cm3.cfg<=3D3BBR=3D3D
>=3D3B >= > >=3D3B>=3D3B&=3D > >> >amp=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Linux thinkpad 2.= > >6.27-11-generic=3D > >> > #1 SMP Thu Jan 29 19:24=3D3D
>=3D3B >=3D3B:39 UTC 2009<=3D3BBR= > >>=3D3B&=3D > >> >=3D3Bgt=3D3D3B i686 GNU/Linux<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B <=3D= > >3BBR>=3D3B&=3D3B=3D > >> >gt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B I don=3D3D
>=3D3B &g= > >t=3D3B't have the c=3D > >> >m3 tarball=3D3D2C but I do have the sources in cm3/ still.<=3D3BBR>= > >=3D3B&=3D > >> >=3D3Bgt=3D3D
>=3D3B >=3D3B=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt= > >=3D3D3B Mika Nystrom wr=3D > >> >ote:<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B Hello everyo= > >ne=3D3D2C<=3D3BBR=3D > >> >>=3D3B&=3D3Bg=3D3D
>=3D3B >=3D3Bt=3D3D3B &=3D3Bgt=3D3D3B = > ><=3D3BBR>=3D3B&=3D > >> >=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B This is=3D3D2C for me=3D3D2C a most un= > >fortunate time =3D > >> >=3D3D
>=3D3B >=3D3Bfor the CM3 servers to<=3D3BBR>=3D3B&= > >=3D3Bgt=3D3D3B &=3D > >> >=3D3Bgt=3D3D3B have crashed. I'm teaching a class =3D3D
>=3D3B >= > >=3D3Busing Mod=3D > >> >ula-3=3D3D2C and we need a<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3B= > >gt=3D3D3B compile=3D > >> >r... here's the una=3D3D
>=3D3B >=3D3Bme of the system I'm trying= > > to use:&=3D > >> >lt=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3= > >B&=3D3Bgt=3D3D3B &am=3D > >> >p=3D3Bgt=3D3D3B Linu=3D3D
>=3D3B >=3D3Bx lara 2.6.24ugcs1 #4 SMP = > >Mon Feb 11 10=3D > >> >:53:03 PST 2008 i686 GNU/Linux<=3D3BBR>=3D3B&=3D3Bg=3D3D
>= > >=3D3B >=3D3Bt=3D > >> >=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3= > >Bgt=3D3D3B The most r=3D > >> >ecent archives I have for Linux are=3D3D
>=3D3B >=3D3B:<=3D3BBR= > >>=3D3B&=3D > >> >=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &= > >amp=3D3Bgt=3D3D3B cm3-m=3D > >> >in-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D3D
>=3D3B >=3D3B-src-all-5.4.= > >0.tgz <=3D > >> =3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&a= > >mp=3D3Bgt=3D3D3B &=3D > >> >=3D3Bgt=3D3D3B And they don't seem =3D3D
>=3D3B >=3D3Bto work on = > >this system: =3D > >> >I can compile a program<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt= > >=3D3D3B but when=3D > >> > I=3D3D
>=3D3B >=3D3B try to run it=3D3D2C it says "Segmentation = > >fault". Can=3D > >> > anyone<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B=3D3D
&= > >gt=3D3B >=3D3B help=3D > >> >? (My understanding is that I need 5.5.1 or later...)<=3D3BBR>=3D3B&= > >amp=3D3Bg=3D > >> >t=3D3D3B &=3D3Bgt=3D3D3B=3D3D
>=3D3B >=3D3B <=3D3BBR>=3D3B= > >&=3D3Bgt=3D3D3B &=3D > >> >=3D3Bgt=3D3D3B Mika<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D= > >3B <=3D3BBR>=3D3B&a=3D > >> >mp=3D3Bgt=3D3D3B <=3D3BBR>=3D3B<=3D3B/body>=3D3B
>=3D3B >= > >=3D3B<=3D3B/html>=3D > >> >=3D3B=3D3D
>=3D3B >=3D3B
>=3D3B >=3D3B--_806446ae-8d10-4d7= > >4-8eea-51aa365e=3D > >> >9204_--
> >> >=3D > >> > > >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_-- > > > >--_55339e45-8c85-4ab6-9440-0d2131bbad69_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >Maybe not.
> >Hm. That is bug. There is use with a cvs tree=2C and use without.
> >I must have broken use without.
> > =3B
> >Try this:
> >export CM3_ROOT=3Droot of cm3 cvs (for me this is /dev2/cm3=2C
> >for you=2C maybe $HOME/cm3?)
> >rm =3B$HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6
> ># *Common and *common in one command
rm =3B$HOME/cm3/cm3-min-LINUXLI= > >BC6-d5.7.0/bin/*ommon
cp root of cm3 cvs/m3-sys/cminstall/src/config/cm3= > >.cfg $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin
> > =3B
> >The .cfg will delegate out to the cvs tree.
> >I don't like having two copies of files..having to keep them in sync..
> > =3BThough the archives are meant to work standalone=2C without CVS. >> > > =3B But I don't test that so much oops sorry.
> >That /might/ not be the right file=2C but it is close.
> > =3B
> > =3B- Jay

 =3B
>=3B To: jay.krell at cornell.edu
>=3B= > > CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] Help finding CM= > >3 compiler for Linux?
>=3B Date: Tue=2C 31 Mar 2009 22:59:18 -0700 >>>=3B From: mika at async.caltech.edu
>=3B
>=3B
>=3B Is the= > >re any documentation for this format beyond what you just
>=3B wrote? = > >Where?
>=3B
>=3B terpsichore-14: cm3
>=3B --- building in .= > >./LINUXLIBC6 ---
>=3B
>=3B new source ->=3B compiling Main.m3<= > >BR>>=3B "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.co= > >mmon"=2C line 169: quake runtime error: undefined variable: ROOT
>=3B = > >
>=3B --procedure-- -line- -file---
>=3B GetM3Back 169 /afs/.ugcs= > >/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common
>=3B _IsM3B= > >ackFlagSupported 181 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin= > >/Unix.common
>=3B IsM3BackFlagSupported 193 /afs/.ugcs/user/mika/cm3/c= > >m3-min-LINUXLIBC6-d5.7.0/bin/Unix.common
>=3B GetM3BackFlag 197 /afs/.= > >ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common
>=3B m3_b= > >ackend 62 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.commo= > >n
>=3B program -- <=3Bbuiltin>=3B
>=3B 6 /afs/.ugcs.caltech.e= > >du/user/mika/test/LINUXLIBC6/m3make.args
>=3B
>=3B
>=3B Fa= > >tal Error: procedure "m3_backend" defined in "/afs/.ugcs/user/mika/cm3/cm3-= > >min-LINUXLIBC6-d5.7.0/bin/cm3.cfg" failed.
>=3B
>=3B Jay writes:= > >
>=3B >=3B--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_
>=3B >=3BC= > >ontent-Type: text/plain=3B charset=3D"iso-8859-1"
>=3B >=3BContent-T= > >ransfer-Encoding: quoted-printable
>=3B >=3B
>=3B >=3B
>= > >=3B >=3BThese archives do have a different format=3D2C yes.
>=3B >= > >=3B
>=3B >=3BBut it isn't a bad format.
>=3B >=3B
>=3B &= > >gt=3Bcminstall is pretty worthless imho.
>=3B >=3B
>=3B >=3BE= > >xtract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.
>=3B >=3B
&= > >gt=3B >=3B=3D20
>=3B >=3B
>=3B >=3B - Jay
>=3B >=3B<= > >BR>>=3B >=3B=3D20
>=3B >=3B>=3B To: jay.krell at cornell.edu
&= > >gt=3B >=3B>=3B Subject: Re: [M3devel] Help finding CM3 compiler for Lin= > >ux?=3D20
>=3B >=3B>=3B Date: Tue=3D2C 31 Mar 2009 15:56:11 -0700 >R>>=3B >=3B>=3B From: mika at async.caltech.edu
>=3B >=3B>=3B= > >=3D20
>=3B >=3B>=3B No=3D2C I'm sorry...
>=3B >=3B>=3B=3D= > >20
>=3B >=3B>=3B the archives do not have the usual format. I'm ex= > >pecting to unpack
>=3B >=3B>=3B and run "cminstall" and then unpac= > >k the big source tar on top and=3D20
>=3B >=3B>=3B build that. But= > > there's no cminstall in the archive on this page.
>=3B >=3B>=3B T= > >his is "the normal procedure" for installing CM3=3D2C no? It's what
>= > >=3B >=3B>=3B the instructions say to do=3D2C as well...
>=3B >= > >=3B>=3B=3D20
>=3B >=3B>=3B And the link from the "Download" page= > > is broken (to -d5.5.0.tgz).
>=3B >=3B>=3B=3D20
>=3B >=3B&g= > >t=3B Mika
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B Jay writes: >>>=3B >=3B>=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>= > >=3B >=3B>=3B >=3BContent-Type: text/plain=3D3B charset=3D3D"iso-8859-= > >1"
>=3B >=3B>=3B >=3BContent-Transfer-Encoding: quoted-printable= > >
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B
>=3B >= > >=3B>=3B >=3B http://modula3.elegosoft.com/cm3/uploaded-archives
>= > >=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B?
>=3B >=3B>= > >=3B >=3B
>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >= > >=3B
>=3B >=3B>=3B >=3BI can make another later this week.
>= > >=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B=3D3D20
>=3B >= > >=3B>=3B >=3B
>=3B >=3B>=3B >=3BAll you need is a working cm3= > > on any system.
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B= > >>=3BFrom there you can build the whole system=3D3D2C targeting any system= > >.
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3BAs long as tha= > >t cm3 understands LONGINT and your target system.
>=3B >=3B>=3B &g= > >t=3B
>=3B >=3B>=3B >=3BAnd it is easier=3D3D2C but not necessary= > >=3D3D2C if you have Python. :)
>=3B >=3B>=3B >=3B
>=3B >= > >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B
>=3B >=3B>= > >=3B >=3B - Jay
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >= > >=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Date: Tue=3D3D2C 31 Mar 2009= > > 15:43:41 -0500
>=3B >=3B>=3B >=3B>=3B From: martinbishop at bell= > >south.net
>=3B >=3B>=3B >=3B>=3B To: mika at async.caltech.edu >>>=3B >=3B>=3B >=3B>=3B CC: m3devel at elegosoft.com
>=3B >= > >=3B>=3B >=3B>=3B Subject: Re: [M3devel] Help finding CM3 compiler for= > > Linux?
>=3B >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B &= > >gt=3B>=3B Not sure if this helps=3D3D2C but on my linux system:
>=3B= > > >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Criti= > >cal Mass Modula-3 version d5.7.0
>=3B >=3B>=3B >=3B>=3B last u= > >pdated: 2008-03-16
>=3B >=3B>=3B >=3B>=3B compiled: 2008-08-14= > > 00:56:14
>=3B >=3B>=3B >=3B>=3B configuration: /usr/local/cm3= > >/bin/cm3.cfg
>=3B >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>= > >=3B >=3B>=3B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:3= > >9 UTC 2009
>=3B >=3B>=3B >=3B>=3B i686 GNU/Linux
>=3B >= > >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B=3D3D20 >>>=3B >=3B>=3B >=3B>=3B I don't have the cm3 tarball=3D3D2C but I= > > do have the sources in cm3/ st=3D
>=3B >=3Bill.
>=3B >=3B>= > >=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Mika Nystrom wr= > >ote:
>=3B >=3B>=3B >=3B>=3B >=3B Hello everyone=3D3D2C
&g= > >t=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B&= > >gt=3B >=3B This is=3D3D2C for me=3D3D2C a most unfortunate time for the C= > >M3 servers=3D
>=3B >=3B to
>=3B >=3B>=3B >=3B>=3B >= > >=3B have crashed. I'm teaching a class using Modula-3=3D3D2C and we need a<= > >BR>>=3B >=3B>=3B >=3B>=3B >=3B compiler... here's the uname of = > >the system I'm trying to use:
>=3B >=3B>=3B >=3B>=3B >=3B=3D= > >3D20
>=3B >=3B>=3B >=3B>=3B >=3B Linux lara 2.6.24ugcs1 #4 S= > >MP Mon Feb 11 10:53:03 PST 2008 i686 GNU/=3D
>=3B >=3BLin=3D3D
&g= > >t=3B >=3B>=3B >=3Bux
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D2= > >0
>=3B >=3B>=3B >=3B>=3B >=3B The most recent archives I hav= > >e for Linux are:
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>= > >=3B >=3B>=3B >=3B>=3B >=3B cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3= > >-src-all-5.4.0.tgz=3D3D20
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20= > >
>=3B >=3B>=3B >=3B>=3B >=3B And they don't seem to work on = > >this system: I can compile a program
>=3B >=3B>=3B >=3B>=3B &g= > >t=3B but when I try to run it=3D3D2C it says "Segmentation fault". Can anyo= > >=3D
>=3B >=3Bne
>=3B >=3B>=3B >=3B>=3B >=3B help? (My= > > understanding is that I need 5.5.1 or later...)
>=3B >=3B>=3B >= > >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B >=3B Mika
= > >>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >= > >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >= > >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>=3B >=3B>=3B >=3BCo= > >ntent-Type: text/html=3D3B charset=3D3D"iso-8859-1"
>=3B >=3B>=3B = > >>=3BContent-Transfer-Encoding: quoted-printable
>=3B >=3B>=3B &g= > >t=3B
>=3B >=3B>=3B >=3B<=3Bhtml>=3B
>=3B >=3B>=3B &= > >gt=3B<=3Bhead>=3B
>=3B >=3B>=3B >=3B<=3Bstyle>=3B
>= > >=3B >=3B>=3B >=3B.hmmessage P
>=3B >=3B>=3B >=3B{
>= > >=3B >=3B>=3B >=3Bmargin:0px=3D3D3B
>=3B >=3B>=3B >=3Bpaddi= > >ng:0px
>=3B >=3B>=3B >=3B}
>=3B >=3B>=3B >=3Bbody.hmm= > >essage
>=3B >=3B>=3B >=3B{
>=3B >=3B>=3B >=3Bfont-siz= > e: 10pt=3D3D3B
>=3B >=3B>=3B >=3Bfont-family:Verdana
>=3B &= > >gt=3B>=3B >=3B}
>=3B >=3B>=3B >=3B<=3B/style>=3B
>= > >=3B >=3B>=3B >=3B<=3B/head>=3B
>=3B >=3B>=3B >=3B<= > >=3Bbody class=3D3D3D'hmmessage'>=3B
>=3B >=3B>=3B >=3B&=3Bn= > >bsp=3D3D3B<=3BA href=3D3D3D"http://modula3.elegosoft.com/cm3/uploaded-arc= > >hive=3D
>=3B >=3Bs" targ=3D3D
>=3B >=3B>=3B >=3Bet=3D3D3D= > >_blank>=3B<=3BFONT color=3D3D3D#0068cf>=3Bhttp://modula3.elegosoft.co= > >m/cm3/u=3D
>=3B >=3Bploaded=3D3D
>=3B >=3B>=3B >=3B-archi= > >ves<=3B/FONT>=3B<=3B/A>=3B<=3BBR>=3B
>=3B >=3B>=3B >= > >=3B?<=3BBR>=3B
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR&= > >gt=3B
>=3B >=3B>=3B >=3BI can make another later this week.<= > >=3BBR>=3B
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B >R>>=3B >=3B>=3B >=3BAll you need is a working cm3 on any system.<= > >=3BBR>=3B
>=3B >=3B>=3B >=3B>=3BFrom there you can build the= > > whole system=3D3D2C targeting any system.<=3BBR=3D
>=3B >=3B>= > >=3B
>=3B >=3B>=3B >=3BAs long as that cm3 understands LONGINT an= > >d your target system.<=3BBR>=3B
>=3B >=3B>=3B >=3BAnd it is = > >easier=3D3D2C but not necessary=3D3D2C if you have Python. :)<=3BBR>=3B= > >
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B
>=3B &g= > >t=3B>=3B >=3B&=3Bnbsp=3D3D3B- Jay<=3BBR>=3B<=3BBR>=3B&=3B= > >nbsp=3D3D3B<=3BBR>=3B&=3Bgt=3D3D3B Date: Tue=3D3D2C 31 Mar 2009=3D >R>>=3B >=3B 15:43:41 -=3D3D
>=3B >=3B>=3B >=3B0500<=3BBR&g= > >t=3B&=3Bgt=3D3D3B From: martinbishop at bellsouth.net<=3BBR>=3B&=3Bg= > >t=3D3D3B To: mika at a=3D
>=3B >=3Bsync.ca=3D3D
>=3B >=3B>=3B = > >>=3Bltech.edu<=3BBR>=3B&=3Bgt=3D3D3B CC: m3devel at elegosoft.com<= > >=3BBR>=3B&=3Bgt=3D3D3B Subject: Re:=3D
>=3B >=3B [M3dev=3D3D >>>=3B >=3B>=3B >=3Bel] Help finding CM3 compiler for Linux?<=3BBR= > >>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B Not su=3D
>=3B &= > >gt=3Bre if t=3D3D
>=3B >=3B>=3B >=3Bhis helps=3D3D2C but on my l= > >inux system:<=3BBR>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B C= > >ritical=3D
>=3B >=3B Mass Mod=3D3D
>=3B >=3B>=3B >=3Bula-= > >3 version d5.7.0<=3BBR>=3B&=3Bgt=3D3D3B last updated: 2008-03-16<= > >=3BBR>=3B&=3Bgt=3D3D3B co=3D
>=3B >=3Bmpiled:=3D3D
>=3B &g= > >t=3B>=3B >=3B 2008-08-14 00:56:14<=3BBR>=3B&=3Bgt=3D3D3B configu= > >ration: /usr/local/cm3/bin/cm3.c=3D
>=3B >=3Bfg<=3BBR=3D3D
>= > >=3B >=3B>=3B >=3B>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3= > >B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 2=3D
>=3B >=3B9 19= > >:24=3D3D
>=3B >=3B>=3B >=3B:39 UTC 2009<=3BBR>=3B&=3Bgt= > >=3D3D3B i686 GNU/Linux<=3BBR>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bg= > >t=3D3D3B <=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3D3B I don=3D3D
&= > >gt=3B >=3B>=3B >=3B't have the cm3 tarball=3D3D2C but I do have the s= > >ources in cm3/ still.<=3BBR=3D
>=3B >=3B>=3B&=3Bgt=3D3D
&g= > >t=3B >=3B>=3B >=3B=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B Mika Nystrom= > > wrote:<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B Hello everyo=3D
&= > >gt=3B >=3Bne=3D3D2C<=3BBR>=3B&=3Bg=3D3D
>=3B >=3B>=3B >= > >=3Bt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3= > >B This is=3D3D2C for me=3D3D2C a most un=3D
>=3B >=3Bfortunate time = > >=3D3D
>=3B >=3B>=3B >=3Bfor the CM3 servers to<=3BBR>=3B&= > >=3Bgt=3D3D3B &=3Bgt=3D3D3B have crashed. I'm teaching a=3D
>=3B >= > >=3B class =3D3D
>=3B >=3B>=3B >=3Busing Modula-3=3D3D2C and we n= > >eed a<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B compiler... here'=3D >R>>=3B >=3Bs the una=3D3D
>=3B >=3B>=3B >=3Bme of the system= > > I'm trying to use:<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B <=3BBR= > >>=3B&=3Bgt=3D3D3B &=3Bg=3D
>=3B >=3Bt=3D3D3B Linu=3D3D
&g= > >t=3B >=3B>=3B >=3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2= > >008 i686 GNU/Linux<=3BBR=3D
>=3B >=3B>=3B&=3Bg=3D3D
>=3B= > > >=3B>=3B >=3Bt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3= > >B &=3Bgt=3D3D3B The most recent archives I have fo=3D
>=3B >=3Br = > >Linux are=3D3D
>=3B >=3B>=3B >=3B:<=3BBR>=3B&=3Bgt=3D3D3B= > > &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B cm3-min-P= > OSIX-LINUXLIBC6-5.=3D
>=3B >=3B4.0.tgz cm3=3D3D
>=3B >=3B>= > >=3B >=3B-src-all-5.4.0.tgz <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3= > >B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B And they =3D
>=3B &g= > >t=3Bdon't seem =3D3D
>=3B >=3B>=3B >=3Bto work on this system: I= > > can compile a program<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B but= > >=3D
>=3B >=3B when I=3D3D
>=3B >=3B>=3B >=3B try to run i= > >t=3D3D2C it says "Segmentation fault". Can anyone<=3BBR>=3B&=3Bgt=3D= > >3D3B=3D
>=3B >=3B &=3Bgt=3D3D3B=3D3D
>=3B >=3B>=3B >= > >=3B help? (My understanding is that I need 5.5.1 or later...)<=3BBR>=3B= > >&=3Bgt=3D3D3B &=3B=3D
>=3B >=3Bgt=3D3D3B=3D3D
>=3B >=3B= > >>=3B >=3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B Mika<=3BBR&= > >gt=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B <= > >=3BBR>=3B<=3B/body=3D
>=3B >=3B>=3B
>=3B >=3B>=3B >= > >=3B<=3B/html>=3B=3D3D
>=3B >=3B>=3B >=3B
>=3B >=3B>= > >=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_--
>=3B >=3B
&g= > >t=3B >=3B--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_
>=3B >=3BContent= > >-Type: text/html=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer= > >-Encoding: quoted-printable
>=3B >=3B
>=3B >=3B<=3Bhtml>= > >=3B
>=3B >=3B<=3Bhead>=3B
>=3B >=3B<=3Bstyle>=3B
&= > >gt=3B >=3B.hmmessage P
>=3B >=3B{
>=3B >=3Bmargin:0px=3D3B<= > >BR>>=3B >=3Bpadding:0px
>=3B >=3B}
>=3B >=3Bbody.hmmessag= > >e
>=3B >=3B{
>=3B >=3Bfont-size: 10pt=3D3B
>=3B >=3Bfo= > >nt-family:Verdana
>=3B >=3B}
>=3B >=3B<=3B/style>=3B
&= > >gt=3B >=3B<=3B/head>=3B
>=3B >=3B<=3Bbody class=3D3D'hmmessa= > >ge'>=3B
>=3B >=3BThese archives do have a different format=3D2C ye= > >s.<=3BBR>=3B
>=3B >=3BBut it isn't a bad format.<=3BBR>=3B >R>>=3B >=3Bcminstall is pretty worthless imho.<=3BBR>=3B
>=3B = > >>=3BExtract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.<=3BBR>=3B<= > >BR>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp= > >=3D3B- Jay<=3BBR>=3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3B&=3B= > >gt=3D3B To: jay.krell at cornell.edu<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B = > >>=3B Subject: Re: [M3devel] Help finding CM3 compiler for Linux? <=3BBR= > >>=3B&=3Bgt=3D3B Dat=3D
>=3B >=3Be: Tue=3D2C 31 Mar 2009 15:56:1= > >1 -0700<=3BBR>=3B&=3Bgt=3D3B From: mika at async.caltech.edu=3D
>= > >=3B >=3B<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B No=3D2C= > > I'm sorry...<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B the = > >archives =3D
>=3B >=3Bdo not have the usual format. I'm expecting to= > > unpack<=3BBR>=3B&=3Bgt=3D3B and run "cm=3D
>=3B >=3Binstall"= > > and then unpack the big source tar on top and <=3BBR>=3B&=3Bgt=3D3B= > > build tha=3D
>=3B >=3Bt. But there's no cminstall in the archive on= > > this page.<=3BBR>=3B&=3Bgt=3D3B This is =3D
>=3B >=3B"the no= > >rmal procedure" for installing CM3=3D2C no? It's what<=3BBR>=3B&=3Bg= > >t=3D3B the in=3D
>=3B >=3Bstructions say to do=3D2C as well...<=3B= > >BR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B And the link from t=3D<= > >BR>>=3B >=3Bhe "Download" page is broken (to -d5.5.0.tgz).<=3BBR>= > >=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Mika<=3BBR=3D
>=3B &g= > >t=3B>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Jay writes:<=3BBR&g= > >t=3B&=3Bgt=3D3B &=3Bgt=3D3B--_806446ae-8d10-4d74-8eea-5=3D
>=3B = > >>=3B1aa365e9204_<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BContent-Type: = > >text/plain=3D3B charset=3D3D"iso-885=3D
>=3B >=3B9-1"<=3BBR>=3B&= > >amp=3Bgt=3D3B &=3Bgt=3D3BContent-Transfer-Encoding: quoted-printable<= > >=3BBR>=3B&=3Bgt=3D3B =3D
>=3B >=3B&=3Bgt=3D3B<=3BBR>=3B&= > >amp=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B htt= > >p://modula3.elegosoft.com/cm3/u=3D
>=3B >=3Bploaded-archives<=3BBR= > >>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= > >=3D3B?<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D= > >
>=3B >=3B=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &a= > >mp=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BI can make another l= > >ater t=3D
>=3B >=3Bhis week.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= > >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&= > >=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >=3B &= > >amp=3Bgt=3D3BAll you need is a working cm3 on any system.<=3BBR>=3B&= > >=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &= > >amp=3Bgt=3D3B&=3Bgt=3D3BFrom there you can build the whole system=3D3D2C= > > targeting an=3D
>=3B >=3By system.<=3BBR>=3B&=3Bgt=3D3B &= > >=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAs long as that cm3 un= > >derstands =3D
>=3B >=3BLONGINT and your target system.<=3BBR>=3B= > >&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAnd= > > it is =3D
>=3B >=3Beasier=3D3D2C but not necessary=3D3D2C if you ha= > >ve Python. :)<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3B=3D
>=3B= > > >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt= > >=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B - Jay<=3B= > >BR>=3B&=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B<=3BBR>=3B&= > >=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B= > >&=3Bgt=3D3B Date: Tue=3D3D2C 31 Mar 2009=3D
>=3B >=3B 15:43:41 -0= > >500<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B From: martinbi= > >shop at bellsouth.net<=3BBR>=3B=3D
>=3B >=3B&=3Bgt=3D3B &=3Bg= > >t=3D3B&=3Bgt=3D3B To: mika at async.caltech.edu<=3BBR>=3B&=3Bgt=3D3B= > > &=3Bgt=3D3B&=3Bgt=3D3B CC: m=3D
>=3B >=3B3devel at elegosoft.com= > ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B Subject: Re: [M3d= > >evel] Help fin=3D
>=3B >=3Bding CM3 compiler for Linux?<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bg= > >t=3D3B &=3Bgt=3D3B&=3Bg=3D
>=3B >=3Bt=3D3B Not sure if this he= > >lps=3D3D2C but on my linux system:<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= > >3B&=3Bg=3D
>=3B >=3Bt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &am= > >p=3Bgt=3D3B&=3Bgt=3D3B Critical Mass Modula-3 version d5.7.0<=3BBR>= > >=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B last upd= > >ated: 2008-03-16<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B c= > >ompiled=3D
>=3B >=3B: 2008-08-14 00:56:14<=3BBR>=3B&=3Bgt=3D3= > >B &=3Bgt=3D3B&=3Bgt=3D3B configuration: /usr/local/cm3/=3D
>=3B = > >>=3Bbin/cm3.cfg<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B= > >=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B Linux thin= > >kp=3D
>=3B >=3Bad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2= > >009<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bg=3D
>=3B >=3Bt= > >=3D3B i686 GNU/Linux<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D= > >3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20= > >=3D
>=3B >=3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D= > >3B I don't have the cm3 tarball=3D3D2C but I do have the=3D
>=3B >= > >=3B sources in cm3/ still.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B = > >=3D
>=3B >=3BMika Nystrom wrote:<=3BBR>=3B&=3Bgt=3D3B &=3B= > >gt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B Hello everyone=3D3D2C<=3BBR>=3B&am= > >p=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B= > >=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt= > >=3D3B This is=3D3D2C fo=3D
>=3B >=3Br me=3D3D2C a most unfortunate t= > >ime for the CM3 servers to<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B have crashed. I'm teaching a = > >class using Modula-3=3D3D2C and we n=3D
>=3B >=3Beed a<=3BBR>=3B= > >&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B compiler... here= > >'s the uname of the sys=3D
>=3B >=3Btem I'm trying to use:<=3BBR&g= > >t=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3B= > >BR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3B=3D
>=3B >=3Bgt=3D3B &am= > >p=3Bgt=3D3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i68= > >=3D
>=3B >=3B6 GNU/Lin=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= > >3Bux<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3= > >B=3D3D20<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &=3Bgt=3D3B&= > >=3Bgt=3D3B &=3Bgt=3D3B The most recent archives I have for Linux are:<= > >=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B = > >&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt= > >=3D3B &=3Bgt=3D3B cm3-min-POSIX-=3D
>=3B >=3BLINUXLIBC6-5.4.0.tgz= > > cm3-src-all-5.4.0.tgz=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&am= > >p=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B=3D3D20<=3BBR>=3B&=3Bg= > >t=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B And they don't seem to w= > >ork on this =3D
>=3B >=3Bsystem: I can compile a program<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B but when I tr= > >=3D
>=3B >=3By to run it=3D3D2C it says "Segmentation fault". Can an= > >yone<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3B=3D
>=3B >=3Bg= > >t=3D3B &=3Bgt=3D3B help? (My understanding is that I need 5.5.1 or later= > >...)<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bg= > >t=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Bgt=3D3B &=3Bgt=3D3B Mika<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >= > >=3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3B= > >gt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &am= > >p=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B-= > >-_806446ae-8d10-4d74-8eea-51aa365e9204_<=3BBR>=3B&=3Bgt=3D3B &=3B= > >gt=3D3BConten=3D
>=3B >=3Bt-Type: text/html=3D3B charset=3D3D"iso-88= > >59-1"<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BContent-Transfe=3D
>= > >=3B >=3Br-Encoding: quoted-printable<=3BBR>=3B&=3Bgt=3D3B &=3Bg= > >t=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3Bhtml&=3Bg= > >t=3D
>=3B >=3B=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Blt=3D3Bhead&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Blt=3D3Bstyle&=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D= > >3B &=3Bgt=3D3B.hmmessage P<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B{&l= > >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bmargin:0px=3D3D3B<=3B=3D
>= > >=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bpadding:0px<=3BBR>=3B&am= > >p=3Bgt=3D3B &=3Bgt=3D3B}<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bbody.= > >hmmessag=3D
>=3B >=3Be<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B{&l= > >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfont-size: 10pt=3D3D3B<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3Bfo=3D
>=3B >=3Bnt-family:Verdana<= > >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B}<=3BBR>=3B&=3Bgt=3D3B &= > >=3Bgt=3D3B&=3Blt=3D3B/style&=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>= > >=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3B/head&=3Bgt=3D3B<=3BBR&g= > >t=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3Bbody class=3D3D3D'hmmessa=3D= > >
>=3B >=3Bge'&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= > >3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BA href=3D3D3D"http://modula3.=3D<= > >BR>>=3B >=3Belegosoft.com/cm3/uploaded-archives" targ=3D3D<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3Bet=3D3D3D_blank&=3B=3D
>=3B >=3Bg= > >t=3D3B&=3Blt=3D3BFONT color=3D3D3D#0068cf&=3Bgt=3D3Bhttp://modula3.el= > >egosoft.com/cm3/upl=3D
>=3B >=3Boaded=3D3D<=3BBR>=3B&=3Bgt=3D= > >3B &=3Bgt=3D3B-archives&=3Blt=3D3B/FONT&=3Bgt=3D3B&=3Blt=3D3B/A= > >&=3Bgt=3D3B&=3Blt=3D3BBR&=3Bg=3D
>=3B >=3Bt=3D3B<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3B?&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3B=3D= > >
>=3B >=3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3= > >BI can make another later this week.&=3Blt=3D3BBR&=3Bgt=3D3B<=3B=3D= > >
>=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp= > >=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= > >=3D3BAll you need=3D
>=3B >=3B is a working cm3 on any system.&= > >=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Bgt=3D3BFrom t=3D
>=3B >=3Bhere you can build the whole system=3D3= > >D2C targeting any system.&=3Blt=3D3BBR&=3Bgt=3D
>=3B >=3B=3D3B= > ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAs long as that cm3 understands = > >LONGINT and your target=3D
>=3B >=3B system.&=3Blt=3D3BBR&=3Bg= > >t=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAnd it is easier=3D3D2C bu= > >t not necess=3D
>=3B >=3Bary=3D3D2C if you have Python. :)&=3Blt= > >=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp= > >=3D3Bnbsp=3D
>=3B >=3B=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR&= > >gt=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B- Jay&=3Blt= > >=3D3BBR&=3Bgt=3D3B&=3Blt=3D
>=3B >=3B=3D3BBR&=3Bgt=3D3B&= > >=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3= > >B Date: Tue=3D3D2C 31 M=3D
>=3B >=3Bar 2009 15:43:41 -=3D3D<=3BBR&= > >gt=3B&=3Bgt=3D3B &=3Bgt=3D3B0500&=3Blt=3D3BBR&=3Bgt=3D3B&=3B= > >amp=3D3Bgt=3D3D3B From=3D
>=3B >=3B: martinbishop at bellsouth.net&= > >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B To: mika at async.ca=3D
= > >>=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bltech.edu&= > >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B CC: m3devel at elego=3D
= > >>=3B >=3Bsoft.com&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B= > > Subject: Re: [M3dev=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D
>= > >=3B >=3B=3D3Bel] Help finding CM3 compiler for Linux?&=3Blt=3D3BBR&= > >=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D
>=3B >=3B=3D3BBR&= > >=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B Not sure if t=3D3D<=3BBR>=3B&=3Bg= > >t=3D3B &=3Bgt=3D3Bhis helps=3D3D2C b=3D
>=3B >=3But on my linux s= > >ystem:&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3B= > >BR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D
>=3B >=3B=3D3D3B Critical Mass = > >Mod=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bula-3 version d5.7.0&= > >=3Blt=3D3BBR&=3Bgt=3D
>=3B >=3B=3D3B&=3Bamp=3D3Bgt=3D3D3B last= > > updated: 2008-03-16&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B = > >comp=3D
>=3B >=3Biled:=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= > >3B 2008-08-14 00:56:14&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3= > >B c=3D
>=3B >=3Bonfiguration: /usr/local/cm3/bin/cm3.cfg&=3Blt=3D= > >3BBR=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B&=3B= > >=3D
>=3B >=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3B= > >amp=3D3Bgt=3D3D3B Linux thinkpad 2.6.27-11-generic=3D
>=3B >=3B #1 S= > >MP Thu Jan 29 19:24=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B:39 UTC = > >2009&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3= > >D3B i686 GNU/Linux&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &a= > >mp=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3B=3D
>=3B >=3Bgt=3D3D3B &a= > >mp=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B I don=3D3D<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3B't have the c=3D
>=3B >=3Bm3 tarball= > >=3D3D2C but I do have the sources in cm3/ still.&=3Blt=3D3BBR&=3Bgt= > >=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D<=3BBR>=3B&=3Bgt=3D3B= > > &=3Bgt=3D3B=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D= > >3B Mika Nystrom wr=3D
>=3B >=3Bote:&=3Blt=3D3BBR&=3Bgt=3D3B&am= > >p=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B Hello everyone=3D3D2C&=3B= > >lt=3D3BBR=3D
>=3B >=3B&=3Bgt=3D3B&=3Bamp=3D3Bg=3D3D<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3Bt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt= > >=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D3B &=3Bam= > >p=3D3Bgt=3D3D3B This is=3D3D2C for me=3D3D2C a most unfortunate time =3D >>>=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfor the CM3 s= > >ervers to&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp= > >=3D
>=3B >=3B=3D3Bgt=3D3D3B have crashed. I'm teaching a class =3D3D= > ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Busing Mod=3D
>=3B >=3Bula= > >-3=3D3D2C and we need a&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D= > >3B &=3Bamp=3D3Bgt=3D3D3B compile=3D
>=3B >=3Br... here's the una= > >=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bme of the system I'm trying= > > to use:&=3B=3D
>=3B >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt= > >=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp= > >=3D3Bgt=3D3D3B &=3Bam=3D
>=3B >=3Bp=3D3Bgt=3D3D3B Linu=3D3D<=3B= > >BR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 1= > >0=3D
>=3B >=3B:53:03 PST 2008 i686 GNU/Linux&=3Blt=3D3BBR&=3Bg= > >t=3D3B&=3Bamp=3D3Bg=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bt=3D<= > >BR>>=3B >=3B=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt= > >=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B The most r=3D
>= > >=3B >=3Becent archives I have for Linux are=3D3D<=3BBR>=3B&=3Bgt= > >=3D3B &=3Bgt=3D3B:&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B = > >>=3B=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3= > >B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B cm3-m=3D
>=3B >= > >=3Bin-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D3D<=3BBR>=3B&=3Bgt=3D3B &= > >=3Bgt=3D3B-src-all-5.4.0.tgz &=3Blt=3D
>=3B =3D3BBR&=3Bgt=3D3B&a= > >mp=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt= > >=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D3B = > >And they don't seem =3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bto work= > > on this system: =3D
>=3B >=3BI can compile a program&=3Blt=3D3BB= > >R&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B but when= > >=3D
>=3B >=3B I=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B try = > >to run it=3D3D2C it says "Segmentation fault". Can=3D
>=3B >=3B anyo= > >ne&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt= > >=3D3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B help=3D
>=3B &= > >gt=3B? (My understanding is that I need 5.5.1 or later...)&=3Blt=3D3BBR&= > >amp=3Bgt=3D3B&=3Bamp=3D3Bg=3D
>=3B >=3Bt=3D3D3B &=3Bamp=3D3Bgt= > >=3D3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B &=3Blt=3D3BBR&am= > >p=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D
>=3B >=3B=3D3Bgt= > >=3D3D3B Mika&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Ba= > >mp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Ba=3D
>=3B >=3B= > >mp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Blt=3D3B/body&=3Bgt= > >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3B/html&=3Bg= > >t=3D
>=3B >=3B=3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >lt=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B--_806446ae-8d10-4d74-8eea-51aa36= > >5e=3D
>=3B >=3B9204_--<=3BBR>=3B<=3B/body>=3B
>=3B >= > >=3B<=3B/html>=3B=3D
>=3B >=3B
>=3B >=3B--_777fdc4e-3c29-4= > >0b4-a3dd-e6243f796cee_--
> >= > > > >--_55339e45-8c85-4ab6-9440-0d2131bbad69_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Apr 1 09:08:41 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 01 Apr 2009 00:08:41 -0700 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: Your message of "Wed, 01 Apr 2009 06:56:45 -0000." Message-ID: <200904010708.n3178fm8073790@camembert.async.caltech.edu> Crazily enough, this seems to have worked.... just had to add "-lpthread" to the LIBC libraries in the file. Oh and I had to make some libXaw symlinks to get your mentor binary to work---they seem to be on libXaw.so.7 now. (Yes I know new major #s shouldn't work, but it does seem to...) Thanks for tonight :-) Jay writes: >--_6a7b1519-a5fa-4142-b418-a208dc02c427_ ... > >You had a kind of working install from 5.4 and running its cminstall. > > cm3 ran but produced crashing binaries. > >=20 > >Take the cm3.cfg file from it and put it at. > ... From wagner at elegosoft.com Wed Apr 1 11:11:53 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 01 Apr 2009 11:11:53 +0200 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: <200904010559.n315xIBx071256@camembert.async.caltech.edu> References: <200904010559.n315xIBx071256@camembert.async.caltech.edu> Message-ID: <20090401111153.ul0hzu7nokc808sg@mail.elegosoft.com> Quoting Mika Nystrom : > > Is there any documentation for this format beyond what you just > wrote? Where? Well, yes, that's the problem with these kinds of archives: (1) they're not well tested and (2) there's no documentation user's can rely on This doesn't mean that I disapprove or want to criticise the contributors, but an official well-documented release with installation notes etc. has some advantages. Unfortunately, the official releases are really outdated now. I succeeded in building current AMD64_LINUX and FreeBSD4 installations on our servers for d5.7.1 tonight and was able to build archives for FreeBSD binaries and sources, but the tooling failed for AMD64_KINUX due to changed and missing configuration files. I'll need to have a closer look at that, some extensions seem to be needed. Anybody who feels he can do that faster than me is of course encouraged (I'll have little time as usual :-/). It may also turn out to be difficult to produce LINUXLIBC6 binaries, as birch and other Elego servers are now 64 bit machines, and trying to use current CM3 with --32 produced lots of assembler errors about unsupported instructions on this architecture. As the old installation on birch seems to be gone without a chance of being restored, it will probably be easiest to use a real 32 bit system and start from 5.4.0 again. Anybody who wants to help should be able to build the binary archives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh easily and upload them to birch at /var/www/modula3.elegosoft.com/cm3/uploaded-archives My guess is that tinderbox will take some time to run smoothly again, as it was highly customized, and I'm not sure if these customizations survied the crash. Please stay tuned and thanks for all your patience, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 1 11:22:58 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Apr 2009 09:22:58 +0000 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: <20090401111153.ul0hzu7nokc808sg@mail.elegosoft.com> References: <200904010559.n315xIBx071256@camembert.async.caltech.edu> <20090401111153.ul0hzu7nokc808sg@mail.elegosoft.com> Message-ID: Olaf, in the LINUXLIBC6 configuration, try putting --32 on the as/gas invocations. You mentioned --32 on cm3, but I wonder if you meant -m32 on cm3. cm3 -m32 as --32 or check the man pages or help. They aren't consistent, for more reasons than shown here (e.g. MIPS has -mabi64, and I think AIX has something else, and HP-UX gcc supports none of these -- no bi-arch support). > probably be easiest to use a real 32 bit system and start from 5.4.0 > again. Using any current system should be plenty easy too. e.g. the distributions I put up. :) AMD64_LINUX should be a good starting point, but I haven't tried it in a bit. I should be able to build a current LINUXLIBC6 very very soon. I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test a switch to the "new" Unix *.i3 files. I'll be using python/make-dist.py though. I do need to get more packages into it though, e.g. cm3ide and m3gdb. - Jay > Date: Wed, 1 Apr 2009 11:11:53 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > CC: mand at elego.de; m3-support at elego.de > Subject: Re: [M3devel] Help finding CM3 compiler for Linux? > > Quoting Mika Nystrom : > > > > > Is there any documentation for this format beyond what you just > > wrote? Where? > > Well, yes, that's the problem with these kinds of archives: > > (1) they're not well tested and > (2) there's no documentation user's can rely on > > This doesn't mean that I disapprove or want to criticise the contributors, > but an official well-documented release with installation notes etc. > has some advantages. Unfortunately, the official releases are really > outdated now. > > I succeeded in building current AMD64_LINUX and FreeBSD4 installations > on our servers for d5.7.1 tonight and was able to build archives for > FreeBSD binaries and sources, but the tooling failed for AMD64_KINUX > due to changed and missing configuration files. I'll need to have a > closer look at that, some extensions seem to be needed. Anybody who > feels he can do that faster than me is of course encouraged (I'll have > little time as usual :-/). > > It may also turn out to be difficult to produce LINUXLIBC6 binaries, > as birch and other Elego servers are now 64 bit machines, and trying > to use current CM3 with --32 produced lots of assembler errors about > unsupported instructions on this architecture. As the old installation > on birch seems to be gone without a chance of being restored, it will > probably be easiest to use a real 32 bit system and start from 5.4.0 > again. > > Anybody who wants to help should be able to build the binary > archives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh > easily and upload them to birch at > > /var/www/modula3.elegosoft.com/cm3/uploaded-archives > > My guess is that tinderbox will take some time to run smoothly again, > as it was highly customized, and I'm not sure if these customizations > survied the crash. > > Please stay tuned and thanks for all your patience, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Wed Apr 1 12:03:47 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 01 Apr 2009 12:03:47 +0200 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090331145127.GB9624@topoi.pooq.com> References: <20090331145127.GB9624@topoi.pooq.com> Message-ID: <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > The BottonVBT contains an action, which is a procedure rather than a > method. b This makes it awkward to subclass ButtonVBT becaue the action > will still expect its first parameter to be a ButtonVBT instead of > belonging to the subclass, and an explicit downcast of some sort will be > needed to acess the subclass's members. > > The Trestle manual says this was a deliberate decision: > > : The action procedure is a field rather than a method in order to allow > : buttons with different action procedures to share their method suites. > > I, however, find it massively inconvenient because it mans I have to > resort to downcasting or the very kludgey VBT.GetProp to access what > should be just there. I'd rather the action procedure was a method. > > But it should be possible to have the best of both worlds. Have an > action2 (better name wanted here) method that is available for > overriding, and by default calls the procedure in the existing action. > field. That action2 method wounl then be called by Trestle wherever > action is now called. > > Does anyone see problems with this? Sounds fine to me offhand. You should test your extensions with some of the existing larger applications, like mentor and Juno-2, of course. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 1 16:25:13 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Apr 2009 14:25:13 +0000 Subject: [M3devel] new Linux/x86 archives Message-ID: new Linux/x86 archives, the ones are version 5.7.1: http://modula3.elegosoft.com/cm3/uploaded-archives => http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-LINUXLIBC6-d5.7.1.tar.gz http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-LINUXLIBC6-d5.7.1.tar.lzma http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-LINUXLIBC6-d5.7.1.tar.gz http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-LINUXLIBC6-d5.7.1.tar.lzma The last one is still compressing/uploading (lzma compresses very slow, but compresses smallest and uncompressed fast or fastest.) notes: Mika's problem is fixed. (Jan 12: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cminstall/src/config-no-install/cm3cfg.common) Be sure to export PATH=installroot/bin:$PATH and LD_LIBRARY_PATH=installroot/lib or LD_LIBRARY_PATH=installroot/lib:$LD_LIBRARY_PATH Don't have Modula-3 .so files in /tmp/tmpdtNszn/... (objdump -x installroot/bin/mentor | grep PATH to see what I mean) A near future build should: not require setting either environment variable, nor look in /tmp. setting $PATH will be optional for convenience to find cm3, but cm3 won't use it to find cm3cg. Shared libs will be found via rpath=$ORIGIN/../lib. (Consensus that that is a good idea? Seems clear to me. $LD_LIBRARY_PATH should still either override or provide fallback, for uninstalled binaries or binaries installed elsewhere.) - Jay From hendrik at topoi.pooq.com Wed Apr 1 16:59:45 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 1 Apr 2009 10:59:45 -0400 Subject: [M3devel] new Linux/x86 archives In-Reply-To: References: Message-ID: <20090401145945.GA12017@topoi.pooq.com> On Wed, Apr 01, 2009 at 02:25:13PM +0000, Jay wrote: > > A near future build should: > not require setting either environment variable, nor look in /tmp. > setting $PATH will be optional for convenience to find cm3, > but cm3 won't use it to find cm3cg. > Shared libs will be found via rpath=$ORIGIN/../lib. Would this be problematic it $ORIGIN is a symbolic link? -- hendrik From vapier at gentoo.org Wed Apr 1 17:23:55 2009 From: vapier at gentoo.org (Mike Frysinger) Date: Wed, 1 Apr 2009 11:23:55 -0400 Subject: [M3devel] new Linux/x86 archives In-Reply-To: <20090401145945.GA12017@topoi.pooq.com> References: <20090401145945.GA12017@topoi.pooq.com> Message-ID: <200904011123.56014.vapier@gentoo.org> On Wednesday 01 April 2009 10:59:45 hendrik at topoi.pooq.com wrote: > On Wed, Apr 01, 2009 at 02:25:13PM +0000, Jay wrote: > > A near future build should: > > not require setting either environment variable, nor look in /tmp. > > setting $PATH will be optional for convenience to find cm3, > > but cm3 won't use it to find cm3cg. > > Shared libs will be found via rpath=$ORIGIN/../lib. > > Would this be problematic it $ORIGIN is a symbolic link? is that realistic ? you'd have to unpack the archive, move only ./bin/ somewhere, and then symlink it back in. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mika at async.caltech.edu Wed Apr 1 18:59:45 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 01 Apr 2009 09:59:45 -0700 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: Your message of "Wed, 01 Apr 2009 09:22:58 -0000." Message-ID: <200904011659.n31GxkMW094881@camembert.async.caltech.edu> I have to say that once I figured out what I needed to do, using Jay's distributions was easy---easier than I'm used to with CM3. All I had to do was: untar the -std dist (forget the min one). Set PATH and LD_LIBRARY_PATH And then---the mysterious part, which takes more than passing knowledge of how CM3 works---providing a cm3.cfg file, which doesn't seem to be provided at all by Jay's archive. It seems to me it would be quite easy to package this up, maybe even with cminstall? That would be easiest I think, to cminstall the whole dist rather than cminstalling just the -min and then making people build their own compiler, libraries, and demo apps... Mika Jay writes: >--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Olaf=2C in the LINUXLIBC6 configuration=2C try putting --32 on the as/gas i= >nvocations. > >You mentioned --32 on cm3=2C but I wonder if you meant -m32 on cm3. > > cm3 -m32=20 > > as --32=20 > >=20 > >or check the man pages or help. They aren't consistent=2C for more reasons = >than shown here (e.g. MIPS has -mabi64=2C and I think AIX has something els= >e=2C and HP-UX gcc supports none of these -- no bi-arch support). > >=20 > > > probably be easiest to use a real 32 bit system and start from 5.4.0 > > again. > > >Using any current system should be plenty easy too. > >e.g. the distributions I put up. :) > >=20 > >AMD64_LINUX should be a good starting point=2C but I haven't tried it in a = >bit. > >=20 > >I should be able to build a current LINUXLIBC6 very very soon. > >I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test= > a switch to the "new" Unix *.i3 files. > >=20 > >I'll be using python/make-dist.py though. > >I do need to get more packages into it though=2C e.g. cm3ide and m3gdb. > >=20 > > - Jay >=20 >> Date: Wed=2C 1 Apr 2009 11:11:53 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> CC: mand at elego.de=3B m3-support at elego.de >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >>=20 >> Quoting Mika Nystrom : >>=20 >> > >> > Is there any documentation for this format beyond what you just >> > wrote? Where? >>=20 >> Well=2C yes=2C that's the problem with these kinds of archives: >>=20 >> (1) they're not well tested and >> (2) there's no documentation user's can rely on >>=20 >> This doesn't mean that I disapprove or want to criticise the contributors= >=2C >> but an official well-documented release with installation notes etc. >> has some advantages. Unfortunately=2C the official releases are really >> outdated now. >>=20 >> I succeeded in building current AMD64_LINUX and FreeBSD4 installations >> on our servers for d5.7.1 tonight and was able to build archives for >> FreeBSD binaries and sources=2C but the tooling failed for AMD64_KINUX >> due to changed and missing configuration files. I'll need to have a >> closer look at that=2C some extensions seem to be needed. Anybody who >> feels he can do that faster than me is of course encouraged (I'll have >> little time as usual :-/). >>=20 >> It may also turn out to be difficult to produce LINUXLIBC6 binaries=2C >> as birch and other Elego servers are now 64 bit machines=2C and trying >> to use current CM3 with --32 produced lots of assembler errors about >> unsupported instructions on this architecture. As the old installation >> on birch seems to be gone without a chance of being restored=2C it will >> probably be easiest to use a real 32 bit system and start from 5.4.0 >> again. >>=20 >> Anybody who wants to help should be able to build the binary >> archives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh >> easily and upload them to birch at >>=20 >> /var/www/modula3.elegosoft.com/cm3/uploaded-archives >>=20 >> My guess is that tinderbox will take some time to run smoothly again=2C >> as it was highly customized=2C and I'm not sure if these customizations >> survied the crash. >>=20 >> Please stay tuned and thanks for all your patience=2C >>=20 >> Olaf >> --=20 >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 9= >5 >> http://www.elegosoft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berli= >n >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214= >194 >>=20 > >--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Olaf=2C in the LINUXLIBC6 configuration=2C try putting --32 on the as/gas i= >nvocations.
>You mentioned --32 on cm3=2C but I wonder if you meant -m32 on cm3.
> =3Bcm3 -m32
> =3Bas --32
> =3B
>or check the man pages or help. They aren't consistent=2C for more reasons = >than shown here (e.g. MIPS has -mabi64=2C and I think AIX has something els= >e=2C and HP-UX gcc supports none of these -- no bi-arch support).
> =3B
> =3B>=3B probably be easiest to use a real 32 bit system and start fr= >om 5.4.0
 =3B>=3B again.

>Using any current system should be plenty easy too.
>e.g. the distributions I put up. :)
> =3B
>AMD64_LINUX should be a good starting point=2C but I haven't tried it in a = >bit.
> =3B
>I should be able to build a current LINUXLIBC6 very very soon.
>I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test= > a switch to the "new" Unix *.i3 files.
> =3B
>I'll be using python/make-dist.py though.
>I do need to get more packages into it though=2C e.g. cm3ide and m3gdb.
> =3B
> =3B- Jay
 =3B
>=3B Date: Wed=2C 1 Apr 2009 11:11:53 +0200<= >BR>>=3B From: wagner at elegosoft.com
>=3B To: m3devel at elegosoft.com>>=3B CC: mand at elego.de=3B m3-support at elego.de
>=3B Subject: Re: [M3= >devel] Help finding CM3 compiler for Linux?
>=3B
>=3B Quoting Mi= >ka Nystrom <=3Bmika at async.caltech.edu>=3B:
>=3B
>=3B >=3B<= >BR>>=3B >=3B Is there any documentation for this format beyond what you= > just
>=3B >=3B wrote? Where?
>=3B
>=3B Well=2C yes=2C th= >at's the problem with these kinds of archives:
>=3B
>=3B (1) the= >y're not well tested and
>=3B (2) there's no documentation user's can = >rely on
>=3B
>=3B This doesn't mean that I disapprove or want to= > criticise the contributors=2C
>=3B but an official well-documented re= >lease with installation notes etc.
>=3B has some advantages. Unfortuna= >tely=2C the official releases are really
>=3B outdated now.
>=3B = >
>=3B I succeeded in building current AMD64_LINUX and FreeBSD4 install= >ations
>=3B on our servers for d5.7.1 tonight and was able to build ar= >chives for
>=3B FreeBSD binaries and sources=2C but the tooling failed= > for AMD64_KINUX
>=3B due to changed and missing configuration files. = I'll need to have a
>=3B closer look at that=2C some extensions seem t= >o be needed. Anybody who
>=3B feels he can do that faster than me is o= >f course encouraged (I'll have
>=3B little time as usual :-/).
>= >=3B
>=3B It may also turn out to be difficult to produce LINUXLIBC6 b= >inaries=2C
>=3B as birch and other Elego servers are now 64 bit machin= >es=2C and trying
>=3B to use current CM3 with --32 produced lots of as= >sembler errors about
>=3B unsupported instructions on this architectur= >e. As the old installation
>=3B on birch seems to be gone without a ch= >ance of being restored=2C it will
>=3B probably be easiest to use a re= >al 32 bit system and start from 5.4.0
>=3B again.
>=3B
>=3B= > Anybody who wants to help should be able to build the binary
>=3B arc= >hives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh
>=3B easily = >and upload them to birch at
>=3B
>=3B /var/www/modula3.elegosoft= >.com/cm3/uploaded-archives
>=3B
>=3B My guess is that tinderbox = >will take some time to run smoothly again=2C
>=3B as it was highly cus= >tomized=2C and I'm not sure if these customizations
>=3B survied the c= >rash.
>=3B
>=3B Please stay tuned and thanks for all your patien= >ce=2C
>=3B
>=3B Olaf
>=3B --
>=3B Olaf Wagner -- eleg= >o Software Solutions GmbH
>=3B Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C= > 13355 Berlin=2C Germany
>=3B phone: +49 30 23 45 86 96 mobile: +49 17= >7 2345 869 fax: +49 30 23 45 86 95
>=3B http://www.elegosoft.com | Ges= >ch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berlin
>=3B Handelregister: Amts= >gericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>=3B
dy> >= > >--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_-- From rodney.bates at wichita.edu Wed Apr 1 19:24:58 2009 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 01 Apr 2009 12:24:58 -0500 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090331145127.GB9624@topoi.pooq.com> References: <20090331145127.GB9624@topoi.pooq.com> Message-ID: <49D3A36A.1030501@wichita.edu> hendrik at topoi.pooq.com wrote: > The BottonVBT contains an action, which is a procedure rather than a > method. b This makes it awkward to subclass ButtonVBT becaue the action > will still expect its first parameter to be a ButtonVBT instead of > belonging to the subclass, and an explicit downcast of some sort will be > needed to acess the subclass's members. > > The Trestle manual says this was a deliberate decision: > > : The action procedure is a field rather than a method in order to allow > : buttons with different action procedures to share their method suites. I don't understand the original reasoning. If 'action' were a method, you could create different buttons with overrides for 'action' but not override any other method and get exactly the same set of shared methods among the buttons as in the original design. What have I missed? > > I, however, find it massively inconvenient because it mans I have to > resort to downcasting or the very kludgey VBT.GetProp to access what > should be just there. I'd rather the action procedure was a method. > > But it should be possible to have the best of both worlds. Have an > action2 (better name wanted here) method that is available for > overriding, and by default calls the procedure in the existing action. > field. That action2 method wounl then be called by Trestle wherever > action is now called. > > Does anyone see problems with this? > > -- hendrik > Rodney Bates From mika at async.caltech.edu Wed Apr 1 19:33:01 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 01 Apr 2009 10:33:01 -0700 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: Your message of "Wed, 01 Apr 2009 12:24:58 CDT." <49D3A36A.1030501@wichita.edu> Message-ID: <200904011733.n31HX1mO096260@camembert.async.caltech.edu> Seems a bit mysterious to me too but I wonder if it's not a way of getting the benefits of multiple inheritance. If you want method m1 from one set of VBTs V and method m2 from another set W, you can't inherit from both. But if the methods are instead procedure fields with the common supertype as the first argument, you can set the fields of X, m1 := V.M1, m2 := W.m2, even though X is a subtype of neither V nor W... You can probably use a design pattern to get something similar without using procedure fields, but that would involve introducing new types. Mika "Rodney M. Bates" writes: >hendrik at topoi.pooq.com wrote: >> The BottonVBT contains an action, which is a procedure rather than a >> method. b This makes it awkward to subclass ButtonVBT becaue the action >> will still expect its first parameter to be a ButtonVBT instead of >> belonging to the subclass, and an explicit downcast of some sort will be >> needed to acess the subclass's members. >> >> The Trestle manual says this was a deliberate decision: >> >> : The action procedure is a field rather than a method in order to allow >> : buttons with different action procedures to share their method suites. > >I don't understand the original reasoning. If 'action' were a method, you >could create different buttons with overrides for 'action' but not override >any other method and get exactly the same set of shared methods among the >buttons as in the original design. What have I missed? > >> >> I, however, find it massively inconvenient because it mans I have to >> resort to downcasting or the very kludgey VBT.GetProp to access what >> should be just there. I'd rather the action procedure was a method. >> >> But it should be possible to have the best of both worlds. Have an >> action2 (better name wanted here) method that is available for >> overriding, and by default calls the procedure in the existing action. >> field. That action2 method wounl then be called by Trestle wherever >> action is now called. >> >> Does anyone see problems with this? >> >> -- hendrik >> > >Rodney Bates From hendrik at topoi.pooq.com Wed Apr 1 22:34:32 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 1 Apr 2009 16:34:32 -0400 Subject: [M3devel] new Linux/x86 archives In-Reply-To: <200904011123.56014.vapier@gentoo.org> References: <20090401145945.GA12017@topoi.pooq.com> <200904011123.56014.vapier@gentoo.org> Message-ID: <20090401203432.GA12427@topoi.pooq.com> On Wed, Apr 01, 2009 at 11:23:55AM -0400, Mike Frysinger wrote: > On Wednesday 01 April 2009 10:59:45 hendrik at topoi.pooq.com wrote: > > On Wed, Apr 01, 2009 at 02:25:13PM +0000, Jay wrote: > > > A near future build should: > > > not require setting either environment variable, nor look in /tmp. > > > setting $PATH will be optional for convenience to find cm3, > > > but cm3 won't use it to find cm3cg. > > > Shared libs will be found via rpath=$ORIGIN/../lib. > > > > Would this be problematic it $ORIGIN is a symbolic link? > > is that realistic ? you'd have to unpack the archive, move only ./bin/ > somewhere, and then symlink it back in. I guess not. > -mike From jay.krell at cornell.edu Wed Apr 1 22:51:22 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Apr 2009 20:51:22 +0000 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: <200904011659.n31GxkMW094881@camembert.async.caltech.edu> References: Your message of "Wed, 01 Apr 2009 09:22:58 -0000." <200904011659.n31GxkMW094881@camembert.async.caltech.edu> Message-ID: Thank you Mika. There is a cm3.cfg file, but it had a small bug. Actually if you look the cm3.cfg file was probably a mere one line that includes LINUXLIBC6. That is probably overly confusing for anyone trying to understand how it works. If you repeat the experiment with the 5.7.1 archives you should find it easier. The not easy cheat is to take cm3cfg.common from current source tree. If you repeat it with a NOT yet existing archive that I have in mind, even easier, however not for all platforms -- i.e. no need to set LD_LIBRARY_PATH, on platforms that support $ORIGIN, but again, not yet. NT386 is already easy this way, since the .dlls are in the bin directory and that is searched; that is NT386-specific. I also need to get m3gdb and cm3ide into it. > It seems to me it would be quite easy to package this up, maybe even > with cminstall? That would be easiest I think, to cminstall the whole I deliberately don't. I find cminstall not very worthwhile. Try the 5.7.1 archive and see what you think? What you are saying I guess is you like the "one level archive" instead of the usual "two level". Agreed. One level can be easily achieved and have cminstall do a copy instead of untargz. But I also find cminstall not all that worthwhile (as I've said..). - Jay ---------------------------------------- > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Help finding CM3 compiler for Linux? > Date: Wed, 1 Apr 2009 09:59:45 -0700 > From: mika at async.caltech.edu > > > I have to say that once I figured out what I needed to do, using > Jay's distributions was easy---easier than I'm used to with CM3. > > All I had to do was: untar the -std dist (forget the min one). > > Set PATH and LD_LIBRARY_PATH > > And then---the mysterious part, which takes more than passing knowledge > of how CM3 works---providing a cm3.cfg file, which doesn't seem to be > provided at all by Jay's archive. > > It seems to me it would be quite easy to package this up, maybe even > with cminstall? That would be easiest I think, to cminstall the whole > dist rather than cminstalling just the -min and then making people build > their own compiler, libraries, and demo apps... > > Mika > > Jay writes: >>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_ >>Content-Type: text/plain; charset="iso-8859-1" >>Content-Transfer-Encoding: quoted-printable >> >> >>Olaf=2C in the LINUXLIBC6 configuration=2C try putting --32 on the as/gas i= >>nvocations. >> >>You mentioned --32 on cm3=2C but I wonder if you meant -m32 on cm3. >> >> cm3 -m32=20 >> >> as --32=20 >> >>=20 >> >>or check the man pages or help. They aren't consistent=2C for more reasons = >>than shown here (e.g. MIPS has -mabi64=2C and I think AIX has something els= >>e=2C and HP-UX gcc supports none of these -- no bi-arch support). >> >>=20 >> >>> probably be easiest to use a real 32 bit system and start from 5.4.0 >>> again. >> >> >>Using any current system should be plenty easy too. >> >>e.g. the distributions I put up. :) >> >>=20 >> >>AMD64_LINUX should be a good starting point=2C but I haven't tried it in a = >>bit. >> >>=20 >> >>I should be able to build a current LINUXLIBC6 very very soon. >> >>I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test= >> a switch to the "new" Unix *.i3 files. >> >>=20 >> >>I'll be using python/make-dist.py though. >> >>I do need to get more packages into it though=2C e.g. cm3ide and m3gdb. >> >>=20 >> >> - Jay >>=20 >>> Date: Wed=2C 1 Apr 2009 11:11:53 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> CC: mand at elego.de=3B m3-support at elego.de >>> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >>>=20 >>> Quoting Mika Nystrom : >>>=20 >>>> >>>> Is there any documentation for this format beyond what you just >>>> wrote? Where? >>>=20 >>> Well=2C yes=2C that's the problem with these kinds of archives: >>>=20 >>> (1) they're not well tested and >>> (2) there's no documentation user's can rely on >>>=20 >>> This doesn't mean that I disapprove or want to criticise the contributors= >>=2C >>> but an official well-documented release with installation notes etc. >>> has some advantages. Unfortunately=2C the official releases are really >>> outdated now. >>>=20 >>> I succeeded in building current AMD64_LINUX and FreeBSD4 installations >>> on our servers for d5.7.1 tonight and was able to build archives for >>> FreeBSD binaries and sources=2C but the tooling failed for AMD64_KINUX >>> due to changed and missing configuration files. I'll need to have a >>> closer look at that=2C some extensions seem to be needed. Anybody who >>> feels he can do that faster than me is of course encouraged (I'll have >>> little time as usual :-/). >>>=20 >>> It may also turn out to be difficult to produce LINUXLIBC6 binaries=2C >>> as birch and other Elego servers are now 64 bit machines=2C and trying >>> to use current CM3 with --32 produced lots of assembler errors about >>> unsupported instructions on this architecture. As the old installation >>> on birch seems to be gone without a chance of being restored=2C it will >>> probably be easiest to use a real 32 bit system and start from 5.4.0 >>> again. >>>=20 >>> Anybody who wants to help should be able to build the binary >>> archives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh >>> easily and upload them to birch at >>>=20 >>> /var/www/modula3.elegosoft.com/cm3/uploaded-archives >>>=20 >>> My guess is that tinderbox will take some time to run smoothly again=2C >>> as it was highly customized=2C and I'm not sure if these customizations >>> survied the crash. >>>=20 >>> Please stay tuned and thanks for all your patience=2C >>>=20 >>> Olaf >>> --=20 >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 9= >>5 >>> http://www.elegosoft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berli= >>n >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214= >>194 >>>=20 >> >>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_ >>Content-Type: text/html; charset="iso-8859-1" >>Content-Transfer-Encoding: quoted-printable >> >> >> >> >> >> >>Olaf=2C in the LINUXLIBC6 configuration=2C try putting --32 on the as/gas i= >>nvocations. >>You mentioned --32 on cm3=2C but I wonder if you meant -m32 on cm3. >> =3Bcm3 -m32 >> =3Bas --32 >> =3B >>or check the man pages or help. They aren't consistent=2C for more reasons = >>than shown here (e.g. MIPS has -mabi64=2C and I think AIX has something els= >>e=2C and HP-UX gcc supports none of these -- no bi-arch support). >> =3B >> =3B>=3B probably be easiest to use a real 32 bit system and start fr= >>om 5.4.0 =3B>=3B again. >>Using any current system should be plenty easy too. >>e.g. the distributions I put up. :) >> =3B >>AMD64_LINUX should be a good starting point=2C but I haven't tried it in a = >>bit. >> =3B >>I should be able to build a current LINUXLIBC6 very very soon. >>I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test= >> a switch to the "new" Unix *.i3 files. >> =3B >>I'll be using python/make-dist.py though. >>I do need to get more packages into it though=2C e.g. cm3ide and m3gdb. >> =3B >> =3B- Jay =3B >=3B Date: Wed=2C 1 Apr 2009 11:11:53 +0200<= >>BR>>=3B From: wagner at elegosoft.com >=3B To: m3devel at elegosoft.com>>>>=3B CC: mand at elego.de=3B m3-support at elego.de >=3B Subject: Re: [M3= >>devel] Help finding CM3 compiler for Linux? >=3B >=3B Quoting Mi= >>ka Nystrom <=3Bmika at async.caltech.edu>=3B: >=3B >=3B>=3B<= >>BR>>=3B>=3B Is there any documentation for this format beyond what you= >> just >=3B>=3B wrote? Where? >=3B >=3B Well=2C yes=2C th= >>at's the problem with these kinds of archives: >=3B >=3B (1) the= >>y're not well tested and >=3B (2) there's no documentation user's can = >>rely on >=3B >=3B This doesn't mean that I disapprove or want to= >> criticise the contributors=2C >=3B but an official well-documented re= >>lease with installation notes etc. >=3B has some advantages. Unfortuna= >>tely=2C the official releases are really >=3B outdated now. >=3B = >> >=3B I succeeded in building current AMD64_LINUX and FreeBSD4 install= >>ations >=3B on our servers for d5.7.1 tonight and was able to build ar= >>chives for >=3B FreeBSD binaries and sources=2C but the tooling failed= >> for AMD64_KINUX >=3B due to changed and missing configuration files. = > I'll need to have a >=3B closer look at that=2C some extensions seem t= >>o be needed. Anybody who >=3B feels he can do that faster than me is o= >>f course encouraged (I'll have >=3B little time as usual :-/). >= >>=3B >=3B It may also turn out to be difficult to produce LINUXLIBC6 b= >>inaries=2C >=3B as birch and other Elego servers are now 64 bit machin= >>es=2C and trying >=3B to use current CM3 with --32 produced lots of as= >>sembler errors about >=3B unsupported instructions on this architectur= >>e. As the old installation >=3B on birch seems to be gone without a ch= >>ance of being restored=2C it will >=3B probably be easiest to use a re= >>al 32 bit system and start from 5.4.0 >=3B again. >=3B >=3B= >> Anybody who wants to help should be able to build the binary >=3B arc= >>hives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh >=3B easily = >>and upload them to birch at >=3B >=3B /var/www/modula3.elegosoft= >>.com/cm3/uploaded-archives >=3B >=3B My guess is that tinderbox = >>will take some time to run smoothly again=2C >=3B as it was highly cus= >>tomized=2C and I'm not sure if these customizations >=3B survied the c= >>rash. >=3B >=3B Please stay tuned and thanks for all your patien= >>ce=2C >=3B >=3B Olaf >=3B -- >=3B Olaf Wagner -- eleg= >>o Software Solutions GmbH >=3B Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C= >> 13355 Berlin=2C Germany >=3B phone: +49 30 23 45 86 96 mobile: +49 17= >>7 2345 869 fax: +49 30 23 45 86 95 >=3B http://www.elegosoft.com | Ges= >>ch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berlin >=3B Handelregister: Amts= >>gericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >=3B >>dy> >>= >> >>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_-- From jay.krell at cornell.edu Wed Apr 1 22:55:46 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Apr 2009 20:55:46 +0000 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: <200904011659.n31GxkMW094881@camembert.async.caltech.edu> References: Your message of "Wed, 01 Apr 2009 09:22:58 -0000." <200904011659.n31GxkMW094881@camembert.async.caltech.edu> Message-ID: er, actually, the two level shouldn't be too bad, given that cminstall extracts the second level..so I don't know. "Usual two level" as in "usual Modula-3 two level", not usual outside Modula-3. But again, your experience was much worse than intended. There is a cm3.cfg file but it had a small but fatal bug. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Help finding CM3 compiler for Linux? > Date: Wed, 1 Apr 2009 20:51:22 +0000 > > > Thank you Mika. There is a cm3.cfg file, but it had a small bug. > Actually if you look the cm3.cfg file was probably a mere one line that includes LINUXLIBC6. That is probably overly confusing for anyone trying to understand how it works. > > If you repeat the experiment with the 5.7.1 archives you should find it easier. > The not easy cheat is to take cm3cfg.common from current source tree. > > If you repeat it with a NOT yet existing archive that I have in mind, even easier, however not for all platforms -- i.e. no need to set LD_LIBRARY_PATH, on platforms that support $ORIGIN, but again, not yet. NT386 is already easy this way, since the .dlls are in the bin directory and that is searched; that is NT386-specific. > > I also need to get m3gdb and cm3ide into it. > >> It seems to me it would be quite easy to package this up, maybe even >> with cminstall? That would be easiest I think, to cminstall the whole > > I deliberately don't. > I find cminstall not very worthwhile. > Try the 5.7.1 archive and see what you think? > > What you are saying I guess is you like the "one level archive" instead of the usual "two level". Agreed. One level can be easily achieved and have cminstall do a copy instead of untargz. But I also find cminstall not all that worthwhile (as I've said..). > > > - Jay > > ---------------------------------------- >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >> Date: Wed, 1 Apr 2009 09:59:45 -0700 >> From: mika at async.caltech.edu >> >> >> I have to say that once I figured out what I needed to do, using >> Jay's distributions was easy---easier than I'm used to with CM3. >> >> All I had to do was: untar the -std dist (forget the min one). >> >> Set PATH and LD_LIBRARY_PATH >> >> And then---the mysterious part, which takes more than passing knowledge >> of how CM3 works---providing a cm3.cfg file, which doesn't seem to be >> provided at all by Jay's archive. >> >> It seems to me it would be quite easy to package this up, maybe even >> with cminstall? That would be easiest I think, to cminstall the whole >> dist rather than cminstalling just the -min and then making people build >> their own compiler, libraries, and demo apps... >> >> Mika >> >> Jay writes: >>>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_ >>>Content-Type: text/plain; charset="iso-8859-1" >>>Content-Transfer-Encoding: quoted-printable >>> >>> >>>Olaf=2C in the LINUXLIBC6 configuration=2C try putting --32 on the as/gas i= >>>nvocations. >>> >>>You mentioned --32 on cm3=2C but I wonder if you meant -m32 on cm3. >>> >>> cm3 -m32=20 >>> >>> as --32=20 >>> >>>=20 >>> >>>or check the man pages or help. They aren't consistent=2C for more reasons = >>>than shown here (e.g. MIPS has -mabi64=2C and I think AIX has something els= >>>e=2C and HP-UX gcc supports none of these -- no bi-arch support). >>> >>>=20 >>> >>>> probably be easiest to use a real 32 bit system and start from 5.4.0 >>>> again. >>> >>> >>>Using any current system should be plenty easy too. >>> >>>e.g. the distributions I put up. :) >>> >>>=20 >>> >>>AMD64_LINUX should be a good starting point=2C but I haven't tried it in a = >>>bit. >>> >>>=20 >>> >>>I should be able to build a current LINUXLIBC6 very very soon. >>> >>>I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test= >>> a switch to the "new" Unix *.i3 files. >>> >>>=20 >>> >>>I'll be using python/make-dist.py though. >>> >>>I do need to get more packages into it though=2C e.g. cm3ide and m3gdb. >>> >>>=20 >>> >>> - Jay >>>=20 >>>> Date: Wed=2C 1 Apr 2009 11:11:53 +0200 >>>> From: wagner at elegosoft.com >>>> To: m3devel at elegosoft.com >>>> CC: mand at elego.de=3B m3-support at elego.de >>>> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >>>>=20 >>>> Quoting Mika Nystrom : >>>>=20 >>>>> >>>>> Is there any documentation for this format beyond what you just >>>>> wrote? Where? >>>>=20 >>>> Well=2C yes=2C that's the problem with these kinds of archives: >>>>=20 >>>> (1) they're not well tested and >>>> (2) there's no documentation user's can rely on >>>>=20 >>>> This doesn't mean that I disapprove or want to criticise the contributors= >>>=2C >>>> but an official well-documented release with installation notes etc. >>>> has some advantages. Unfortunately=2C the official releases are really >>>> outdated now. >>>>=20 >>>> I succeeded in building current AMD64_LINUX and FreeBSD4 installations >>>> on our servers for d5.7.1 tonight and was able to build archives for >>>> FreeBSD binaries and sources=2C but the tooling failed for AMD64_KINUX >>>> due to changed and missing configuration files. I'll need to have a >>>> closer look at that=2C some extensions seem to be needed. Anybody who >>>> feels he can do that faster than me is of course encouraged (I'll have >>>> little time as usual :-/). >>>>=20 >>>> It may also turn out to be difficult to produce LINUXLIBC6 binaries=2C >>>> as birch and other Elego servers are now 64 bit machines=2C and trying >>>> to use current CM3 with --32 produced lots of assembler errors about >>>> unsupported instructions on this architecture. As the old installation >>>> on birch seems to be gone without a chance of being restored=2C it will >>>> probably be easiest to use a real 32 bit system and start from 5.4.0 >>>> again. >>>>=20 >>>> Anybody who wants to help should be able to build the binary >>>> archives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh >>>> easily and upload them to birch at >>>>=20 >>>> /var/www/modula3.elegosoft.com/cm3/uploaded-archives >>>>=20 >>>> My guess is that tinderbox will take some time to run smoothly again=2C >>>> as it was highly customized=2C and I'm not sure if these customizations >>>> survied the crash. >>>>=20 >>>> Please stay tuned and thanks for all your patience=2C >>>>=20 >>>> Olaf >>>> --=20 >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 9= >>>5 >>>> http://www.elegosoft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berli= >>>n >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214= >>>194 >>>>=20 >>> >>>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_ >>>Content-Type: text/html; charset="iso-8859-1" >>>Content-Transfer-Encoding: quoted-printable >>> >>> >>> >>> > > >>> >>> >>>Olaf=2C in the LINUXLIBC6 configuration=2C try putting --32 on the as/gas i= >>>nvocations. > >>>You mentioned --32 on cm3=2C but I wonder if you meant -m32 on cm3. > >>> =3Bcm3 -m32 > >>> =3Bas --32 > >>> =3B > >>>or check the man pages or help. They aren't consistent=2C for more reasons = >>>than shown here (e.g. MIPS has -mabi64=2C and I think AIX has something els= >>>e=2C and HP-UX gcc supports none of these -- no bi-arch support). > >>> =3B > >>> =3B>=3B probably be easiest to use a real 32 bit system and start fr= >>>om 5.4.0 > =3B>=3B again. > > >>>Using any current system should be plenty easy too. > >>>e.g. the distributions I put up. :) > >>> =3B > >>>AMD64_LINUX should be a good starting point=2C but I haven't tried it in a = >>>bit. > >>> =3B > >>>I should be able to build a current LINUXLIBC6 very very soon. > >>>I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test= >>> a switch to the "new" Unix *.i3 files. > >>> =3B > >>>I'll be using python/make-dist.py though. > >>>I do need to get more packages into it though=2C e.g. cm3ide and m3gdb. > >>> =3B > >>> =3B- Jay > =3B >>=3B Date: Wed=2C 1 Apr 2009 11:11:53 +0200<= >>>BR>>=3B From: wagner at elegosoft.com >>=3B To: m3devel at elegosoft.com>>>>=3B CC: mand at elego.de=3B m3-support at elego.de >>=3B Subject: Re: [M3= >>>devel] Help finding CM3 compiler for Linux? >>=3B >>=3B Quoting Mi= >>>ka Nystrom <=3Bmika at async.caltech.edu>=3B: >>=3B >>=3B>=3B<= >>>BR>>=3B>=3B Is there any documentation for this format beyond what you= >>> just >>=3B>=3B wrote? Where? >>=3B >>=3B Well=2C yes=2C th= >>>at's the problem with these kinds of archives: >>=3B >>=3B (1) the= >>>y're not well tested and >>=3B (2) there's no documentation user's can = >>>rely on >>=3B >>=3B This doesn't mean that I disapprove or want to= >>> criticise the contributors=2C >>=3B but an official well-documented re= >>>lease with installation notes etc. >>=3B has some advantages. Unfortuna= >>>tely=2C the official releases are really >>=3B outdated now. >>=3B = >>> >>=3B I succeeded in building current AMD64_LINUX and FreeBSD4 install= >>>ations >>=3B on our servers for d5.7.1 tonight and was able to build ar= >>>chives for >>=3B FreeBSD binaries and sources=2C but the tooling failed= >>> for AMD64_KINUX >>=3B due to changed and missing configuration files. = >> I'll need to have a >>=3B closer look at that=2C some extensions seem t= >>>o be needed. Anybody who >>=3B feels he can do that faster than me is o= >>>f course encouraged (I'll have >>=3B little time as usual :-/). >>= >>>=3B >>=3B It may also turn out to be difficult to produce LINUXLIBC6 b= >>>inaries=2C >>=3B as birch and other Elego servers are now 64 bit machin= >>>es=2C and trying >>=3B to use current CM3 with --32 produced lots of as= >>>sembler errors about >>=3B unsupported instructions on this architectur= >>>e. As the old installation >>=3B on birch seems to be gone without a ch= >>>ance of being restored=2C it will >>=3B probably be easiest to use a re= >>>al 32 bit system and start from 5.4.0 >>=3B again. >>=3B >>=3B= >>> Anybody who wants to help should be able to build the binary >>=3B arc= >>>hives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh >>=3B easily = >>>and upload them to birch at >>=3B >>=3B /var/www/modula3.elegosoft= >>>.com/cm3/uploaded-archives >>=3B >>=3B My guess is that tinderbox = >>>will take some time to run smoothly again=2C >>=3B as it was highly cus= >>>tomized=2C and I'm not sure if these customizations >>=3B survied the c= >>>rash. >>=3B >>=3B Please stay tuned and thanks for all your patien= >>>ce=2C >>=3B >>=3B Olaf >>=3B -- >>=3B Olaf Wagner -- eleg= >>>o Software Solutions GmbH >>=3B Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C= >>> 13355 Berlin=2C Germany >>=3B phone: +49 30 23 45 86 96 mobile: +49 17= >>>7 2345 869 fax: +49 30 23 45 86 95 >>=3B http://www.elegosoft.com | Ges= >>>ch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berlin >>=3B Handelregister: Amts= >>>gericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>=3B >>>dy> >>>= >>> >>>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_-- From mika at async.caltech.edu Thu Apr 2 00:25:25 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 01 Apr 2009 15:25:25 -0700 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: Your message of "Wed, 01 Apr 2009 20:51:22 -0000." Message-ID: <200904012225.n31MPPDd007216@camembert.async.caltech.edu> Actually I think that the thing that has caused me the most problems in the past is that the -min and the -src-all get out of sync, since the binary bootstrapping dists are often not distributed (for size reasons?) with full source archives from exactly the same date. So when you try to build src-all with the binary bootstrap, something goes wrong. It's the whole... ok I need a binary install (since it's a real compiler), but now I have to bootstrap everything. And then the bootstrap turns out not to be 100% compatible with the compiler sources, libraries, some little detail in m3tk, ... Another way of saying this is "Isn't CM3 way overdue for a 'release'?" Mika Jay writes: > >Thank you Mika. There is a cm3.cfg file, but it had a small bug. > Actually if you look the cm3.cfg file was probably a mere one line that includes LINUXLIBC6. That is probably overly confusing for anyone trying to understand how it works. > >If you repeat the experiment with the 5.7.1 archives you should find it easier. > The not easy cheat is to take cm3cfg.common from current source tree. > >If you repeat it with a NOT yet existing archive that I have in mind, even easier, however not for all platforms -- i.e. no need to set LD_LIBRARY_PATH, on platforms that support $ORIGIN, but again, not yet. >NT386 is already easy this way, since the .dlls are in the bin directory and that is searched; that is NT386-specific. > >I also need to get m3gdb and cm3ide into it. > >> It seems to me it would be quite easy to package this up, maybe even >> with cminstall? That would be easiest I think, to cminstall the whole > >I deliberately don't. >I find cminstall not very worthwhile. >Try the 5.7.1 archive and see what you think? > >What you are saying I guess is you like the "one level archive" instead of the usual "two level". Agreed. One level can be easily achieved and have cminstall do a copy instead of untargz. But I also find cmin >stall not all that worthwhile (as I've said..). > > > - Jay > >---------------------------------------- >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >> Date: Wed, 1 Apr 2009 09:59:45 -0700 >> From: mika at async.caltech.edu >> >> >> I have to say that once I figured out what I needed to do, using >> Jay's distributions was easy---easier than I'm used to with CM3. >> >> All I had to do was: untar the -std dist (forget the min one). >> >> Set PATH and LD_LIBRARY_PATH >> >> And then---the mysterious part, which takes more than passing knowledge >> of how CM3 works---providing a cm3.cfg file, which doesn't seem to be >> provided at all by Jay's archive. >> >> It seems to me it would be quite easy to package this up, maybe even >> with cminstall? That would be easiest I think, to cminstall the whole >> dist rather than cminstalling just the -min and then making people build >> their own compiler, libraries, and demo apps... >> >> Mika >> >> Jay writes: >>>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_ >>>Content-Type: text/plain; charset="iso-8859-1" >>>Content-Transfer-Encoding: quoted-printable >>> >>> >>>Olaf=2C in the LINUXLIBC6 configuration=2C try putting --32 on the as/gas i= >>>nvocations. >>> >>>You mentioned --32 on cm3=2C but I wonder if you meant -m32 on cm3. >>> >>> cm3 -m32=20 >>> >>> as --32=20 >>> >>>=20 >>> >>>or check the man pages or help. They aren't consistent=2C for more reasons = >>>than shown here (e.g. MIPS has -mabi64=2C and I think AIX has something els= >>>e=2C and HP-UX gcc supports none of these -- no bi-arch support). >>> >>>=20 >>> >>>> probably be easiest to use a real 32 bit system and start from 5.4.0 >>>> again. >>> >>> >>>Using any current system should be plenty easy too. >>> >>>e.g. the distributions I put up. :) >>> >>>=20 >>> >>>AMD64_LINUX should be a good starting point=2C but I haven't tried it in a = >>>bit. >>> >>>=20 >>> >>>I should be able to build a current LINUXLIBC6 very very soon. >>> >>>I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test= >>> a switch to the "new" Unix *.i3 files. >>> >>>=20 >>> >>>I'll be using python/make-dist.py though. >>> >>>I do need to get more packages into it though=2C e.g. cm3ide and m3gdb. >>> >>>=20 >>> >>> - Jay >>>=20 >>>> Date: Wed=2C 1 Apr 2009 11:11:53 +0200 >>>> From: wagner at elegosoft.com >>>> To: m3devel at elegosoft.com >>>> CC: mand at elego.de=3B m3-support at elego.de >>>> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >>>>=20 >>>> Quoting Mika Nystrom : >>>>=20 >>>>> >>>>> Is there any documentation for this format beyond what you just >>>>> wrote? Where? >>>>=20 >>>> Well=2C yes=2C that's the problem with these kinds of archives: >>>>=20 >>>> (1) they're not well tested and >>>> (2) there's no documentation user's can rely on >>>>=20 >>>> This doesn't mean that I disapprove or want to criticise the contributors= >>>=2C >>>> but an official well-documented release with installation notes etc. >>>> has some advantages. Unfortunately=2C the official releases are really >>>> outdated now. >>>>=20 >>>> I succeeded in building current AMD64_LINUX and FreeBSD4 installations >>>> on our servers for d5.7.1 tonight and was able to build archives for >>>> FreeBSD binaries and sources=2C but the tooling failed for AMD64_KINUX >>>> due to changed and missing configuration files. I'll need to have a >>>> closer look at that=2C some extensions seem to be needed. Anybody who >>>> feels he can do that faster than me is of course encouraged (I'll have >>>> little time as usual :-/). >>>>=20 >>>> It may also turn out to be difficult to produce LINUXLIBC6 binaries=2C >>>> as birch and other Elego servers are now 64 bit machines=2C and trying >>>> to use current CM3 with --32 produced lots of assembler errors about >>>> unsupported instructions on this architecture. As the old installation >>>> on birch seems to be gone without a chance of being restored=2C it will >>>> probably be easiest to use a real 32 bit system and start from 5.4.0 >>>> again. >>>>=20 >>>> Anybody who wants to help should be able to build the binary >>>> archives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh >>>> easily and upload them to birch at >>>>=20 >>>> /var/www/modula3.elegosoft.com/cm3/uploaded-archives >>>>=20 >>>> My guess is that tinderbox will take some time to run smoothly again=2C >>>> as it was highly customized=2C and I'm not sure if these customizations >>>> survied the crash. >>>>=20 >>>> Please stay tuned and thanks for all your patience=2C >>>>=20 >>>> Olaf >>>> --=20 >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 9= >>>5 >>>> http://www.elegosoft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berli= >>>n >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214= >>>194 >>>>=20 >>> >>>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_ >>>Content-Type: text/html; charset="iso-8859-1" >>>Content-Transfer-Encoding: quoted-printable >>> >>> >>> >>> > > >>> >>> >>>Olaf=2C in the LINUXLIBC6 configuration=2C try putting --32 on the as/gas i= >>>nvocations. > >>>You mentioned --32 on cm3=2C but I wonder if you meant -m32 on cm3. > >>> =3Bcm3 -m32 > >>> =3Bas --32 > >>> =3B > >>>or check the man pages or help. They aren't consistent=2C for more reasons = >>>than shown here (e.g. MIPS has -mabi64=2C and I think AIX has something els= >>>e=2C and HP-UX gcc supports none of these -- no bi-arch support). > >>> =3B > >>> =3B>=3B probably be easiest to use a real 32 bit system and start fr= >>>om 5.4.0 > =3B>=3B again. > > >>>Using any current system should be plenty easy too. > >>>e.g. the distributions I put up. :) > >>> =3B > >>>AMD64_LINUX should be a good starting point=2C but I haven't tried it in a = >>>bit. > >>> =3B > >>>I should be able to build a current LINUXLIBC6 very very soon. > >>>I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test= >>> a switch to the "new" Unix *.i3 files. > >>> =3B > >>>I'll be using python/make-dist.py though. > >>>I do need to get more packages into it though=2C e.g. cm3ide and m3gdb. > >>> =3B > >>> =3B- Jay > =3B >>=3B Date: Wed=2C 1 Apr 2009 11:11:53 +0200<= >>>BR>>=3B From: wagner at elegosoft.com >>=3B To: m3devel at elegosoft.com>>>>=3B CC: mand at elego.de=3B m3-support at elego.de >>=3B Subject: Re: [M3= >>>devel] Help finding CM3 compiler for Linux? >>=3B >>=3B Quoting Mi= >>>ka Nystrom <=3Bmika at async.caltech.edu>=3B: >>=3B >>=3B>=3B<= >>>BR>>=3B>=3B Is there any documentation for this format beyond what you= >>> just >>=3B>=3B wrote? Where? >>=3B >>=3B Well=2C yes=2C th= >>>at's the problem with these kinds of archives: >>=3B >>=3B (1) the= >>>y're not well tested and >>=3B (2) there's no documentation user's can = >>>rely on >>=3B >>=3B This doesn't mean that I disapprove or want to= >>> criticise the contributors=2C >>=3B but an official well-documented re= >>>lease with installation notes etc. >>=3B has some advantages. Unfortuna= >>>tely=2C the official releases are really >>=3B outdated now. >>=3B = >>> >>=3B I succeeded in building current AMD64_LINUX and FreeBSD4 install= >>>ations >>=3B on our servers for d5.7.1 tonight and was able to build ar= >>>chives for >>=3B FreeBSD binaries and sources=2C but the tooling failed= >>> for AMD64_KINUX >>=3B due to changed and missing configuration files. = >> I'll need to have a >>=3B closer look at that=2C some extensions seem t= >>>o be needed. Anybody who >>=3B feels he can do that faster than me is o= >>>f course encouraged (I'll have >>=3B little time as usual :-/). >>= >>>=3B >>=3B It may also turn out to be difficult to produce LINUXLIBC6 b= >>>inaries=2C >>=3B as birch and other Elego servers are now 64 bit machin= >>>es=2C and trying >>=3B to use current CM3 with --32 produced lots of as= >>>sembler errors about >>=3B unsupported instructions on this architectur= >>>e. As the old installation >>=3B on birch seems to be gone without a ch= >>>ance of being restored=2C it will >>=3B probably be easiest to use a re= >>>al 32 bit system and start from 5.4.0 >>=3B again. >>=3B >>=3B= >>> Anybody who wants to help should be able to build the binary >>=3B arc= >>>hives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh >>=3B easily = >>>and upload them to birch at >>=3B >>=3B /var/www/modula3.elegosoft= >>>.com/cm3/uploaded-archives >>=3B >>=3B My guess is that tinderbox = >>>will take some time to run smoothly again=2C >>=3B as it was highly cus= >>>tomized=2C and I'm not sure if these customizations >>=3B survied the c= >>>rash. >>=3B >>=3B Please stay tuned and thanks for all your patien= >>>ce=2C >>=3B >>=3B Olaf >>=3B -- >>=3B Olaf Wagner -- eleg= >>>o Software Solutions GmbH >>=3B Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C= >>> 13355 Berlin=2C Germany >>=3B phone: +49 30 23 45 86 96 mobile: +49 17= >>>7 2345 869 fax: +49 30 23 45 86 95 >>=3B http://www.elegosoft.com | Ges= >>>ch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berlin >>=3B Handelregister: Amts= >>>gericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>=3B >>>dy> >>>= >>> >>>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_-- From rcoleburn at scires.com Thu Apr 2 01:05:16 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 01 Apr 2009 19:05:16 -0400 Subject: [M3devel] new cm3 release (was: Help finding CM3 compiler for Linux?) In-Reply-To: <200904012225.n31MPPDd007216@camembert.async.caltech.edu> References: Your message of "Wed, 01 Apr 2009 20:51:22 -0000." <200904012225.n31MPPDd007216@camembert.async.caltech.edu> Message-ID: <49D3BAD7.1E75.00D7.1@scires.com> I agree about needing a new release. I suppose there is some value in maintaining a MINimal size binary distribution, but I think it would also nice to also provide a FULL distribution with everything pre-built. (Of course, this will eat up more space on elego machines.) I have ready access to Windows XP (32-bit and 64-bit) and Vista platforms. I would be glad to build and supply the distros for these platforms. Suggest we agree upon a plan and a timeframe. a. make a tag or something in CVS that marks what will comprise the official sources for the release b. agree upon distribution format (platform naming conventions, compressed archive format for MIN and FULL variants) c. get a list of who is going to supply distros for which platforms d. establish procedure for how the distros will be uploaded to elego e. set a date for contributors to have the distros uploaded f. have someone put together the web page showing links to all the distros along with updated installation instructions One sticky issue in the past has been target location. If we unpack a distro and put it in a different place in the filesystem tree, we don't want it to break. I know that cminstall attempted to adjust the cm3.cfg file to deal with location differences. Do we need/want to build an installer program or script to deal with this issue, perhaps even adjusting cminstall will suffice? Or, do we give a set of instructions on which file(s) to edit when moving the install location? For Windows, I don't mind building an installer. Perhaps the installer could let you choose whether to install the MIN or the FULL version. Also, I think the Tinderbox has been great, but perhaps it can be improved. I know I would like to see testing for Windows platforms added. I have an XP computer I can pretty much dedicate to this task. The problem is that I tried with Olaf's help to get it working, but there were too many dependencies on unix-type shell/script environment, and trying to force fit into cygwin didn't work well for the native Win32 implementation. Thoughts? Regards, Randy >>> Mika Nystrom 4/1/2009 6:25 PM >>> Actually I think that the thing that has caused me the most problems in the past is that the -min and the -src-all get out of sync, since the binary bootstrapping dists are often not distributed (for size reasons?) with full source archives from exactly the same date. So when you try to build src-all with the binary bootstrap, something goes wrong. It's the whole... ok I need a binary install (since it's a real compiler), but now I have to bootstrap everything. And then the bootstrap turns out not to be 100% compatible with the compiler sources, libraries, some little detail in m3tk, ... Another way of saying this is "Isn't CM3 way overdue for a 'release'?" Mika CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 2 01:28:01 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Apr 2009 23:28:01 +0000 Subject: [M3devel] new cm3 release (was: Help finding CM3 compiler for Linux?) In-Reply-To: <49D3BAD7.1E75.00D7.1@scires.com> References: Your message of "Wed, 01 Apr 2009 20:51:22 -0000." <200904012225.n31MPPDd007216@camembert.async.caltech.edu> <49D3BAD7.1E75.00D7.1@scires.com> Message-ID: "std" is already essentially "full", or meant to be at least. Granted my "std" is missing m3gdb and cm3ide, at least. But it isn't small. "std" isn't new or specific to my releases. It has been in all the "open" cm3 releases, and probably the Critical Mass ones too. I've been meaning to put together "boot" releases that are perhaps smaller than "min", though that isn't perhaps their defining characteristic. They would consist of assembly code for the Modula-3 and uncompiled C code. Very similar to the old Digital SRC releases, and I think the ezm3 releases. The Digital SRC boot format no longer works, because it depended on quake/m3build/m3ship being written in C. A defining characteristic probably of "boot" is that it is safe against API and ABI changes. Another one perhaps though is having to spend the time to build cm3cg. My current "boot" archives build only cm3, but extending them to build m3core and libm3 would be trivial, extending them to build all of "std", not too difficult. I gather one of the nice things PM3 had was they shipped IL instead of assembly. That can be a a lot more portable, or extremely portable. "more portable" -- varying mainly only in wordsize and endian, /maybe/ smaller issues like alignment (almost always the same anyway), page size (not really) "extremely portable" -- factor even those out Though you'd also have to factor out the Time/Date stuff. And if you had user thread support in there, portability gains would be lost. This approach, in fact, can lead to "universal posix" distributions, at the cost of user having to build cm3cg. In fact you could build the Win32 code and have the last-on-the-target stage pick the appropriate files, leading to really "universal" distributions. > One sticky issue in the past has been target location This is not an issue with my config files, hasn't been for a long time. Kind of bothersome..you know..I solved this years ago..to still be discussing it as an issue.. Yeah, I realize my ChangeLog is not readable but... Quake code can query for its own location. At least as of a while ago. Maybe not in much old versions. (I didn't add the feature, I merely discovered it was there.) My cm3.cfg file does that. And then build the rest of the paths from there -- at least for cm3/cm3cg/pkg/lib. The location of cl.exe and link.exe aren't solved by path. For those, I just run "cl" and "link" and depend on $PATH. That's how people often deal with gcc/ld, though I realize there is no unversality here. Some people use full paths to gcc/ld, some rely on $PATH, ditto for cl/link (actually for cl/link, most "people" use an interactive GUI that hides tons of stuff, but there are still "automated builds" that have to do something.) I did some experimentation with building a GUI NT install, using "InnoSetup". It was just a glorified untargz, which does have some value. A little fancier than just distributing a .zip file. I didn't get to the point of (offering to) altering $PATH, ensuring cl.exe/link.exe were available. But this perhaps be adequately handled by one line documentation telling people to run the "shortcut" that Visual C++ installs, that runs an appropriately setup command line (the platform SDK and DDK do the same). I dread the "freeze" state approaching releases. Please hopefully there is a "tag" or "branch" for the release, and I can continue working "my way" (churn too high for near release). - Jay Date: Wed, 1 Apr 2009 19:05:16 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] new cm3 release (was: Help finding CM3 compiler for Linux?) I agree about needing a new release. I suppose there is some value in maintaining a MINimal size binary distribution, but I think it would also nice to also provide a FULL distribution with everything pre-built. (Of course, this will eat up more space on elego machines.) I have ready access to Windows XP (32-bit and 64-bit) and Vista platforms. I would be glad to build and supply the distros for these platforms. Suggest we agree upon a plan and a timeframe. a. make a tag or something in CVS that marks what will comprise the official sources for the release b. agree upon distribution format (platform naming conventions, compressed archive format for MIN and FULL variants) c. get a list of who is going to supply distros for which platforms d. establish procedure for how the distros will be uploaded to elego e. set a date for contributors to have the distros uploaded f. have someone put together the web page showing links to all the distros along with updated installation instructions One sticky issue in the past has been target location. If we unpack a distro and put it in a different place in the filesystem tree, we don't want it to break. I know that cminstall attempted to adjust the cm3.cfg file to deal with location differences. Do we need/want to build an installer program or script to deal with this issue, perhaps even adjusting cminstall will suffice? Or, do we give a set of instructions on which file(s) to edit when moving the install location? For Windows, I don't mind building an installer. Perhaps the installer could let you choose whether to install the MIN or the FULL version. Also, I think the Tinderbox has been great, but perhaps it can be improved. I know I would like to see testing for Windows platforms added. I have an XP computer I can pretty much dedicate to this task. The problem is that I tried with Olaf's help to get it working, but there were too many dependencies on unix-type shell/script environment, and trying to force fit into cygwin didn't work well for the native Win32 implementation. Thoughts? Regards, Randy >>> Mika Nystrom 4/1/2009 6:25 PM >>> Actually I think that the thing that has caused me the most problems in the past is that the -min and the -src-all get out of sync, since the binary bootstrapping dists are often not distributed (for size reasons?) with full source archives from exactly the same date. So when you try to build src-all with the binary bootstrap, something goes wrong. It's the whole... ok I need a binary install (since it's a real compiler), but now I have to bootstrap everything. And then the bootstrap turns out not to be 100% compatible with the compiler sources, libraries, some little detail in m3tk, ... Another way of saying this is "Isn't CM3 way overdue for a 'release'?" Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Thu Apr 2 02:03:47 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 1 Apr 2009 17:03:47 -0700 (PDT) Subject: [M3devel] new cm3 release (was: Help finding CM3 compiler for Linux?) In-Reply-To: <49D3BAD7.1E75.00D7.1@scires.com> Message-ID: <903288.9641.qm@web24714.mail.ird.yahoo.com> Hey what a port of the tinderbox to Obliq, in that way, we could allow the system to test and report hosted on itself and get a hand from the M3 runtime capabilities, network objects and pretty staff (GUIs included, it could allow even to test directly from the Obliq interpreter without recompiling nothing, just using M3 runtime), however depending on M3 runtime I don't know is that is the idea, I think it makes sense since it's supposed to be a M3 system in the platform to be tested and reported. If the test failed there should be a lastok obliq script and runtime that worked so it can be in any case reported on the status web page. With CM3-IDE we could also create a Link from the Initial web page to see the status locally and get or send reported status more easily integrated? Oh, I would like to help but still I haven't checked the latest versions of the complete system, I still want to wait to have all server services running on Elego.de (thanks all there cvs is running) but we can think meanwhile on it. Thanks in advance --- El mi?, 1/4/09, Randy Coleburn escribi?: De: Randy Coleburn Asunto: [M3devel] new cm3 release (was: Help finding CM3 compiler for Linux?) Para: m3devel at elegosoft.com Fecha: mi?rcoles, 1 abril, 2009 6:05 I agree about needing a new release. ? I suppose there is some value in maintaining a MINimal size binary distribution, but I think it would also nice to also provide a FULL distribution with everything pre-built.? (Of course, this will eat up more space on elego machines.) ? I have ready access to Windows XP (32-bit and 64-bit) and Vista platforms.? I would be glad to build and supply the distros for these platforms. ? Suggest we agree upon a plan and a timeframe. a.? make a tag or something in CVS that marks what will comprise the official sources for the release b.? agree upon distribution format (platform naming conventions, compressed archive format for MIN and FULL variants) c.? get a list of who is going to supply distros for which platforms d.? establish procedure for how the distros will be uploaded to elego e.? set a date for contributors to have the distros uploaded f.? have someone put together the web page showing links to all the distros along with updated installation instructions ? One sticky issue in the past has been target location.? If we unpack a distro and put it in a different place in the filesystem tree, we don't want it to break.? I know that cminstall attempted to adjust the cm3.cfg file to deal with location differences.? Do we need/want to build an installer program or script to deal with this issue, perhaps even adjusting cminstall will suffice?? Or, do we give a set of instructions on which file(s) to edit when moving the install location? ? For Windows, I don't mind building an installer.? Perhaps the installer could let you choose whether to install the MIN or the FULL version. ? Also, I think the Tinderbox has been great, but perhaps it can be improved.? I know I would like to see testing for Windows platforms added.? I have an XP computer I can pretty much dedicate to this task.? The problem is that I tried with Olaf's help to get it working, but there were too many dependencies on unix-type shell/script environment, and trying to force fit into cygwin didn't work well for the native Win32 implementation.? Thoughts? ? Regards, Randy >>> Mika Nystrom 4/1/2009 6:25 PM >>> Actually I think that the thing that has caused me the most problems in the past is that the -min and the -src-all get out of sync, since the binary bootstrapping dists are often not distributed (for size reasons?) with full source archives from exactly the same date.? So when you try to build src-all with the binary bootstrap, something goes wrong.? It's the whole... ok I need a binary install (since it's a real compiler), but now I have to bootstrap everything.? And then the bootstrap turns out not to be 100% compatible with the compiler sources, libraries, some little detail in m3tk, ... Another way of saying this is "Isn't CM3 way overdue for a 'release'?" ??? Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Apr 2 08:57:54 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 02 Apr 2009 08:57:54 +0200 Subject: [M3devel] new cm3 release (was: Help finding CM3 compiler for Linux?) In-Reply-To: <49D3BAD7.1E75.00D7.1@scires.com> References: Your message of "Wed, 01 Apr 2009 20:51:22 -0000." <200904012225.n31MPPDd007216@camembert.async.caltech.edu> <49D3BAD7.1E75.00D7.1@scires.com> Message-ID: <20090402085754.wpgiv2sgg800c0c4@mail.elegosoft.com> Quoting Randy Coleburn : > I agree about needing a new release. I suggested a new release twice within the recent two years, but nobody seemed to really support that idea. I never got round to do the work myself. > I suppose there is some value in maintaining a MINimal size binary > distribution, but I think it would also nice to also provide a FULL > distribution with everything pre-built. (Of course, this will eat > up more space on elego machines.) That should be no problem. As for archive size, I think disk sizes and transfer rates have changed much in recent years. We could easily provide full distribution archives in binary form. For those who just want the compiler, I'd suggest something of the size of the core set as defined in the script. > I have ready access to Windows XP (32-bit and 64-bit) and Vista > platforms. I would be glad to build and supply the distros for > these platforms. Great. > Suggest we agree upon a plan and a timeframe. > a. make a tag or something in CVS that marks what will comprise the > official sources for the release I can take over the CVS and pinging work, if everybody agrees. I won't have time to actually build and test all distributions. > b. agree upon distribution format (platform naming conventions, > compressed archive format for MIN and FULL variants) I'd suggest a switch to the complete binary archive format; but we need to automate and document the process. probably Jay has already done most of it, but I haven't tested it. > c. get a list of who is going to supply distros for which platforms Elego can provide FreeBSD 6.X and Linux on AMD64 easily. > d. establish procedure for how the distros will be uploaded to elego We should simply start by collecting release candidates in the uploaded-archives section of the server. We can use a naming scheme to separate these from other archives (cm3-*-*5.7.1-rc[1-9]?). > e. set a date for contributors to have the distros uploaded > f. have someone put together the web page showing links to all the > distros along with updated installation instructions I can do that, too, if you like. > One sticky issue in the past has been target location. If we unpack > a distro and put it in a different place in the filesystem tree, we > don't want it to break. I know that cminstall attempted to adjust > the cm3.cfg file to deal with location differences. Do we need/want > to build an installer program or script to deal with this issue, > perhaps even adjusting cminstall will suffice? Or, do we give a set > of instructions on which file(s) to edit when moving the install > location? I think Jay's archives can be easily relocated. > For Windows, I don't mind building an installer. Perhaps the > installer could let you choose whether to install the MIN or the > FULL version. > > Also, I think the Tinderbox has been great, but perhaps it can be > improved. I know I would like to see testing for Windows platforms > added. I have an XP computer I can pretty much dedicate to this > task. The problem is that I tried with Olaf's help to get it > working, but there were too many dependencies on unix-type > shell/script environment, and trying to force fit into cygwin didn't > work well for the native Win32 implementation. Thoughts? I had working most of it, but then got lost in other work again, and the virtual machine I used was so slow (and tended to crash :-/) We need to start again from where I stopped. > Regards, > Randy > >>>> Mika Nystrom 4/1/2009 6:25 PM >>> > > Actually I think that the thing that has caused me the most problems > in the past is that the -min and the -src-all get out of sync, since > the binary bootstrapping dists are often not distributed (for size > reasons?) with full source archives from exactly the same date. So > when you try to build src-all with the binary bootstrap, something > goes wrong. It's the whole... ok I need a binary install (since > it's a real compiler), but now I have to bootstrap everything. And > then the bootstrap turns out not to be 100% compatible with the > compiler sources, libraries, some little detail in m3tk, ... If you are happy with just overwriting everything existing, it should be no problem to switch to full binary archives. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 3 13:03:56 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 3 Apr 2009 11:03:56 +0000 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: <200904012225.n31MPPDd007216@camembert.async.caltech.edu> References: Your message of "Wed, 01 Apr 2009 20:51:22 -0000." <200904012225.n31MPPDd007216@camembert.async.caltech.edu> Message-ID: "Good oops", I only just noticed that the older releases only had "min binary" and "std src". I thought they had both min and std binary for users to chose from, and I was following suit. (noticed this 'cause I want to try old Solaris/PPC_DARWIN see when the formsedit crash came in; it's still there) - Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Wed, 1 Apr 2009 15:25:25 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Help finding CM3 compiler for Linux? > > > Actually I think that the thing that has caused me the most problems > in the past is that the -min and the -src-all get out of sync, since > the binary bootstrapping dists are often not distributed (for size > reasons?) with full source archives from exactly the same date. So > when you try to build src-all with the binary bootstrap, something > goes wrong. It's the whole... ok I need a binary install (since > it's a real compiler), but now I have to bootstrap everything. And > then the bootstrap turns out not to be 100% compatible with the > compiler sources, libraries, some little detail in m3tk, ... > > Another way of saying this is "Isn't CM3 way overdue for a 'release'?" > > Mika > > Jay writes: >> >>Thank you Mika. There is a cm3.cfg file, but it had a small bug. >> Actually if you look the cm3.cfg file was probably a mere one line that includes LINUXLIBC6. That is probably overly confusing for anyone trying to understand how it works. >> >>If you repeat the experiment with the 5.7.1 archives you should find it easier. >> The not easy cheat is to take cm3cfg.common from current source tree. >> >>If you repeat it with a NOT yet existing archive that I have in mind, even easier, however not for all platforms -- i.e. no need to set LD_LIBRARY_PATH, on platforms that support $ORIGIN, but again, not yet. >>NT386 is already easy this way, since the .dlls are in the bin directory and that is searched; that is NT386-specific. >> >>I also need to get m3gdb and cm3ide into it. >> >>> It seems to me it would be quite easy to package this up, maybe even >>> with cminstall? That would be easiest I think, to cminstall the whole >> >>I deliberately don't. >>I find cminstall not very worthwhile. >>Try the 5.7.1 archive and see what you think? >> >>What you are saying I guess is you like the "one level archive" instead of the usual "two level". Agreed. One level can be easily achieved and have cminstall do a copy instead of untargz. But I also find cmin >>stall not all that worthwhile (as I've said..). >> >> >> - Jay >> >>---------------------------------------- >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >>> Date: Wed, 1 Apr 2009 09:59:45 -0700 >>> From: mika at async.caltech.edu >>> >>> >>> I have to say that once I figured out what I needed to do, using >>> Jay's distributions was easy---easier than I'm used to with CM3. >>> >>> All I had to do was: untar the -std dist (forget the min one). >>> >>> Set PATH and LD_LIBRARY_PATH >>> >>> And then---the mysterious part, which takes more than passing knowledge >>> of how CM3 works---providing a cm3.cfg file, which doesn't seem to be >>> provided at all by Jay's archive. >>> >>> It seems to me it would be quite easy to package this up, maybe even >>> with cminstall? That would be easiest I think, to cminstall the whole >>> dist rather than cminstalling just the -min and then making people build >>> their own compiler, libraries, and demo apps... >>> >>> Mika >>> >>> Jay writes: >>>>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_ >>>>Content-Type: text/plain; charset="iso-8859-1" >>>>Content-Transfer-Encoding: quoted-printable >>>> >>>> >>>>Olaf=2C in the LINUXLIBC6 configuration=2C try putting --32 on the as/gas i= >>>>nvocations. >>>> >>>>You mentioned --32 on cm3=2C but I wonder if you meant -m32 on cm3. >>>> >>>> cm3 -m32=20 >>>> >>>> as --32=20 >>>> >>>>=20 >>>> >>>>or check the man pages or help. They aren't consistent=2C for more reasons = >>>>than shown here (e.g. MIPS has -mabi64=2C and I think AIX has something els= >>>>e=2C and HP-UX gcc supports none of these -- no bi-arch support). >>>> >>>>=20 >>>> >>>>> probably be easiest to use a real 32 bit system and start from 5.4.0 >>>>> again. >>>> >>>> >>>>Using any current system should be plenty easy too. >>>> >>>>e.g. the distributions I put up. :) >>>> >>>>=20 >>>> >>>>AMD64_LINUX should be a good starting point=2C but I haven't tried it in a = >>>>bit. >>>> >>>>=20 >>>> >>>>I should be able to build a current LINUXLIBC6 very very soon. >>>> >>>>I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test= >>>> a switch to the "new" Unix *.i3 files. >>>> >>>>=20 >>>> >>>>I'll be using python/make-dist.py though. >>>> >>>>I do need to get more packages into it though=2C e.g. cm3ide and m3gdb. >>>> >>>>=20 >>>> >>>> - Jay >>>>=20 >>>>> Date: Wed=2C 1 Apr 2009 11:11:53 +0200 >>>>> From: wagner at elegosoft.com >>>>> To: m3devel at elegosoft.com >>>>> CC: mand at elego.de=3B m3-support at elego.de >>>>> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >>>>>=20 >>>>> Quoting Mika Nystrom : >>>>>=20 >>>>>> >>>>>> Is there any documentation for this format beyond what you just >>>>>> wrote? Where? >>>>>=20 >>>>> Well=2C yes=2C that's the problem with these kinds of archives: >>>>>=20 >>>>> (1) they're not well tested and >>>>> (2) there's no documentation user's can rely on >>>>>=20 >>>>> This doesn't mean that I disapprove or want to criticise the contributors= >>>>=2C >>>>> but an official well-documented release with installation notes etc. >>>>> has some advantages. Unfortunately=2C the official releases are really >>>>> outdated now. >>>>>=20 >>>>> I succeeded in building current AMD64_LINUX and FreeBSD4 installations >>>>> on our servers for d5.7.1 tonight and was able to build archives for >>>>> FreeBSD binaries and sources=2C but the tooling failed for AMD64_KINUX >>>>> due to changed and missing configuration files. I'll need to have a >>>>> closer look at that=2C some extensions seem to be needed. Anybody who >>>>> feels he can do that faster than me is of course encouraged (I'll have >>>>> little time as usual :-/). >>>>>=20 >>>>> It may also turn out to be difficult to produce LINUXLIBC6 binaries=2C >>>>> as birch and other Elego servers are now 64 bit machines=2C and trying >>>>> to use current CM3 with --32 produced lots of assembler errors about >>>>> unsupported instructions on this architecture. As the old installation >>>>> on birch seems to be gone without a chance of being restored=2C it will >>>>> probably be easiest to use a real 32 bit system and start from 5.4.0 >>>>> again. >>>>>=20 >>>>> Anybody who wants to help should be able to build the binary >>>>> archives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh >>>>> easily and upload them to birch at >>>>>=20 >>>>> /var/www/modula3.elegosoft.com/cm3/uploaded-archives >>>>>=20 >>>>> My guess is that tinderbox will take some time to run smoothly again=2C >>>>> as it was highly customized=2C and I'm not sure if these customizations >>>>> survied the crash. >>>>>=20 >>>>> Please stay tuned and thanks for all your patience=2C >>>>>=20 >>>>> Olaf >>>>> --=20 >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 9= >>>>5 >>>>> http://www.elegosoft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berli= >>>>n >>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214= >>>>194 >>>>>=20 >>>> >>>>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_ >>>>Content-Type: text/html; charset="iso-8859-1" >>>>Content-Transfer-Encoding: quoted-printable >>>> >>>> >>>> >>>> >> >> >>>> >>>> >>>>Olaf=2C in the LINUXLIBC6 configuration=2C try putting --32 on the as/gas i= >>>>nvocations. >> >>>>You mentioned --32 on cm3=2C but I wonder if you meant -m32 on cm3. >> >>>> =3Bcm3 -m32 >> >>>> =3Bas --32 >> >>>> =3B >> >>>>or check the man pages or help. They aren't consistent=2C for more reasons = >>>>than shown here (e.g. MIPS has -mabi64=2C and I think AIX has something els= >>>>e=2C and HP-UX gcc supports none of these -- no bi-arch support). >> >>>> =3B >> >>>> =3B>=3B probably be easiest to use a real 32 bit system and start fr= >>>>om 5.4.0 >> =3B>=3B again. >> >> >>>>Using any current system should be plenty easy too. >> >>>>e.g. the distributions I put up. :) >> >>>> =3B >> >>>>AMD64_LINUX should be a good starting point=2C but I haven't tried it in a = >>>>bit. >> >>>> =3B >> >>>>I should be able to build a current LINUXLIBC6 very very soon. >> >>>>I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test= >>>> a switch to the "new" Unix *.i3 files. >> >>>> =3B >> >>>>I'll be using python/make-dist.py though. >> >>>>I do need to get more packages into it though=2C e.g. cm3ide and m3gdb. >> >>>> =3B >> >>>> =3B- Jay >> =3B >>>=3B Date: Wed=2C 1 Apr 2009 11:11:53 +0200<= >>>>BR>>=3B From: wagner at elegosoft.com >>>=3B To: m3devel at elegosoft.com>>>>=3B CC: mand at elego.de=3B m3-support at elego.de >>>=3B Subject: Re: [M3= >>>>devel] Help finding CM3 compiler for Linux? >>>=3B >>>=3B Quoting Mi= >>>>ka Nystrom <=3Bmika at async.caltech.edu>=3B: >>>=3B >>>=3B>=3B<= >>>>BR>>=3B>=3B Is there any documentation for this format beyond what you= >>>> just >>>=3B>=3B wrote? Where? >>>=3B >>>=3B Well=2C yes=2C th= >>>>at's the problem with these kinds of archives: >>>=3B >>>=3B (1) the= >>>>y're not well tested and >>>=3B (2) there's no documentation user's can = >>>>rely on >>>=3B >>>=3B This doesn't mean that I disapprove or want to= >>>> criticise the contributors=2C >>>=3B but an official well-documented re= >>>>lease with installation notes etc. >>>=3B has some advantages. Unfortuna= >>>>tely=2C the official releases are really >>>=3B outdated now. >>>=3B = >>>> >>>=3B I succeeded in building current AMD64_LINUX and FreeBSD4 install= >>>>ations >>>=3B on our servers for d5.7.1 tonight and was able to build ar= >>>>chives for >>>=3B FreeBSD binaries and sources=2C but the tooling failed= >>>> for AMD64_KINUX >>>=3B due to changed and missing configuration files. = >>> I'll need to have a >>>=3B closer look at that=2C some extensions seem t= >>>>o be needed. Anybody who >>>=3B feels he can do that faster than me is o= >>>>f course encouraged (I'll have >>>=3B little time as usual :-/). >>>= >>>>=3B >>>=3B It may also turn out to be difficult to produce LINUXLIBC6 b= >>>>inaries=2C >>>=3B as birch and other Elego servers are now 64 bit machin= >>>>es=2C and trying >>>=3B to use current CM3 with --32 produced lots of as= >>>>sembler errors about >>>=3B unsupported instructions on this architectur= >>>>e. As the old installation >>>=3B on birch seems to be gone without a ch= >>>>ance of being restored=2C it will >>>=3B probably be easiest to use a re= >>>>al 32 bit system and start from 5.4.0 >>>=3B again. >>>=3B >>>=3B= >>>> Anybody who wants to help should be able to build the binary >>>=3B arc= >>>>hives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh >>>=3B easily = >>>>and upload them to birch at >>>=3B >>>=3B /var/www/modula3.elegosoft= >>>>.com/cm3/uploaded-archives >>>=3B >>>=3B My guess is that tinderbox = >>>>will take some time to run smoothly again=2C >>>=3B as it was highly cus= >>>>tomized=2C and I'm not sure if these customizations >>>=3B survied the c= >>>>rash. >>>=3B >>>=3B Please stay tuned and thanks for all your patien= >>>>ce=2C >>>=3B >>>=3B Olaf >>>=3B -- >>>=3B Olaf Wagner -- eleg= >>>>o Software Solutions GmbH >>>=3B Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C= >>>> 13355 Berlin=2C Germany >>>=3B phone: +49 30 23 45 86 96 mobile: +49 17= >>>>7 2345 869 fax: +49 30 23 45 86 95 >>>=3B http://www.elegosoft.com | Ges= >>>>ch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berlin >>>=3B Handelregister: Amts= >>>>gericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>>=3B >>>>dy> >>>>= >>>> >>>>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_-- From jay.krell at cornell.edu Sun Apr 5 14:56:07 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 5 Apr 2009 12:56:07 +0000 Subject: [M3devel] runpath/unshipped vs. shipped binaries Message-ID: Hey..I have a crazy notion that maybe "ship" should first "relink". I've seen this thing..when I watch thw grass grow..I mean autoconf output run.. "how to embed full paths upon install"..."relink"... on some systems.. and I think..geez..what a waste, instead of just copying files, first they get relinked. Now..I find myself wanting something this and it seems maybe only this can provide. Let's limit discusion to Linux for now. These issues are not unique to it. But the area is full of confusing variables enough. When I build a "regular" build, historically, on Linux, binaries have a big bunch of paths run together in them, like: /cm3/pkg/m3core/AMD64_LINUX:/cm3/pkg/libm3/AMD64_LINUX:etc. Maybe maybe each one directory is associated with each one library, though I don't think so. This is called the "run path" and is where dependent shared libraries are sought, among other places. $LD_LIBRARY_PATH is another place but there is some general vague intent that "real" binaries shouldn't depend on that, that it is only for "ad hoc development mode". These full paths are specific to my machine. Other people might have /usr/local/cm3/pkg. Or whatever. Now, today I have made things a bit better. The first path is $ORIGIN/../lib. $ORIGIN is a special syntax for "The directory with the executable". That really is not a sufficient mechanism, but it is a small step forwarder. YOu want relativity from the referencing file, not just the executable. Or something more abstract not dealing with paths at all.. Now, when I make a distribution, I build everything in /tmp/tmprandom. These paths are in the binaries produce. Possibly preceded by $ORIGIN/../lib, but still, I'd rather not "infect" the binaries with these paths. Now, we also run binaries before they are installed -- PklFonts in particular. And user should be expected to be able to run uninstalled binaries. SO long story long... I suggest relink immediately prior to "ship". But this link will omit the bulk of -Wl,-rpath chunks, leaving only the -Wl,-rpath $ORIGIN/../lib. Thoughts? My "research" so far only applies to Linux. Maybe the prepending of $ORIGIN/../lib is enough mitigation. It does bug me though that if you move the binaries around such that ../lib is not correct, and you happen to have the same /tmp/tmprandom/... on your system that I had..very unlikely I realize.. that you will "unintentionally" load the "wrong" file. I'm not super keen on making these changes either..actually digging through and changing all the relevant Modula-3.... Other options include something like the M3_NEED_STANDALONE_LINKS option. Or maybe this is kind of novel/clever/reasonable, always building standalone and shared, standlone named plain "foo", shared/dynamic named "foo.dynamic", and have ship install the dynamic one, built with just -Wl,-rpath,$ORIGIN? This would waste a lot of time and diskspace for rarely used files though. Well, duh, a little less wasteful, when building dynamic, build two versions, both dynamic, one with the one small rpath, one with the usual larger one? This is easier. However if you assume a high build/run/debug to it works/install ratio, this is also wasteful. I come back to the original -- relink upon ship. Again, I'm not super excited to do this work, but it really does seem like the right thing. More generally, if you think about systems that don't support $ORIGIN and you think about some of the Modula-3 distribution formats, relinkin during setup/install of a "distribution" is also a good albeit onerous idea. There's this general theme around "how much of the build occurs on one machine vs. the machine the binaries will run on" and "stopping the build near the end, and finishing it later on another machine". - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 5 14:59:24 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 5 Apr 2009 12:59:24 +0000 Subject: [M3devel] some new archives -- AMD64_LINUX and PPC_DARWIN Message-ID: some new archives I put up PPC_DARWIN and AMD64_LINUX binaries on http://modula3.elegosoft.com/cm3/uploaded-archives. PPC_DARWIN still has the usually crashing formsvbt. I've started building Solaris 5.4 locally to see if it has the bug and then will proceed from there... AMD64_LINUX has paths like /tmp/tmprandom, and $ORIGIN/../lib in it, as mentioned in my other mail. AMD64_LINUX built easily starting with the earlier archives there. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.m.bates at cox.net Mon Apr 6 03:45:15 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Sun, 05 Apr 2009 20:45:15 -0500 Subject: [M3devel] small objects In-Reply-To: References: <200903300333.n2U3XBME062502@camembert.async.caltech.edu> Message-ID: <49D95EAB.8020802@cox.net> I spent quite a bit of time playing with a more general system where there is a set of "tagged" types, with (an implementation-defined subrange of) INTEGER and a reference type both being a subtype of a tagged type. It might have been tolerable, if it weren't for the interaction with object subtypes and opaque types, which quickly gets deep into a deep linguistic tar pit. Tony's approach is much simpler and would serve what I see as the need. It does sacrifice any static checking of what reference type is being tagged, and will also require an extra runtime ISTYPE/TYPECASE. Would INTEGER and REFANY be assignable to TAGGED, or would there also need to be an explicit conversion in that direction too, say VAL(x, TAGGED)? I think I favor the explicit conversion here. It is a bit inconsistent with the usual Modula-3 assignability philosophy, but not requiring the explicit conversion already gets your toes into tar. We would have to have something more like ISTYPE, though, which will tell which type the value belongs to without risking a runtime error, which VAL would do. An intermediate approach might be to have a set of tagged types constructed by, say, TAGGED T, where I is a reference type, but with no subtype relations on them at all, thus still requiring the explicit conversions and checks. I do want to say, I _really_ want this capability somehow. I have an ADT module whose internal data structure, for full generality, needs to have two heap objects (the second because it has nonstatic size) and 11 total words counting the orginal pointer, in the case of values that would fit directly into the "pointer" word. Moreover, these small cases are in the great majority. Besides the 11-to-one increase in actual occupied space, there is extra time for allocation, periodic tracing, and collection, space loss due to heap fragmentation, and time/space tradeoff loss due to reduced locality of reference. So sometimes, it would be a big performance gain if we could do it. Tony Hosking wrote: > It is a much more pervasive hack than I would be comfortable with > since it touches on the compiler (for all the type operations) as well > as the run-time system in ways that are pretty gross. I would much > rather have a new TAGGED builtin. ISTYPE would not work on it since > that only works on references. The only thing you need is a way to > extract the value -- we could overload VAL(x, T) where x can be a > TAGGED and T can be REFANY or INTEGER. > > From carson at taltos.org Mon Apr 6 05:17:02 2009 From: carson at taltos.org (Carson Gaspar) Date: Sun, 05 Apr 2009 20:17:02 -0700 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: References: Message-ID: <49D9742E.6080100@taltos.org> Jay wrote: ... > When I build a "regular" build, historically, on Linux, > binaries have a big bunch of paths run together in them, like: > > > /cm3/pkg/m3core/AMD64_LINUX:/cm3/pkg/libm3/AMD64_LINUX:etc. ... > Now, today I have made things a bit better. > > > The first path is $ORIGIN/../lib. > $ORIGIN is a special syntax for "The directory with the executable". > That really is not a sufficient mechanism, but it is a small step forwarder. > YOu want relativity from the referencing file, not just the executable. > Or something more abstract not dealing with paths at all.. If you're saying that today you produce binaries with an RPATH of: $ORIGIN/../lib:/cm3/pkg/m3core/AMD64_LINUX:... That's just... horrid. Assuming all of your libraries are in ${exe_path}/../lib, you need exactly one RPATH entry: $ORIGIN/../lib Get rid of _all_ the other "-R foo" link arguments, and all will be well. No need to relink if you link properly the first time. -- Carson From jay.krell at cornell.edu Mon Apr 6 06:23:14 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 6 Apr 2009 04:23:14 +0000 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: <49D9742E.6080100@taltos.org> References: <49D9742E.6080100@taltos.org> Message-ID: - The horrid RPATH is not my doing. It has "always" been that way. - The horrid RPATH is needed, for running not installed binaries, a very real scenario, - Jay ---------------------------------------- > Date: Sun, 5 Apr 2009 20:17:02 -0700 > From: carson at taltos.org > To: m3devel at elegosoft.com > Subject: Re: [M3devel] runpath/unshipped vs. shipped binaries > > Jay wrote: > ... >> When I build a "regular" build, historically, on Linux, >> binaries have a big bunch of paths run together in them, like: >> >> >> /cm3/pkg/m3core/AMD64_LINUX:/cm3/pkg/libm3/AMD64_LINUX:etc. > ... >> Now, today I have made things a bit better. >> >> >> The first path is $ORIGIN/../lib. >> $ORIGIN is a special syntax for "The directory with the executable". >> That really is not a sufficient mechanism, but it is a small step forwarder. >> YOu want relativity from the referencing file, not just the executable. >> Or something more abstract not dealing with paths at all.. > > If you're saying that today you produce binaries with an RPATH of: > > $ORIGIN/../lib:/cm3/pkg/m3core/AMD64_LINUX:... > > That's just... horrid. > > Assuming all of your libraries are in ${exe_path}/../lib, you need > exactly one RPATH entry: > > $ORIGIN/../lib > > Get rid of _all_ the other "-R foo" link arguments, and all will be > well. No need to relink if you link properly the first time. > > -- > Carson From hosking at cs.purdue.edu Mon Apr 6 07:08:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 6 Apr 2009 15:08:29 +1000 Subject: [M3devel] small objects In-Reply-To: <49D95E70.6000004@wichita.edu> References: <200903300333.n2U3XBME062502@camembert.async.caltech.edu> <49D95E70.6000004@wichita.edu> Message-ID: <40B7AD71-FBDD-4321-837F-D294DD4A3D45@cs.purdue.edu> I like the notion of having a TAGGED INTEGER type that is a hybrid ordinal/reference. Subtyping rules for references would now be as follows: NULL <: REF T <: REFANY TAGGED INTEGER <: REF T <: REFANY ROOT <: REFANY NULL <: T OBJECT ... END <: T TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: REFANY, not T <: ADDRESS) Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference type. Values of TAGGED INTEGER are non-pointer values similar to the value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and NARROW(x, TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to ISTYPE(x, NULL), NARROW(x, NULL), and TYPECODE(NULL). Because TAGGED INTEGER is an ordinal we can extract the integer value it holds using ORD(x). Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED INTEGER). ***The only problem with this scheme is how to efficiently perform run- time tests for dereferencing NULL, and TAGGED INTEGER?*** So, here is a slightly less elegant alternative that is probably straightforward to implement. Introduce a separate TAGGED hierarchy. NULL <: REF T <: REFANY NULL <: UNTRACED REF T <: ADDRESS TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. ROOT <: REFANY TAGGED ROOT <: TAGGED REFANY NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED REFANY. This way, tagged references only need a run-time test for the tag on dereference (we can throw an "attempt to dereference TAGGED INTEGER" at run time, just like we throw "attempt to dereference NIL" for untagged references). This check can be a straightforward test of the low bit tag. Of course, the weird thing here is now that we don't have a single NULL value for TAGGED references --- we have multiple null values VAL(x, TAGGED INTEGER). Instead of asking "x == NIL" we must ask "ISTYPE(x, TAGGED INTEGER)". Of course, because TAGGED INTEGER is an ordinal, we can also perform the usual ordinal operations like INC(x), DEC(x), wherever x is typed TAGGED INTEGER. On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: > I spent quite a bit of time playing with a more general system where > there is a set of "tagged" types, with (an implementation-defined > subrange of) INTEGER and a reference type both being a subtype of a > tagged type. It might have been tolerable, if it weren't for the > interaction with object subtypes and opaque types, which quickly > gets deep into a deep linguistic tar pit. > > Tony's approach is much simpler and would serve what I see as the > need. It does sacrifice any static checking of what reference type > is being tagged, and will also require an extra runtime ISTYPE/ > TYPECASE. > > Would INTEGER and REFANY be assignable to TAGGED, or would there > also need to be an explicit conversion in that direction too, say > VAL(x, TAGGED)? I think I favor the explicit conversion here. It > is a bit inconsistent with the usual Modula-3 assignability > philosophy, > but not requiring the explicit conversion already gets your toes > into tar. > > We would have to have something more like ISTYPE, though, which will > tell which type the value belongs to without risking a runtime error, > which VAL would do. > > An intermediate approach might be to have a set of tagged types > constructed by, say, TAGGED T, where I is a reference type, but > with no subtype relations on them at all, thus still requiring > the explicit conversions and checks. > > I do want to say, I _really_ want this capability somehow. I have > an ADT module whose internal data structure, for full generality, > needs to have two heap objects (the second because it has nonstatic > size) and 11 total words counting the orginal pointer, in the case of > values that would fit directly into the "pointer" word. Moreover, > these small cases are in the great majority. > > Besides the 11-to-one increase in actual occupied space, there > is extra time for allocation, periodic tracing, and collection, space > loss due to heap fragmentation, and time/space tradeoff loss due to > reduced locality of reference. So sometimes, it would be a big > performance gain if we could do it. > > > Tony Hosking wrote: >> It is a much more pervasive hack than I would be comfortable with >> since it touches on the compiler (for all the type operations) as >> well >> as the run-time system in ways that are pretty gross. I would much >> rather have a new TAGGED builtin. ISTYPE would not work on it since >> that only works on references. The only thing you need is a way to >> extract the value -- we could overload VAL(x, T) where x can be a >> TAGGED and T can be REFANY or INTEGER. >> From jay.krell at cornell.edu Mon Apr 6 07:14:01 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 6 Apr 2009 05:14:01 +0000 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: <49D9742E.6080100@taltos.org> References: <49D9742E.6080100@taltos.org> Message-ID: Here's another point I just discovered...granted, I did say I was only talking about Linux..but on Solaris, I just learned about -s on ldd: ldd -s /cm3/bin/Juno find object=libm3.so.5; required by /home/jay/cm3/bin/../lib/libjuno-compiler.so.5 search path=/usr/local/lib (LD_LIBRARY_PATH) trying path=/usr/local/lib/libm3.so.5 search path=$ORIGIN/../lib:/cm3/pkg/juno-machine/SOLgnu:/cm3/pkg/libm3/SOLgnu:/cm3/pkg/m3core/SO Lgnu (RPATH from file /home/jay/cm3/bin/../lib/libjuno-compiler.so.5) trying path=/home/jay/cm3/pkg/juno-compiler/SOLgnu/../lib/libm3.so.5 trying path=/cm3/pkg/juno-machine/SOLgnu/libm3.so.5 trying path=/cm3/pkg/libm3/SOLgnu/libm3.so.5 find object=libm3core.so.5; required by /home/jay/cm3/bin/../lib/libjuno-compiler.so.5 search path=/usr/local/lib (LD_LIBRARY_PATH) trying path=/usr/local/lib/libm3core.so.5 search path=$ORIGIN/../lib:/cm3/pkg/juno-machine/SOLgnu:/cm3/pkg/libm3/SOLgnu:/cm3/pkg/m3core/SO Lgnu (RPATH from file /home/jay/cm3/bin/../lib/libjuno-compiler.so.5) trying path=/home/jay/cm3/pkg/juno-compiler/SOLgnu/../lib/libm3core.so.5 trying path=/cm3/pkg/juno-machine/SOLgnu/libm3core.so.5 Which shows us that $ORIGIN is not the executable, it is the referencing file. Could be ipmlemented to be "both", have it search both, but I don't think it is. This begs for another large change. Don't ship any /cm3/pkg/foo/platform/libfoo.so. Ship only /cm3/lib/libfoo.so The second is already a symlink to the first anyway. And then add $ORIGIN and $ORIGIN/../lib to RPATH. Heck -- might as well just shove it all into /cm3/bin and just use $ORIGIN, kind of like how NT works..ok, I know that last step wouldn't likely be popular and it isn't important -- keep lib and bin split. One of the qeustions is -- do we believe we have a "useful" "hierarchy", or the world is really kind of flat anyway, embrace it? Given that lib is full of symlinks into pkg, seems like flat is the case and the hierarchy just looks nice, at least for .so file placement (*.i3/*.m3/*.m3x/*.a files would remain asis). I also think there's an issue here that..the ship structure and source structure should perhaps have been kept in parallel. That might allow for relative rpaths to work for uninstalled or installed binaries. Except, the source structure has more hierarchy than the ship structure, always. That is, shipping is a rearrangement of the source structure -- insert "pkg" and flatten. src/m3-libs/m3core => install/pkg/m3core src/m3-foo/bar => install/pkg/bar If instead it went: src/m3-libs/m3core => install/m3-libs/m3core src/m3-foo/bar => install/m3-foo/bar or: src/m3-libs/m3core => install/pkg/m3-libs/m3core src/m3-foo/bar => install/pkg/m3-foo/bar Then relative paths could probably be used in both roots with the same meaning. But they can't. I come back to..I guess..removing all the .so files from the pkg store, or reversing the sense of the symlinks. Or heck, just telling the linker -L /cm3/lib instead of -L/cm3/pkg/foo. That last step might be trivial and helpful. I'll try it, later. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: carson at taltos.org; m3devel at elegosoft.com > Subject: RE: [M3devel] runpath/unshipped vs. shipped binaries > Date: Mon, 6 Apr 2009 04:23:14 +0000 > > > > - The horrid RPATH is not my doing. It has "always" been that way. > > - The horrid RPATH is needed, for running not installed binaries, a very real scenario, > > - Jay > > > > ---------------------------------------- >> Date: Sun, 5 Apr 2009 20:17:02 -0700 >> From: carson at taltos.org >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] runpath/unshipped vs. shipped binaries >> >> Jay wrote: >> ... >>> When I build a "regular" build, historically, on Linux, >>> binaries have a big bunch of paths run together in them, like: >>> >>> >>> /cm3/pkg/m3core/AMD64_LINUX:/cm3/pkg/libm3/AMD64_LINUX:etc. >> ... >>> Now, today I have made things a bit better. >>> >>> >>> The first path is $ORIGIN/../lib. >>> $ORIGIN is a special syntax for "The directory with the executable". >>> That really is not a sufficient mechanism, but it is a small step forwarder. >>> YOu want relativity from the referencing file, not just the executable. >>> Or something more abstract not dealing with paths at all.. >> >> If you're saying that today you produce binaries with an RPATH of: >> >> $ORIGIN/../lib:/cm3/pkg/m3core/AMD64_LINUX:... >> >> That's just... horrid. >> >> Assuming all of your libraries are in ${exe_path}/../lib, you need >> exactly one RPATH entry: >> >> $ORIGIN/../lib >> >> Get rid of _all_ the other "-R foo" link arguments, and all will be >> well. No need to relink if you link properly the first time. >> >> -- >> Carson From carson at taltos.org Mon Apr 6 08:54:00 2009 From: carson at taltos.org (Carson Gaspar) Date: Sun, 05 Apr 2009 23:54:00 -0700 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: References: <49D9742E.6080100@taltos.org> Message-ID: <49D9A708.1050101@taltos.org> Jay wrote: > > - The horrid RPATH is not my doing. It has "always" been that way. > > - The horrid RPATH is needed, for running not installed binaries, a very real scenario, No. It's not needed. Please provide a use case where a crappy polluted RPATH provides any benefit, and be specific. If you need to _temporarily_ run binaries in the build tree, where ${exe_path}/../lib does not contain libraries, set LD_LIBRARY_PATH (which overrides RPATH). Or, better still, fix the build to put things in $foo/bin and $foo/lib before you run them. Hard-coding /tmp/frobnitz/blah/lib in RPATH is _extremely_ bad from many perspectives, including security. Don't do it. No really, don't. -- Carson From carson at taltos.org Mon Apr 6 09:00:27 2009 From: carson at taltos.org (Carson Gaspar) Date: Mon, 06 Apr 2009 00:00:27 -0700 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: References: <49D9742E.6080100@taltos.org> Message-ID: <49D9A88B.4070109@taltos.org> Jay wrote: > Which shows us that $ORIGIN is not the executable, it is the referencing file. > Could be ipmlemented to be "both", have it search both, but I don't think it is. $ORIGIN is the location of the object being linked. That may be the executable, or may be a shared library. So if you have: foo.so bar.so, linked against foo.so baz.exe, linked against bar.so And RPATH for all of them is "$ORIGIN/../lib", when you execute baz.exe, it looks for bar.so in $path_to_baz/../lib/bar.so. It then looks for foo.so in $path_to_bar/../lib/foo.so. Note that this is _different_ from linking baz.exe _explicitly_ against foo.so, instead of _implicitly_ via bar.so. Make sure the RPATH you use when linking objects, whether they be executables or shared objects, is correct. -- Carson From jay.krell at cornell.edu Mon Apr 6 10:08:50 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 6 Apr 2009 08:08:50 +0000 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: <49D9A708.1050101@taltos.org> References: <49D9742E.6080100@taltos.org> <49D9A708.1050101@taltos.org> Message-ID: Well, the big polluted runpath is how Modula-3 has always built things. The only reason for /tmp/tmprandom is because I build up an entire new install from scratch. Otherwise it would be /usr/local/cm3/pkg/... or such. If you look at the distributions Olaf has put out you can see he does similar. I think the Tinderbox builds are the same. This is tied up in the Quake code: M3_SPLIT_LIBNAMES = TRUE % --- split library names and pass -L/-l arguments to the linker if not defined("M3_SHARED_LIB_ARG") M3_SHARED_LIB_ARG = "-Wl,-R" end plus the fact that "install" is very interested in a "package store" and each set of files going in their own directory, and "imported libraries" coming from there, not a flattened /cm3/lib. I'm not sure I like it either, but it has been this way. Running uninstalled binaries seems very reasonable to me, and is also a long standing practise in the cm3 system, but maybe only one instance. I'm trying to find a way to - have a small portable runpath - allow uninstalled binaries to work but I think you might be right that LD_LIBRARY_PATH is how to get the second scenario to work. But that does require LD_LIBRARY_PATH be set within making a distribution. Or maybe just build PklFonts standalone, or ship it and then run it. Standalone is easiest. But this is really tying people's hands it seems, in terms of how much uninstalled binaries work. Maybe there should be an option to install .sos to /usr/lib so LD_LIBRARY_PATH can be left alone? I'm still looking into it all though. Could be that -L/cm3/pkg/foo -lfoo is fine, as long as the -R is dropped. I'll have to check that the full path to libfoo.so isn't recorded, but just the leaf libfoo.so. I guess for .so files we can use rpath like $ORIGIN/../../../lib. Where the ".." are backing up over pkg/package/platform to get back to root. - Jay ---------------------------------------- > Date: Sun, 5 Apr 2009 23:54:00 -0700 > From: carson at taltos.org > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] runpath/unshipped vs. shipped binaries > > Jay wrote: >> >> - The horrid RPATH is not my doing. It has "always" been that way. >> >> - The horrid RPATH is needed, for running not installed binaries, a very real scenario, > > No. It's not needed. Please provide a use case where a crappy polluted > RPATH provides any benefit, and be specific. > > If you need to _temporarily_ run binaries in the build tree, where > ${exe_path}/../lib does not contain libraries, set LD_LIBRARY_PATH > (which overrides RPATH). Or, better still, fix the build to put things > in $foo/bin and $foo/lib before you run them. > > Hard-coding /tmp/frobnitz/blah/lib in RPATH is _extremely_ bad from many > perspectives, including security. Don't do it. No really, don't. > > -- > Carson From carson at taltos.org Mon Apr 6 10:35:42 2009 From: carson at taltos.org (Carson Gaspar) Date: Mon, 06 Apr 2009 01:35:42 -0700 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: References: <49D9742E.6080100@taltos.org> <49D9A708.1050101@taltos.org> Message-ID: <49D9BEDE.1010603@taltos.org> BTW, I'm glad you're working on this, I just want to make sure we end up someplace better ;-) Jay wrote: > Well, the big polluted runpath is how Modula-3 has always built > things. The only reason for /tmp/tmprandom is because I build up an > entire new install from scratch. Otherwise it would be > /usr/local/cm3/pkg/... or such. If you look at the distributions Olaf > has put out you can see he does similar. I think the Tinderbox builds > are the same. The problem with using /tmp is that _any_ user can throw their own .so's in there. Bogus /usr/... paths are still unfortunate, but not a security nightmare like /tmp/... paths are. It may be that re-organizing the build system to behave better is more work than you have time for at the moment, and throwing in a $ORIGIN RPATH isn't a bad thing even if you don't fix the rest. But please don't ship binaries with an RPATH containing /tmp - someone will hurt themselves. -- Carson From jay.krell at cornell.edu Mon Apr 6 10:37:24 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 6 Apr 2009 08:37:24 +0000 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: <49D9A708.1050101@taltos.org> References: <49D9742E.6080100@taltos.org> <49D9A708.1050101@taltos.org> Message-ID: ok, nevermind, thanks Carson, that helped. Like you said: RUNPATH shall be small and portable and just $ORIGIN/../lib. I saw $ORIGIN within pkg and not lib, but now I see it only within lib. Maybe a clean rebuild fixed that, not sure (I had been just deleting all the .a files). If it flips and becomes consistently pkg, I'll try ORIGIN/../../../lib. Too many dot dots seems bad, could be escaping some part of the file system into who-knows-where. I have an idea you could verify your location something like $ORIGIN/../../../pkg/package/platform/.../../../lib. The extra traversal "../../../pkg/package/platform" ensure things are kind of how you expect, though wasteful. Anyway, hopefully not this. Running uninstalled binaries shall require either LD_LIBRARY_PATH or build_standalone(). m3tests uses build_standalone. This is maybe why more stuff is build_standalone -- anything that runs uninstalled when doing buildlobal, the various stub code generators. Systems that don't support $ORIGIN, hopefully that is not many, such as NetBSD, will require LD_LIBRARY_PATH. Another option is to relink on the target and point at /cm3/lib or such, but that requires the notion of relinking on target, which is in limbo. No full path is likely to be baked into any binary, for any system. Darwin is different but achieves similar goals. I changed my configuration files for PPC_DARWIN. I don't have the other architectures available (hm, maybe non-OSX Darwin in a VM, maybe). NT386 is different but achieves similar goals. There all the .exes and .dlls are shipped to the same directory. .exe directories are generally searched for .dlls. A lot of this is still speculative. Solaris seems in good shape, and Darwin, but I have to look into others still. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: carson at taltos.org > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] runpath/unshipped vs. shipped binaries > Date: Mon, 6 Apr 2009 08:08:50 +0000 > > > Well, the big polluted runpath is how Modula-3 has always built things. > The only reason for /tmp/tmprandom is because I build up an entire new install from scratch. Otherwise it would be /usr/local/cm3/pkg/... or such. > If you look at the distributions Olaf has put out you can see he does similar. > I think the Tinderbox builds are the same. > > > This is tied up in the Quake code: > M3_SPLIT_LIBNAMES = TRUE > % --- split library names and pass -L/-l arguments to the linker > if not defined("M3_SHARED_LIB_ARG") > M3_SHARED_LIB_ARG = "-Wl,-R" > end > > plus the fact that "install" is very interested in a "package store" and each set of files going in their own directory, and "imported libraries" coming from there, not a flattened /cm3/lib. > > > I'm not sure I like it either, but it has been this way. > > Running uninstalled binaries seems very reasonable to me, and is also a long standing practise in the cm3 system, but maybe only one instance. > > > I'm trying to find a way to > - have a small portable runpath > - allow uninstalled binaries to work > > but I think you might be right that LD_LIBRARY_PATH is how to get the second scenario to work. But that does require LD_LIBRARY_PATH be set within making a distribution. Or maybe just build PklFonts standalone, or ship it and then run it. Standalone is easiest. > > But this is really tying people's hands it seems, in terms of how much uninstalled binaries work. Maybe there should be an option to install .sos to /usr/lib so LD_LIBRARY_PATH can be left alone? > > > I'm still looking into it all though. > Could be that -L/cm3/pkg/foo -lfoo is fine, as long as the -R is dropped. > I'll have to check that the full path to libfoo.so isn't recorded, but just the leaf libfoo.so. > > I guess for .so files we can use rpath like $ORIGIN/../../../lib. > Where the ".." are backing up over pkg/package/platform to get back to root. > > > > - Jay > > > ---------------------------------------- >> Date: Sun, 5 Apr 2009 23:54:00 -0700 >> From: carson at taltos.org >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] runpath/unshipped vs. shipped binaries >> >> Jay wrote: >>> >>> - The horrid RPATH is not my doing. It has "always" been that way. >>> >>> - The horrid RPATH is needed, for running not installed binaries, a very real scenario, >> >> No. It's not needed. Please provide a use case where a crappy polluted >> RPATH provides any benefit, and be specific. >> >> If you need to _temporarily_ run binaries in the build tree, where >> ${exe_path}/../lib does not contain libraries, set LD_LIBRARY_PATH >> (which overrides RPATH). Or, better still, fix the build to put things >> in $foo/bin and $foo/lib before you run them. >> >> Hard-coding /tmp/frobnitz/blah/lib in RPATH is _extremely_ bad from many >> perspectives, including security. Don't do it. No really, don't. >> >> -- >> Carson From jay.krell at cornell.edu Mon Apr 6 10:43:52 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 6 Apr 2009 08:43:52 +0000 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: <49D9BEDE.1010603@taltos.org> References: <49D9742E.6080100@taltos.org> <49D9A708.1050101@taltos.org> <49D9BEDE.1010603@taltos.org> Message-ID: Good point thanks, /usr/random better than /tmp/random. I'd build as root, so you are safe from non-root, or somesuch. Hopefully it'll become moot. I have made progress inserting $ORIGIN at the front already. I need to double check if that is /cm3/lib or /cm3/pkg/foo/linuxlibc6. Hopefully /cm3/lib. And then see about removing the rest. Solaris is looking good, at least. NetBSD doesn't support $origin. (but hey, my NetBSD machine is booted to FreeBSD currently, where, besides these issues, I want to switch to the new/small/portable Unix/*.i3 files :) ) Ok, Linux/x86 is looking good. Just a tad ugly, you end up with "../lib" for each level in the dependency tree: ldd -v /cm3/bin/Juno: libm3X11R4.so.5 => /home/jay/cm3/bin/../lib/../lib/libm3X11R4.so.5 but that's ok. Pray tell, what's the difference between RPATH and RUNPATH? objdump -f -x /cm3/bin/Juno Dynamic Section: NEEDED libjuno-compiler.so.5 NEEDED libjuno-machine.so.5 NEEDED libm3formsvbt.so.5 NEEDED libm3vbtkit.so.5 NEEDED libm3ui.so.5 NEEDED libm3netobj.so.5 NEEDED libm3.so.5 NEEDED libm3core.so.5 NEEDED libc.so.6 RPATH $ORIGIN/../lib RUNPATH $ORIGIN/../lib - Jay ---------------------------------------- > Date: Mon, 6 Apr 2009 01:35:42 -0700 > From: carson at taltos.org > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] runpath/unshipped vs. shipped binaries > > BTW, I'm glad you're working on this, I just want to make sure we end up > someplace better ;-) > > Jay wrote: >> Well, the big polluted runpath is how Modula-3 has always built >> things. The only reason for /tmp/tmprandom is because I build up an >> entire new install from scratch. Otherwise it would be >> /usr/local/cm3/pkg/... or such. If you look at the distributions Olaf >> has put out you can see he does similar. I think the Tinderbox builds >> are the same. > > The problem with using /tmp is that _any_ user can throw their own .so's > in there. Bogus /usr/... paths are still unfortunate, but not a security > nightmare like /tmp/... paths are. > > It may be that re-organizing the build system to behave better is more > work than you have time for at the moment, and throwing in a $ORIGIN > RPATH isn't a bad thing even if you don't fix the rest. But please don't > ship binaries with an RPATH containing /tmp - someone will hurt themselves. > > -- > Carson From carson at taltos.org Mon Apr 6 10:51:40 2009 From: carson at taltos.org (Carson Gaspar) Date: Mon, 06 Apr 2009 01:51:40 -0700 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: References: <49D9742E.6080100@taltos.org> <49D9A708.1050101@taltos.org> <49D9BEDE.1010603@taltos.org> Message-ID: <49D9C29C.9000404@taltos.org> Jay wrote: > Pray tell, what's the difference between RPATH and RUNPATH? > > objdump -f -x /cm3/bin/Juno > > Dynamic Section: > NEEDED libjuno-compiler.so.5 > NEEDED libjuno-machine.so.5 > NEEDED libm3formsvbt.so.5 > NEEDED libm3vbtkit.so.5 > NEEDED libm3ui.so.5 > NEEDED libm3netobj.so.5 > NEEDED libm3.so.5 > NEEDED libm3core.so.5 > NEEDED libc.so.6 > RPATH $ORIGIN/../lib > RUNPATH $ORIGIN/../lib AFAIK none. At least on Solaris they always point to the same string address. I suspect one is legacy and the other is ELF standard. -- Carson From jay.krell at cornell.edu Mon Apr 6 14:33:15 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 6 Apr 2009 12:33:15 +0000 Subject: [M3devel] some new archives -- AMD64_LINUX, PPC_DARWIN, NT386 Message-ID: NT386 now also. (This part is not difficult..) - Jay ________________________________ > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: some new archives -- AMD64_LINUX and PPC_DARWIN > Date: Sun, 5 Apr 2009 12:59:24 +0000 > > some new archives > > I put up PPC_DARWIN and AMD64_LINUX binaries on http://modula3.elegosoft.com/cm3/uploaded-archives. > > > PPC_DARWIN still has the usually crashing formsvbt. > I've started building Solaris 5.4 locally to see if it has the bug > > and then will proceed from there... > > > > AMD64_LINUX has paths like /tmp/tmprandom, and $ORIGIN/../lib in it, as mentioned > in my other mail. > > > AMD64_LINUX built easily starting with the earlier archives there. > > - Jay From wagner at elegosoft.com Mon Apr 6 14:42:42 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 06 Apr 2009 14:42:42 +0200 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: References: <49D9742E.6080100@taltos.org> <49D9A708.1050101@taltos.org> Message-ID: <20090406144242.almwq5chwgo04kwo@mail.elegosoft.com> Quoting Jay : > Running uninstalled binaries shall require either LD_LIBRARY_PATH > or build_standalone(). m3tests uses build_standalone. This is maybe > why more stuff is build_standalone -- anything that runs uninstalled > when doing buildlobal, the various stub code generators. Please just use build_standalone for all binaries that are needed by the build system itself. That shouldn't be many. Otherwise, I think setting LD_LIBRARY_PATH is acceptable. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Mon Apr 6 16:50:25 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 07:50:25 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Sun, 05 Apr 2009 20:45:15 CDT." <49D95EAB.8020802@cox.net> Message-ID: <200904061450.n36EoPk9085841@camembert.async.caltech.edu> Hi Rodney, I would like this capability too, but I am a bit wary of Tony's idea of changing the Modula-3 language---even in a "minor" way. I've been working for the last week or so on an application using the Modula-3 Toolkit, and I must say I have realized that the Modula-3 type system has a lot more subtleties than I thought. I would not want to make any real changes to it. There's a paper called "The Modula-3 Type System" by Cardelli, Donahue, Kalsow, and Nelson that is worth studying in detail before making any changes whatsoever, I think. Also remember that changes to the type system will affect m3tk and anything that depends on m3tk (which includes two or three stub generators in the main tree and who knows how many dependencies outside of it). I'm still not sure why we can't take the approach of Word.T . Make a RefanyOrInt.T that can safely be: 1. Tested whether it is a small integer or a REFANY 2. If a REFANY, be dereferenced as normal, *or* via RefanyOrInt.ToRefany 3. If a small integer, can be extracted via RefanyOrInt.ToInt 4. Created either as a small integer or a REFANY Any other operations on it (including ISTYPE and TYPECASE, at least when the object is a small integer) would result in a checked runtime error. Note that with the declaration "RefanyOrInt.T = REFANY", the current compiler will as far as I know not accept any operations on RefanyOrInt.T outside of ISTYPE, TYPECASE, and NARROW (explicit or implicit). I wouldn't be surprised if most of what I'm proposing already works (i.e., crashes with a checked runtime error as it should) with the current runtime. Anything that slips through would need to be fixed up with a one-bit check of the LSB of the REFANY for the operations mentioned above. Unfortunately this has to be done for operations on every REFANY, not just the new type. I think that Modula-3 programmers are already aware that using REFANYs involves forcing the runtime to do extra type-checking work, so they already know not to use them if they are looking for maximum performance, so I don't think that burdening operations on REFANY with an extra one-bit check is too onerous. An advantage of my proposal is that the amount of code in the new proposed library is truly diminutive. In fact, I think I posted pretty much that code to the list a few weeks ago. (If you missed it, it's http://www.async.caltech.edu/~mika/interp/ ) Mika "Rodney M. Bates" writes: >I spent quite a bit of time playing with a more general system where >there is a set of "tagged" types, with (an implementation-defined >subrange of) INTEGER and a reference type both being a subtype of a >tagged type. It might have been tolerable, if it weren't for the >interaction with object subtypes and opaque types, which quickly >gets deep into a deep linguistic tar pit. > >Tony's approach is much simpler and would serve what I see as the >need. It does sacrifice any static checking of what reference type >is being tagged, and will also require an extra runtime ISTYPE/TYPECASE. > >Would INTEGER and REFANY be assignable to TAGGED, or would there >also need to be an explicit conversion in that direction too, say >VAL(x, TAGGED)? I think I favor the explicit conversion here. It >is a bit inconsistent with the usual Modula-3 assignability philosophy, >but not requiring the explicit conversion already gets your toes into tar. > >We would have to have something more like ISTYPE, though, which will >tell which type the value belongs to without risking a runtime error, >which VAL would do. > >An intermediate approach might be to have a set of tagged types >constructed by, say, TAGGED T, where I is a reference type, but >with no subtype relations on them at all, thus still requiring >the explicit conversions and checks. > >I do want to say, I _really_ want this capability somehow. I have >an ADT module whose internal data structure, for full generality, >needs to have two heap objects (the second because it has nonstatic >size) and 11 total words counting the orginal pointer, in the case of >values that would fit directly into the "pointer" word. Moreover, >these small cases are in the great majority. > >Besides the 11-to-one increase in actual occupied space, there >is extra time for allocation, periodic tracing, and collection, space >loss due to heap fragmentation, and time/space tradeoff loss due to >reduced locality of reference. So sometimes, it would be a big >performance gain if we could do it. > > >Tony Hosking wrote: > It is a much more pervasive hack than I would be comfortable with >> since it touches on the compiler (for all the type operations) as well >> as the run-time system in ways that are pretty gross. I would much >> rather have a new TAGGED builtin. ISTYPE would not work on it since >> that only works on references. The only thing you need is a way to >> extract the value -- we could overload VAL(x, T) where x can be a >> TAGGED and T can be REFANY or INTEGER. >> >> From mika at async.caltech.edu Mon Apr 6 17:29:29 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 08:29:29 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Mon, 06 Apr 2009 15:08:29 +1000." <40B7AD71-FBDD-4321-837F-D294DD4A3D45@cs.purdue.edu> Message-ID: <200904061529.n36FTTn0086974@camembert.async.caltech.edu> Ah I should read my whole inbox before replying. I take it you would worry that in my proposal (to do this all in a library) the use of REFANY to store an integer could be abused somehow. That the Modula-3 type system (as it exists now) explicitly rules out doing such things, and therefore, a language change is necessary.... Mika Tony Hosking writes: >I like the notion of having a TAGGED INTEGER type that is a hybrid >ordinal/reference. > >Subtyping rules for references would now be as follows: > >NULL <: REF T <: REFANY >TAGGED INTEGER <: REF T <: REFANY > >ROOT <: REFANY >NULL <: T OBJECT ... END <: T >TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: REFANY, not >T <: ADDRESS) > >Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >type. Values of TAGGED INTEGER are non-pointer values similar to the >value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and NARROW(x, >TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to ISTYPE(x, >NULL), NARROW(x, NULL), and TYPECODE(NULL). > >Because TAGGED INTEGER is an ordinal we can extract the integer value >it holds using ORD(x). >Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >INTEGER). > >***The only problem with this scheme is how to efficiently perform run- >time tests for dereferencing NULL, and TAGGED INTEGER?*** > >So, here is a slightly less elegant alternative that is probably >straightforward to implement. Introduce a separate TAGGED hierarchy. > >NULL <: REF T <: REFANY >NULL <: UNTRACED REF T <: ADDRESS >TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY > >Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. > >ROOT <: REFANY >TAGGED ROOT <: TAGGED REFANY >NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY > >Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED >REFANY. > >This way, tagged references only need a run-time test for the tag on >dereference (we can throw an "attempt to dereference TAGGED INTEGER" >at run time, just like we throw "attempt to dereference NIL" for >untagged references). This check can be a straightforward test of the >low bit tag. Of course, the weird thing here is now that we don't >have a single NULL value for TAGGED references --- we have multiple >null values VAL(x, TAGGED INTEGER). Instead of asking "x == NIL" we >must ask "ISTYPE(x, TAGGED INTEGER)". > >Of course, because TAGGED INTEGER is an ordinal, we can also perform >the usual ordinal operations like INC(x), DEC(x), wherever x is typed >TAGGED INTEGER. > > >On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: > >> I spent quite a bit of time playing with a more general system where >> there is a set of "tagged" types, with (an implementation-defined >> subrange of) INTEGER and a reference type both being a subtype of a >> tagged type. It might have been tolerable, if it weren't for the >> interaction with object subtypes and opaque types, which quickly >> gets deep into a deep linguistic tar pit. >> >> Tony's approach is much simpler and would serve what I see as the >> need. It does sacrifice any static checking of what reference type >> is being tagged, and will also require an extra runtime ISTYPE/ >> TYPECASE. >> >> Would INTEGER and REFANY be assignable to TAGGED, or would there >> also need to be an explicit conversion in that direction too, say >> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >> is a bit inconsistent with the usual Modula-3 assignability >> philosophy, >> but not requiring the explicit conversion already gets your toes >> into tar. >> >> We would have to have something more like ISTYPE, though, which will >> tell which type the value belongs to without risking a runtime error, >> which VAL would do. >> >> An intermediate approach might be to have a set of tagged types >> constructed by, say, TAGGED T, where I is a reference type, but >> with no subtype relations on them at all, thus still requiring >> the explicit conversions and checks. >> >> I do want to say, I _really_ want this capability somehow. I have >> an ADT module whose internal data structure, for full generality, >> needs to have two heap objects (the second because it has nonstatic >> size) and 11 total words counting the orginal pointer, in the case of >> values that would fit directly into the "pointer" word. Moreover, >> these small cases are in the great majority. >> >> Besides the 11-to-one increase in actual occupied space, there >> is extra time for allocation, periodic tracing, and collection, space >> loss due to heap fragmentation, and time/space tradeoff loss due to >> reduced locality of reference. So sometimes, it would be a big >> performance gain if we could do it. >> >> >> Tony Hosking wrote: >>> It is a much more pervasive hack than I would be comfortable with >>> since it touches on the compiler (for all the type operations) as >>> well >>> as the run-time system in ways that are pretty gross. I would much >>> rather have a new TAGGED builtin. ISTYPE would not work on it since >>> that only works on references. The only thing you need is a way to >>> extract the value -- we could overload VAL(x, T) where x can be a >>> TAGGED and T can be REFANY or INTEGER. >>> From mika at async.caltech.edu Mon Apr 6 17:32:56 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 08:32:56 -0700 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: Your message of "Mon, 06 Apr 2009 14:42:42 +0200." <20090406144242.almwq5chwgo04kwo@mail.elegosoft.com> Message-ID: <200904061532.n36FWunc087102@camembert.async.caltech.edu> Would this mean that users of CM3 have to set LD_LIBRARY_PATH for things they build themselves but don't ship? I almost never ship binaries because I don't want user "mika" to have write access to the place whither the Modula-3 compiler normally ships. But I use them... from cron and other places. Other users may use them too... Mika Olaf Wagner writes: >Quoting Jay : > >> Running uninstalled binaries shall require either LD_LIBRARY_PATH >> or build_standalone(). m3tests uses build_standalone. This is maybe >> why more stuff is build_standalone -- anything that runs uninstalled >> when doing buildlobal, the various stub code generators. > >Please just use build_standalone for all binaries that are needed >by the build system itself. That shouldn't be many. > >Otherwise, I think setting LD_LIBRARY_PATH is acceptable. > >Olaf >-- >Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb??ude 12, 13355 Berlin, Germany >phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 6 17:51:19 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 06 Apr 2009 17:51:19 +0200 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: <200904061532.n36FWunc087102@camembert.async.caltech.edu> References: <200904061532.n36FWunc087102@camembert.async.caltech.edu> Message-ID: <20090406175119.5nknbzf9dwkcwkks@mail.elegosoft.com> Quoting Mika Nystrom : > > Would this mean that users of CM3 have to set LD_LIBRARY_PATH for > things they build themselves but don't ship? Probably. If the libraries cannot be located by the system in a standard path, it needs help. We could probably come up with a small script which prints the needed settings for a local M3 workspace. > I almost never ship binaries because I don't want user "mika" to > have write access to the place whither the Modula-3 compiler normally > ships. But I use them... from cron and other places. Other users > may use them too... Have you got a better suggestion? This is really not an M3 problem, but a general Unix question. How should dynamic shared object files be found (especially, when they are scattered across an M3 workspace)? If we burn in the local paths, we need to relink the objects before shipping. I also wouldn't like it when some installed program stops to work because the original creator made changes to his home directories... Any ideas? Olaf > Mika > > Olaf Wagner writes: >> Quoting Jay : >> >>> Running uninstalled binaries shall require either LD_LIBRARY_PATH >>> or build_standalone(). m3tests uses build_standalone. This is maybe >>> why more stuff is build_standalone -- anything that runs uninstalled >>> when doing buildlobal, the various stub code generators. >> >> Please just use build_standalone for all binaries that are needed >> by the build system itself. That shouldn't be many. >> >> Otherwise, I think setting LD_LIBRARY_PATH is acceptable. >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb??ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 mika at async.caltech.edu Mon Apr 6 19:12:55 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 10:12:55 -0700 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: Your message of "Mon, 06 Apr 2009 17:51:19 +0200." <20090406175119.5nknbzf9dwkcwkks@mail.elegosoft.com> Message-ID: <200904061712.n36HCtNO089745@camembert.async.caltech.edu> I think what Jay was trying to do sounds right. I think the binary should run without jumping through hoops if it hasn't been shipped. Once shipped it should not be possible to break it by fiddling around in the build directories. This does seem to imply that m3ship does something a bit more than "cp". I think it would be enough if it reordered the defaults, from "link with build tree first, /usr/local/lib second" to "link with /usr/local/lib first, build tree second" (or not at all build tree). Is it bad to have m3ship re-link? Mika Olaf Wagner writes: >Quoting Mika Nystrom : > >> >> Would this mean that users of CM3 have to set LD_LIBRARY_PATH for >> things they build themselves but don't ship? > >Probably. If the libraries cannot be located by the system in a >standard path, it needs help. We could probably come up with a small >script which prints the needed settings for a local M3 workspace. > >> I almost never ship binaries because I don't want user "mika" to >> have write access to the place whither the Modula-3 compiler normally >> ships. But I use them... from cron and other places. Other users >> may use them too... > >Have you got a better suggestion? >This is really not an M3 problem, but a general Unix question. >How should dynamic shared object files be found (especially, when >they are scattered across an M3 workspace)? If we burn in the local >paths, we need to relink the objects before shipping. I also wouldn't >like it when some installed program stops to work because the original >creator made changes to his home directories... > >Any ideas? > >Olaf > >> Mika >> >> Olaf Wagner writes: >>> Quoting Jay : >>> >>>> Running uninstalled binaries shall require either LD_LIBRARY_PATH >>>> or build_standalone(). m3tests uses build_standalone. This is maybe >>>> why more stuff is build_standalone -- anything that runs uninstalled >>>> when doing buildlobal, the various stub code generators. >>> >>> Please just use build_standalone for all binaries that are needed >>> by the build system itself. That shouldn't be many. >>> >>> Otherwise, I think setting LD_LIBRARY_PATH is acceptable. >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb????ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 rodney.m.bates at cox.net Mon Apr 6 21:11:29 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 06 Apr 2009 14:11:29 -0500 Subject: [M3devel] small objects In-Reply-To: <200904061529.n36FTTn0086974@camembert.async.caltech.edu> References: <200904061529.n36FTTn0086974@camembert.async.caltech.edu> Message-ID: <49DA53E1.8020408@cox.net> At first, I just envisioned implementing a small object type entirely inside an UNSAFE module, using unsafe operations to construct/test/separate the values. I think if the GC were to just to ignore words in heap objects that the type system claims are unambiguously pointers but actually have misaligned values, this could be done. But it flies in the face of a fundamental principle of Modula-3, namely that an UNSAFE module, if coded correctly, can prevent all other code from consequences of the unsafety. Unfortunately, this can't be done with the small pointers, because, even if opaque, they are still reference types, and client code can dereference them (including the implicit dereference in accessing a method or field of an object) and do ISTYPE, NARROW, TYPECASE, and assignments that do an implicit NARROW. All these operations could be done outside the implementing module and all could suffer from misaligned values. In fact, misaligned integer "objects" violate another principle that the bit pattern must always be a valid representation of some value of the type. However, this does suggest a different and very simple linguistic solution: Just have a new builtin type, say VERYOPAQUE, that supports no operations other than moving it around, i.e., assignment, bindings, passing as a parameter, etc. Only unsafe code could do anyhing with it, by using LOOPHOLE. The only problem is, would somebody then want one of these in a size other than one word? Mika Nystrom wrote: > Ah I should read my whole inbox before replying. > > I take it you would worry that in my proposal (to do this all in a > library) the use of REFANY to store an integer could be abused > somehow. That the Modula-3 type system (as it exists now) explicitly > rules out doing such things, and therefore, a language change is > necessary.... > > Mika > > Tony Hosking writes: > >> I like the notion of having a TAGGED INTEGER type that is a hybrid >> ordinal/reference. >> >> Subtyping rules for references would now be as follows: >> >> NULL <: REF T <: REFANY >> TAGGED INTEGER <: REF T <: REFANY >> >> ROOT <: REFANY >> NULL <: T OBJECT ... END <: T >> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: REFANY, not >> T <: ADDRESS) >> >> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >> type. Values of TAGGED INTEGER are non-pointer values similar to the >> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and NARROW(x, >> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to ISTYPE(x, >> NULL), NARROW(x, NULL), and TYPECODE(NULL). >> >> Because TAGGED INTEGER is an ordinal we can extract the integer value >> it holds using ORD(x). >> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >> INTEGER). >> >> ***The only problem with this scheme is how to efficiently perform run- >> time tests for dereferencing NULL, and TAGGED INTEGER?*** >> >> So, here is a slightly less elegant alternative that is probably >> straightforward to implement. Introduce a separate TAGGED hierarchy. >> >> NULL <: REF T <: REFANY >> NULL <: UNTRACED REF T <: ADDRESS >> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >> >> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >> >> ROOT <: REFANY >> TAGGED ROOT <: TAGGED REFANY >> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >> >> Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED >> REFANY. >> >> This way, tagged references only need a run-time test for the tag on >> dereference (we can throw an "attempt to dereference TAGGED INTEGER" >> at run time, just like we throw "attempt to dereference NIL" for >> untagged references). This check can be a straightforward test of the >> low bit tag. Of course, the weird thing here is now that we don't >> have a single NULL value for TAGGED references --- we have multiple >> null values VAL(x, TAGGED INTEGER). Instead of asking "x == NIL" we >> must ask "ISTYPE(x, TAGGED INTEGER)". >> >> Of course, because TAGGED INTEGER is an ordinal, we can also perform >> the usual ordinal operations like INC(x), DEC(x), wherever x is typed >> TAGGED INTEGER. >> >> >> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >> >> >>> I spent quite a bit of time playing with a more general system where >>> there is a set of "tagged" types, with (an implementation-defined >>> subrange of) INTEGER and a reference type both being a subtype of a >>> tagged type. It might have been tolerable, if it weren't for the >>> interaction with object subtypes and opaque types, which quickly >>> gets deep into a deep linguistic tar pit. >>> >>> Tony's approach is much simpler and would serve what I see as the >>> need. It does sacrifice any static checking of what reference type >>> is being tagged, and will also require an extra runtime ISTYPE/ >>> TYPECASE. >>> >>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>> also need to be an explicit conversion in that direction too, say >>> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >>> is a bit inconsistent with the usual Modula-3 assignability >>> philosophy, >>> but not requiring the explicit conversion already gets your toes >>> into tar. >>> >>> We would have to have something more like ISTYPE, though, which will >>> tell which type the value belongs to without risking a runtime error, >>> which VAL would do. >>> >>> An intermediate approach might be to have a set of tagged types >>> constructed by, say, TAGGED T, where I is a reference type, but >>> with no subtype relations on them at all, thus still requiring >>> the explicit conversions and checks. >>> >>> I do want to say, I _really_ want this capability somehow. I have >>> an ADT module whose internal data structure, for full generality, >>> needs to have two heap objects (the second because it has nonstatic >>> size) and 11 total words counting the orginal pointer, in the case of >>> values that would fit directly into the "pointer" word. Moreover, >>> these small cases are in the great majority. >>> >>> Besides the 11-to-one increase in actual occupied space, there >>> is extra time for allocation, periodic tracing, and collection, space >>> loss due to heap fragmentation, and time/space tradeoff loss due to >>> reduced locality of reference. So sometimes, it would be a big >>> performance gain if we could do it. >>> >>> >>> Tony Hosking wrote: >>> >>>> It is a much more pervasive hack than I would be comfortable with >>>> since it touches on the compiler (for all the type operations) as >>>> well >>>> as the run-time system in ways that are pretty gross. I would much >>>> rather have a new TAGGED builtin. ISTYPE would not work on it since >>>> that only works on references. The only thing you need is a way to >>>> extract the value -- we could overload VAL(x, T) where x can be a >>>> TAGGED and T can be REFANY or INTEGER. >>>> >>>> > > From mika at async.caltech.edu Mon Apr 6 22:03:03 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 13:03:03 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Mon, 06 Apr 2009 14:11:29 CDT." <49DA53E1.8020408@cox.net> Message-ID: <200904062003.n36K3381094096@camembert.async.caltech.edu> "Rodney M. Bates" writes: >At first, I just envisioned implementing a small object type >entirely inside an UNSAFE module, using unsafe operations >to construct/test/separate the values. I think if the GC were >to just to ignore words in heap objects that the type system >claims are unambiguously pointers but actually have misaligned >values, this could be done. Right that's precisely what the module I posted does. > >But it flies in the face of a fundamental principle of Modula-3, >namely that an UNSAFE module, if coded correctly, can prevent >all other code from consequences of the unsafety. Unfortunately, >this can't be done with the small pointers, because, even if >opaque, they are still reference types, and client code can >dereference them (including the implicit dereference in accessing >a method or field of an object) and do ISTYPE, NARROW, TYPECASE, >and assignments that do an implicit NARROW. All these operations >could be done outside the implementing module and all could >suffer from misaligned values. Well yes that is true. But the client can't dereference REFANY. Modula-3 doesn't permit that. That's an important practical point, because now we're limited to the other things: ISTYPE, NARROW (implicit and explicit), TYPECASE. (There are two more, actually, and they are = and #.) As long as those can be guaranteed to fail you're OK. [ Actually see my P.S. below! ] > >In fact, misaligned integer "objects" violate another principle that >the bit pattern must always be a valid representation of some value >of the type. Yes I think maybe this is what Tony is worried about. But let's just change the definition of REFANY to include anything with the LSB set...? In Modula-3-ese it would be more like the following: "REFANY can hold three types of objects. NIL, REF something or an implementation-defined other set of values that can only be accessed in an UNSAFE module. It is a checked runtime error to pass a 'REFANY of the third kind' to ISTYPE, NARROW, TYPECASE." [ Actually see my P.S. below! ] Then I propose we punt the handling of the new REFANYs to this unsafe module we spoke about above. As far as Modula-3 is concerned, there's just a set of values of (apparently) very little utility that can be represented by REFANY. If you think about it, this is really not so crazy. Any module that uses REFANY today is designed around to the fact that there are plenty of values of REFANY that can be of no interest to that module except for passing along to another module. (REFANY can easily represent a type which a module has no way of accessing *any* declaration of beyond just REFANY.) We're just adding some others, the only difference being that the new values are of no interest to any non-UNSAFE module. (Eh, technically this is already true for any reference type that is declared in an UNSAFE module today so one might argue we have in fact added nothing.) > >However, this does suggest a different and very simple linguistic >solution: Just have a new builtin type, say VERYOPAQUE, that >supports no operations other than moving it around, i.e., >assignment, bindings, passing as a parameter, etc. Only unsafe >code could do anyhing with it, by using LOOPHOLE. The only >problem is, would somebody then want one of these in a size other >than one word? This is nice, and we already have a candidate type, in fact: ADDRESS. But the problem is that the GC doesn't follow this even if the LSB is clear... which we *do* want. Why are you worried about getting it in sizes other than one word? That seems to me to be an application problem. If someone wants an ARRAY OF VERYOPAQUE is that a problem? Mika P.S. Illustration of the above, in today's Modula-3: UNSAFE MODULE Unsafe; (* this module is just declared UNSAFE to conform with the definition above, namely, that T can only be manipulated in an UNSAFE module, which this is! *) TYPE T = BRANDED OBJECT END; BEGIN Safe.P(NEW(T)) END Unsafe. (****************************************) MODULE Safe; PROCEDURE P(r : REFANY) = BEGIN NARROW(r, X); (* checked runtime error for all X *) ISTYPE(r, X); (* returns FALSE for all X except REFANY itself *) TYPECASE r OF X => (* only gets executed for X = REFANY *) END; END P; BEGIN END Safe. Actually is this behavior so bad for tagged integers? Since it is the behavior of existing code... why not keep it? Then you can even store a tagged integer in a RefList.T, say, even if that RefList.T uses NARROW or ISTYPE on the argument (I don't see why it would, but why not...?) > >Mika Nystrom wrote: >> Ah I should read my whole inbox before replying. >> >> I take it you would worry that in my proposal (to do this all in a >> library) the use of REFANY to store an integer could be abused >> somehow. That the Modula-3 type system (as it exists now) explicitly >> rules out doing such things, and therefore, a language change is >> necessary.... >> >> Mika >> >> Tony Hosking writes: >> >>> I like the notion of having a TAGGED INTEGER type that is a hybrid >>> ordinal/reference. >>> >>> Subtyping rules for references would now be as follows: >>> >>> NULL <: REF T <: REFANY >>> TAGGED INTEGER <: REF T <: REFANY >>> >>> ROOT <: REFANY >>> NULL <: T OBJECT ... END <: T >>> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: REFANY, not >>> T <: ADDRESS) >>> >>> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >>> type. Values of TAGGED INTEGER are non-pointer values similar to the >>> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and NARROW(x, >>> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to ISTYPE(x, >>> NULL), NARROW(x, NULL), and TYPECODE(NULL). >>> >>> Because TAGGED INTEGER is an ordinal we can extract the integer value >>> it holds using ORD(x). >>> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >>> INTEGER). >>> >>> ***The only problem with this scheme is how to efficiently perform run- >>> time tests for dereferencing NULL, and TAGGED INTEGER?*** >> >>> So, here is a slightly less elegant alternative that is probably >>> straightforward to implement. Introduce a separate TAGGED hierarchy. >>> >>> NULL <: REF T <: REFANY >>> NULL <: UNTRACED REF T <: ADDRESS >>> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >>> >>> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >>> >>> ROOT <: REFANY >>> TAGGED ROOT <: TAGGED REFANY >>> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >>> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >>> >>> Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED >>> REFANY. >>> >>> This way, tagged references only need a run-time test for the tag on >>> dereference (we can throw an "attempt to dereference TAGGED INTEGER" >>> at run time, just like we throw "attempt to dereference NIL" for >>> untagged references). This check can be a straightforward test of the >>> low bit tag. Of course, the weird thing here is now that we don't >>> have a single NULL value for TAGGED references --- we have multiple >>> null values VAL(x, TAGGED INTEGER). Instead of asking "x == NIL" we >>> must ask "ISTYPE(x, TAGGED INTEGER)". >>> >>> Of course, because TAGGED INTEGER is an ordinal, we can also perform >>> the usual ordinal operations like INC(x), DEC(x), wherever x is typed >>> TAGGED INTEGER. >>> >>> >>> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >>> >>> >>>> I spent quite a bit of time playing with a more general system where >>>> there is a set of "tagged" types, with (an implementation-defined >>>> subrange of) INTEGER and a reference type both being a subtype of a >>>> tagged type. It might have been tolerable, if it weren't for the >>>> interaction with object subtypes and opaque types, which quickly >>>> gets deep into a deep linguistic tar pit. >>>> >>>> Tony's approach is much simpler and would serve what I see as the >>>> need. It does sacrifice any static checking of what reference type >>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>> TYPECASE. >>>> >>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>> also need to be an explicit conversion in that direction too, say >>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >>>> is a bit inconsistent with the usual Modula-3 assignability >>>> philosophy, >>>> but not requiring the explicit conversion already gets your toes >>>> into tar. >>>> >>>> We would have to have something more like ISTYPE, though, which will >>>> tell which type the value belongs to without risking a runtime error, >>>> which VAL would do. >>>> >>>> An intermediate approach might be to have a set of tagged types >>>> constructed by, say, TAGGED T, where I is a reference type, but >>>> with no subtype relations on them at all, thus still requiring >>>> the explicit conversions and checks. >>>> >>>> I do want to say, I _really_ want this capability somehow. I have >>>> an ADT module whose internal data structure, for full generality, >>>> needs to have two heap objects (the second because it has nonstatic >>>> size) and 11 total words counting the orginal pointer, in the case of >>>> values that would fit directly into the "pointer" word. Moreover, >>>> these small cases are in the great majority. >>>> >>>> Besides the 11-to-one increase in actual occupied space, there >>>> is extra time for allocation, periodic tracing, and collection, space >>>> loss due to heap fragmentation, and time/space tradeoff loss due to >>>> reduced locality of reference. So sometimes, it would be a big >>>> performance gain if we could do it. >>>> >>>> >>>> Tony Hosking wrote: >>>> >>>>> It is a much more pervasive hack than I would be comfortable with >>>>> since it touches on the compiler (for all the type operations) as >>>>> well >>>>> as the run-time system in ways that are pretty gross. I would much >>>>> rather have a new TAGGED builtin. ISTYPE would not work on it since >>>>> that only works on references. The only thing you need is a way to >>>>> extract the value -- we could overload VAL(x, T) where x can be a >>>>> TAGGED and T can be REFANY or INTEGER. >>>>> >>>>> >> >> From mika at async.caltech.edu Mon Apr 6 22:17:37 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 13:17:37 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Mon, 06 Apr 2009 13:03:03 PDT." <200904062003.n36K3381094096@camembert.async.caltech.edu> Message-ID: <200904062017.n36KHbcq094473@camembert.async.caltech.edu> Ok I admit I missed something important. TYPECODE. It's easy enough to allocate a special TYPECODE to the tagged integer. One not used by any "real" type of course. It will break pickles and fingerprints. Pickles can be fixed, check the typecode and call a routine in the TaggedInteger interface (by default, user can override it?) to translate to and fro. But what about fingerprints? Again I guess we can just return the fingerprint of a nonexistent type............................. Hummm humm. Ok, how about this... let's declare a completely hidden type ... UNSAFE MODULE TaggedInteger; TYPE T = BRANDED OBJECT x : INTEGER END; BEGIN END TaggedInteger. Now, fix up TYPECODE, ISTYPE, NARROW, TYPECASE so that they all act *precisely* as if TaggedInteger.T were passed to them, when they see a REFANY with the LSB set. fingerprinting the type will give you the fingerprint of TaggedInteger.T. (But you better not rely on that! Only UNSAFE modules can do anything with this information, anyhow, so who cares, but see below.) I don't see how this breaks anything at all once we introduce the 'REFANY of the third kind', which is so small a change to the language's type system that I'm not sure it even qualifies as a change. Pickles are already unsafe, so the fact that the current pickles package would subvert the type system based on what I propose is a non-issue (language wise), it just means a few extra lines of code in the pickles package. The reason for the x : field above is that I propose that this be how the tagged integer be un/pickled, as an instance of an object of the (actual) type TaggedInteger.T. Mika Mika Nystrom writes: >"Rodney M. Bates" writes: >>At first, I just envisioned implementing a small object type >>entirely inside an UNSAFE module, using unsafe operations >>to construct/test/separate the values. I think if the GC were >>to just to ignore words in heap objects that the type system >>claims are unambiguously pointers but actually have misaligned >>values, this could be done. > >Right that's precisely what the module I posted does. > >> >>But it flies in the face of a fundamental principle of Modula-3, >>namely that an UNSAFE module, if coded correctly, can prevent >>all other code from consequences of the unsafety. Unfortunately, >>this can't be done with the small pointers, because, even if >>opaque, they are still reference types, and client code can >>dereference them (including the implicit dereference in accessing >>a method or field of an object) and do ISTYPE, NARROW, TYPECASE, >>and assignments that do an implicit NARROW. All these operations >>could be done outside the implementing module and all could >>suffer from misaligned values. > >Well yes that is true. But the client can't dereference REFANY. >Modula-3 doesn't permit that. That's an important practical point, >because now we're limited to the other things: ISTYPE, NARROW >(implicit and explicit), TYPECASE. (There are two more, actually, >and they are = and #.) As long as those can be guaranteed to fail >you're OK. [ Actually see my P.S. below! ] > >> >>In fact, misaligned integer "objects" violate another principle that >>the bit pattern must always be a valid representation of some value >>of the type. > >Yes I think maybe this is what Tony is worried about. But let's >just change the definition of REFANY to include anything with the >LSB set...? > >In Modula-3-ese it would be more like the following: > >"REFANY can hold three types of objects. NIL, REF something or an >implementation-defined other set of values that can only be accessed >in an UNSAFE module. It is a checked runtime error to pass a 'REFANY >of the third kind' to ISTYPE, NARROW, TYPECASE." [ Actually see my P.S. below! ] > >Then I propose we punt the handling of the new REFANYs to this >unsafe module we spoke about above. As far as Modula-3 is concerned, >there's just a set of values of (apparently) very little utility >that can be represented by REFANY. If you think about it, this is >really not so crazy. Any module that uses REFANY today is designed >around to the fact that there are plenty of values of REFANY that >can be of no interest to that module except for passing along to >another module. (REFANY can easily represent a type which a module >has no way of accessing *any* declaration of beyond just REFANY.) >We're just adding some others, the only difference being that the >new values are of no interest to any non-UNSAFE module. (Eh, >technically this is already true for any reference type that is >declared in an UNSAFE module today so one might argue we have in >fact added nothing.) > >> >>However, this does suggest a different and very simple linguistic >>solution: Just have a new builtin type, say VERYOPAQUE, that >>supports no operations other than moving it around, i.e., >>assignment, bindings, passing as a parameter, etc. Only unsafe >>code could do anyhing with it, by using LOOPHOLE. The only >>problem is, would somebody then want one of these in a size other >>than one word? > >This is nice, and we already have a candidate type, in fact: ADDRESS. >But the problem is that the GC doesn't follow this even if the LSB >is clear... which we *do* want. > >Why are you worried about getting it in sizes other than one word? >That seems to me to be an application problem. If someone wants >an ARRAY OF VERYOPAQUE is that a problem? > > Mika > >P.S. Illustration of the above, in today's Modula-3: > >UNSAFE MODULE Unsafe; > >(* this module is just declared UNSAFE to conform with the definition > above, namely, that T can only be manipulated in an UNSAFE > module, which this is! *) > >TYPE T = BRANDED OBJECT END; > >BEGIN > Safe.P(NEW(T)) >END Unsafe. > >(****************************************) > >MODULE Safe; > >PROCEDURE P(r : REFANY) = > BEGIN > NARROW(r, X); (* checked runtime error for all X *) > > ISTYPE(r, X); (* returns FALSE for all X except REFANY itself *) > > TYPECASE r OF > X => (* only gets executed for X = REFANY *) > END; > END P; > >BEGIN END Safe. > >Actually is this behavior so bad for tagged integers? Since it is >the behavior of existing code... why not keep it? Then you can even >store a tagged integer in a RefList.T, say, even if that RefList.T >uses NARROW or ISTYPE on the argument (I don't see why it would, but >why not...?) > > > >> >>Mika Nystrom wrote: >>> Ah I should read my whole inbox before replying. >>> >>> I take it you would worry that in my proposal (to do this all in a >>> library) the use of REFANY to store an integer could be abused >>> somehow. That the Modula-3 type system (as it exists now) explicitly >>> rules out doing such things, and therefore, a language change is >>> necessary.... >>> >>> Mika >>> >>> Tony Hosking writes: >>> >>>> I like the notion of having a TAGGED INTEGER type that is a hybrid >>>> ordinal/reference. >>>> >>>> Subtyping rules for references would now be as follows: >>>> >>>> NULL <: REF T <: REFANY >>>> TAGGED INTEGER <: REF T <: REFANY >>>> >>>> ROOT <: REFANY >>>> NULL <: T OBJECT ... END <: T >>>> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: REFANY, not >>>> T <: ADDRESS) >>>> >>>> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >>>> type. Values of TAGGED INTEGER are non-pointer values similar to the >>>> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and NARROW(x, >>>> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to ISTYPE(x, >>>> NULL), NARROW(x, NULL), and TYPECODE(NULL). >>>> >>>> Because TAGGED INTEGER is an ordinal we can extract the integer value >>>> it holds using ORD(x). >>>> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >>>> INTEGER). >>>> >>>> ***The only problem with this scheme is how to efficiently perform run- >>>> time tests for dereferencing NULL, and TAGGED INTEGER?*** >>> >>>> So, here is a slightly less elegant alternative that is probably >>>> straightforward to implement. Introduce a separate TAGGED hierarchy. >>>> >>>> NULL <: REF T <: REFANY >>>> NULL <: UNTRACED REF T <: ADDRESS >>>> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >>>> >>>> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >>>> >>>> ROOT <: REFANY >>>> TAGGED ROOT <: TAGGED REFANY >>>> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >>>> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >>>> >>>> Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED >>>> REFANY. >>>> >>>> This way, tagged references only need a run-time test for the tag on >>>> dereference (we can throw an "attempt to dereference TAGGED INTEGER" >>>> at run time, just like we throw "attempt to dereference NIL" for >>>> untagged references). This check can be a straightforward test of the >>>> low bit tag. Of course, the weird thing here is now that we don't >>>> have a single NULL value for TAGGED references --- we have multiple >>>> null values VAL(x, TAGGED INTEGER). Instead of asking "x == NIL" we >>>> must ask "ISTYPE(x, TAGGED INTEGER)". >>>> >>>> Of course, because TAGGED INTEGER is an ordinal, we can also perform >>>> the usual ordinal operations like INC(x), DEC(x), wherever x is typed >>>> TAGGED INTEGER. >>>> >>>> >>>> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >>>> >>>> >>>>> I spent quite a bit of time playing with a more general system where >>>>> there is a set of "tagged" types, with (an implementation-defined >>>>> subrange of) INTEGER and a reference type both being a subtype of a >>>>> tagged type. It might have been tolerable, if it weren't for the >>>>> interaction with object subtypes and opaque types, which quickly >>>>> gets deep into a deep linguistic tar pit. >>>>> >>>>> Tony's approach is much simpler and would serve what I see as the >>>>> need. It does sacrifice any static checking of what reference type >>>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>>> TYPECASE. >>>>> >>>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>>> also need to be an explicit conversion in that direction too, say >>>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >>>>> is a bit inconsistent with the usual Modula-3 assignability >>>>> philosophy, >>>>> but not requiring the explicit conversion already gets your toes >>>>> into tar. >>>>> >>>>> We would have to have something more like ISTYPE, though, which will >>>>> tell which type the value belongs to without risking a runtime error, >>>>> which VAL would do. >>>>> >>>>> An intermediate approach might be to have a set of tagged types >>>>> constructed by, say, TAGGED T, where I is a reference type, but >>>>> with no subtype relations on them at all, thus still requiring >>>>> the explicit conversions and checks. >>>>> >>>>> I do want to say, I _really_ want this capability somehow. I have >>>>> an ADT module whose internal data structure, for full generality, >>>>> needs to have two heap objects (the second because it has nonstatic >>>>> size) and 11 total words counting the orginal pointer, in the case of >>>>> values that would fit directly into the "pointer" word. Moreover, >>>>> these small cases are in the great majority. >>>>> >>>>> Besides the 11-to-one increase in actual occupied space, there >>>>> is extra time for allocation, periodic tracing, and collection, space >>>>> loss due to heap fragmentation, and time/space tradeoff loss due to >>>>> reduced locality of reference. So sometimes, it would be a big >>>>> performance gain if we could do it. >>>>> >>>>> >>>>> Tony Hosking wrote: >>>>> >>>>>> It is a much more pervasive hack than I would be comfortable with >>>>>> since it touches on the compiler (for all the type operations) as >>>>>> well >>>>>> as the run-time system in ways that are pretty gross. I would much >>>>>> rather have a new TAGGED builtin. ISTYPE would not work on it since >>>>>> that only works on references. The only thing you need is a way to >>>>>> extract the value -- we could overload VAL(x, T) where x can be a >>>>>> TAGGED and T can be REFANY or INTEGER. >>>>>> >>>>>> >>> >>> From mika at async.caltech.edu Mon Apr 6 22:31:57 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 13:31:57 -0700 Subject: [M3devel] Implementing the "Singleton pattern" in Modula-3 Message-ID: <200904062031.n36KVvC2094839@camembert.async.caltech.edu> Tony, Jay, you two seem to be most knowledgeable about this. Let's say I wanted to implement the "singleton pattern" in Modula-3. At present there seems to be no way of doing this. What about changing RTAllocator.callback as follows (or adding another callback): VAR callback : PROCEDURE(r : REFANY) : REFANY := NIL; (* If non-NIL, the allocator calls "callback(r)" just before returning a new traced reference "r" and instead returns the result of callback(r). See "RTAllocStats" for an example client. It is a checked runtime error for the typecode of r to differ from the typecode of the return value of callback(r). *) Mika From mika at async.caltech.edu Mon Apr 6 22:39:18 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 13:39:18 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Mon, 06 Apr 2009 13:03:03 PDT." <200904062003.n36K3381094096@camembert.async.caltech.edu> Message-ID: <200904062039.n36KdIsY095003@camembert.async.caltech.edu> And finally, to forestall a possible objection to the scheme I proposed: Yes, it is true that even a non-UNSAFE module can allocate a TaggedInteger.T by calling new := RTAllocator.NewTraced(TYPECODE(r)) where r is a tagged integer. But since it cannot dereference that new value or do anything else with it, I don't think this is a problem. The Pickler (built into the TaggedInteger module, one must assume) would simply have to be on the lookout for values of the "real" TaggedInteger.T versus those that are just numbers with the LSB set, and act accordingly. Since the T declaration is only visible within the UNSAFE module there can never be any question of another module's muddling the two types up. Mika Mika Nystrom writes: >"Rodney M. Bates" writes: >>At first, I just envisioned implementing a small object type >>entirely inside an UNSAFE module, using unsafe operations >>to construct/test/separate the values. I think if the GC were >>to just to ignore words in heap objects that the type system >>claims are unambiguously pointers but actually have misaligned >>values, this could be done. > >Right that's precisely what the module I posted does. > >> >>But it flies in the face of a fundamental principle of Modula-3, >>namely that an UNSAFE module, if coded correctly, can prevent >>all other code from consequences of the unsafety. Unfortunately, >>this can't be done with the small pointers, because, even if >>opaque, they are still reference types, and client code can >>dereference them (including the implicit dereference in accessing >>a method or field of an object) and do ISTYPE, NARROW, TYPECASE, >>and assignments that do an implicit NARROW. All these operations >>could be done outside the implementing module and all could >>suffer from misaligned values. > >Well yes that is true. But the client can't dereference REFANY. >Modula-3 doesn't permit that. That's an important practical point, >because now we're limited to the other things: ISTYPE, NARROW >(implicit and explicit), TYPECASE. (There are two more, actually, >and they are = and #.) As long as those can be guaranteed to fail >you're OK. [ Actually see my P.S. below! ] > >> >>In fact, misaligned integer "objects" violate another principle that >>the bit pattern must always be a valid representation of some value >>of the type. > >Yes I think maybe this is what Tony is worried about. But let's >just change the definition of REFANY to include anything with the >LSB set...? > >In Modula-3-ese it would be more like the following: > >"REFANY can hold three types of objects. NIL, REF something or an >implementation-defined other set of values that can only be accessed >in an UNSAFE module. It is a checked runtime error to pass a 'REFANY >of the third kind' to ISTYPE, NARROW, TYPECASE." [ Actually see my P.S. below! ] > >Then I propose we punt the handling of the new REFANYs to this >unsafe module we spoke about above. As far as Modula-3 is concerned, >there's just a set of values of (apparently) very little utility >that can be represented by REFANY. If you think about it, this is >really not so crazy. Any module that uses REFANY today is designed >around to the fact that there are plenty of values of REFANY that >can be of no interest to that module except for passing along to >another module. (REFANY can easily represent a type which a module >has no way of accessing *any* declaration of beyond just REFANY.) >We're just adding some others, the only difference being that the >new values are of no interest to any non-UNSAFE module. (Eh, >technically this is already true for any reference type that is >declared in an UNSAFE module today so one might argue we have in >fact added nothing.) > >> >>However, this does suggest a different and very simple linguistic >>solution: Just have a new builtin type, say VERYOPAQUE, that >>supports no operations other than moving it around, i.e., >>assignment, bindings, passing as a parameter, etc. Only unsafe >>code could do anyhing with it, by using LOOPHOLE. The only >>problem is, would somebody then want one of these in a size other >>than one word? > >This is nice, and we already have a candidate type, in fact: ADDRESS. >But the problem is that the GC doesn't follow this even if the LSB >is clear... which we *do* want. > >Why are you worried about getting it in sizes other than one word? >That seems to me to be an application problem. If someone wants >an ARRAY OF VERYOPAQUE is that a problem? > > Mika > >P.S. Illustration of the above, in today's Modula-3: > >UNSAFE MODULE Unsafe; > >(* this module is just declared UNSAFE to conform with the definition > above, namely, that T can only be manipulated in an UNSAFE > module, which this is! *) > >TYPE T = BRANDED OBJECT END; > >BEGIN > Safe.P(NEW(T)) >END Unsafe. > >(****************************************) > >MODULE Safe; > >PROCEDURE P(r : REFANY) = > BEGIN > NARROW(r, X); (* checked runtime error for all X *) > > ISTYPE(r, X); (* returns FALSE for all X except REFANY itself *) > > TYPECASE r OF > X => (* only gets executed for X = REFANY *) > END; > END P; > >BEGIN END Safe. > >Actually is this behavior so bad for tagged integers? Since it is >the behavior of existing code... why not keep it? Then you can even >store a tagged integer in a RefList.T, say, even if that RefList.T >uses NARROW or ISTYPE on the argument (I don't see why it would, but >why not...?) > > > >> >>Mika Nystrom wrote: >>> Ah I should read my whole inbox before replying. >>> >>> I take it you would worry that in my proposal (to do this all in a >>> library) the use of REFANY to store an integer could be abused >>> somehow. That the Modula-3 type system (as it exists now) explicitly >>> rules out doing such things, and therefore, a language change is >>> necessary.... >>> >>> Mika >>> >>> Tony Hosking writes: >>> >>>> I like the notion of having a TAGGED INTEGER type that is a hybrid >>>> ordinal/reference. >>>> >>>> Subtyping rules for references would now be as follows: >>>> >>>> NULL <: REF T <: REFANY >>>> TAGGED INTEGER <: REF T <: REFANY >>>> >>>> ROOT <: REFANY >>>> NULL <: T OBJECT ... END <: T >>>> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: REFANY, not >>>> T <: ADDRESS) >>>> >>>> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >>>> type. Values of TAGGED INTEGER are non-pointer values similar to the >>>> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and NARROW(x, >>>> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to ISTYPE(x, >>>> NULL), NARROW(x, NULL), and TYPECODE(NULL). >>>> >>>> Because TAGGED INTEGER is an ordinal we can extract the integer value >>>> it holds using ORD(x). >>>> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >>>> INTEGER). >>>> >>>> ***The only problem with this scheme is how to efficiently perform run- >>>> time tests for dereferencing NULL, and TAGGED INTEGER?*** >>> >>>> So, here is a slightly less elegant alternative that is probably >>>> straightforward to implement. Introduce a separate TAGGED hierarchy. >>>> >>>> NULL <: REF T <: REFANY >>>> NULL <: UNTRACED REF T <: ADDRESS >>>> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >>>> >>>> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >>>> >>>> ROOT <: REFANY >>>> TAGGED ROOT <: TAGGED REFANY >>>> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >>>> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >>>> >>>> Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED >>>> REFANY. >>>> >>>> This way, tagged references only need a run-time test for the tag on >>>> dereference (we can throw an "attempt to dereference TAGGED INTEGER" >>>> at run time, just like we throw "attempt to dereference NIL" for >>>> untagged references). This check can be a straightforward test of the >>>> low bit tag. Of course, the weird thing here is now that we don't >>>> have a single NULL value for TAGGED references --- we have multiple >>>> null values VAL(x, TAGGED INTEGER). Instead of asking "x == NIL" we >>>> must ask "ISTYPE(x, TAGGED INTEGER)". >>>> >>>> Of course, because TAGGED INTEGER is an ordinal, we can also perform >>>> the usual ordinal operations like INC(x), DEC(x), wherever x is typed >>>> TAGGED INTEGER. >>>> >>>> >>>> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >>>> >>>> >>>>> I spent quite a bit of time playing with a more general system where >>>>> there is a set of "tagged" types, with (an implementation-defined >>>>> subrange of) INTEGER and a reference type both being a subtype of a >>>>> tagged type. It might have been tolerable, if it weren't for the >>>>> interaction with object subtypes and opaque types, which quickly >>>>> gets deep into a deep linguistic tar pit. >>>>> >>>>> Tony's approach is much simpler and would serve what I see as the >>>>> need. It does sacrifice any static checking of what reference type >>>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>>> TYPECASE. >>>>> >>>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>>> also need to be an explicit conversion in that direction too, say >>>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >>>>> is a bit inconsistent with the usual Modula-3 assignability >>>>> philosophy, >>>>> but not requiring the explicit conversion already gets your toes >>>>> into tar. >>>>> >>>>> We would have to have something more like ISTYPE, though, which will >>>>> tell which type the value belongs to without risking a runtime error, >>>>> which VAL would do. >>>>> >>>>> An intermediate approach might be to have a set of tagged types >>>>> constructed by, say, TAGGED T, where I is a reference type, but >>>>> with no subtype relations on them at all, thus still requiring >>>>> the explicit conversions and checks. >>>>> >>>>> I do want to say, I _really_ want this capability somehow. I have >>>>> an ADT module whose internal data structure, for full generality, >>>>> needs to have two heap objects (the second because it has nonstatic >>>>> size) and 11 total words counting the orginal pointer, in the case of >>>>> values that would fit directly into the "pointer" word. Moreover, >>>>> these small cases are in the great majority. >>>>> >>>>> Besides the 11-to-one increase in actual occupied space, there >>>>> is extra time for allocation, periodic tracing, and collection, space >>>>> loss due to heap fragmentation, and time/space tradeoff loss due to >>>>> reduced locality of reference. So sometimes, it would be a big >>>>> performance gain if we could do it. >>>>> >>>>> >>>>> Tony Hosking wrote: >>>>> >>>>>> It is a much more pervasive hack than I would be comfortable with >>>>>> since it touches on the compiler (for all the type operations) as >>>>>> well >>>>>> as the run-time system in ways that are pretty gross. I would much >>>>>> rather have a new TAGGED builtin. ISTYPE would not work on it since >>>>>> that only works on references. The only thing you need is a way to >>>>>> extract the value -- we could overload VAL(x, T) where x can be a >>>>>> TAGGED and T can be REFANY or INTEGER. >>>>>> >>>>>> >>> >>> From hosking at cs.purdue.edu Tue Apr 7 02:06:03 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 10:06:03 +1000 Subject: [M3devel] small objects In-Reply-To: <200904061450.n36EoPk9085841@camembert.async.caltech.edu> References: <200904061450.n36EoPk9085841@camembert.async.caltech.edu> Message-ID: <59082335-E94F-48FC-AD7B-6632542B5ED4@cs.purdue.edu> I really don't like your proposal for the reasons you mention. It makes regular REF more expensive than it currently is. What is it about my relatively minor changes to the type system that you object to? I've just about finished changing the compiler front-end (in relatively minor ways) to accomodate the proposal I made yesterday. And it has the advantage of separating REF from TAGGED REF so we keep the standard REF clean. On 7 Apr 2009, at 00:50, Mika Nystrom wrote: > Hi Rodney, > > I would like this capability too, but I am a bit wary of Tony's > idea of changing the Modula-3 language---even in a "minor" way. > I've been working for the last week or so on an application using > the Modula-3 Toolkit, and I must say I have realized that the > Modula-3 type system has a lot more subtleties than I thought. I > would not want to make any real changes to it. There's a paper > called "The Modula-3 Type System" by Cardelli, Donahue, Kalsow, and > Nelson that is worth studying in detail before making any changes > whatsoever, I think. Also remember that changes to the type system > will affect m3tk and anything that depends on m3tk (which includes > two or three stub generators in the main tree and who knows how > many dependencies outside of it). > > I'm still not sure why we can't take the approach of Word.T . > Make a RefanyOrInt.T that can safely be: > > 1. Tested whether it is a small integer or a REFANY > > 2. If a REFANY, be dereferenced as normal, *or* via > RefanyOrInt.ToRefany > > 3. If a small integer, can be extracted via RefanyOrInt.ToInt > > 4. Created either as a small integer or a REFANY > > Any other operations on it (including ISTYPE and TYPECASE, at least > when the object is a small integer) would result in a checked runtime > error. > > Note that with the declaration "RefanyOrInt.T = REFANY", the current > compiler will as far as I know not accept any operations on > RefanyOrInt.T outside of ISTYPE, TYPECASE, and NARROW (explicit or > implicit). > > I wouldn't be surprised if most of what I'm proposing already works > (i.e., crashes with a checked runtime error as it should) with the > current runtime. Anything that slips through would need to be fixed > up with a one-bit check of the LSB of the REFANY for the operations > mentioned above. Unfortunately this has to be done for operations on > every REFANY, not just the new type. > > I think that Modula-3 programmers are already aware that using > REFANYs involves forcing the runtime to do extra type-checking work, > so they already know not to use them if they are looking for maximum > performance, so I don't think that burdening operations on REFANY > with an extra one-bit check is too onerous. > > An advantage of my proposal is that the amount of code in the new > proposed library is truly diminutive. In fact, I think I posted > pretty much that code to the list a few weeks ago. > > (If you missed it, it's > > http://www.async.caltech.edu/~mika/interp/ > > ) > > Mika > > > "Rodney M. Bates" writes: >> I spent quite a bit of time playing with a more general system where >> there is a set of "tagged" types, with (an implementation-defined >> subrange of) INTEGER and a reference type both being a subtype of a >> tagged type. It might have been tolerable, if it weren't for the >> interaction with object subtypes and opaque types, which quickly >> gets deep into a deep linguistic tar pit. >> >> Tony's approach is much simpler and would serve what I see as the >> need. It does sacrifice any static checking of what reference type >> is being tagged, and will also require an extra runtime ISTYPE/ >> TYPECASE. >> >> Would INTEGER and REFANY be assignable to TAGGED, or would there >> also need to be an explicit conversion in that direction too, say >> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >> is a bit inconsistent with the usual Modula-3 assignability >> philosophy, >> but not requiring the explicit conversion already gets your toes >> into tar. >> >> We would have to have something more like ISTYPE, though, which will >> tell which type the value belongs to without risking a runtime error, >> which VAL would do. >> >> An intermediate approach might be to have a set of tagged types >> constructed by, say, TAGGED T, where I is a reference type, but >> with no subtype relations on them at all, thus still requiring >> the explicit conversions and checks. >> >> I do want to say, I _really_ want this capability somehow. I have >> an ADT module whose internal data structure, for full generality, >> needs to have two heap objects (the second because it has nonstatic >> size) and 11 total words counting the orginal pointer, in the case of >> values that would fit directly into the "pointer" word. Moreover, >> these small cases are in the great majority. >> >> Besides the 11-to-one increase in actual occupied space, there >> is extra time for allocation, periodic tracing, and collection, space >> loss due to heap fragmentation, and time/space tradeoff loss due to >> reduced locality of reference. So sometimes, it would be a big >> performance gain if we could do it. >> >> >> Tony Hosking wrote: >> It is a much more pervasive hack than I would be comfortable with >>> since it touches on the compiler (for all the type operations) as >>> well >>> as the run-time system in ways that are pretty gross. I would much >>> rather have a new TAGGED builtin. ISTYPE would not work on it since >>> that only works on references. The only thing you need is a way to >>> extract the value -- we could overload VAL(x, T) where x can be a >>> TAGGED and T can be REFANY or INTEGER. >>> >>> From hosking at cs.purdue.edu Tue Apr 7 02:07:10 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 10:07:10 +1000 Subject: [M3devel] small objects In-Reply-To: <200904061450.n36EoPk9085841@camembert.async.caltech.edu> References: <200904061450.n36EoPk9085841@camembert.async.caltech.edu> Message-ID: PS What you propose has more pervasive impact on the run-time system and performance than my proposal simply because it conflates tagging with existing REFANY. On 7 Apr 2009, at 00:50, Mika Nystrom wrote: > Hi Rodney, > > I would like this capability too, but I am a bit wary of Tony's > idea of changing the Modula-3 language---even in a "minor" way. > I've been working for the last week or so on an application using > the Modula-3 Toolkit, and I must say I have realized that the > Modula-3 type system has a lot more subtleties than I thought. I > would not want to make any real changes to it. There's a paper > called "The Modula-3 Type System" by Cardelli, Donahue, Kalsow, and > Nelson that is worth studying in detail before making any changes > whatsoever, I think. Also remember that changes to the type system > will affect m3tk and anything that depends on m3tk (which includes > two or three stub generators in the main tree and who knows how > many dependencies outside of it). > > I'm still not sure why we can't take the approach of Word.T . > Make a RefanyOrInt.T that can safely be: > > 1. Tested whether it is a small integer or a REFANY > > 2. If a REFANY, be dereferenced as normal, *or* via > RefanyOrInt.ToRefany > > 3. If a small integer, can be extracted via RefanyOrInt.ToInt > > 4. Created either as a small integer or a REFANY > > Any other operations on it (including ISTYPE and TYPECASE, at least > when the object is a small integer) would result in a checked runtime > error. > > Note that with the declaration "RefanyOrInt.T = REFANY", the current > compiler will as far as I know not accept any operations on > RefanyOrInt.T outside of ISTYPE, TYPECASE, and NARROW (explicit or > implicit). > > I wouldn't be surprised if most of what I'm proposing already works > (i.e., crashes with a checked runtime error as it should) with the > current runtime. Anything that slips through would need to be fixed > up with a one-bit check of the LSB of the REFANY for the operations > mentioned above. Unfortunately this has to be done for operations on > every REFANY, not just the new type. > > I think that Modula-3 programmers are already aware that using > REFANYs involves forcing the runtime to do extra type-checking work, > so they already know not to use them if they are looking for maximum > performance, so I don't think that burdening operations on REFANY > with an extra one-bit check is too onerous. > > An advantage of my proposal is that the amount of code in the new > proposed library is truly diminutive. In fact, I think I posted > pretty much that code to the list a few weeks ago. > > (If you missed it, it's > > http://www.async.caltech.edu/~mika/interp/ > > ) > > Mika > > > "Rodney M. Bates" writes: >> I spent quite a bit of time playing with a more general system where >> there is a set of "tagged" types, with (an implementation-defined >> subrange of) INTEGER and a reference type both being a subtype of a >> tagged type. It might have been tolerable, if it weren't for the >> interaction with object subtypes and opaque types, which quickly >> gets deep into a deep linguistic tar pit. >> >> Tony's approach is much simpler and would serve what I see as the >> need. It does sacrifice any static checking of what reference type >> is being tagged, and will also require an extra runtime ISTYPE/ >> TYPECASE. >> >> Would INTEGER and REFANY be assignable to TAGGED, or would there >> also need to be an explicit conversion in that direction too, say >> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >> is a bit inconsistent with the usual Modula-3 assignability >> philosophy, >> but not requiring the explicit conversion already gets your toes >> into tar. >> >> We would have to have something more like ISTYPE, though, which will >> tell which type the value belongs to without risking a runtime error, >> which VAL would do. >> >> An intermediate approach might be to have a set of tagged types >> constructed by, say, TAGGED T, where I is a reference type, but >> with no subtype relations on them at all, thus still requiring >> the explicit conversions and checks. >> >> I do want to say, I _really_ want this capability somehow. I have >> an ADT module whose internal data structure, for full generality, >> needs to have two heap objects (the second because it has nonstatic >> size) and 11 total words counting the orginal pointer, in the case of >> values that would fit directly into the "pointer" word. Moreover, >> these small cases are in the great majority. >> >> Besides the 11-to-one increase in actual occupied space, there >> is extra time for allocation, periodic tracing, and collection, space >> loss due to heap fragmentation, and time/space tradeoff loss due to >> reduced locality of reference. So sometimes, it would be a big >> performance gain if we could do it. >> >> >> Tony Hosking wrote: >> It is a much more pervasive hack than I would be comfortable with >>> since it touches on the compiler (for all the type operations) as >>> well >>> as the run-time system in ways that are pretty gross. I would much >>> rather have a new TAGGED builtin. ISTYPE would not work on it since >>> that only works on references. The only thing you need is a way to >>> extract the value -- we could overload VAL(x, T) where x can be a >>> TAGGED and T can be REFANY or INTEGER. >>> >>> From mika at async.caltech.edu Tue Apr 7 02:42:23 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 17:42:23 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Tue, 07 Apr 2009 10:06:03 +1000." <59082335-E94F-48FC-AD7B-6632542B5ED4@cs.purdue.edu> Message-ID: <200904070042.n370gNK3001242@camembert.async.caltech.edu> You mean this proposal (you had two, I think)? --- NULL <: REF T <: REFANY NULL <: UNTRACED REF T <: ADDRESS TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. ROOT <: REFANY TAGGED ROOT <: TAGGED REFANY NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED REFANY. --- I like it fine, I think... I'm just worried, generally, about changing the type system. Hmmmm... you mean that the TAGGED things would just be a separate hierarchy? So you'd just add TAGGED in front of the REFs for this new hierarchy. But why no NULL? And you're comfortable with doing the conversions automatically? So tx : TAGGED INTEGER := 5; x : INTEGER := tx; would be OK? In that case it's just the m3tk that needs to be modified, and that's just busy work, I think. If it works it's beautiful... Mika Tony Hosking writes: >I really don't like your proposal for the reasons you mention. It >makes regular REF more expensive than it currently is. What is it >about my relatively minor changes to the type system that you object >to? I've just about finished changing the compiler front-end (in >relatively minor ways) to accomodate the proposal I made yesterday. >And it has the advantage of separating REF from TAGGED REF so we keep >the standard REF clean. > >On 7 Apr 2009, at 00:50, Mika Nystrom wrote: > >> Hi Rodney, >> >> I would like this capability too, but I am a bit wary of Tony's >> idea of changing the Modula-3 language---even in a "minor" way. >> I've been working for the last week or so on an application using >> the Modula-3 Toolkit, and I must say I have realized that the > Modula-3 type system has a lot more subtleties than I thought. I >> would not want to make any real changes to it. There's a paper >> called "The Modula-3 Type System" by Cardelli, Donahue, Kalsow, and >> Nelson that is worth studying in detail before making any changes >> whatsoever, I think. Also remember that changes to the type system >> will affect m3tk and anything that depends on m3tk (which includes >> two or three stub generators in the main tree and who knows how >> many dependencies outside of it). >> >> I'm still not sure why we can't take the approach of Word.T . >> Make a RefanyOrInt.T that can safely be: >> >> 1. Tested whether it is a small integer or a REFANY >> >> 2. If a REFANY, be dereferenced as normal, *or* via >> RefanyOrInt.ToRefany >> >> 3. If a small integer, can be extracted via RefanyOrInt.ToInt >> >> 4. Created either as a small integer or a REFANY >> >> Any other operations on it (including ISTYPE and TYPECASE, at least >> when the object is a small integer) would result in a checked runtime >> error. >> >> Note that with the declaration "RefanyOrInt.T = REFANY", the current >> compiler will as far as I know not accept any operations on >> RefanyOrInt.T outside of ISTYPE, TYPECASE, and NARROW (explicit or >> implicit). >> >> I wouldn't be surprised if most of what I'm proposing already works >> (i.e., crashes with a checked runtime error as it should) with the >> current runtime. Anything that slips through would need to be fixed >> up with a one-bit check of the LSB of the REFANY for the operations >> mentioned above. Unfortunately this has to be done for operations on >> every REFANY, not just the new type. >> >> I think that Modula-3 programmers are already aware that using >> REFANYs involves forcing the runtime to do extra type-checking work, >> so they already know not to use them if they are looking for maximum >> performance, so I don't think that burdening operations on REFANY >> with an extra one-bit check is too onerous. >> >> An advantage of my proposal is that the amount of code in the new >> proposed library is truly diminutive. In fact, I think I posted >> pretty much that code to the list a few weeks ago. >> >> (If you missed it, it's >> >> http://www.async.caltech.edu/~mika/interp/ >> >> ) >> >> Mika >> >> >> "Rodney M. Bates" writes: >>> I spent quite a bit of time playing with a more general system where >>> there is a set of "tagged" types, with (an implementation-defined >>> subrange of) INTEGER and a reference type both being a subtype of a >>> tagged type. It might have been tolerable, if it weren't for the >>> interaction with object subtypes and opaque types, which quickly >>> gets deep into a deep linguistic tar pit. >>> >>> Tony's approach is much simpler and would serve what I see as the >>> need. It does sacrifice any static checking of what reference type >>> is being tagged, and will also require an extra runtime ISTYPE/ >>> TYPECASE. >>> >>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>> also need to be an explicit conversion in that direction too, say >>> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >>> is a bit inconsistent with the usual Modula-3 assignability >>> philosophy, >>> but not requiring the explicit conversion already gets your toes >>> into tar. >>> >>> We would have to have something more like ISTYPE, though, which will >>> tell which type the value belongs to without risking a runtime error, >>> which VAL would do. >>> >>> An intermediate approach might be to have a set of tagged types >>> constructed by, say, TAGGED T, where I is a reference type, but >>> with no subtype relations on them at all, thus still requiring >>> the explicit conversions and checks. >>> >>> I do want to say, I _really_ want this capability somehow. I have >>> an ADT module whose internal data structure, for full generality, >>> needs to have two heap objects (the second because it has nonstatic >>> size) and 11 total words counting the orginal pointer, in the case of >>> values that would fit directly into the "pointer" word. Moreover, >>> these small cases are in the great majority. >>> >>> Besides the 11-to-one increase in actual occupied space, there >>> is extra time for allocation, periodic tracing, and collection, space >>> loss due to heap fragmentation, and time/space tradeoff loss due to >>> reduced locality of reference. So sometimes, it would be a big >>> performance gain if we could do it. >>> >>> >>> Tony Hosking wrote: >>> It is a much more pervasive hack than I would be comfortable with >>>> since it touches on the compiler (for all the type operations) as >>>> well >>>> as the run-time system in ways that are pretty gross. I would much >>>> rather have a new TAGGED builtin. ISTYPE would not work on it since >>>> that only works on references. The only thing you need is a way to >>>> extract the value -- we could overload VAL(x, T) where x can be a >>>> TAGGED and T can be REFANY or INTEGER. >>>> >>>> From hosking at cs.purdue.edu Tue Apr 7 03:00:46 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 11:00:46 +1000 Subject: [M3devel] Implementing the "Singleton pattern" in Modula-3 In-Reply-To: <200904062031.n36KVvC2094839@camembert.async.caltech.edu> References: <200904062031.n36KVvC2094839@camembert.async.caltech.edu> Message-ID: <110C0337-7E0A-4283-9F1C-BEBAF26929F8@cs.purdue.edu> I would exploit opaque types and branding. If T is opaque then you cannot instantiate T except in scopes where T's concrete type has been revealed or is known to be an object type. Thus, you could define an interface: GENERIC INTERFACE Singleton(Rep); TYPE T <: REFANY; VAR t: T; END Singleton. GENERIC MODULE Singleton(Rep); REVEAL T = BRANDED REF Rep.T; BEGIN t := NEW(T); END Singleton. where Rep defines the type T. You could do similar for object types. On 7 Apr 2009, at 06:31, Mika Nystrom wrote: > > Tony, Jay, you two seem to be most knowledgeable about this. > > Let's say I wanted to implement the "singleton pattern" in > Modula-3. At present there seems to be no way of doing this. > > What about changing RTAllocator.callback as follows (or adding > another callback): > > VAR callback : PROCEDURE(r : REFANY) : REFANY := NIL; > > (* If non-NIL, the allocator calls "callback(r)" just before returning > a new traced reference "r" and instead returns the result of > callback(r). > See "RTAllocStats" for an example client. It is a checked runtime > error > for the typecode of r to differ from the typecode of the return > value of > callback(r). *) > > Mika > > > From mika at async.caltech.edu Tue Apr 7 03:18:19 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 18:18:19 -0700 Subject: [M3devel] Implementing the "Singleton pattern" in Modula-3 In-Reply-To: Your message of "Tue, 07 Apr 2009 11:00:46 +1000." <110C0337-7E0A-4283-9F1C-BEBAF26929F8@cs.purdue.edu> Message-ID: <200904070118.n371IJQn002161@camembert.async.caltech.edu> Well I think the problem is with this "is known to be an object type"... You may in fact want to override the methods of the singleton, but ensure that only one ever gets instantiated. It's a minor problem, but it does sometimes bother me that it is difficult to prevent clients from NEWing pretty much anything they like. By the way, the "Modula-3 Type System" paper also talks about a nifty way to do narrowing very quickly (page 10, last paragraph). I remember this is occasionally problematic. (RTType.IsSubtype isn't great.) They speak of keeping an array of supertypes for each type, and recording the "depth" (distance from REFANY) of every type in, I guess, RT0.TypeDefn. This seems moderately space-efficient (better than a 2D array of all the typecodes), and very fast. Mika Tony Hosking writes: >I would exploit opaque types and branding. If T is opaque then you >cannot instantiate T except in scopes where T's concrete type has been >revealed or is known to be an object type. Thus, you could define an >interface: > >GENERIC INTERFACE Singleton(Rep); >TYPE T <: REFANY; >VAR t: T; >END Singleton. > >GENERIC MODULE Singleton(Rep); >REVEAL T = BRANDED REF Rep.T; >BEGIN > t := NEW(T); >END Singleton. > >where Rep defines the type T. You could do similar for object types. > > >On 7 Apr 2009, at 06:31, Mika Nystrom wrote: > >> >> Tony, Jay, you two seem to be most knowledgeable about this. >> >> Let's say I wanted to implement the "singleton pattern" in >> Modula-3. At present there seems to be no way of doing this. >> >> What about changing RTAllocator.callback as follows (or adding >> another callback): >> >> VAR callback : PROCEDURE(r : REFANY) : REFANY := NIL; >> >> (* If non-NIL, the allocator calls "callback(r)" just before returning >> a new traced reference "r" and instead returns the result of >> callback(r). >> See "RTAllocStats" for an example client. It is a checked runtime >> error >> for the typecode of r to differ from the typecode of the return >> value of >> callback(r). *) >> >> Mika >> >> >> From hosking at cs.purdue.edu Tue Apr 7 04:02:10 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 12:02:10 +1000 Subject: [M3devel] small objects In-Reply-To: <200904061529.n36FTTn0086974@camembert.async.caltech.edu> References: <200904061529.n36FTTn0086974@camembert.async.caltech.edu> Message-ID: <3F4FF36C-E96A-45F7-A345-4D557D424F52@cs.purdue.edu> On 7 Apr 2009, at 01:29, Mika Nystrom wrote: > Ah I should read my whole inbox before replying. As should I... ;-) > I take it you would worry that in my proposal (to do this all in a > library) the use of REFANY to store an integer could be abused > somehow. That the Modula-3 type system (as it exists now) explicitly > rules out doing such things, and therefore, a language change is > necessary.... My concern is the mismatch between NIL checking and tag-checking. I'd like to partition tagged references from regular references to keep things clean. I never liked overloading, especially for a systems language like Modula-3 where operations and typing should have a reasonable (and efficient) operational semantics. > > > Mika > > Tony Hosking writes: >> I like the notion of having a TAGGED INTEGER type that is a hybrid >> ordinal/reference. >> >> Subtyping rules for references would now be as follows: >> >> NULL <: REF T <: REFANY >> TAGGED INTEGER <: REF T <: REFANY >> >> ROOT <: REFANY >> NULL <: T OBJECT ... END <: T >> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: REFANY, >> not >> T <: ADDRESS) >> >> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >> type. Values of TAGGED INTEGER are non-pointer values similar to the >> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and NARROW(x, >> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to ISTYPE(x, >> NULL), NARROW(x, NULL), and TYPECODE(NULL). >> >> Because TAGGED INTEGER is an ordinal we can extract the integer value >> it holds using ORD(x). >> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >> INTEGER). >> >> ***The only problem with this scheme is how to efficiently perform >> run- >> time tests for dereferencing NULL, and TAGGED INTEGER?*** >> >> So, here is a slightly less elegant alternative that is probably >> straightforward to implement. Introduce a separate TAGGED hierarchy. >> >> NULL <: REF T <: REFANY >> NULL <: UNTRACED REF T <: ADDRESS >> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >> >> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >> >> ROOT <: REFANY >> TAGGED ROOT <: TAGGED REFANY >> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >> >> Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED >> REFANY. >> >> This way, tagged references only need a run-time test for the tag on >> dereference (we can throw an "attempt to dereference TAGGED INTEGER" >> at run time, just like we throw "attempt to dereference NIL" for >> untagged references). This check can be a straightforward test of >> the >> low bit tag. Of course, the weird thing here is now that we don't >> have a single NULL value for TAGGED references --- we have multiple >> null values VAL(x, TAGGED INTEGER). Instead of asking "x == NIL" we >> must ask "ISTYPE(x, TAGGED INTEGER)". >> >> Of course, because TAGGED INTEGER is an ordinal, we can also perform >> the usual ordinal operations like INC(x), DEC(x), wherever x is typed >> TAGGED INTEGER. >> >> >> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >> >>> I spent quite a bit of time playing with a more general system where >>> there is a set of "tagged" types, with (an implementation-defined >>> subrange of) INTEGER and a reference type both being a subtype of a >>> tagged type. It might have been tolerable, if it weren't for the >>> interaction with object subtypes and opaque types, which quickly >>> gets deep into a deep linguistic tar pit. >>> >>> Tony's approach is much simpler and would serve what I see as the >>> need. It does sacrifice any static checking of what reference type >>> is being tagged, and will also require an extra runtime ISTYPE/ >>> TYPECASE. >>> >>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>> also need to be an explicit conversion in that direction too, say >>> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >>> is a bit inconsistent with the usual Modula-3 assignability >>> philosophy, >>> but not requiring the explicit conversion already gets your toes >>> into tar. >>> >>> We would have to have something more like ISTYPE, though, which will >>> tell which type the value belongs to without risking a runtime >>> error, >>> which VAL would do. >>> >>> An intermediate approach might be to have a set of tagged types >>> constructed by, say, TAGGED T, where I is a reference type, but >>> with no subtype relations on them at all, thus still requiring >>> the explicit conversions and checks. >>> >>> I do want to say, I _really_ want this capability somehow. I have >>> an ADT module whose internal data structure, for full generality, >>> needs to have two heap objects (the second because it has nonstatic >>> size) and 11 total words counting the orginal pointer, in the case >>> of >>> values that would fit directly into the "pointer" word. Moreover, >>> these small cases are in the great majority. >>> >>> Besides the 11-to-one increase in actual occupied space, there >>> is extra time for allocation, periodic tracing, and collection, >>> space >>> loss due to heap fragmentation, and time/space tradeoff loss due to >>> reduced locality of reference. So sometimes, it would be a big >>> performance gain if we could do it. >>> >>> >>> Tony Hosking wrote: >>>> It is a much more pervasive hack than I would be comfortable with >>>> since it touches on the compiler (for all the type operations) as >>>> well >>>> as the run-time system in ways that are pretty gross. I would much >>>> rather have a new TAGGED builtin. ISTYPE would not work on it >>>> since >>>> that only works on references. The only thing you need is a way to >>>> extract the value -- we could overload VAL(x, T) where x can be a >>>> TAGGED and T can be REFANY or INTEGER. >>>> From hosking at cs.purdue.edu Tue Apr 7 04:03:35 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 12:03:35 +1000 Subject: [M3devel] small objects In-Reply-To: <200904062003.n36K3381094096@camembert.async.caltech.edu> References: <200904062003.n36K3381094096@camembert.async.caltech.edu> Message-ID: <92E0969B-63C7-43BE-A501-B78A5E520B55@cs.purdue.edu> On 7 Apr 2009, at 06:03, Mika Nystrom wrote: > "Rodney M. Bates" writes: >> At first, I just envisioned implementing a small object type >> entirely inside an UNSAFE module, using unsafe operations >> to construct/test/separate the values. I think if the GC were >> to just to ignore words in heap objects that the type system >> claims are unambiguously pointers but actually have misaligned >> values, this could be done. > > Right that's precisely what the module I posted does. > >> >> But it flies in the face of a fundamental principle of Modula-3, >> namely that an UNSAFE module, if coded correctly, can prevent >> all other code from consequences of the unsafety. Unfortunately, >> this can't be done with the small pointers, because, even if >> opaque, they are still reference types, and client code can >> dereference them (including the implicit dereference in accessing >> a method or field of an object) and do ISTYPE, NARROW, TYPECASE, >> and assignments that do an implicit NARROW. All these operations >> could be done outside the implementing module and all could >> suffer from misaligned values. > > Well yes that is true. But the client can't dereference REFANY. > Modula-3 doesn't permit that. That's an important practical point, > because now we're limited to the other things: ISTYPE, NARROW > (implicit and explicit), TYPECASE. (There are two more, actually, > and they are = and #.) As long as those can be guaranteed to fail > you're OK. [ Actually see my P.S. below! ] > >> >> In fact, misaligned integer "objects" violate another principle that >> the bit pattern must always be a valid representation of some value >> of the type. > > Yes I think maybe this is what Tony is worried about. But let's > just change the definition of REFANY to include anything with the > LSB set...? But then a "NULL" check needs to both test for zero and test for lsb set. I am not comfortable with this. > In Modula-3-ese it would be more like the following: > > "REFANY can hold three types of objects. NIL, REF something or an > implementation-defined other set of values that can only be accessed > in an UNSAFE module. It is a checked runtime error to pass a 'REFANY > of the third kind' to ISTYPE, NARROW, TYPECASE." [ Actually see my > P.S. below! ] > > Then I propose we punt the handling of the new REFANYs to this > unsafe module we spoke about above. As far as Modula-3 is concerned, > there's just a set of values of (apparently) very little utility > that can be represented by REFANY. If you think about it, this is > really not so crazy. Any module that uses REFANY today is designed > around to the fact that there are plenty of values of REFANY that > can be of no interest to that module except for passing along to > another module. (REFANY can easily represent a type which a module > has no way of accessing *any* declaration of beyond just REFANY.) > We're just adding some others, the only difference being that the > new values are of no interest to any non-UNSAFE module. (Eh, > technically this is already true for any reference type that is > declared in an UNSAFE module today so one might argue we have in > fact added nothing.) > >> >> However, this does suggest a different and very simple linguistic >> solution: Just have a new builtin type, say VERYOPAQUE, that >> supports no operations other than moving it around, i.e., >> assignment, bindings, passing as a parameter, etc. Only unsafe >> code could do anyhing with it, by using LOOPHOLE. The only >> problem is, would somebody then want one of these in a size other >> than one word? > > This is nice, and we already have a candidate type, in fact: ADDRESS. > But the problem is that the GC doesn't follow this even if the LSB > is clear... which we *do* want. > > Why are you worried about getting it in sizes other than one word? > That seems to me to be an application problem. If someone wants > an ARRAY OF VERYOPAQUE is that a problem? > > Mika > > P.S. Illustration of the above, in today's Modula-3: > > UNSAFE MODULE Unsafe; > > (* this module is just declared UNSAFE to conform with the definition > above, namely, that T can only be manipulated in an UNSAFE > module, which this is! *) > > TYPE T = BRANDED OBJECT END; > > BEGIN > Safe.P(NEW(T)) > END Unsafe. > > (****************************************) > > MODULE Safe; > > PROCEDURE P(r : REFANY) = > BEGIN > NARROW(r, X); (* checked runtime error for all X *) > > ISTYPE(r, X); (* returns FALSE for all X except REFANY itself *) > > TYPECASE r OF > X => (* only gets executed for X = REFANY *) > END; > END P; > > BEGIN END Safe. > > Actually is this behavior so bad for tagged integers? Since it is > the behavior of existing code... why not keep it? Then you can even > store a tagged integer in a RefList.T, say, even if that RefList.T > uses NARROW or ISTYPE on the argument (I don't see why it would, but > why not...?) > > > >> >> Mika Nystrom wrote: >>> Ah I should read my whole inbox before replying. >>> >>> I take it you would worry that in my proposal (to do this all in a >>> library) the use of REFANY to store an integer could be abused >>> somehow. That the Modula-3 type system (as it exists now) >>> explicitly >>> rules out doing such things, and therefore, a language change is >>> necessary.... >>> >>> Mika >>> >>> Tony Hosking writes: >>> >>>> I like the notion of having a TAGGED INTEGER type that is a hybrid >>>> ordinal/reference. >>>> >>>> Subtyping rules for references would now be as follows: >>>> >>>> NULL <: REF T <: REFANY >>>> TAGGED INTEGER <: REF T <: REFANY >>>> >>>> ROOT <: REFANY >>>> NULL <: T OBJECT ... END <: T >>>> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: >>>> REFANY, not >>>> T <: ADDRESS) >>>> >>>> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >>>> type. Values of TAGGED INTEGER are non-pointer values similar to >>>> the >>>> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and NARROW(x, >>>> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to >>>> ISTYPE(x, >>>> NULL), NARROW(x, NULL), and TYPECODE(NULL). >>>> >>>> Because TAGGED INTEGER is an ordinal we can extract the integer >>>> value >>>> it holds using ORD(x). >>>> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >>>> INTEGER). >>>> >>>> ***The only problem with this scheme is how to efficiently >>>> perform run- >>>> time tests for dereferencing NULL, and TAGGED INTEGER?*** >>> >>>> So, here is a slightly less elegant alternative that is probably >>>> straightforward to implement. Introduce a separate TAGGED >>>> hierarchy. >>>> >>>> NULL <: REF T <: REFANY >>>> NULL <: UNTRACED REF T <: ADDRESS >>>> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >>>> >>>> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >>>> >>>> ROOT <: REFANY >>>> TAGGED ROOT <: TAGGED REFANY >>>> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >>>> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >>>> >>>> Note that NULL is not a subtype of T OBJECT ... END where T <: >>>> TAGGED >>>> REFANY. >>>> >>>> This way, tagged references only need a run-time test for the tag >>>> on >>>> dereference (we can throw an "attempt to dereference TAGGED >>>> INTEGER" >>>> at run time, just like we throw "attempt to dereference NIL" for >>>> untagged references). This check can be a straightforward test >>>> of the >>>> low bit tag. Of course, the weird thing here is now that we don't >>>> have a single NULL value for TAGGED references --- we have multiple >>>> null values VAL(x, TAGGED INTEGER). Instead of asking "x == NIL" >>>> we >>>> must ask "ISTYPE(x, TAGGED INTEGER)". >>>> >>>> Of course, because TAGGED INTEGER is an ordinal, we can also >>>> perform >>>> the usual ordinal operations like INC(x), DEC(x), wherever x is >>>> typed >>>> TAGGED INTEGER. >>>> >>>> >>>> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >>>> >>>> >>>>> I spent quite a bit of time playing with a more general system >>>>> where >>>>> there is a set of "tagged" types, with (an implementation-defined >>>>> subrange of) INTEGER and a reference type both being a subtype >>>>> of a >>>>> tagged type. It might have been tolerable, if it weren't for the >>>>> interaction with object subtypes and opaque types, which quickly >>>>> gets deep into a deep linguistic tar pit. >>>>> >>>>> Tony's approach is much simpler and would serve what I see as the >>>>> need. It does sacrifice any static checking of what reference >>>>> type >>>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>>> TYPECASE. >>>>> >>>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>>> also need to be an explicit conversion in that direction too, say >>>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >>>>> is a bit inconsistent with the usual Modula-3 assignability >>>>> philosophy, >>>>> but not requiring the explicit conversion already gets your toes >>>>> into tar. >>>>> >>>>> We would have to have something more like ISTYPE, though, which >>>>> will >>>>> tell which type the value belongs to without risking a runtime >>>>> error, >>>>> which VAL would do. >>>>> >>>>> An intermediate approach might be to have a set of tagged types >>>>> constructed by, say, TAGGED T, where I is a reference type, but >>>>> with no subtype relations on them at all, thus still requiring >>>>> the explicit conversions and checks. >>>>> >>>>> I do want to say, I _really_ want this capability somehow. I have >>>>> an ADT module whose internal data structure, for full generality, >>>>> needs to have two heap objects (the second because it has >>>>> nonstatic >>>>> size) and 11 total words counting the orginal pointer, in the >>>>> case of >>>>> values that would fit directly into the "pointer" word. >>>>> Moreover, >>>>> these small cases are in the great majority. >>>>> >>>>> Besides the 11-to-one increase in actual occupied space, there >>>>> is extra time for allocation, periodic tracing, and collection, >>>>> space >>>>> loss due to heap fragmentation, and time/space tradeoff loss due >>>>> to >>>>> reduced locality of reference. So sometimes, it would be a big >>>>> performance gain if we could do it. >>>>> >>>>> >>>>> Tony Hosking wrote: >>>>> >>>>>> It is a much more pervasive hack than I would be comfortable with >>>>>> since it touches on the compiler (for all the type operations) as >>>>>> well >>>>>> as the run-time system in ways that are pretty gross. I would >>>>>> much >>>>>> rather have a new TAGGED builtin. ISTYPE would not work on it >>>>>> since >>>>>> that only works on references. The only thing you need is a >>>>>> way to >>>>>> extract the value -- we could overload VAL(x, T) where x can be a >>>>>> TAGGED and T can be REFANY or INTEGER. >>>>>> >>>>>> >>> >>> From hosking at cs.purdue.edu Tue Apr 7 04:04:51 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 12:04:51 +1000 Subject: [M3devel] small objects In-Reply-To: <200904062017.n36KHbcq094473@camembert.async.caltech.edu> References: <200904062017.n36KHbcq094473@camembert.async.caltech.edu> Message-ID: <06AB3448-B400-4D98-8283-399355263471@cs.purdue.edu> I still don't understand the objections to my proposal. I think it is a similarly small change that does not pollute the old REFANY hierarchy. On 7 Apr 2009, at 06:17, Mika Nystrom wrote: > Ok I admit I missed something important. > > TYPECODE. > > It's easy enough to allocate a special TYPECODE to the tagged > integer. One not used by any "real" type of course. > > It will break pickles and fingerprints. Pickles can be fixed, > check the typecode and call a routine in the TaggedInteger > interface (by default, user can override it?) to translate > to and fro. > > But what about fingerprints? Again I guess we can just > return the fingerprint of a nonexistent > type............................. > > Hummm humm. > > Ok, how about this... > > let's declare a completely hidden type ... > > UNSAFE MODULE TaggedInteger; > > TYPE T = BRANDED OBJECT x : INTEGER END; > > BEGIN END TaggedInteger. > > Now, fix up TYPECODE, ISTYPE, NARROW, TYPECASE so that they all > act *precisely* as if TaggedInteger.T were passed to them, > when they see a REFANY with the LSB set. fingerprinting the > type will give you the fingerprint of TaggedInteger.T. (But > you better not rely on that! Only UNSAFE modules can do anything > with this information, anyhow, so who cares, but see below.) > > I don't see how this breaks anything at all once we introduce the > 'REFANY of the third kind', which is so small a change to the > language's type system that I'm not sure it even qualifies as a > change. Pickles are already unsafe, so the fact that the current > pickles package would subvert the type system based on what I propose > is a non-issue (language wise), it just means a few extra lines of > code in the pickles package. > > The reason for the x : field above is that I propose that this > be how the tagged integer be un/pickled, as an instance of an > object of the (actual) type TaggedInteger.T. > > Mika > > > > > Mika Nystrom writes: >> "Rodney M. Bates" writes: >>> At first, I just envisioned implementing a small object type >>> entirely inside an UNSAFE module, using unsafe operations >>> to construct/test/separate the values. I think if the GC were >>> to just to ignore words in heap objects that the type system >>> claims are unambiguously pointers but actually have misaligned >>> values, this could be done. >> >> Right that's precisely what the module I posted does. >> >>> >>> But it flies in the face of a fundamental principle of Modula-3, >>> namely that an UNSAFE module, if coded correctly, can prevent >>> all other code from consequences of the unsafety. Unfortunately, >>> this can't be done with the small pointers, because, even if >>> opaque, they are still reference types, and client code can >>> dereference them (including the implicit dereference in accessing >>> a method or field of an object) and do ISTYPE, NARROW, TYPECASE, >>> and assignments that do an implicit NARROW. All these operations >>> could be done outside the implementing module and all could >>> suffer from misaligned values. >> >> Well yes that is true. But the client can't dereference REFANY. >> Modula-3 doesn't permit that. That's an important practical point, >> because now we're limited to the other things: ISTYPE, NARROW >> (implicit and explicit), TYPECASE. (There are two more, actually, >> and they are = and #.) As long as those can be guaranteed to fail >> you're OK. [ Actually see my P.S. below! ] >> >>> >>> In fact, misaligned integer "objects" violate another principle >>> that >>> the bit pattern must always be a valid representation of some value >>> of the type. >> >> Yes I think maybe this is what Tony is worried about. But let's >> just change the definition of REFANY to include anything with the >> LSB set...? >> >> In Modula-3-ese it would be more like the following: >> >> "REFANY can hold three types of objects. NIL, REF something or an >> implementation-defined other set of values that can only be accessed >> in an UNSAFE module. It is a checked runtime error to pass a 'REFANY >> of the third kind' to ISTYPE, NARROW, TYPECASE." [ Actually see my >> P.S. below! ] >> >> Then I propose we punt the handling of the new REFANYs to this >> unsafe module we spoke about above. As far as Modula-3 is concerned, >> there's just a set of values of (apparently) very little utility >> that can be represented by REFANY. If you think about it, this is >> really not so crazy. Any module that uses REFANY today is designed >> around to the fact that there are plenty of values of REFANY that >> can be of no interest to that module except for passing along to >> another module. (REFANY can easily represent a type which a module >> has no way of accessing *any* declaration of beyond just REFANY.) >> We're just adding some others, the only difference being that the >> new values are of no interest to any non-UNSAFE module. (Eh, >> technically this is already true for any reference type that is >> declared in an UNSAFE module today so one might argue we have in >> fact added nothing.) >> >>> >>> However, this does suggest a different and very simple linguistic >>> solution: Just have a new builtin type, say VERYOPAQUE, that >>> supports no operations other than moving it around, i.e., >>> assignment, bindings, passing as a parameter, etc. Only unsafe >>> code could do anyhing with it, by using LOOPHOLE. The only >>> problem is, would somebody then want one of these in a size other >>> than one word? >> >> This is nice, and we already have a candidate type, in fact: ADDRESS. >> But the problem is that the GC doesn't follow this even if the LSB >> is clear... which we *do* want. >> >> Why are you worried about getting it in sizes other than one word? >> That seems to me to be an application problem. If someone wants >> an ARRAY OF VERYOPAQUE is that a problem? >> >> Mika >> >> P.S. Illustration of the above, in today's Modula-3: >> >> UNSAFE MODULE Unsafe; >> >> (* this module is just declared UNSAFE to conform with the definition >> above, namely, that T can only be manipulated in an UNSAFE >> module, which this is! *) >> >> TYPE T = BRANDED OBJECT END; >> >> BEGIN >> Safe.P(NEW(T)) >> END Unsafe. >> >> (****************************************) >> >> MODULE Safe; >> >> PROCEDURE P(r : REFANY) = >> BEGIN >> NARROW(r, X); (* checked runtime error for all X *) >> >> ISTYPE(r, X); (* returns FALSE for all X except REFANY itself *) >> >> TYPECASE r OF >> X => (* only gets executed for X = REFANY *) >> END; >> END P; >> >> BEGIN END Safe. >> >> Actually is this behavior so bad for tagged integers? Since it is >> the behavior of existing code... why not keep it? Then you can even >> store a tagged integer in a RefList.T, say, even if that RefList.T >> uses NARROW or ISTYPE on the argument (I don't see why it would, but >> why not...?) >> >> >> >>> >>> Mika Nystrom wrote: >>>> Ah I should read my whole inbox before replying. >>>> >>>> I take it you would worry that in my proposal (to do this all in a >>>> library) the use of REFANY to store an integer could be abused >>>> somehow. That the Modula-3 type system (as it exists now) >>>> explicitly >>>> rules out doing such things, and therefore, a language change is >>>> necessary.... >>>> >>>> Mika >>>> >>>> Tony Hosking writes: >>>> >>>>> I like the notion of having a TAGGED INTEGER type that is a hybrid >>>>> ordinal/reference. >>>>> >>>>> Subtyping rules for references would now be as follows: >>>>> >>>>> NULL <: REF T <: REFANY >>>>> TAGGED INTEGER <: REF T <: REFANY >>>>> >>>>> ROOT <: REFANY >>>>> NULL <: T OBJECT ... END <: T >>>>> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: >>>>> REFANY, not >>>>> T <: ADDRESS) >>>>> >>>>> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >>>>> type. Values of TAGGED INTEGER are non-pointer values similar >>>>> to the >>>>> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and >>>>> NARROW(x, >>>>> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to >>>>> ISTYPE(x, >>>>> NULL), NARROW(x, NULL), and TYPECODE(NULL). >>>>> >>>>> Because TAGGED INTEGER is an ordinal we can extract the integer >>>>> value >>>>> it holds using ORD(x). >>>>> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >>>>> INTEGER). >>>>> >>>>> ***The only problem with this scheme is how to efficiently >>>>> perform run- >>>>> time tests for dereferencing NULL, and TAGGED INTEGER?*** >>>> >>>>> So, here is a slightly less elegant alternative that is probably >>>>> straightforward to implement. Introduce a separate TAGGED >>>>> hierarchy. >>>>> >>>>> NULL <: REF T <: REFANY >>>>> NULL <: UNTRACED REF T <: ADDRESS >>>>> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >>>>> >>>>> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >>>>> >>>>> ROOT <: REFANY >>>>> TAGGED ROOT <: TAGGED REFANY >>>>> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >>>>> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >>>>> >>>>> Note that NULL is not a subtype of T OBJECT ... END where T <: >>>>> TAGGED >>>>> REFANY. >>>>> >>>>> This way, tagged references only need a run-time test for the >>>>> tag on >>>>> dereference (we can throw an "attempt to dereference TAGGED >>>>> INTEGER" >>>>> at run time, just like we throw "attempt to dereference NIL" for >>>>> untagged references). This check can be a straightforward test >>>>> of the >>>>> low bit tag. Of course, the weird thing here is now that we don't >>>>> have a single NULL value for TAGGED references --- we have >>>>> multiple >>>>> null values VAL(x, TAGGED INTEGER). Instead of asking "x == >>>>> NIL" we >>>>> must ask "ISTYPE(x, TAGGED INTEGER)". >>>>> >>>>> Of course, because TAGGED INTEGER is an ordinal, we can also >>>>> perform >>>>> the usual ordinal operations like INC(x), DEC(x), wherever x is >>>>> typed >>>>> TAGGED INTEGER. >>>>> >>>>> >>>>> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >>>>> >>>>> >>>>>> I spent quite a bit of time playing with a more general system >>>>>> where >>>>>> there is a set of "tagged" types, with (an implementation-defined >>>>>> subrange of) INTEGER and a reference type both being a subtype >>>>>> of a >>>>>> tagged type. It might have been tolerable, if it weren't for the >>>>>> interaction with object subtypes and opaque types, which quickly >>>>>> gets deep into a deep linguistic tar pit. >>>>>> >>>>>> Tony's approach is much simpler and would serve what I see as the >>>>>> need. It does sacrifice any static checking of what reference >>>>>> type >>>>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>>>> TYPECASE. >>>>>> >>>>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>>>> also need to be an explicit conversion in that direction too, say >>>>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. >>>>>> It >>>>>> is a bit inconsistent with the usual Modula-3 assignability >>>>>> philosophy, >>>>>> but not requiring the explicit conversion already gets your toes >>>>>> into tar. >>>>>> >>>>>> We would have to have something more like ISTYPE, though, which >>>>>> will >>>>>> tell which type the value belongs to without risking a runtime >>>>>> error, >>>>>> which VAL would do. >>>>>> >>>>>> An intermediate approach might be to have a set of tagged types >>>>>> constructed by, say, TAGGED T, where I is a reference type, but >>>>>> with no subtype relations on them at all, thus still requiring >>>>>> the explicit conversions and checks. >>>>>> >>>>>> I do want to say, I _really_ want this capability somehow. I >>>>>> have >>>>>> an ADT module whose internal data structure, for full generality, >>>>>> needs to have two heap objects (the second because it has >>>>>> nonstatic >>>>>> size) and 11 total words counting the orginal pointer, in the >>>>>> case of >>>>>> values that would fit directly into the "pointer" word. >>>>>> Moreover, >>>>>> these small cases are in the great majority. >>>>>> >>>>>> Besides the 11-to-one increase in actual occupied space, there >>>>>> is extra time for allocation, periodic tracing, and collection, >>>>>> space >>>>>> loss due to heap fragmentation, and time/space tradeoff loss >>>>>> due to >>>>>> reduced locality of reference. So sometimes, it would be a big >>>>>> performance gain if we could do it. >>>>>> >>>>>> >>>>>> Tony Hosking wrote: >>>>>> >>>>>>> It is a much more pervasive hack than I would be comfortable >>>>>>> with >>>>>>> since it touches on the compiler (for all the type operations) >>>>>>> as >>>>>>> well >>>>>>> as the run-time system in ways that are pretty gross. I would >>>>>>> much >>>>>>> rather have a new TAGGED builtin. ISTYPE would not work on it >>>>>>> since >>>>>>> that only works on references. The only thing you need is a >>>>>>> way to >>>>>>> extract the value -- we could overload VAL(x, T) where x can >>>>>>> be a >>>>>>> TAGGED and T can be REFANY or INTEGER. >>>>>>> >>>>>>> >>>> >>>> From hosking at cs.purdue.edu Tue Apr 7 04:07:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 12:07:19 +1000 Subject: [M3devel] Implementing the "Singleton pattern" in Modula-3 In-Reply-To: <200904070118.n371IJQn002161@camembert.async.caltech.edu> References: <200904070118.n371IJQn002161@camembert.async.caltech.edu> Message-ID: On 7 Apr 2009, at 11:18, Mika Nystrom wrote: > Well I think the problem is with this "is known to be an object > type"... But if the opaque type T is T<:REFANY and the only revelation is branded and private to a module (not exported by its interfaces) then no-one can determine that it is an object type without forging the BRAND. > You may in fact want to override the methods of the singleton, but > ensure that only one ever gets instantiated. > > It's a minor problem, but it does sometimes bother me that it is > difficult to prevent clients from NEWing pretty much anything they > like. > > By the way, the "Modula-3 Type System" paper also talks about a > nifty way to do narrowing very quickly (page 10, last paragraph). > I remember this is occasionally problematic. (RTType.IsSubtype > isn't great.) They speak of keeping an array of supertypes > for each type, and recording the "depth" (distance from REFANY) > of every type in, I guess, RT0.TypeDefn. This seems moderately > space-efficient (better than a 2D array of all the typecodes), > and very fast. > > Mika > > Tony Hosking writes: >> I would exploit opaque types and branding. If T is opaque then you >> cannot instantiate T except in scopes where T's concrete type has >> been >> revealed or is known to be an object type. Thus, you could define an >> interface: >> >> GENERIC INTERFACE Singleton(Rep); >> TYPE T <: REFANY; >> VAR t: T; >> END Singleton. >> >> GENERIC MODULE Singleton(Rep); >> REVEAL T = BRANDED REF Rep.T; >> BEGIN >> t := NEW(T); >> END Singleton. >> >> where Rep defines the type T. You could do similar for object types. >> >> >> On 7 Apr 2009, at 06:31, Mika Nystrom wrote: >> >>> >>> Tony, Jay, you two seem to be most knowledgeable about this. >>> >>> Let's say I wanted to implement the "singleton pattern" in >>> Modula-3. At present there seems to be no way of doing this. >>> >>> What about changing RTAllocator.callback as follows (or adding >>> another callback): >>> >>> VAR callback : PROCEDURE(r : REFANY) : REFANY := NIL; >>> >>> (* If non-NIL, the allocator calls "callback(r)" just before >>> returning >>> a new traced reference "r" and instead returns the result of >>> callback(r). >>> See "RTAllocStats" for an example client. It is a checked runtime >>> error >>> for the typecode of r to differ from the typecode of the return >>> value of >>> callback(r). *) >>> >>> Mika >>> >>> >>> From hosking at cs.purdue.edu Tue Apr 7 04:16:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 12:16:29 +1000 Subject: [M3devel] small objects In-Reply-To: <200904070042.n370gNK3001242@camembert.async.caltech.edu> References: <200904070042.n370gNK3001242@camembert.async.caltech.edu> Message-ID: <9F2237E2-73A2-4926-A438-A6032F70B4F6@cs.purdue.edu> On 7 Apr 2009, at 10:42, Mika Nystrom wrote: > You mean this proposal (you had two, I think)? Yes, this is the proposal I converged on. It really is only minimal change to the type system: introduction of a third hierarchy of TAGGED reference types. I did something similar for orthogonal persistence a few years ago where it was useful to have a TRANSIENT reference hierarchy for things that should not persist. [The semantics was that every run of a program would initialize TRANSIENT references to NIL rather than have them have the persistent value. This was slightly messier in that I also permitted TRANSIENT REFANY <: REFANY, which was a little odd.] > -- > > NULL <: REF T <: REFANY > NULL <: UNTRACED REF T <: ADDRESS > TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY > > Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. > > ROOT <: REFANY > TAGGED ROOT <: TAGGED REFANY > NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS > TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY > > Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED > REFANY. > > --- > > I like it fine, I think... I'm just worried, generally, about > changing the type system. Hmmmm... you mean that the TAGGED > things would just be a separate hierarchy? The change is relatively minor in that it doesn't touch the original REFANY hierarchy. > So you'd just add TAGGED in front of the REFs for this new hierarchy. > But why no NULL? No NULL because then we need a test for both NIL and values of type TAGGED INTEGER on every dereference. You can easily declare: TYPE Null = TAGGED INTEGER; CONST Nil = VAL(0, TAGGED INTEGER); The point is that TAGGED INTEGER now lets you have a range of non- pointer reference values, whereas NIL is the singleton non-reference value in type NULL. > And you're comfortable with doing the conversions automatically? No, I said that the conversions needed to be explicit > > So > > tx : TAGGED INTEGER := 5; tx: TAGGED INTEGER := VAL(5,TAGGED INTEGER); > x : INTEGER := tx; x: INTEGER := ORD(tx); > would be OK? > > In that case it's just the m3tk that needs to be modified, and > that's just busy work, I think. If it works it's beautiful... As I said, I am almost done with the compiler changes, and only need to push it into the run-time. Things like m3tk and pickles will need to be smartened up as necessary. > > > Mika > > > > Tony Hosking writes: >> I really don't like your proposal for the reasons you mention. It >> makes regular REF more expensive than it currently is. What is it >> about my relatively minor changes to the type system that you object >> to? I've just about finished changing the compiler front-end (in >> relatively minor ways) to accomodate the proposal I made yesterday. >> And it has the advantage of separating REF from TAGGED REF so we keep >> the standard REF clean. >> >> On 7 Apr 2009, at 00:50, Mika Nystrom wrote: >> >>> Hi Rodney, >>> >>> I would like this capability too, but I am a bit wary of Tony's >>> idea of changing the Modula-3 language---even in a "minor" way. >>> I've been working for the last week or so on an application using >>> the Modula-3 Toolkit, and I must say I have realized that the >> Modula-3 type system has a lot more subtleties than I thought. I >>> would not want to make any real changes to it. There's a paper >>> called "The Modula-3 Type System" by Cardelli, Donahue, Kalsow, and >>> Nelson that is worth studying in detail before making any changes >>> whatsoever, I think. Also remember that changes to the type system >>> will affect m3tk and anything that depends on m3tk (which includes >>> two or three stub generators in the main tree and who knows how >>> many dependencies outside of it). >>> >>> I'm still not sure why we can't take the approach of Word.T . >>> Make a RefanyOrInt.T that can safely be: >>> >>> 1. Tested whether it is a small integer or a REFANY >>> >>> 2. If a REFANY, be dereferenced as normal, *or* via >>> RefanyOrInt.ToRefany >>> >>> 3. If a small integer, can be extracted via RefanyOrInt.ToInt >>> >>> 4. Created either as a small integer or a REFANY >>> >>> Any other operations on it (including ISTYPE and TYPECASE, at least >>> when the object is a small integer) would result in a checked >>> runtime >>> error. >>> >>> Note that with the declaration "RefanyOrInt.T = REFANY", the current >>> compiler will as far as I know not accept any operations on >>> RefanyOrInt.T outside of ISTYPE, TYPECASE, and NARROW (explicit or >>> implicit). >>> >>> I wouldn't be surprised if most of what I'm proposing already works >>> (i.e., crashes with a checked runtime error as it should) with the >>> current runtime. Anything that slips through would need to be fixed >>> up with a one-bit check of the LSB of the REFANY for the operations >>> mentioned above. Unfortunately this has to be done for operations >>> on >>> every REFANY, not just the new type. >>> >>> I think that Modula-3 programmers are already aware that using >>> REFANYs involves forcing the runtime to do extra type-checking work, >>> so they already know not to use them if they are looking for maximum >>> performance, so I don't think that burdening operations on REFANY >>> with an extra one-bit check is too onerous. >>> >>> An advantage of my proposal is that the amount of code in the new >>> proposed library is truly diminutive. In fact, I think I posted >>> pretty much that code to the list a few weeks ago. >>> >>> (If you missed it, it's >>> >>> http://www.async.caltech.edu/~mika/interp/ >>> >>> ) >>> >>> Mika >>> >>> >>> "Rodney M. Bates" writes: >>>> I spent quite a bit of time playing with a more general system >>>> where >>>> there is a set of "tagged" types, with (an implementation-defined >>>> subrange of) INTEGER and a reference type both being a subtype of a >>>> tagged type. It might have been tolerable, if it weren't for the >>>> interaction with object subtypes and opaque types, which quickly >>>> gets deep into a deep linguistic tar pit. >>>> >>>> Tony's approach is much simpler and would serve what I see as the >>>> need. It does sacrifice any static checking of what reference type >>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>> TYPECASE. >>>> >>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>> also need to be an explicit conversion in that direction too, say >>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >>>> is a bit inconsistent with the usual Modula-3 assignability >>>> philosophy, >>>> but not requiring the explicit conversion already gets your toes >>>> into tar. >>>> >>>> We would have to have something more like ISTYPE, though, which >>>> will >>>> tell which type the value belongs to without risking a runtime >>>> error, >>>> which VAL would do. >>>> >>>> An intermediate approach might be to have a set of tagged types >>>> constructed by, say, TAGGED T, where I is a reference type, but >>>> with no subtype relations on them at all, thus still requiring >>>> the explicit conversions and checks. >>>> >>>> I do want to say, I _really_ want this capability somehow. I have >>>> an ADT module whose internal data structure, for full generality, >>>> needs to have two heap objects (the second because it has nonstatic >>>> size) and 11 total words counting the orginal pointer, in the >>>> case of >>>> values that would fit directly into the "pointer" word. Moreover, >>>> these small cases are in the great majority. >>>> >>>> Besides the 11-to-one increase in actual occupied space, there >>>> is extra time for allocation, periodic tracing, and collection, >>>> space >>>> loss due to heap fragmentation, and time/space tradeoff loss due to >>>> reduced locality of reference. So sometimes, it would be a big >>>> performance gain if we could do it. >>>> >>>> >>>> Tony Hosking wrote: >>>> It is a much more pervasive hack than I would be comfortable with >>>>> since it touches on the compiler (for all the type operations) as >>>>> well >>>>> as the run-time system in ways that are pretty gross. I would >>>>> much >>>>> rather have a new TAGGED builtin. ISTYPE would not work on it >>>>> since >>>>> that only works on references. The only thing you need is a way >>>>> to >>>>> extract the value -- we could overload VAL(x, T) where x can be a >>>>> TAGGED and T can be REFANY or INTEGER. >>>>> >>>>> From rcoleburn at scires.com Tue Apr 7 04:27:42 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 06 Apr 2009 22:27:42 -0400 Subject: [M3devel] small objects In-Reply-To: <9F2237E2-73A2-4926-A438-A6032F70B4F6@cs.purdue.edu> References: <200904070042.n370gNK3001242@camembert.async.caltech.edu> <9F2237E2-73A2-4926-A438-A6032F70B4F6@cs.purdue.edu> Message-ID: <49DA8196.1E75.00D7.1@scires.com> Hey, will this proposal mean that packages like "stable" and "stubgen" need to be changed also, in addition to both versions of pickles? What about any package that deals with parsing of M3 code, e.g. pretty-printers, CM3IDE, etc.? Regards, Randy >>> Tony Hosking 4/6/2009 10:16 PM >>> On 7 Apr 2009, at 10:42, Mika Nystrom wrote: > You mean this proposal (you had two, I think)? Yes, this is the proposal I converged on. It really is only minimal change to the type system: introduction of a third hierarchy of TAGGED reference types. I did something similar for orthogonal persistence a few years ago where it was useful to have a TRANSIENT reference hierarchy for things that should not persist. [The semantics was that every run of a program would initialize TRANSIENT references to NIL rather than have them have the persistent value. This was slightly messier in that I also permitted TRANSIENT REFANY <: REFANY, which was a little odd.] > -- > > NULL <: REF T <: REFANY > NULL <: UNTRACED REF T <: ADDRESS > TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY > > Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. > > ROOT <: REFANY > TAGGED ROOT <: TAGGED REFANY > NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS > TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY > > Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED > REFANY. > > --- > > I like it fine, I think... I'm just worried, generally, about > changing the type system. Hmmmm... you mean that the TAGGED > things would just be a separate hierarchy? The change is relatively minor in that it doesn't touch the original REFANY hierarchy. > So you'd just add TAGGED in front of the REFs for this new hierarchy. > But why no NULL? No NULL because then we need a test for both NIL and values of type TAGGED INTEGER on every dereference. You can easily declare: TYPE Null = TAGGED INTEGER; CONST Nil = VAL(0, TAGGED INTEGER); The point is that TAGGED INTEGER now lets you have a range of non- pointer reference values, whereas NIL is the singleton non-reference value in type NULL. > And you're comfortable with doing the conversions automatically? No, I said that the conversions needed to be explicit > > So > > tx : TAGGED INTEGER := 5; tx: TAGGED INTEGER := VAL(5,TAGGED INTEGER); > x : INTEGER := tx; x: INTEGER := ORD(tx); > would be OK? > > In that case it's just the m3tk that needs to be modified, and > that's just busy work, I think. If it works it's beautiful... As I said, I am almost done with the compiler changes, and only need to push it into the run-time. Things like m3tk and pickles will need to be smartened up as necessary. > > > Mika > > > > Tony Hosking writes: >> I really don't like your proposal for the reasons you mention. It >> makes regular REF more expensive than it currently is. What is it >> about my relatively minor changes to the type system that you object >> to? I've just about finished changing the compiler front-end (in >> relatively minor ways) to accomodate the proposal I made yesterday. >> And it has the advantage of separating REF from TAGGED REF so we keep >> the standard REF clean. >> >> On 7 Apr 2009, at 00:50, Mika Nystrom wrote: >> >>> Hi Rodney, >>> >>> I would like this capability too, but I am a bit wary of Tony's >>> idea of changing the Modula-3 language---even in a "minor" way. >>> I've been working for the last week or so on an application using >>> the Modula-3 Toolkit, and I must say I have realized that the >> Modula-3 type system has a lot more subtleties than I thought. I >>> would not want to make any real changes to it. There's a paper >>> called "The Modula-3 Type System" by Cardelli, Donahue, Kalsow, and >>> Nelson that is worth studying in detail before making any changes >>> whatsoever, I think. Also remember that changes to the type system >>> will affect m3tk and anything that depends on m3tk (which includes >>> two or three stub generators in the main tree and who knows how >>> many dependencies outside of it). >>> >>> I'm still not sure why we can't take the approach of Word.T . >>> Make a RefanyOrInt.T that can safely be: >>> >>> 1. Tested whether it is a small integer or a REFANY >>> >>> 2. If a REFANY, be dereferenced as normal, *or* via >>> RefanyOrInt.ToRefany >>> >>> 3. If a small integer, can be extracted via RefanyOrInt.ToInt >>> >>> 4. Created either as a small integer or a REFANY >>> >>> Any other operations on it (including ISTYPE and TYPECASE, at least >>> when the object is a small integer) would result in a checked >>> runtime >>> error. >>> >>> Note that with the declaration "RefanyOrInt.T = REFANY", the current >>> compiler will as far as I know not accept any operations on >>> RefanyOrInt.T outside of ISTYPE, TYPECASE, and NARROW (explicit or >>> implicit). >>> >>> I wouldn't be surprised if most of what I'm proposing already works >>> (i.e., crashes with a checked runtime error as it should) with the >>> current runtime. Anything that slips through would need to be fixed >>> up with a one-bit check of the LSB of the REFANY for the operations >>> mentioned above. Unfortunately this has to be done for operations >>> on >>> every REFANY, not just the new type. >>> >>> I think that Modula-3 programmers are already aware that using >>> REFANYs involves forcing the runtime to do extra type-checking work, >>> so they already know not to use them if they are looking for maximum >>> performance, so I don't think that burdening operations on REFANY >>> with an extra one-bit check is too onerous. >>> >>> An advantage of my proposal is that the amount of code in the new >>> proposed library is truly diminutive. In fact, I think I posted >>> pretty much that code to the list a few weeks ago. >>> >>> (If you missed it, it's >>> >>> http://www.async.caltech.edu/~mika/interp/ >>> >>> ) >>> >>> Mika >>> >>> >>> "Rodney M. Bates" writes: >>>> I spent quite a bit of time playing with a more general system >>>> where >>>> there is a set of "tagged" types, with (an implementation-defined >>>> subrange of) INTEGER and a reference type both being a subtype of a >>>> tagged type. It might have been tolerable, if it weren't for the >>>> interaction with object subtypes and opaque types, which quickly >>>> gets deep into a deep linguistic tar pit. >>>> >>>> Tony's approach is much simpler and would serve what I see as the >>>> need. It does sacrifice any static checking of what reference type >>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>> TYPECASE. >>>> >>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>> also need to be an explicit conversion in that direction too, say >>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >>>> is a bit inconsistent with the usual Modula-3 assignability >>>> philosophy, >>>> but not requiring the explicit conversion already gets your toes >>>> into tar. >>>> >>>> We would have to have something more like ISTYPE, though, which >>>> will >>>> tell which type the value belongs to without risking a runtime >>>> error, >>>> which VAL would do. >>>> >>>> An intermediate approach might be to have a set of tagged types >>>> constructed by, say, TAGGED T, where I is a reference type, but >>>> with no subtype relations on them at all, thus still requiring >>>> the explicit conversions and checks. >>>> >>>> I do want to say, I _really_ want this capability somehow. I have >>>> an ADT module whose internal data structure, for full generality, >>>> needs to have two heap objects (the second because it has nonstatic >>>> size) and 11 total words counting the orginal pointer, in the >>>> case of >>>> values that would fit directly into the "pointer" word. Moreover, >>>> these small cases are in the great majority. >>>> >>>> Besides the 11-to-one increase in actual occupied space, there >>>> is extra time for allocation, periodic tracing, and collection, >>>> space >>>> loss due to heap fragmentation, and time/space tradeoff loss due to >>>> reduced locality of reference. So sometimes, it would be a big >>>> performance gain if we could do it. >>>> >>>> >>>> Tony Hosking wrote: >>>> It is a much more pervasive hack than I would be comfortable with >>>>> since it touches on the compiler (for all the type operations) as >>>>> well >>>>> as the run-time system in ways that are pretty gross. I would >>>>> much >>>>> rather have a new TAGGED builtin. ISTYPE would not work on it >>>>> since >>>>> that only works on references. The only thing you need is a way >>>>> to >>>>> extract the value -- we could overload VAL(x, T) where x can be a >>>>> TAGGED and T can be REFANY or INTEGER. >>>>> >>>>> 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 Tue Apr 7 04:52:59 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 12:52:59 +1000 Subject: [M3devel] small objects In-Reply-To: <49DA8196.1E75.00D7.1@scires.com> References: <200904070042.n370gNK3001242@camembert.async.caltech.edu> <9F2237E2-73A2-4926-A438-A6032F70B4F6@cs.purdue.edu> <49DA8196.1E75.00D7.1@scires.com> Message-ID: <985F59A0-82EA-4F55-B6C8-DA057B9E23DB@cs.purdue.edu> On 7 Apr 2009, at 12:27, Randy Coleburn wrote: > Hey, will this proposal mean that packages like "stable" and > "stubgen" need to be changed also, in addition to both versions of > pickles? They build on m3tk so should just work, modulo any builtin typecode information. TAGGED INTEGER will have a predefined typecode just like NULL. > What about any package that deals with parsing of M3 code, e.g. > pretty-printers, CM3IDE, etc.? Same. To that end, how do those cope with LONGINT right now? I did push the changes for LONGINT into m3tk. > Regards, > Randy > > >>> Tony Hosking 4/6/2009 10:16 PM >>> > On 7 Apr 2009, at 10:42, Mika Nystrom wrote: > > > You mean this proposal (you had two, I think)? > > Yes, this is the proposal I converged on. It really is only minimal > change to the type system: introduction of a third hierarchy of > TAGGED reference types. I did something similar for orthogonal > persistence a few years ago where it was useful to have a TRANSIENT > reference hierarchy for things that should not persist. [The > semantics was that every run of a program would initialize TRANSIENT > references to NIL rather than have them have the persistent value. > This was slightly messier in that I also permitted TRANSIENT REFANY <: > REFANY, which was a little odd.] > > > -- > > > > NULL <: REF T <: REFANY > > NULL <: UNTRACED REF T <: ADDRESS > > TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY > > > > Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. > > > > ROOT <: REFANY > > TAGGED ROOT <: TAGGED REFANY > > NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS > > TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY > > > > Note that NULL is not a subtype of T OBJECT ... END where T <: > TAGGED > > REFANY. > > > > --- > > > > I like it fine, I think... I'm just worried, generally, about > > changing the type system. Hmmmm... you mean that the TAGGED > > things would just be a separate hierarchy? > > The change is relatively minor in that it doesn't touch the original > REFANY hierarchy. > > > So you'd just add TAGGED in front of the REFs for this new > hierarchy. > > But why no NULL? > > No NULL because then we need a test for both NIL and values of type > TAGGED INTEGER on every dereference. You can easily declare: > > TYPE Null = TAGGED INTEGER; > CONST Nil = VAL(0, TAGGED INTEGER); > > The point is that TAGGED INTEGER now lets you have a range of non- > pointer reference values, whereas NIL is the singleton non-reference > value in type NULL. > > > And you're comfortable with doing the conversions automatically? > > No, I said that the conversions needed to be explicit > > > > > So > > > > tx : TAGGED INTEGER := 5; > > tx: TAGGED INTEGER := VAL(5,TAGGED INTEGER); > > > x : INTEGER := tx; > > x: INTEGER := ORD(tx); > > > would be OK? > > > > In that case it's just the m3tk that needs to be modified, and > > that's just busy work, I think. If it works it's beautiful... > > As I said, I am almost done with the compiler changes, and only need > to push it into the run-time. Things like m3tk and pickles will need > to be smartened up as necessary. > > > > > > > Mika > > > > > > > > Tony Hosking writes: > >> I really don't like your proposal for the reasons you mention. It > >> makes regular REF more expensive than it currently is. What is it > >> about my relatively minor changes to the type system that you > object > >> to? I've just about finished changing the compiler front-end (in > >> relatively minor ways) to accomodate the proposal I made yesterday. > >> And it has the advantage of separating REF from TAGGED REF so we > keep > >> the standard REF clean. > >> > >> On 7 Apr 2009, at 00:50, Mika Nystrom wrote: > >> > >>> Hi Rodney, > >>> > >>> I would like this capability too, but I am a bit wary of Tony's > >>> idea of changing the Modula-3 language---even in a "minor" way. > >>> I've been working for the last week or so on an application using > >>> the Modula-3 Toolkit, and I must say I have realized that the > >> Modula-3 type system has a lot more subtleties than I thought. I > >>> would not want to make any real changes to it. There's a paper > >>> called "The Modula-3 Type System" by Cardelli, Donahue, Kalsow, > and > >>> Nelson that is worth studying in detail before making any changes > >>> whatsoever, I think. Also remember that changes to the type > system > >>> will affect m3tk and anything that depends on m3tk (which includes > >>> two or three stub generators in the main tree and who knows how > >>> many dependencies outside of it). > >>> > >>> I'm still not sure why we can't take the approach of Word.T . > >>> Make a RefanyOrInt.T that can safely be: > >>> > >>> 1. Tested whether it is a small integer or a REFANY > >>> > >>> 2. If a REFANY, be dereferenced as normal, *or* via > >>> RefanyOrInt.ToRefany > >>> > >>> 3. If a small integer, can be extracted via RefanyOrInt.ToInt > >>> > >>> 4. Created either as a small integer or a REFANY > >>> > >>> Any other operations on it (including ISTYPE and TYPECASE, at > least > >>> when the object is a small integer) would result in a checked > >>> runtime > >>> error. > >>> > >>> Note that with the declaration "RefanyOrInt.T = REFANY", the > current > >>> compiler will as far as I know not accept any operations on > >>> RefanyOrInt.T outside of ISTYPE, TYPECASE, and NARROW (explicit or > >>> implicit). > >>> > >>> I wouldn't be surprised if most of what I'm proposing already > works > >>> (i.e., crashes with a checked runtime error as it should) with the > >>> current runtime. Anything that slips through would need to be > fixed > >>> up with a one-bit check of the LSB of the REFANY for the > operations > >>> mentioned above. Unfortunately this has to be done for operations > >>> on > >>> every REFANY, not just the new type. > >>> > >>> I think that Modula-3 programmers are already aware that using > >>> REFANYs involves forcing the runtime to do extra type-checking > work, > >>> so they already know not to use them if they are looking for > maximum > >>> performance, so I don't think that burdening operations on REFANY > >>> with an extra one-bit check is too onerous. > >>> > >>> An advantage of my proposal is that the amount of code in the new > >>> proposed library is truly diminutive. In fact, I think I posted > >>> pretty much that code to the list a few weeks ago. > >>> > >>> (If you missed it, it's > >>> > >>> http://www.async.caltech.edu/~mika/interp/ > >>> > >>> ) > >>> > >>> Mika > >>> > >>> > >>> "Rodney M. Bates" writes: > >>>> I spent quite a bit of time playing with a more general system > >>>> where > >>>> there is a set of "tagged" types, with (an implementation-defined > >>>> subrange of) INTEGER and a reference type both being a subtype > of a > >>>> tagged type. It might have been tolerable, if it weren't for the > >>>> interaction with object subtypes and opaque types, which quickly > >>>> gets deep into a deep linguistic tar pit. > >>>> > >>>> Tony's approach is much simpler and would serve what I see as the > >>>> need. It does sacrifice any static checking of what reference > type > >>>> is being tagged, and will also require an extra runtime ISTYPE/ > >>>> TYPECASE. > >>>> > >>>> Would INTEGER and REFANY be assignable to TAGGED, or would there > >>>> also need to be an explicit conversion in that direction too, say > >>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. > It > >>>> is a bit inconsistent with the usual Modula-3 assignability > >>>> philosophy, > >>>> but not requiring the explicit conversion already gets your toes > >>>> into tar. > >>>> > >>>> We would have to have something more like ISTYPE, though, which > >>>> will > >>>> tell which type the value belongs to without risking a runtime > >>>> error, > >>>> which VAL would do. > >>>> > >>>> An intermediate approach might be to have a set of tagged types > >>>> constructed by, say, TAGGED T, where I is a reference type, but > >>>> with no subtype relations on them at all, thus still requiring > >>>> the explicit conversions and checks. > >>>> > >>>> I do want to say, I _really_ want this capability somehow. I > have > >>>> an ADT module whose internal data structure, for full generality, > >>>> needs to have two heap objects (the second because it has > nonstatic > >>>> size) and 11 total words counting the orginal pointer, in the > >>>> case of > >>>> values that would fit directly into the "pointer" word. > Moreover, > >>>> these small cases are in the great majority. > >>>> > >>>> Besides the 11-to-one increase in actual occupied space, there > >>>> is extra time for allocation, periodic tracing, and collection, > >>>> space > >>>> loss due to heap fragmentation, and time/space tradeoff loss > due to > >>>> reduced locality of reference. So sometimes, it would be a big > >>>> performance gain if we could do it. > >>>> > >>>> > >>>> Tony Hosking wrote: > >>>> It is a much more pervasive hack than I would be comfortable with > >>>>> since it touches on the compiler (for all the type operations) > as > >>>>> well > >>>>> as the run-time system in ways that are pretty gross. I would > >>>>> much > >>>>> rather have a new TAGGED builtin. ISTYPE would not work on it > >>>>> since > >>>>> that only works on references. The only thing you need is a way > >>>>> to > >>>>> extract the value -- we could overload VAL(x, T) where x can > be a > >>>>> TAGGED and T can be REFANY or INTEGER. > >>>>> > >>>>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Apr 7 07:28:32 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 22:28:32 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Tue, 07 Apr 2009 12:16:29 +1000." <9F2237E2-73A2-4926-A438-A6032F70B4F6@cs.purdue.edu> Message-ID: <200904070528.n375SWNg010291@camembert.async.caltech.edu> Ok, I see. You've done this before! Then I think you are qualified to say that it's doable and straightforward. It certainly seems all right from what you say. It sounds like it's implementation-wise not very different from the library idea I was proposing, but much more elegant. But but... this NULL business. You don't think that we who want to use the TAGGED INTEGER deserve to pay an extra instruction for the convenience? Is there actually an instruction checking for NULL? You don't just let the system segfault the process? Is this because you might have an indexed pointer that might be persuaded to point into mapped memory even if 0 is an illegal address? (Could you insert the NULL check only for pointers to types that are larger than a certain size, say one page?) It seems a little inconvenient to me not to have a pointer that's NIL. What you suggest doesn't really work super-elegantly... I'm thinking: in my Scheme interpreter, I represent Scheme types as Modula-3 REFs (following Norvig's JScheme almost exactly). The empty list is just Modula-3's NIL. But what you're saying is that some integer should be selected as "special" to denote the empty list, the non-object, or whatever you want to call it. What if I want to represent that integer? In any case, the all-zeros bit pattern would not be a legal TAGGED type, would it, under your proposal? Or am I completely missing something here? Mika Tony Hosking writes: >On 7 Apr 2009, at 10:42, Mika Nystrom wrote: > >> You mean this proposal (you had two, I think)? > >Yes, this is the proposal I converged on. It really is only minimal >change to the type system: introduction of a third hierarchy of >TAGGED reference types. I did something similar for orthogonal >persistence a few years ago where it was useful to have a TRANSIENT >reference hierarchy for things that should not persist. [The >semantics was that every run of a program would initialize TRANSIENT >references to NIL rather than have them have the persistent value. >This was slightly messier in that I also permitted TRANSIENT REFANY <: >REFANY, which was a little odd.] > >> -- >> >> NULL <: REF T <: REFANY >> NULL <: UNTRACED REF T <: ADDRESS >> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >> >> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >> >> ROOT <: REFANY >> TAGGED ROOT <: TAGGED REFANY >> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >> >> Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED >> REFANY. >> >> --- >> >> I like it fine, I think... I'm just worried, generally, about >> changing the type system. Hmmmm... you mean that the TAGGED >> things would just be a separate hierarchy? > >The change is relatively minor in that it doesn't touch the original >REFANY hierarchy. > >> So you'd just add TAGGED in front of the REFs for this new hierarchy. >> But why no NULL? > >No NULL because then we need a test for both NIL and values of type >TAGGED INTEGER on every dereference. You can easily declare: > >TYPE Null = TAGGED INTEGER; >CONST Nil = VAL(0, TAGGED INTEGER); > >The point is that TAGGED INTEGER now lets you have a range of non- >pointer reference values, whereas NIL is the singleton non-reference >value in type NULL. > >> And you're comfortable with doing the conversions automatically? > >No, I said that the conversions needed to be explicit > >> >> So >> >> tx : TAGGED INTEGER := 5; > >tx: TAGGED INTEGER := VAL(5,TAGGED INTEGER); > >> x : INTEGER := tx; > >x: INTEGER := ORD(tx); > >> would be OK? >> >> In that case it's just the m3tk that needs to be modified, and >> that's just busy work, I think. If it works it's beautiful... > >As I said, I am almost done with the compiler changes, and only need >to push it into the run-time. Things like m3tk and pickles will need >to be smartened up as necessary. > >> >> >> Mika >> >> >> >> Tony Hosking writes: >>> I really don't like your proposal for the reasons you mention. It >>> makes regular REF more expensive than it currently is. What is it >>> about my relatively minor changes to the type system that you object >>> to? I've just about finished changing the compiler front-end (in >>> relatively minor ways) to accomodate the proposal I made yesterday. >>> And it has the advantage of separating REF from TAGGED REF so we keep >>> the standard REF clean. >>> >>> On 7 Apr 2009, at 00:50, Mika Nystrom wrote: >>> >>>> Hi Rodney, >>>> >>>> I would like this capability too, but I am a bit wary of Tony's >>>> idea of changing the Modula-3 language---even in a "minor" way. >>>> I've been working for the last week or so on an application using >>>> the Modula-3 Toolkit, and I must say I have realized that the >>> Modula-3 type system has a lot more subtleties than I thought. I >>>> would not want to make any real changes to it. There's a paper >>>> called "The Modula-3 Type System" by Cardelli, Donahue, Kalsow, and >>>> Nelson that is worth studying in detail before making any changes >>>> whatsoever, I think. Also remember that changes to the type system >>>> will affect m3tk and anything that depends on m3tk (which includes >>>> two or three stub generators in the main tree and who knows how >>>> many dependencies outside of it). >>>> >>>> I'm still not sure why we can't take the approach of Word.T . >>>> Make a RefanyOrInt.T that can safely be: >>>> >>>> 1. Tested whether it is a small integer or a REFANY >>>> >>>> 2. If a REFANY, be dereferenced as normal, *or* via >>>> RefanyOrInt.ToRefany >>>> >>>> 3. If a small integer, can be extracted via RefanyOrInt.ToInt >>>> >>>> 4. Created either as a small integer or a REFANY >>>> >>>> Any other operations on it (including ISTYPE and TYPECASE, at least >>>> when the object is a small integer) would result in a checked >>> runtime >>>> error. >>>> >>>> Note that with the declaration "RefanyOrInt.T = REFANY", the current >>>> compiler will as far as I know not accept any operations on >>>> RefanyOrInt.T outside of ISTYPE, TYPECASE, and NARROW (explicit or >>>> implicit). >>>> >>>> I wouldn't be surprised if most of what I'm proposing already works >>>> (i.e., crashes with a checked runtime error as it should) with the >>>> current runtime. Anything that slips through would need to be fixed >>>> up with a one-bit check of the LSB of the REFANY for the operations >>>> mentioned above. Unfortunately this has to be done for operations >>>> on >>>> every REFANY, not just the new type. >>>> >>>> I think that Modula-3 programmers are already aware that using >>>> REFANYs involves forcing the runtime to do extra type-checking work, >>>> so they already know not to use them if they are looking for maximum >>>> performance, so I don't think that burdening operations on REFANY >>>> with an extra one-bit check is too onerous. >>>> >>>> An advantage of my proposal is that the amount of code in the new >>>> proposed library is truly diminutive. In fact, I think I posted >>>> pretty much that code to the list a few weeks ago. >>>> >>>> (If you missed it, it's >>>> >>>> http://www.async.caltech.edu/~mika/interp/ >>>> >>>> ) >>>> >>>> Mika >>>> >>>> >>>> "Rodney M. Bates" writes: >>>>> I spent quite a bit of time playing with a more general system >>>>> where >>>>> there is a set of "tagged" types, with (an implementation-defined >>>>> subrange of) INTEGER and a reference type both being a subtype of a >>>>> tagged type. It might have been tolerable, if it weren't for the >>>>> interaction with object subtypes and opaque types, which quickly >>>>> gets deep into a deep linguistic tar pit. >>>>> >>>>> Tony's approach is much simpler and would serve what I see as the >>>>> need. It does sacrifice any static checking of what reference type >>>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>>> TYPECASE. >>>>> >>>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>>> also need to be an explicit conversion in that direction too, say >>>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >>>>> is a bit inconsistent with the usual Modula-3 assignability >>>>> philosophy, >>>>> but not requiring the explicit conversion already gets your toes >>>>> into tar. >>>>> >>>>> We would have to have something more like ISTYPE, though, which >>>>> will >>>>> tell which type the value belongs to without risking a runtime >>>>> error, >>>>> which VAL would do. >>>>> >>>>> An intermediate approach might be to have a set of tagged types >>>>> constructed by, say, TAGGED T, where I is a reference type, but >>>>> with no subtype relations on them at all, thus still requiring >>>>> the explicit conversions and checks. >>>>> >>>>> I do want to say, I _really_ want this capability somehow. I have >>>>> an ADT module whose internal data structure, for full generality, >>>>> needs to have two heap objects (the second because it has nonstatic >>>>> size) and 11 total words counting the orginal pointer, in the >>>>> case of >>>>> values that would fit directly into the "pointer" word. Moreover, >>>>> these small cases are in the great majority. >>>>> >>>>> Besides the 11-to-one increase in actual occupied space, there >>>>> is extra time for allocation, periodic tracing, and collection, >>>>> space >>>>> loss due to heap fragmentation, and time/space tradeoff loss due to >>>>> reduced locality of reference. So sometimes, it would be a big >>>>> performance gain if we could do it. >>>> >>>>> >>>>> Tony Hosking wrote: >>>>> It is a much more pervasive hack than I would be comfortable with >>>>>> since it touches on the compiler (for all the type operations) as >>>>>> well >>>>>> as the run-time system in ways that are pretty gross. I would >>>>>> much >>>>>> rather have a new TAGGED builtin. ISTYPE would not work on it >>>>>> since >>>>>> that only works on references. The only thing you need is a way >>>>>> to >>>>>> extract the value -- we could overload VAL(x, T) where x can be a >>>>>> TAGGED and T can be REFANY or INTEGER. >>>>>> >>>>>> From mika at async.caltech.edu Tue Apr 7 07:39:17 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 22:39:17 -0700 Subject: [M3devel] Implementing the "Singleton pattern" in Modula-3 In-Reply-To: Your message of "Tue, 07 Apr 2009 12:07:19 +1000." Message-ID: <200904070539.n375dHGR010710@camembert.async.caltech.edu> Hmm, well ... so in C++ and Smalltalk you can accomplish something along these lines: INTERFACE Singleton; TYPE T = SomeSuperTypeIReallyWantToSubClass OBJECT METHODS m(); END; END Singleton. (****************************************) MODULE Client; BEGIN theSingleton := NEW(Singleton.T, m := MyM); theSingleton2 := NEW(Singleton.T, m := MyM); END Client. And by some magic involving overriding "new methods", you are guaranteed that theSingleton and theSingleton2 are the same object... In Modula-3 you can do something similar by providing an appropriate init, but this can still get a bit hairy since the client can override init and then you're back where you started. As I said this is really quite a minor issue but it has annoyed me a few times that I have to be very careful about allocating only one of something, especially when it might be allocated from lots of places and you want to make sure only one ever gets allocated in a single program execution. (E.g., various types of "registries"...) Mika Tony Hosking writes: >On 7 Apr 2009, at 11:18, Mika Nystrom wrote: > >> Well I think the problem is with this "is known to be an object >> type"... > >But if the opaque type T is T<:REFANY and the only revelation is >branded and private to a module (not exported by its interfaces) then >no-one can determine that it is an object type without forging the >BRAND. > >> You may in fact want to override the methods of the singleton, but >> ensure that only one ever gets instantiated. >> >> It's a minor problem, but it does sometimes bother me that it is >> difficult to prevent clients from NEWing pretty much anything they >> like. >> >> By the way, the "Modula-3 Type System" paper also talks about a >> nifty way to do narrowing very quickly (page 10, last paragraph). >> I remember this is occasionally problematic. (RTType.IsSubtype >> isn't great.) They speak of keeping an array of supertypes >> for each type, and recording the "depth" (distance from REFANY) >> of every type in, I guess, RT0.TypeDefn. This seems moderately >> space-efficient (better than a 2D array of all the typecodes), >> and very fast. >> >> Mika >> >> Tony Hosking writes: >>> I would exploit opaque types and branding. If T is opaque then you >>> cannot instantiate T except in scopes where T's concrete type has >>> been >>> revealed or is known to be an object type. Thus, you could define an >>> interface: >>> >>> GENERIC INTERFACE Singleton(Rep); >>> TYPE T <: REFANY; >>> VAR t: T; >>> END Singleton. >>> >>> GENERIC MODULE Singleton(Rep); >>> REVEAL T = BRANDED REF Rep.T; >>> BEGIN >>> t := NEW(T); >>> END Singleton. >>> >>> where Rep defines the type T. You could do similar for object types. >>> >>> >>> On 7 Apr 2009, at 06:31, Mika Nystrom wrote: >>> >>>> >>>> Tony, Jay, you two seem to be most knowledgeable about this. >>>> >>>> Let's say I wanted to implement the "singleton pattern" in >>>> Modula-3. At present there seems to be no way of doing this. >>>> >>>> What about changing RTAllocator.callback as follows (or adding >>>> another callback): >>>> >>>> VAR callback : PROCEDURE(r : REFANY) : REFANY := NIL; >>>> >>>> (* If non-NIL, the allocator calls "callback(r)" just before >>>> returning >>>> a new traced reference "r" and instead returns the result of >>>> callback(r). >>>> See "RTAllocStats" for an example client. It is a checked runtime >>>> error >>>> for the typecode of r to differ from the typecode of the return >>>> value of >>>> callback(r). *) >>>> >>>> Mika >>>> >>>> >>>> From hosking at cs.purdue.edu Tue Apr 7 08:15:50 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 16:15:50 +1000 Subject: [M3devel] Implementing the "Singleton pattern" in Modula-3 In-Reply-To: <200904070539.n375dHGR010710@camembert.async.caltech.edu> References: <200904070539.n375dHGR010710@camembert.async.caltech.edu> Message-ID: <2D76BEAC-54E2-48FB-BFF3-90339E0E1F75@cs.purdue.edu> Yes, I admit this is cumbersome: GENERIC MODULE Singleton(Super, Impl); REVEAL T = Super BRANDED OBJECT OVERRIDES m := Impl.m END; BEGIN t := NEW(T); END Singleton. On 7 Apr 2009, at 15:39, Mika Nystrom wrote: > > Hmm, well ... so in C++ and Smalltalk you can accomplish something > along these lines: > > INTERFACE Singleton; > > TYPE > T = SomeSuperTypeIReallyWantToSubClass OBJECT METHODS > m(); > END; > > END Singleton. > > (****************************************) > > MODULE Client; > > BEGIN > > theSingleton := NEW(Singleton.T, m := MyM); > theSingleton2 := NEW(Singleton.T, m := MyM); > > END Client. > > And by some magic involving overriding "new methods", you are > guaranteed that theSingleton and theSingleton2 are the same object... > > In Modula-3 you can do something similar by providing an appropriate > init, but this can still get a bit hairy since the client can > override init and then you're back where you started. > > As I said this is really quite a minor issue but it has annoyed me > a few times that I have to be very careful about allocating only one > of something, especially when it might be allocated from lots of > places and you want to make sure only one ever gets allocated in a > single > program execution. (E.g., various types of "registries"...) > > Mika > > Tony Hosking writes: >> On 7 Apr 2009, at 11:18, Mika Nystrom wrote: >> >>> Well I think the problem is with this "is known to be an object >>> type"... >> >> But if the opaque type T is T<:REFANY and the only revelation is >> branded and private to a module (not exported by its interfaces) then >> no-one can determine that it is an object type without forging the >> BRAND. >> >>> You may in fact want to override the methods of the singleton, but >>> ensure that only one ever gets instantiated. >>> >>> It's a minor problem, but it does sometimes bother me that it is >>> difficult to prevent clients from NEWing pretty much anything they >>> like. >>> >>> By the way, the "Modula-3 Type System" paper also talks about a >>> nifty way to do narrowing very quickly (page 10, last paragraph). >>> I remember this is occasionally problematic. (RTType.IsSubtype >>> isn't great.) They speak of keeping an array of supertypes >>> for each type, and recording the "depth" (distance from REFANY) >>> of every type in, I guess, RT0.TypeDefn. This seems moderately >>> space-efficient (better than a 2D array of all the typecodes), >>> and very fast. >>> >>> Mika >>> >>> Tony Hosking writes: >>>> I would exploit opaque types and branding. If T is opaque then you >>>> cannot instantiate T except in scopes where T's concrete type has >>>> been >>>> revealed or is known to be an object type. Thus, you could >>>> define an >>>> interface: >>>> >>>> GENERIC INTERFACE Singleton(Rep); >>>> TYPE T <: REFANY; >>>> VAR t: T; >>>> END Singleton. >>>> >>>> GENERIC MODULE Singleton(Rep); >>>> REVEAL T = BRANDED REF Rep.T; >>>> BEGIN >>>> t := NEW(T); >>>> END Singleton. >>>> >>>> where Rep defines the type T. You could do similar for object >>>> types. >>>> >>>> >>>> On 7 Apr 2009, at 06:31, Mika Nystrom wrote: >>>> >>>>> >>>>> Tony, Jay, you two seem to be most knowledgeable about this. >>>>> >>>>> Let's say I wanted to implement the "singleton pattern" in >>>>> Modula-3. At present there seems to be no way of doing this. >>>>> >>>>> What about changing RTAllocator.callback as follows (or adding >>>>> another callback): >>>>> >>>>> VAR callback : PROCEDURE(r : REFANY) : REFANY := NIL; >>>>> >>>>> (* If non-NIL, the allocator calls "callback(r)" just before >>>>> returning >>>>> a new traced reference "r" and instead returns the result of >>>>> callback(r). >>>>> See "RTAllocStats" for an example client. It is a checked runtime >>>>> error >>>>> for the typecode of r to differ from the typecode of the return >>>>> value of >>>>> callback(r). *) >>>>> >>>>> Mika >>>>> >>>>> >>>>> From hosking at cs.purdue.edu Tue Apr 7 08:27:41 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 16:27:41 +1000 Subject: [M3devel] small objects In-Reply-To: <200904070528.n375SWNg010291@camembert.async.caltech.edu> References: <200904070528.n375SWNg010291@camembert.async.caltech.edu> Message-ID: <8D54C0C3-478C-4E87-BBD7-216215FF2921@cs.purdue.edu> No, you are right on the money. I was just trying to avoid attempts to dereference tagged integers with a run-time check like a nil-check. I am starting to come around to your library idea. As you say, TaggedInteger.T would give a static error on dereference, so no need for a run-time check. Similarly, because one cannot NARROW (implicitly or explicitly) a TaggedInteger.T it is impossible to assign to anything other than a REFANY which avoids polluting other reference fields and so eliminates my initial concern. Hmmm.... ;-) On 7 Apr 2009, at 15:28, Mika Nystrom wrote: > > Ok, I see. You've done this before! Then I think you are qualified > to say that it's doable and straightforward. It certainly seems all > right from what you say. It sounds like it's implementation-wise not > very different from the library idea I was proposing, but much more > elegant. > > But but... this NULL business. You don't think that we who want to > use the TAGGED INTEGER deserve to pay an extra instruction for the > convenience? Is there actually an instruction checking for NULL? > You don't just let the system segfault the process? Is this because > you might have an indexed pointer that might be persuaded to point > into > mapped memory even if 0 is an illegal address? (Could you insert the > NULL check only for pointers to types that are larger than a certain > size, say one page?) > > It seems a little inconvenient to me not to have a pointer that's > NIL. What you suggest doesn't really work super-elegantly... > > I'm thinking: in my Scheme interpreter, I represent Scheme types as > Modula-3 REFs (following Norvig's JScheme almost exactly). The > empty list is just Modula-3's NIL. > > But what you're saying is that some integer should be selected as > "special" to denote the empty list, the non-object, or whatever you > want to call it. What if I want to represent that integer? > > In any case, the all-zeros bit pattern would not be a legal TAGGED > type, would it, under your proposal? > > Or am I completely missing something here? > > Mika > > Tony Hosking writes: >> On 7 Apr 2009, at 10:42, Mika Nystrom wrote: >> >>> You mean this proposal (you had two, I think)? >> >> Yes, this is the proposal I converged on. It really is only minimal >> change to the type system: introduction of a third hierarchy of >> TAGGED reference types. I did something similar for orthogonal >> persistence a few years ago where it was useful to have a TRANSIENT >> reference hierarchy for things that should not persist. [The >> semantics was that every run of a program would initialize TRANSIENT >> references to NIL rather than have them have the persistent value. >> This was slightly messier in that I also permitted TRANSIENT REFANY >> <: >> REFANY, which was a little odd.] >> >>> -- >>> >>> NULL <: REF T <: REFANY >>> NULL <: UNTRACED REF T <: ADDRESS >>> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >>> >>> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >>> >>> ROOT <: REFANY >>> TAGGED ROOT <: TAGGED REFANY >>> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >>> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >>> >>> Note that NULL is not a subtype of T OBJECT ... END where T <: >>> TAGGED >>> REFANY. >>> >>> --- >>> >>> I like it fine, I think... I'm just worried, generally, about >>> changing the type system. Hmmmm... you mean that the TAGGED >>> things would just be a separate hierarchy? >> >> The change is relatively minor in that it doesn't touch the original >> REFANY hierarchy. >> >>> So you'd just add TAGGED in front of the REFs for this new >>> hierarchy. >>> But why no NULL? >> >> No NULL because then we need a test for both NIL and values of type >> TAGGED INTEGER on every dereference. You can easily declare: >> >> TYPE Null = TAGGED INTEGER; >> CONST Nil = VAL(0, TAGGED INTEGER); >> >> The point is that TAGGED INTEGER now lets you have a range of non- >> pointer reference values, whereas NIL is the singleton non-reference >> value in type NULL. >> >>> And you're comfortable with doing the conversions automatically? >> >> No, I said that the conversions needed to be explicit >> >>> >>> So >>> >>> tx : TAGGED INTEGER := 5; >> >> tx: TAGGED INTEGER := VAL(5,TAGGED INTEGER); >> >>> x : INTEGER := tx; >> >> x: INTEGER := ORD(tx); >> >>> would be OK? >>> >>> In that case it's just the m3tk that needs to be modified, and >>> that's just busy work, I think. If it works it's beautiful... >> >> As I said, I am almost done with the compiler changes, and only need >> to push it into the run-time. Things like m3tk and pickles will need >> to be smartened up as necessary. >> >>> >>> >>> Mika >>> >>> >>> >>> Tony Hosking writes: >>>> I really don't like your proposal for the reasons you mention. It >>>> makes regular REF more expensive than it currently is. What is it >>>> about my relatively minor changes to the type system that you >>>> object >>>> to? I've just about finished changing the compiler front-end (in >>>> relatively minor ways) to accomodate the proposal I made yesterday. >>>> And it has the advantage of separating REF from TAGGED REF so we >>>> keep >>>> the standard REF clean. >>>> >>>> On 7 Apr 2009, at 00:50, Mika Nystrom wrote: >>>> >>>>> Hi Rodney, >>>>> >>>>> I would like this capability too, but I am a bit wary of Tony's >>>>> idea of changing the Modula-3 language---even in a "minor" way. >>>>> I've been working for the last week or so on an application using >>>>> the Modula-3 Toolkit, and I must say I have realized that the >>>> Modula-3 type system has a lot more subtleties than I thought. I >>>>> would not want to make any real changes to it. There's a paper >>>>> called "The Modula-3 Type System" by Cardelli, Donahue, Kalsow, >>>>> and >>>>> Nelson that is worth studying in detail before making any changes >>>>> whatsoever, I think. Also remember that changes to the type >>>>> system >>>>> will affect m3tk and anything that depends on m3tk (which includes >>>>> two or three stub generators in the main tree and who knows how >>>>> many dependencies outside of it). >>>>> >>>>> I'm still not sure why we can't take the approach of Word.T . >>>>> Make a RefanyOrInt.T that can safely be: >>>>> >>>>> 1. Tested whether it is a small integer or a REFANY >>>>> >>>>> 2. If a REFANY, be dereferenced as normal, *or* via >>>>> RefanyOrInt.ToRefany >>>>> >>>>> 3. If a small integer, can be extracted via RefanyOrInt.ToInt >>>>> >>>>> 4. Created either as a small integer or a REFANY >>>>> >>>>> Any other operations on it (including ISTYPE and TYPECASE, at >>>>> least >>>>> when the object is a small integer) would result in a checked >>>> runtime >>>>> error. >>>>> >>>>> Note that with the declaration "RefanyOrInt.T = REFANY", the >>>>> current >>>>> compiler will as far as I know not accept any operations on >>>>> RefanyOrInt.T outside of ISTYPE, TYPECASE, and NARROW (explicit or >>>>> implicit). >>>>> >>>>> I wouldn't be surprised if most of what I'm proposing already >>>>> works >>>>> (i.e., crashes with a checked runtime error as it should) with the >>>>> current runtime. Anything that slips through would need to be >>>>> fixed >>>>> up with a one-bit check of the LSB of the REFANY for the >>>>> operations >>>>> mentioned above. Unfortunately this has to be done for operations >>>>> on >>>>> every REFANY, not just the new type. >>>>> >>>>> I think that Modula-3 programmers are already aware that using >>>>> REFANYs involves forcing the runtime to do extra type-checking >>>>> work, >>>>> so they already know not to use them if they are looking for >>>>> maximum >>>>> performance, so I don't think that burdening operations on REFANY >>>>> with an extra one-bit check is too onerous. >>>>> >>>>> An advantage of my proposal is that the amount of code in the new >>>>> proposed library is truly diminutive. In fact, I think I posted >>>>> pretty much that code to the list a few weeks ago. >>>>> >>>>> (If you missed it, it's >>>>> >>>>> http://www.async.caltech.edu/~mika/interp/ >>>>> >>>>> ) >>>>> >>>>> Mika >>>>> >>>>> >>>>> "Rodney M. Bates" writes: >>>>>> I spent quite a bit of time playing with a more general system >>>>>> where >>>>>> there is a set of "tagged" types, with (an implementation-defined >>>>>> subrange of) INTEGER and a reference type both being a subtype >>>>>> of a >>>>>> tagged type. It might have been tolerable, if it weren't for the >>>>>> interaction with object subtypes and opaque types, which quickly >>>>>> gets deep into a deep linguistic tar pit. >>>>>> >>>>>> Tony's approach is much simpler and would serve what I see as the >>>>>> need. It does sacrifice any static checking of what reference >>>>>> type >>>>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>>>> TYPECASE. >>>>>> >>>>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>>>> also need to be an explicit conversion in that direction too, say >>>>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. >>>>>> It >>>>>> is a bit inconsistent with the usual Modula-3 assignability >>>>>> philosophy, >>>>>> but not requiring the explicit conversion already gets your toes >>>>>> into tar. >>>>>> >>>>>> We would have to have something more like ISTYPE, though, which >>>>>> will >>>>>> tell which type the value belongs to without risking a runtime >>>>>> error, >>>>>> which VAL would do. >>>>>> >>>>>> An intermediate approach might be to have a set of tagged types >>>>>> constructed by, say, TAGGED T, where I is a reference type, but >>>>>> with no subtype relations on them at all, thus still requiring >>>>>> the explicit conversions and checks. >>>>>> >>>>>> I do want to say, I _really_ want this capability somehow. I >>>>>> have >>>>>> an ADT module whose internal data structure, for full generality, >>>>>> needs to have two heap objects (the second because it has >>>>>> nonstatic >>>>>> size) and 11 total words counting the orginal pointer, in the >>>>>> case of >>>>>> values that would fit directly into the "pointer" word. >>>>>> Moreover, >>>>>> these small cases are in the great majority. >>>>>> >>>>>> Besides the 11-to-one increase in actual occupied space, there >>>>>> is extra time for allocation, periodic tracing, and collection, >>>>>> space >>>>>> loss due to heap fragmentation, and time/space tradeoff loss >>>>>> due to >>>>>> reduced locality of reference. So sometimes, it would be a big >>>>>> performance gain if we could do it. >>>>> >>>>>> >>>>>> Tony Hosking wrote: >>>>>> It is a much more pervasive hack than I would be comfortable with >>>>>>> since it touches on the compiler (for all the type operations) >>>>>>> as >>>>>>> well >>>>>>> as the run-time system in ways that are pretty gross. I would >>>>>>> much >>>>>>> rather have a new TAGGED builtin. ISTYPE would not work on it >>>>>>> since >>>>>>> that only works on references. The only thing you need is a way >>>>>>> to >>>>>>> extract the value -- we could overload VAL(x, T) where x can >>>>>>> be a >>>>>>> TAGGED and T can be REFANY or INTEGER. >>>>>>> >>>>>>> From hosking at cs.purdue.edu Tue Apr 7 08:55:12 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 16:55:12 +1000 Subject: [M3devel] small objects In-Reply-To: <200904062039.n36KdIsY095003@camembert.async.caltech.edu> References: <200904062039.n36KdIsY095003@camembert.async.caltech.edu> Message-ID: After all of this -- I may simply be coming back around to your original proposal -- why not simply declare: TaggedInteger.T = REFANY; ? You can't instantiate a REFANY. All we really need is the LOOPHOLEing of your original proposal to extract the integer values, and to make sure that ISTYPE and NARROW have the behavior you describe for tagged REFANY. Does it make sense that TYPECODE(r) = TYPECODE(REFANY) for any tagged REFANY? What else are we missing? On 7 Apr 2009, at 06:39, Mika Nystrom wrote: > And finally, to forestall a possible objection to the scheme > I proposed: > > Yes, it is true that even a non-UNSAFE module can allocate a > TaggedInteger.T by calling > > new := RTAllocator.NewTraced(TYPECODE(r)) > > where r is a tagged integer. > > But since it cannot dereference that new value or do anything else > with it, I don't think this is a problem. The Pickler (built into > the TaggedInteger module, one must assume) would simply have to > be on the lookout for values of the "real" TaggedInteger.T versus > those that are just numbers with the LSB set, and act accordingly. > Since the T declaration is only visible within the UNSAFE module > there can never be any question of another module's muddling the > two types up. > > Mika > > Mika Nystrom writes: >> "Rodney M. Bates" writes: >>> At first, I just envisioned implementing a small object type >>> entirely inside an UNSAFE module, using unsafe operations >>> to construct/test/separate the values. I think if the GC were >>> to just to ignore words in heap objects that the type system >>> claims are unambiguously pointers but actually have misaligned >>> values, this could be done. >> >> Right that's precisely what the module I posted does. >> >>> >>> But it flies in the face of a fundamental principle of Modula-3, >>> namely that an UNSAFE module, if coded correctly, can prevent >>> all other code from consequences of the unsafety. Unfortunately, >>> this can't be done with the small pointers, because, even if >>> opaque, they are still reference types, and client code can >>> dereference them (including the implicit dereference in accessing >>> a method or field of an object) and do ISTYPE, NARROW, TYPECASE, >>> and assignments that do an implicit NARROW. All these operations >>> could be done outside the implementing module and all could >>> suffer from misaligned values. >> >> Well yes that is true. But the client can't dereference REFANY. >> Modula-3 doesn't permit that. That's an important practical point, >> because now we're limited to the other things: ISTYPE, NARROW >> (implicit and explicit), TYPECASE. (There are two more, actually, >> and they are = and #.) As long as those can be guaranteed to fail >> you're OK. [ Actually see my P.S. below! ] >> >>> >>> In fact, misaligned integer "objects" violate another principle >>> that >>> the bit pattern must always be a valid representation of some value >>> of the type. >> >> Yes I think maybe this is what Tony is worried about. But let's >> just change the definition of REFANY to include anything with the >> LSB set...? >> >> In Modula-3-ese it would be more like the following: >> >> "REFANY can hold three types of objects. NIL, REF something or an >> implementation-defined other set of values that can only be accessed >> in an UNSAFE module. It is a checked runtime error to pass a 'REFANY >> of the third kind' to ISTYPE, NARROW, TYPECASE." [ Actually see my >> P.S. below! ] >> >> Then I propose we punt the handling of the new REFANYs to this >> unsafe module we spoke about above. As far as Modula-3 is concerned, >> there's just a set of values of (apparently) very little utility >> that can be represented by REFANY. If you think about it, this is >> really not so crazy. Any module that uses REFANY today is designed >> around to the fact that there are plenty of values of REFANY that >> can be of no interest to that module except for passing along to >> another module. (REFANY can easily represent a type which a module >> has no way of accessing *any* declaration of beyond just REFANY.) >> We're just adding some others, the only difference being that the >> new values are of no interest to any non-UNSAFE module. (Eh, >> technically this is already true for any reference type that is >> declared in an UNSAFE module today so one might argue we have in >> fact added nothing.) >> >>> >>> However, this does suggest a different and very simple linguistic >>> solution: Just have a new builtin type, say VERYOPAQUE, that >>> supports no operations other than moving it around, i.e., >>> assignment, bindings, passing as a parameter, etc. Only unsafe >>> code could do anyhing with it, by using LOOPHOLE. The only >>> problem is, would somebody then want one of these in a size other >>> than one word? >> >> This is nice, and we already have a candidate type, in fact: ADDRESS. >> But the problem is that the GC doesn't follow this even if the LSB >> is clear... which we *do* want. >> >> Why are you worried about getting it in sizes other than one word? >> That seems to me to be an application problem. If someone wants >> an ARRAY OF VERYOPAQUE is that a problem? >> >> Mika >> >> P.S. Illustration of the above, in today's Modula-3: >> >> UNSAFE MODULE Unsafe; >> >> (* this module is just declared UNSAFE to conform with the definition >> above, namely, that T can only be manipulated in an UNSAFE >> module, which this is! *) >> >> TYPE T = BRANDED OBJECT END; >> >> BEGIN >> Safe.P(NEW(T)) >> END Unsafe. >> >> (****************************************) >> >> MODULE Safe; >> >> PROCEDURE P(r : REFANY) = >> BEGIN >> NARROW(r, X); (* checked runtime error for all X *) >> >> ISTYPE(r, X); (* returns FALSE for all X except REFANY itself *) >> >> TYPECASE r OF >> X => (* only gets executed for X = REFANY *) >> END; >> END P; >> >> BEGIN END Safe. >> >> Actually is this behavior so bad for tagged integers? Since it is >> the behavior of existing code... why not keep it? Then you can even >> store a tagged integer in a RefList.T, say, even if that RefList.T >> uses NARROW or ISTYPE on the argument (I don't see why it would, but >> why not...?) >> >> >> >>> >>> Mika Nystrom wrote: >>>> Ah I should read my whole inbox before replying. >>>> >>>> I take it you would worry that in my proposal (to do this all in a >>>> library) the use of REFANY to store an integer could be abused >>>> somehow. That the Modula-3 type system (as it exists now) >>>> explicitly >>>> rules out doing such things, and therefore, a language change is >>>> necessary.... >>>> >>>> Mika >>>> >>>> Tony Hosking writes: >>>> >>>>> I like the notion of having a TAGGED INTEGER type that is a hybrid >>>>> ordinal/reference. >>>>> >>>>> Subtyping rules for references would now be as follows: >>>>> >>>>> NULL <: REF T <: REFANY >>>>> TAGGED INTEGER <: REF T <: REFANY >>>>> >>>>> ROOT <: REFANY >>>>> NULL <: T OBJECT ... END <: T >>>>> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: >>>>> REFANY, not >>>>> T <: ADDRESS) >>>>> >>>>> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >>>>> type. Values of TAGGED INTEGER are non-pointer values similar >>>>> to the >>>>> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and >>>>> NARROW(x, >>>>> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to >>>>> ISTYPE(x, >>>>> NULL), NARROW(x, NULL), and TYPECODE(NULL). >>>>> >>>>> Because TAGGED INTEGER is an ordinal we can extract the integer >>>>> value >>>>> it holds using ORD(x). >>>>> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >>>>> INTEGER). >>>>> >>>>> ***The only problem with this scheme is how to efficiently >>>>> perform run- >>>>> time tests for dereferencing NULL, and TAGGED INTEGER?*** >>>> >>>>> So, here is a slightly less elegant alternative that is probably >>>>> straightforward to implement. Introduce a separate TAGGED >>>>> hierarchy. >>>>> >>>>> NULL <: REF T <: REFANY >>>>> NULL <: UNTRACED REF T <: ADDRESS >>>>> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >>>>> >>>>> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >>>>> >>>>> ROOT <: REFANY >>>>> TAGGED ROOT <: TAGGED REFANY >>>>> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >>>>> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >>>>> >>>>> Note that NULL is not a subtype of T OBJECT ... END where T <: >>>>> TAGGED >>>>> REFANY. >>>>> >>>>> This way, tagged references only need a run-time test for the >>>>> tag on >>>>> dereference (we can throw an "attempt to dereference TAGGED >>>>> INTEGER" >>>>> at run time, just like we throw "attempt to dereference NIL" for >>>>> untagged references). This check can be a straightforward test >>>>> of the >>>>> low bit tag. Of course, the weird thing here is now that we don't >>>>> have a single NULL value for TAGGED references --- we have >>>>> multiple >>>>> null values VAL(x, TAGGED INTEGER). Instead of asking "x == >>>>> NIL" we >>>>> must ask "ISTYPE(x, TAGGED INTEGER)". >>>>> >>>>> Of course, because TAGGED INTEGER is an ordinal, we can also >>>>> perform >>>>> the usual ordinal operations like INC(x), DEC(x), wherever x is >>>>> typed >>>>> TAGGED INTEGER. >>>>> >>>>> >>>>> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >>>>> >>>>> >>>>>> I spent quite a bit of time playing with a more general system >>>>>> where >>>>>> there is a set of "tagged" types, with (an implementation-defined >>>>>> subrange of) INTEGER and a reference type both being a subtype >>>>>> of a >>>>>> tagged type. It might have been tolerable, if it weren't for the >>>>>> interaction with object subtypes and opaque types, which quickly >>>>>> gets deep into a deep linguistic tar pit. >>>>>> >>>>>> Tony's approach is much simpler and would serve what I see as the >>>>>> need. It does sacrifice any static checking of what reference >>>>>> type >>>>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>>>> TYPECASE. >>>>>> >>>>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>>>> also need to be an explicit conversion in that direction too, say >>>>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. >>>>>> It >>>>>> is a bit inconsistent with the usual Modula-3 assignability >>>>>> philosophy, >>>>>> but not requiring the explicit conversion already gets your toes >>>>>> into tar. >>>>>> >>>>>> We would have to have something more like ISTYPE, though, which >>>>>> will >>>>>> tell which type the value belongs to without risking a runtime >>>>>> error, >>>>>> which VAL would do. >>>>>> >>>>>> An intermediate approach might be to have a set of tagged types >>>>>> constructed by, say, TAGGED T, where I is a reference type, but >>>>>> with no subtype relations on them at all, thus still requiring >>>>>> the explicit conversions and checks. >>>>>> >>>>>> I do want to say, I _really_ want this capability somehow. I >>>>>> have >>>>>> an ADT module whose internal data structure, for full generality, >>>>>> needs to have two heap objects (the second because it has >>>>>> nonstatic >>>>>> size) and 11 total words counting the orginal pointer, in the >>>>>> case of >>>>>> values that would fit directly into the "pointer" word. >>>>>> Moreover, >>>>>> these small cases are in the great majority. >>>>>> >>>>>> Besides the 11-to-one increase in actual occupied space, there >>>>>> is extra time for allocation, periodic tracing, and collection, >>>>>> space >>>>>> loss due to heap fragmentation, and time/space tradeoff loss >>>>>> due to >>>>>> reduced locality of reference. So sometimes, it would be a big >>>>>> performance gain if we could do it. >>>>>> >>>>>> >>>>>> Tony Hosking wrote: >>>>>> >>>>>>> It is a much more pervasive hack than I would be comfortable >>>>>>> with >>>>>>> since it touches on the compiler (for all the type operations) >>>>>>> as >>>>>>> well >>>>>>> as the run-time system in ways that are pretty gross. I would >>>>>>> much >>>>>>> rather have a new TAGGED builtin. ISTYPE would not work on it >>>>>>> since >>>>>>> that only works on references. The only thing you need is a >>>>>>> way to >>>>>>> extract the value -- we could overload VAL(x, T) where x can >>>>>>> be a >>>>>>> TAGGED and T can be REFANY or INTEGER. >>>>>>> >>>>>>> >>>> >>>> From hosking at cs.purdue.edu Tue Apr 7 08:58:43 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 16:58:43 +1000 Subject: [M3devel] small objects In-Reply-To: References: <200904062039.n36KdIsY095003@camembert.async.caltech.edu> Message-ID: erratum: TYPECODE(r) = RT0.RefanyTypecode if r is a tagged REFANY. (It is a static error to say TYPECODE(REFANY)) On 7 Apr 2009, at 16:55, Tony Hosking wrote: > After all of this -- I may simply be coming back around to your > original proposal -- why not simply declare: > > TaggedInteger.T = REFANY; > > ? > > You can't instantiate a REFANY. > > All we really need is the LOOPHOLEing of your original proposal to > extract the integer values, and to make sure that ISTYPE and NARROW > have the behavior you describe for tagged REFANY. Does it make > sense that TYPECODE(r) = TYPECODE(REFANY) for any tagged REFANY? > What else are we missing? > > On 7 Apr 2009, at 06:39, Mika Nystrom wrote: > >> And finally, to forestall a possible objection to the scheme >> I proposed: >> >> Yes, it is true that even a non-UNSAFE module can allocate a >> TaggedInteger.T by calling >> >> new := RTAllocator.NewTraced(TYPECODE(r)) >> >> where r is a tagged integer. >> >> But since it cannot dereference that new value or do anything else >> with it, I don't think this is a problem. The Pickler (built into >> the TaggedInteger module, one must assume) would simply have to >> be on the lookout for values of the "real" TaggedInteger.T versus >> those that are just numbers with the LSB set, and act accordingly. >> Since the T declaration is only visible within the UNSAFE module >> there can never be any question of another module's muddling the >> two types up. >> >> Mika >> >> Mika Nystrom writes: >>> "Rodney M. Bates" writes: >>>> At first, I just envisioned implementing a small object type >>>> entirely inside an UNSAFE module, using unsafe operations >>>> to construct/test/separate the values. I think if the GC were >>>> to just to ignore words in heap objects that the type system >>>> claims are unambiguously pointers but actually have misaligned >>>> values, this could be done. >>> >>> Right that's precisely what the module I posted does. >>> >>>> >>>> But it flies in the face of a fundamental principle of Modula-3, >>>> namely that an UNSAFE module, if coded correctly, can prevent >>>> all other code from consequences of the unsafety. Unfortunately, >>>> this can't be done with the small pointers, because, even if >>>> opaque, they are still reference types, and client code can >>>> dereference them (including the implicit dereference in accessing >>>> a method or field of an object) and do ISTYPE, NARROW, TYPECASE, >>>> and assignments that do an implicit NARROW. All these operations >>>> could be done outside the implementing module and all could >>>> suffer from misaligned values. >>> >>> Well yes that is true. But the client can't dereference REFANY. >>> Modula-3 doesn't permit that. That's an important practical point, >>> because now we're limited to the other things: ISTYPE, NARROW >>> (implicit and explicit), TYPECASE. (There are two more, actually, >>> and they are = and #.) As long as those can be guaranteed to fail >>> you're OK. [ Actually see my P.S. below! ] >>> >>>> >>>> In fact, misaligned integer "objects" violate another principle >>>> that >>>> the bit pattern must always be a valid representation of some value >>>> of the type. >>> >>> Yes I think maybe this is what Tony is worried about. But let's >>> just change the definition of REFANY to include anything with the >>> LSB set...? >>> >>> In Modula-3-ese it would be more like the following: >>> >>> "REFANY can hold three types of objects. NIL, REF something or an >>> implementation-defined other set of values that can only be accessed >>> in an UNSAFE module. It is a checked runtime error to pass a >>> 'REFANY >>> of the third kind' to ISTYPE, NARROW, TYPECASE." [ Actually see my >>> P.S. below! ] >>> >>> Then I propose we punt the handling of the new REFANYs to this >>> unsafe module we spoke about above. As far as Modula-3 is >>> concerned, >>> there's just a set of values of (apparently) very little utility >>> that can be represented by REFANY. If you think about it, this is >>> really not so crazy. Any module that uses REFANY today is designed >>> around to the fact that there are plenty of values of REFANY that >>> can be of no interest to that module except for passing along to >>> another module. (REFANY can easily represent a type which a module >>> has no way of accessing *any* declaration of beyond just REFANY.) >>> We're just adding some others, the only difference being that the >>> new values are of no interest to any non-UNSAFE module. (Eh, >>> technically this is already true for any reference type that is >>> declared in an UNSAFE module today so one might argue we have in >>> fact added nothing.) >>> >>>> >>>> However, this does suggest a different and very simple linguistic >>>> solution: Just have a new builtin type, say VERYOPAQUE, that >>>> supports no operations other than moving it around, i.e., >>>> assignment, bindings, passing as a parameter, etc. Only unsafe >>>> code could do anyhing with it, by using LOOPHOLE. The only >>>> problem is, would somebody then want one of these in a size other >>>> than one word? >>> >>> This is nice, and we already have a candidate type, in fact: >>> ADDRESS. >>> But the problem is that the GC doesn't follow this even if the LSB >>> is clear... which we *do* want. >>> >>> Why are you worried about getting it in sizes other than one word? >>> That seems to me to be an application problem. If someone wants >>> an ARRAY OF VERYOPAQUE is that a problem? >>> >>> Mika >>> >>> P.S. Illustration of the above, in today's Modula-3: >>> >>> UNSAFE MODULE Unsafe; >>> >>> (* this module is just declared UNSAFE to conform with the >>> definition >>> above, namely, that T can only be manipulated in an UNSAFE >>> module, which this is! *) >>> >>> TYPE T = BRANDED OBJECT END; >>> >>> BEGIN >>> Safe.P(NEW(T)) >>> END Unsafe. >>> >>> (****************************************) >>> >>> MODULE Safe; >>> >>> PROCEDURE P(r : REFANY) = >>> BEGIN >>> NARROW(r, X); (* checked runtime error for all X *) >>> >>> ISTYPE(r, X); (* returns FALSE for all X except REFANY itself *) >>> >>> TYPECASE r OF >>> X => (* only gets executed for X = REFANY *) >>> END; >>> END P; >>> >>> BEGIN END Safe. >>> >>> Actually is this behavior so bad for tagged integers? Since it is >>> the behavior of existing code... why not keep it? Then you can even >>> store a tagged integer in a RefList.T, say, even if that RefList.T >>> uses NARROW or ISTYPE on the argument (I don't see why it would, but >>> why not...?) >>> >>> >>> >>>> >>>> Mika Nystrom wrote: >>>>> Ah I should read my whole inbox before replying. >>>>> >>>>> I take it you would worry that in my proposal (to do this all in a >>>>> library) the use of REFANY to store an integer could be abused >>>>> somehow. That the Modula-3 type system (as it exists now) >>>>> explicitly >>>>> rules out doing such things, and therefore, a language change is >>>>> necessary.... >>>>> >>>>> Mika >>>>> >>>>> Tony Hosking writes: >>>>> >>>>>> I like the notion of having a TAGGED INTEGER type that is a >>>>>> hybrid >>>>>> ordinal/reference. >>>>>> >>>>>> Subtyping rules for references would now be as follows: >>>>>> >>>>>> NULL <: REF T <: REFANY >>>>>> TAGGED INTEGER <: REF T <: REFANY >>>>>> >>>>>> ROOT <: REFANY >>>>>> NULL <: T OBJECT ... END <: T >>>>>> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: >>>>>> REFANY, not >>>>>> T <: ADDRESS) >>>>>> >>>>>> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >>>>>> type. Values of TAGGED INTEGER are non-pointer values similar >>>>>> to the >>>>>> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and >>>>>> NARROW(x, >>>>>> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to >>>>>> ISTYPE(x, >>>>>> NULL), NARROW(x, NULL), and TYPECODE(NULL). >>>>>> >>>>>> Because TAGGED INTEGER is an ordinal we can extract the integer >>>>>> value >>>>>> it holds using ORD(x). >>>>>> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >>>>>> INTEGER). >>>>>> >>>>>> ***The only problem with this scheme is how to efficiently >>>>>> perform run- >>>>>> time tests for dereferencing NULL, and TAGGED INTEGER?*** >>>>> >>>>>> So, here is a slightly less elegant alternative that is probably >>>>>> straightforward to implement. Introduce a separate TAGGED >>>>>> hierarchy. >>>>>> >>>>>> NULL <: REF T <: REFANY >>>>>> NULL <: UNTRACED REF T <: ADDRESS >>>>>> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >>>>>> >>>>>> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >>>>>> >>>>>> ROOT <: REFANY >>>>>> TAGGED ROOT <: TAGGED REFANY >>>>>> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >>>>>> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >>>>>> >>>>>> Note that NULL is not a subtype of T OBJECT ... END where T <: >>>>>> TAGGED >>>>>> REFANY. >>>>>> >>>>>> This way, tagged references only need a run-time test for the >>>>>> tag on >>>>>> dereference (we can throw an "attempt to dereference TAGGED >>>>>> INTEGER" >>>>>> at run time, just like we throw "attempt to dereference NIL" for >>>>>> untagged references). This check can be a straightforward test >>>>>> of the >>>>>> low bit tag. Of course, the weird thing here is now that we >>>>>> don't >>>>>> have a single NULL value for TAGGED references --- we have >>>>>> multiple >>>>>> null values VAL(x, TAGGED INTEGER). Instead of asking "x == >>>>>> NIL" we >>>>>> must ask "ISTYPE(x, TAGGED INTEGER)". >>>>>> >>>>>> Of course, because TAGGED INTEGER is an ordinal, we can also >>>>>> perform >>>>>> the usual ordinal operations like INC(x), DEC(x), wherever x is >>>>>> typed >>>>>> TAGGED INTEGER. >>>>>> >>>>>> >>>>>> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >>>>>> >>>>>> >>>>>>> I spent quite a bit of time playing with a more general system >>>>>>> where >>>>>>> there is a set of "tagged" types, with (an implementation- >>>>>>> defined >>>>>>> subrange of) INTEGER and a reference type both being a subtype >>>>>>> of a >>>>>>> tagged type. It might have been tolerable, if it weren't for >>>>>>> the >>>>>>> interaction with object subtypes and opaque types, which quickly >>>>>>> gets deep into a deep linguistic tar pit. >>>>>>> >>>>>>> Tony's approach is much simpler and would serve what I see as >>>>>>> the >>>>>>> need. It does sacrifice any static checking of what reference >>>>>>> type >>>>>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>>>>> TYPECASE. >>>>>>> >>>>>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>>>>> also need to be an explicit conversion in that direction too, >>>>>>> say >>>>>>> VAL(x, TAGGED)? I think I favor the explicit conversion >>>>>>> here. It >>>>>>> is a bit inconsistent with the usual Modula-3 assignability >>>>>>> philosophy, >>>>>>> but not requiring the explicit conversion already gets your toes >>>>>>> into tar. >>>>>>> >>>>>>> We would have to have something more like ISTYPE, though, >>>>>>> which will >>>>>>> tell which type the value belongs to without risking a runtime >>>>>>> error, >>>>>>> which VAL would do. >>>>>>> >>>>>>> An intermediate approach might be to have a set of tagged types >>>>>>> constructed by, say, TAGGED T, where I is a reference type, but >>>>>>> with no subtype relations on them at all, thus still requiring >>>>>>> the explicit conversions and checks. >>>>>>> >>>>>>> I do want to say, I _really_ want this capability somehow. I >>>>>>> have >>>>>>> an ADT module whose internal data structure, for full >>>>>>> generality, >>>>>>> needs to have two heap objects (the second because it has >>>>>>> nonstatic >>>>>>> size) and 11 total words counting the orginal pointer, in the >>>>>>> case of >>>>>>> values that would fit directly into the "pointer" word. >>>>>>> Moreover, >>>>>>> these small cases are in the great majority. >>>>>>> >>>>>>> Besides the 11-to-one increase in actual occupied space, there >>>>>>> is extra time for allocation, periodic tracing, and >>>>>>> collection, space >>>>>>> loss due to heap fragmentation, and time/space tradeoff loss >>>>>>> due to >>>>>>> reduced locality of reference. So sometimes, it would be a big >>>>>>> performance gain if we could do it. >>>>>>> >>>>>>> >>>>>>> Tony Hosking wrote: >>>>>>> >>>>>>>> It is a much more pervasive hack than I would be comfortable >>>>>>>> with >>>>>>>> since it touches on the compiler (for all the type >>>>>>>> operations) as >>>>>>>> well >>>>>>>> as the run-time system in ways that are pretty gross. I >>>>>>>> would much >>>>>>>> rather have a new TAGGED builtin. ISTYPE would not work on >>>>>>>> it since >>>>>>>> that only works on references. The only thing you need is a >>>>>>>> way to >>>>>>>> extract the value -- we could overload VAL(x, T) where x can >>>>>>>> be a >>>>>>>> TAGGED and T can be REFANY or INTEGER. >>>>>>>> >>>>>>>> >>>>> >>>>> From mika at async.caltech.edu Tue Apr 7 09:27:13 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 07 Apr 2009 00:27:13 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Tue, 07 Apr 2009 16:58:43 +1000." Message-ID: <200904070727.n377RDug014714@camembert.async.caltech.edu> Oh I see. I think... You're saying that because RT0.RefanyTypecode is essentially "useless", it's OK to have values with that typecode since no (existing) module can do anything with that knowledge? So...this proposal says that ISTYPE returns FALSE for everything except ISTYPE(r,REFANY). TYPECASE, same. TYPECODE, as you say, RT0.RefanyTypecode. In other words, it's a useless value except for whatever unsafe code is lurking inside TaggedInteger. So normally, TYPECODE never returns RT0.RefanyTypecode? That's the only thing that would change as far as I can tell... I can't see how that could possibly break anything. Checking for the tagged integers can then be done by checking whether TYPECODE returns RT0.RefanyTypecode. The pickler would build an object when it sees that and pickle that, instead of the tagged integer. So change the language spec to allow the above behavior for a value of type REFANY and to say that unsafe modules may be able to do some other implementation-dependent things with these 'REFANYs of the third kind'? Mika Tony Hosking writes: >erratum: > >TYPECODE(r) = RT0.RefanyTypecode if r is a tagged REFANY. > >(It is a static error to say TYPECODE(REFANY)) > >On 7 Apr 2009, at 16:55, Tony Hosking wrote: > >> After all of this -- I may simply be coming back around to your >> original proposal -- why not simply declare: >> >> TaggedInteger.T = REFANY; >> >> ? >> >> You can't instantiate a REFANY. >> >> All we really need is the LOOPHOLEing of your original proposal to >> extract the integer values, and to make sure that ISTYPE and NARROW >> have the behavior you describe for tagged REFANY. Does it make >> sense that TYPECODE(r) = TYPECODE(REFANY) for any tagged REFANY? >> What else are we missing? >> >> On 7 Apr 2009, at 06:39, Mika Nystrom wrote: >> >>> And finally, to forestall a possible objection to the scheme >>> I proposed: >>> >>> Yes, it is true that even a non-UNSAFE module can allocate a >>> TaggedInteger.T by calling >>> >>> new := RTAllocator.NewTraced(TYPECODE(r)) >>> >>> where r is a tagged integer. >>> >>> But since it cannot dereference that new value or do anything else >>> with it, I don't think this is a problem. The Pickler (built into >>> the TaggedInteger module, one must assume) would simply have to >>> be on the lookout for values of the "real" TaggedInteger.T versus >>> those that are just numbers with the LSB set, and act accordingly. >>> Since the T declaration is only visible within the UNSAFE module >>> there can never be any question of another module's muddling the >>> two types up. >>> >>> Mika >>> >>> Mika Nystrom writes: >>>> "Rodney M. Bates" writes: >>>>> At first, I just envisioned implementing a small object type >>>>> entirely inside an UNSAFE module, using unsafe operations >>>>> to construct/test/separate the values. I think if the GC were >>>>> to just to ignore words in heap objects that the type system >>>>> claims are unambiguously pointers but actually have misaligned >>>>> values, this could be done. >>>> >>>> Right that's precisely what the module I posted does. >>>> >>>>> >>>>> But it flies in the face of a fundamental principle of Modula-3, >>>>> namely that an UNSAFE module, if coded correctly, can prevent >>>>> all other code from consequences of the unsafety. Unfortunately, >>>>> this can't be done with the small pointers, because, even if >>>>> opaque, they are still reference types, and client code can >>>>> dereference them (including the implicit dereference in accessing >>>>> a method or field of an object) and do ISTYPE, NARROW, TYPECASE, >>>>> and assignments that do an implicit NARROW. All these operations >>>>> could be done outside the implementing module and all could >>>>> suffer from misaligned values. >>>> >>>> Well yes that is true. But the client can't dereference REFANY. >>>> Modula-3 doesn't permit that. That's an important practical point, >>>> because now we're limited to the other things: ISTYPE, NARROW >>>> (implicit and explicit), TYPECASE. (There are two more, actually, >>>> and they are = and #.) As long as those can be guaranteed to fail >>>> you're OK. [ Actually see my P.S. below! ] >>>> >>>>> >>>>> In fact, misaligned integer "objects" violate another principle >>>>> that >>>>> the bit pattern must always be a valid representation of some value >>>>> of the type. >>>> >>>> Yes I think maybe this is what Tony is worried about. But let's >>>> just change the definition of REFANY to include anything with the >>>> LSB set...? >>>> >>>> In Modula-3-ese it would be more like the following: >>>> >>>> "REFANY can hold three types of objects. NIL, REF something or an >>>> implementation-defined other set of values that can only be accessed >>>> in an UNSAFE module. It is a checked runtime error to pass a >>>> 'REFANY >>>> of the third kind' to ISTYPE, NARROW, TYPECASE." [ Actually see my >>>> P.S. below! ] >>>> >>>> Then I propose we punt the handling of the new REFANYs to this >>>> unsafe module we spoke about above. As far as Modula-3 is >>>> concerned, >>>> there's just a set of values of (apparently) very little utility >>>> that can be represented by REFANY. If you think about it, this is >>>> really not so crazy. Any module that uses REFANY today is designed >>>> around to the fact that there are plenty of values of REFANY that >>>> can be of no interest to that module except for passing along to >>>> another module. (REFANY can easily represent a type which a module >>>> has no way of accessing *any* declaration of beyond just REFANY.) >>>> We're just adding some others, the only difference being that the >>>> new values are of no interest to any non-UNSAFE module. (Eh, >>>> technically this is already true for any reference type that is >>>> declared in an UNSAFE module today so one might argue we have in >>>> fact added nothing.) >>>> >>>>> >>>>> However, this does suggest a different and very simple linguistic >>>>> solution: Just have a new builtin type, say VERYOPAQUE, that >>>>> supports no operations other than moving it around, i.e., >>>>> assignment, bindings, passing as a parameter, etc. Only unsafe >>>>> code could do anyhing with it, by using LOOPHOLE. The only >>>>> problem is, would somebody then want one of these in a size other >>>>> than one word? >>>> >>>> This is nice, and we already have a candidate type, in fact: >>>> ADDRESS. >>>> But the problem is that the GC doesn't follow this even if the LSB >>>> is clear... which we *do* want. >>>> >>>> Why are you worried about getting it in sizes other than one word? >>>> That seems to me to be an application problem. If someone wants >>>> an ARRAY OF VERYOPAQUE is that a problem? >>>> >>>> Mika >>>> >>>> P.S. Illustration of the above, in today's Modula-3: >>>> >>>> UNSAFE MODULE Unsafe; >>>> >>>> (* this module is just declared UNSAFE to conform with the >>>> definition >>>> above, namely, that T can only be manipulated in an UNSAFE >>>> module, which this is! *) >>>> >>>> TYPE T = BRANDED OBJECT END; >>>> >>>> BEGIN >>>> Safe.P(NEW(T)) >>>> END Unsafe. >>>> >>>> (****************************************) >>>> >>>> MODULE Safe; >>>> >>>> PROCEDURE P(r : REFANY) = >>>> BEGIN >>>> NARROW(r, X); (* checked runtime error for all X *) >>>> >>>> ISTYPE(r, X); (* returns FALSE for all X except REFANY itself *) >>>> >>>> TYPECASE r OF >>>> X => (* only gets executed for X = REFANY *) >>>> END; >>>> END P; >>>> >>>> BEGIN END Safe. >>>> >>>> Actually is this behavior so bad for tagged integers? Since it is >>>> the behavior of existing code... why not keep it? Then you can even >>>> store a tagged integer in a RefList.T, say, even if that RefList.T >>>> uses NARROW or ISTYPE on the argument (I don't see why it would, but >>>> why not...?) >>>> >>>> >>>> >>>>> >>>>> Mika Nystrom wrote: >>>>>> Ah I should read my whole inbox before replying. >>>>>> >>>>>> I take it you would worry that in my proposal (to do this all in a >>>>>> library) the use of REFANY to store an integer could be abused >>>>>> somehow. That the Modula-3 type system (as it exists now) >>>>>> explicitly >>>>>> rules out doing such things, and therefore, a language change is >>>>>> necessary.... >>>>>> >>>>>> Mika >>>>>> >>>>>> Tony Hosking writes: >>>>>> >>>>>>> I like the notion of having a TAGGED INTEGER type that is a >>>>>>> hybrid >>>>>>> ordinal/reference. >>>>>>> >>>>>>> Subtyping rules for references would now be as follows: >>>>>>> >>>>>>> NULL <: REF T <: REFANY >>>>>>> TAGGED INTEGER <: REF T <: REFANY >>>>>>> >>>>>>> ROOT <: REFANY >>>>>>> NULL <: T OBJECT ... END <: T >>>>>>> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: >>>>>>> REFANY, not >>>>>>> T <: ADDRESS) >>>>>>> >>>>>>> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >>>>>>> type. Values of TAGGED INTEGER are non-pointer values similar >>>>>>> to the >>>>>>> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and >>>>>>> NARROW(x, >>>>>>> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to >>>>>>> ISTYPE(x, >>>>>>> NULL), NARROW(x, NULL), and TYPECODE(NULL). >>>>>> >>>>>>> Because TAGGED INTEGER is an ordinal we can extract the integer >>>>>>> value >>>>>>> it holds using ORD(x). >>>>>>> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >>>>>>> INTEGER). >>>>>>> >>>>>>> ***The only problem with this scheme is how to efficiently >>>>>>> perform run- >>>>>>> time tests for dereferencing NULL, and TAGGED INTEGER?*** >>>>>> >>>>>>> So, here is a slightly less elegant alternative that is probably >>>>>>> straightforward to implement. Introduce a separate TAGGED >>>>>>> hierarchy. >>>>>>> >>>>>>> NULL <: REF T <: REFANY >>>>>>> NULL <: UNTRACED REF T <: ADDRESS >>>>>>> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >>>>>>> >>>>>>> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >>>>>>> >>>>>>> ROOT <: REFANY >>>>>>> TAGGED ROOT <: TAGGED REFANY >>>>>>> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >>>>>>> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >>>>>>> >>>>>>> Note that NULL is not a subtype of T OBJECT ... END where T <: >>>>>>> TAGGED >>>>>>> REFANY. >>>>>>> >>>>>>> This way, tagged references only need a run-time test for the >>>>>>> tag on >>>>>>> dereference (we can throw an "attempt to dereference TAGGED >>>>>>> INTEGER" >>>>>>> at run time, just like we throw "attempt to dereference NIL" for >>>>>>> untagged references). This check can be a straightforward test >>>>>>> of the >>>>>>> low bit tag. Of course, the weird thing here is now that we >>>>>>> don't >>>>>>> have a single NULL value for TAGGED references --- we have >>>>>>> multiple >>>>>>> null values VAL(x, TAGGED INTEGER). Instead of asking "x == >>>>>>> NIL" we >>>>>>> must ask "ISTYPE(x, TAGGED INTEGER)". >>>>>>> >>>>>>> Of course, because TAGGED INTEGER is an ordinal, we can also >>>>>>> perform >>>>>>> the usual ordinal operations like INC(x), DEC(x), wherever x is >>>>>>> typed >>>>>>> TAGGED INTEGER. >>>>>>> >>>>>>> >>>>>>> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >>>>>>> >>>>>>> >>>>>>>> I spent quite a bit of time playing with a more general system >>>>>>>> where >>>>>>>> there is a set of "tagged" types, with (an implementation- >>>>>>>> defined >>>>>>>> subrange of) INTEGER and a reference type both being a subtype >>>>>>>> of a >>>>>>>> tagged type. It might have been tolerable, if it weren't for >>>>>>>> the >>>>>>>> interaction with object subtypes and opaque types, which quickly >>>>>>>> gets deep into a deep linguistic tar pit. >>>>>>>> >>>>>>>> Tony's approach is much simpler and would serve what I see as >>>>>>>> the >>>>>>>> need. It does sacrifice any static checking of what reference >>>>>>>> type >>>>>>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>>>>>> TYPECASE. >>>>>>>> >>>>>>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>>>>>> also need to be an explicit conversion in that direction too, >>>>>>>> say >>>>>>>> VAL(x, TAGGED)? I think I favor the explicit conversion >>>>>>>> here. It >>>>>>>> is a bit inconsistent with the usual Modula-3 assignability >>>>>>>> philosophy, >>>>>>>> but not requiring the explicit conversion already gets your toes >>>>>>>> into tar. >>>>>>>> >>>>>>>> We would have to have something more like ISTYPE, though, >>>>>>>> which will >>>>>>>> tell which type the value belongs to without risking a runtime >>>>>>>> error, >>>>>>>> which VAL would do. >>>>>>>> >>>>>>>> An intermediate approach might be to have a set of tagged types >>>>>>>> constructed by, say, TAGGED T, where I is a reference type, but >>>>>>>> with no subtype relations on them at all, thus still requiring >>>>>>>> the explicit conversions and checks. >>>>>>>> >>>>>>>> I do want to say, I _really_ want this capability somehow. I >>>>>>>> have >>>>>>>> an ADT module whose internal data structure, for full >>>>>>>> generality, >>>>>>>> needs to have two heap objects (the second because it has >>>>>>>> nonstatic >>>>>>>> size) and 11 total words counting the orginal pointer, in the >>>>>>>> case of >>>>>>>> values that would fit directly into the "pointer" word. >>>>>>>> Moreover, >>>>>>>> these small cases are in the great majority. >>>>>>>> >>>>>>>> Besides the 11-to-one increase in actual occupied space, there >>>>>>>> is extra time for allocation, periodic tracing, and >>>>>>>> collection, space >>>>>>>> loss due to heap fragmentation, and time/space tradeoff loss >>>>>>>> due to >>>>>>>> reduced locality of reference. So sometimes, it would be a big >>>>>>>> performance gain if we could do it. >>>>>>>> >>>>>>>> >>>>>>>> Tony Hosking wrote: >>>>>>>> >>>>>>>>> It is a much more pervasive hack than I would be comfortable >>>>>>>>> with >>>>>>>>> since it touches on the compiler (for all the type >>>>>>>>> operations) as >>>>>>>>> well >>>>>>>>> as the run-time system in ways that are pretty gross. I >>>>>>>>> would much >>>>>>>>> rather have a new TAGGED builtin. ISTYPE would not work on >>>>>>>>> it since >>>>>>>>> that only works on references. The only thing you need is a >>>>>>>>> way to >>>>>>>>> extract the value -- we could overload VAL(x, T) where x can >>>>>>>>> be a >>>>>>>>> TAGGED and T can be REFANY or INTEGER. >>>>>>>>> >>>>>>>>> >>>>>> >>>>>> From hosking at cs.purdue.edu Tue Apr 7 11:27:04 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 19:27:04 +1000 Subject: [M3devel] small objects In-Reply-To: <200904070727.n377RDug014714@camembert.async.caltech.edu> References: <200904070727.n377RDug014714@camembert.async.caltech.edu> Message-ID: <46A56B65-6B75-47E8-ABDC-CBFC357594CE@cs.purdue.edu> Exactly! I really like this. But why wouldn't the pickler have a special for tagged REFANY? By the way, I think it is language definition agnostic - the behaviours are consistent with the spec: > ISTYPE (x: Reference; T: RefType) : BOOLEAN x a tagged REFANY returns FALSE, unless T is REFANY > ISTYPE(x, T) is TRUE if and only if x is a member of T. T must be an > object type or traced reference type, and x must be assignable to T. > NARROW (x: Reference; T: RefType): T > x a tagged REFANY causes a runtime error > NARROW(x, T) returns x after checking that x is a member of T. If > the check fails, a runtime error occurs. T must be an object type or > traced reference type, and x must be assignable to T. > > TYPECODE (T: RefType) : CARDINAL > (r: REFANY) : CARDINAL > r a tagged REFANY returns RT0.RefanyTypecode > (r: UNTRACED ROOT) : CARDINAL > > Every object type or traced reference type (including NULL) has an > associated integer code. Different types have different codes. The > code for a type is constant for any single execution of a program, > but may differ for different executions. TYPECODE(T) returns the > code for the type T and TYPECODE(r) returns the code for the > allocated type of r. It is a static error if T is REFANY or is not > an object type or traced reference type. Does anyone have a good reason why TYPECODE(REFANY) should be a static error? On 7 Apr 2009, at 17:27, Mika Nystrom wrote: > Oh I see. I think... > > You're saying that because RT0.RefanyTypecode is essentially > "useless", it's OK to have values with that typecode since no > (existing) module can do anything with that knowledge? > > So...this proposal says that ISTYPE returns FALSE for everything > except ISTYPE(r,REFANY). > > TYPECASE, same. > > TYPECODE, as you say, RT0.RefanyTypecode. > > In other words, it's a useless value except for whatever unsafe code > is lurking inside TaggedInteger. > > So normally, TYPECODE never returns RT0.RefanyTypecode? That's the > only thing that would change as far as I can tell... I can't see how > that could possibly break anything. > > Checking for the tagged integers can then be done by checking whether > TYPECODE returns RT0.RefanyTypecode. The pickler would build an > object when it sees that and pickle that, instead of the tagged > integer. > > So change the language spec to allow the above behavior for a value > of type REFANY and to say that unsafe modules may be able to do > some other implementation-dependent things with these 'REFANYs of > the third kind'? > > Mika > > > Tony Hosking writes: >> erratum: >> >> TYPECODE(r) = RT0.RefanyTypecode if r is a tagged REFANY. >> >> (It is a static error to say TYPECODE(REFANY)) >> >> On 7 Apr 2009, at 16:55, Tony Hosking wrote: >> >>> After all of this -- I may simply be coming back around to your >>> original proposal -- why not simply declare: >>> >>> TaggedInteger.T = REFANY; >>> >>> ? >>> >>> You can't instantiate a REFANY. >>> >>> All we really need is the LOOPHOLEing of your original proposal to >>> extract the integer values, and to make sure that ISTYPE and NARROW >>> have the behavior you describe for tagged REFANY. Does it make >>> sense that TYPECODE(r) = TYPECODE(REFANY) for any tagged REFANY? >>> What else are we missing? >>> >>> On 7 Apr 2009, at 06:39, Mika Nystrom wrote: >>> >>>> And finally, to forestall a possible objection to the scheme >>>> I proposed: >>>> >>>> Yes, it is true that even a non-UNSAFE module can allocate a >>>> TaggedInteger.T by calling >>>> >>>> new := RTAllocator.NewTraced(TYPECODE(r)) >>>> >>>> where r is a tagged integer. >>>> >>>> But since it cannot dereference that new value or do anything else >>>> with it, I don't think this is a problem. The Pickler (built into >>>> the TaggedInteger module, one must assume) would simply have to >>>> be on the lookout for values of the "real" TaggedInteger.T versus >>>> those that are just numbers with the LSB set, and act accordingly. >>>> Since the T declaration is only visible within the UNSAFE module >>>> there can never be any question of another module's muddling the >>>> two types up. >>>> >>>> Mika >>>> >>>> Mika Nystrom writes: >>>>> "Rodney M. Bates" writes: >>>>>> At first, I just envisioned implementing a small object type >>>>>> entirely inside an UNSAFE module, using unsafe operations >>>>>> to construct/test/separate the values. I think if the GC were >>>>>> to just to ignore words in heap objects that the type system >>>>>> claims are unambiguously pointers but actually have misaligned >>>>>> values, this could be done. >>>>> >>>>> Right that's precisely what the module I posted does. >>>>> >>>>>> >>>>>> But it flies in the face of a fundamental principle of Modula-3, >>>>>> namely that an UNSAFE module, if coded correctly, can prevent >>>>>> all other code from consequences of the unsafety. Unfortunately, >>>>>> this can't be done with the small pointers, because, even if >>>>>> opaque, they are still reference types, and client code can >>>>>> dereference them (including the implicit dereference in accessing >>>>>> a method or field of an object) and do ISTYPE, NARROW, TYPECASE, >>>>>> and assignments that do an implicit NARROW. All these operations >>>>>> could be done outside the implementing module and all could >>>>>> suffer from misaligned values. >>>>> >>>>> Well yes that is true. But the client can't dereference REFANY. >>>>> Modula-3 doesn't permit that. That's an important practical >>>>> point, >>>>> because now we're limited to the other things: ISTYPE, NARROW >>>>> (implicit and explicit), TYPECASE. (There are two more, actually, >>>>> and they are = and #.) As long as those can be guaranteed to fail >>>>> you're OK. [ Actually see my P.S. below! ] >>>>> >>>>>> >>>>>> In fact, misaligned integer "objects" violate another principle >>>>>> that >>>>>> the bit pattern must always be a valid representation of some >>>>>> value >>>>>> of the type. >>>>> >>>>> Yes I think maybe this is what Tony is worried about. But let's >>>>> just change the definition of REFANY to include anything with the >>>>> LSB set...? >>>>> >>>>> In Modula-3-ese it would be more like the following: >>>>> >>>>> "REFANY can hold three types of objects. NIL, REF something or an >>>>> implementation-defined other set of values that can only be >>>>> accessed >>>>> in an UNSAFE module. It is a checked runtime error to pass a >>>>> 'REFANY >>>>> of the third kind' to ISTYPE, NARROW, TYPECASE." [ Actually see my >>>>> P.S. below! ] >>>>> >>>>> Then I propose we punt the handling of the new REFANYs to this >>>>> unsafe module we spoke about above. As far as Modula-3 is >>>>> concerned, >>>>> there's just a set of values of (apparently) very little utility >>>>> that can be represented by REFANY. If you think about it, this is >>>>> really not so crazy. Any module that uses REFANY today is >>>>> designed >>>>> around to the fact that there are plenty of values of REFANY that >>>>> can be of no interest to that module except for passing along to >>>>> another module. (REFANY can easily represent a type which a >>>>> module >>>>> has no way of accessing *any* declaration of beyond just REFANY.) >>>>> We're just adding some others, the only difference being that the >>>>> new values are of no interest to any non-UNSAFE module. (Eh, >>>>> technically this is already true for any reference type that is >>>>> declared in an UNSAFE module today so one might argue we have in >>>>> fact added nothing.) >>>>> >>>>>> >>>>>> However, this does suggest a different and very simple linguistic >>>>>> solution: Just have a new builtin type, say VERYOPAQUE, that >>>>>> supports no operations other than moving it around, i.e., >>>>>> assignment, bindings, passing as a parameter, etc. Only unsafe >>>>>> code could do anyhing with it, by using LOOPHOLE. The only >>>>>> problem is, would somebody then want one of these in a size other >>>>>> than one word? >>>>> >>>>> This is nice, and we already have a candidate type, in fact: >>>>> ADDRESS. >>>>> But the problem is that the GC doesn't follow this even if the LSB >>>>> is clear... which we *do* want. >>>>> >>>>> Why are you worried about getting it in sizes other than one word? >>>>> That seems to me to be an application problem. If someone wants >>>>> an ARRAY OF VERYOPAQUE is that a problem? >>>>> >>>>> Mika >>>>> >>>>> P.S. Illustration of the above, in today's Modula-3: >>>>> >>>>> UNSAFE MODULE Unsafe; >>>>> >>>>> (* this module is just declared UNSAFE to conform with the >>>>> definition >>>>> above, namely, that T can only be manipulated in an UNSAFE >>>>> module, which this is! *) >>>>> >>>>> TYPE T = BRANDED OBJECT END; >>>>> >>>>> BEGIN >>>>> Safe.P(NEW(T)) >>>>> END Unsafe. >>>>> >>>>> (****************************************) >>>>> >>>>> MODULE Safe; >>>>> >>>>> PROCEDURE P(r : REFANY) = >>>>> BEGIN >>>>> NARROW(r, X); (* checked runtime error for all X *) >>>>> >>>>> ISTYPE(r, X); (* returns FALSE for all X except REFANY itself *) >>>>> >>>>> TYPECASE r OF >>>>> X => (* only gets executed for X = REFANY *) >>>>> END; >>>>> END P; >>>>> >>>>> BEGIN END Safe. >>>>> >>>>> Actually is this behavior so bad for tagged integers? Since it is >>>>> the behavior of existing code... why not keep it? Then you can >>>>> even >>>>> store a tagged integer in a RefList.T, say, even if that RefList.T >>>>> uses NARROW or ISTYPE on the argument (I don't see why it would, >>>>> but >>>>> why not...?) >>>>> >>>>> >>>>> >>>>>> >>>>>> Mika Nystrom wrote: >>>>>>> Ah I should read my whole inbox before replying. >>>>>>> >>>>>>> I take it you would worry that in my proposal (to do this all >>>>>>> in a >>>>>>> library) the use of REFANY to store an integer could be abused >>>>>>> somehow. That the Modula-3 type system (as it exists now) >>>>>>> explicitly >>>>>>> rules out doing such things, and therefore, a language change is >>>>>>> necessary.... >>>>>>> >>>>>>> Mika >>>>>>> >>>>>>> Tony Hosking writes: >>>>>>> >>>>>>>> I like the notion of having a TAGGED INTEGER type that is a >>>>>>>> hybrid >>>>>>>> ordinal/reference. >>>>>>>> >>>>>>>> Subtyping rules for references would now be as follows: >>>>>>>> >>>>>>>> NULL <: REF T <: REFANY >>>>>>>> TAGGED INTEGER <: REF T <: REFANY >>>>>>>> >>>>>>>> ROOT <: REFANY >>>>>>>> NULL <: T OBJECT ... END <: T >>>>>>>> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: >>>>>>>> REFANY, not >>>>>>>> T <: ADDRESS) >>>>>>>> >>>>>>>> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/ >>>>>>>> reference >>>>>>>> type. Values of TAGGED INTEGER are non-pointer values similar >>>>>>>> to the >>>>>>>> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and >>>>>>>> NARROW(x, >>>>>>>> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to >>>>>>>> ISTYPE(x, >>>>>>>> NULL), NARROW(x, NULL), and TYPECODE(NULL). >>>>>>> >>>>>>>> Because TAGGED INTEGER is an ordinal we can extract the integer >>>>>>>> value >>>>>>>> it holds using ORD(x). >>>>>>>> Similarly, we can construct a TAGGED INTEGER using VAL(x, >>>>>>>> TAGGED >>>>>>>> INTEGER). >>>>>>>> >>>>>>>> ***The only problem with this scheme is how to efficiently >>>>>>>> perform run- >>>>>>>> time tests for dereferencing NULL, and TAGGED INTEGER?*** >>>>>>> >>>>>>>> So, here is a slightly less elegant alternative that is >>>>>>>> probably >>>>>>>> straightforward to implement. Introduce a separate TAGGED >>>>>>>> hierarchy. >>>>>>>> >>>>>>>> NULL <: REF T <: REFANY >>>>>>>> NULL <: UNTRACED REF T <: ADDRESS >>>>>>>> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >>>>>>>> >>>>>>>> Note that NULL is not a subtype of TAGGED REF T or TAGGED >>>>>>>> REFANY. >>>>>>>> >>>>>>>> ROOT <: REFANY >>>>>>>> TAGGED ROOT <: TAGGED REFANY >>>>>>>> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >>>>>>>> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED >>>>>>>> REFANY >>>>>>>> >>>>>>>> Note that NULL is not a subtype of T OBJECT ... END where T <: >>>>>>>> TAGGED >>>>>>>> REFANY. >>>>>>>> >>>>>>>> This way, tagged references only need a run-time test for the >>>>>>>> tag on >>>>>>>> dereference (we can throw an "attempt to dereference TAGGED >>>>>>>> INTEGER" >>>>>>>> at run time, just like we throw "attempt to dereference NIL" >>>>>>>> for >>>>>>>> untagged references). This check can be a straightforward test >>>>>>>> of the >>>>>>>> low bit tag. Of course, the weird thing here is now that we >>>>>>>> don't >>>>>>>> have a single NULL value for TAGGED references --- we have >>>>>>>> multiple >>>>>>>> null values VAL(x, TAGGED INTEGER). Instead of asking "x == >>>>>>>> NIL" we >>>>>>>> must ask "ISTYPE(x, TAGGED INTEGER)". >>>>>>>> >>>>>>>> Of course, because TAGGED INTEGER is an ordinal, we can also >>>>>>>> perform >>>>>>>> the usual ordinal operations like INC(x), DEC(x), wherever x is >>>>>>>> typed >>>>>>>> TAGGED INTEGER. >>>>>>>> >>>>>>>> >>>>>>>> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >>>>>>>> >>>>>>>> >>>>>>>>> I spent quite a bit of time playing with a more general system >>>>>>>>> where >>>>>>>>> there is a set of "tagged" types, with (an implementation- >>>>>>>>> defined >>>>>>>>> subrange of) INTEGER and a reference type both being a subtype >>>>>>>>> of a >>>>>>>>> tagged type. It might have been tolerable, if it weren't for >>>>>>>>> the >>>>>>>>> interaction with object subtypes and opaque types, which >>>>>>>>> quickly >>>>>>>>> gets deep into a deep linguistic tar pit. >>>>>>>>> >>>>>>>>> Tony's approach is much simpler and would serve what I see as >>>>>>>>> the >>>>>>>>> need. It does sacrifice any static checking of what reference >>>>>>>>> type >>>>>>>>> is being tagged, and will also require an extra runtime >>>>>>>>> ISTYPE/ >>>>>>>>> TYPECASE. >>>>>>>>> >>>>>>>>> Would INTEGER and REFANY be assignable to TAGGED, or would >>>>>>>>> there >>>>>>>>> also need to be an explicit conversion in that direction too, >>>>>>>>> say >>>>>>>>> VAL(x, TAGGED)? I think I favor the explicit conversion >>>>>>>>> here. It >>>>>>>>> is a bit inconsistent with the usual Modula-3 assignability >>>>>>>>> philosophy, >>>>>>>>> but not requiring the explicit conversion already gets your >>>>>>>>> toes >>>>>>>>> into tar. >>>>>>>>> >>>>>>>>> We would have to have something more like ISTYPE, though, >>>>>>>>> which will >>>>>>>>> tell which type the value belongs to without risking a runtime >>>>>>>>> error, >>>>>>>>> which VAL would do. >>>>>>>>> >>>>>>>>> An intermediate approach might be to have a set of tagged >>>>>>>>> types >>>>>>>>> constructed by, say, TAGGED T, where I is a reference type, >>>>>>>>> but >>>>>>>>> with no subtype relations on them at all, thus still requiring >>>>>>>>> the explicit conversions and checks. >>>>>>>>> >>>>>>>>> I do want to say, I _really_ want this capability somehow. I >>>>>>>>> have >>>>>>>>> an ADT module whose internal data structure, for full >>>>>>>>> generality, >>>>>>>>> needs to have two heap objects (the second because it has >>>>>>>>> nonstatic >>>>>>>>> size) and 11 total words counting the orginal pointer, in the >>>>>>>>> case of >>>>>>>>> values that would fit directly into the "pointer" word. >>>>>>>>> Moreover, >>>>>>>>> these small cases are in the great majority. >>>>>>>>> >>>>>>>>> Besides the 11-to-one increase in actual occupied space, there >>>>>>>>> is extra time for allocation, periodic tracing, and >>>>>>>>> collection, space >>>>>>>>> loss due to heap fragmentation, and time/space tradeoff loss >>>>>>>>> due to >>>>>>>>> reduced locality of reference. So sometimes, it would be a >>>>>>>>> big >>>>>>>>> performance gain if we could do it. >>>>>>>>> >>>>>>>>> >>>>>>>>> Tony Hosking wrote: >>>>>>>>> >>>>>>>>>> It is a much more pervasive hack than I would be comfortable >>>>>>>>>> with >>>>>>>>>> since it touches on the compiler (for all the type >>>>>>>>>> operations) as >>>>>>>>>> well >>>>>>>>>> as the run-time system in ways that are pretty gross. I >>>>>>>>>> would much >>>>>>>>>> rather have a new TAGGED builtin. ISTYPE would not work on >>>>>>>>>> it since >>>>>>>>>> that only works on references. The only thing you need is a >>>>>>>>>> way to >>>>>>>>>> extract the value -- we could overload VAL(x, T) where x can >>>>>>>>>> be a >>>>>>>>>> TAGGED and T can be REFANY or INTEGER. >>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Apr 7 13:49:58 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 7 Apr 2009 07:49:58 -0400 Subject: [M3devel] small objects In-Reply-To: <985F59A0-82EA-4F55-B6C8-DA057B9E23DB@cs.purdue.edu> References: <200904070042.n370gNK3001242@camembert.async.caltech.edu> <9F2237E2-73A2-4926-A438-A6032F70B4F6@cs.purdue.edu> <49DA8196.1E75.00D7.1@scires.com> <985F59A0-82EA-4F55-B6C8-DA057B9E23DB@cs.purdue.edu> Message-ID: <20090407114957.GA27695@topoi.pooq.com> On Tue, Apr 07, 2009 at 12:52:59PM +1000, Tony Hosking wrote: > On 7 Apr 2009, at 12:27, Randy Coleburn wrote: > > >Hey, will this proposal mean that packages like "stable" and > >"stubgen" need to be changed also, in addition to both versions of > >pickles? > > They build on m3tk so should just work, modulo any builtin typecode > information. TAGGED INTEGER will have a predefined typecode just like > NULL. I'm confused. I thought the only tagged types were reference types. -- hendrik From hendrik at topoi.pooq.com Tue Apr 7 14:12:17 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 7 Apr 2009 08:12:17 -0400 Subject: [M3devel] small objects In-Reply-To: References: <200904062039.n36KdIsY095003@camembert.async.caltech.edu> Message-ID: <20090407121217.GB27695@topoi.pooq.com> On Tue, Apr 07, 2009 at 04:55:12PM +1000, Tony Hosking wrote: > After all of this -- I may simply be coming back around to your > original proposal -- why not simply declare: > > TaggedInteger.T = REFANY; You'd be adding a range of integers to the set of things a REFANY could hold. Might that enable one to pass these integers as REFANYs to existing code that isn't expecting it? Might code that checks its input for suitable preconditions then let this case slide? Or would any test that checks that a REFANY holds an appropriate reference or NIL automatically manage to exclude tagged integers, just as it excludes inappropriate references? I don't mind the proposed semantics for REFANY -- if it had been there from the beginning. But with a lot of existing code in existing libraries, would it be safer to use a new type for this new meaning? You could, of course, stull have an unsafe module that defines TaggedInteger.T = NEWTYPEWITHNEWNAME; -- hendrik From hendrik at topoi.pooq.com Tue Apr 7 14:21:28 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 7 Apr 2009 08:21:28 -0400 Subject: [M3devel] small objects In-Reply-To: <200904070727.n377RDug014714@camembert.async.caltech.edu> References: <200904070727.n377RDug014714@camembert.async.caltech.edu> Message-ID: <20090407122128.GC27695@topoi.pooq.com> On Tue, Apr 07, 2009 at 12:27:13AM -0700, Mika Nystrom wrote: > Oh I see. I think... > > You're saying that because RT0.RefanyTypecode is essentially > "useless", it's OK to have values with that typecode since no > (existing) module can do anything with that knowledge? This looks like inelegant semantics. A way of retrofitting a new feature in an existing semantic gap. The kind of patch that will bite us if ever there is a proper use for the typecode for REFANY. (I can imagine someday someone might have a use for such a thing, such as a dynamic test on typecodes to determine whether one type is a subtypoe of another ... I can't really imagine what someone might need in the future). But I thing this kind of thing might really stand in the way. REFANY is about references. Let's have a new type, with its own typecode, for things that can be other than references. -- hendrik From hosking at cs.purdue.edu Tue Apr 7 14:26:08 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 22:26:08 +1000 Subject: [M3devel] small objects In-Reply-To: <20090407121217.GB27695@topoi.pooq.com> References: <200904062039.n36KdIsY095003@camembert.async.caltech.edu> <20090407121217.GB27695@topoi.pooq.com> Message-ID: You can't do anything directly with a REFANY. To use it you need to narrow to a concrete type. We would disallow that for tagged values with a run-time check. Existing code needs to check (using ISTYPE or TYPECASE), or know by design, what type is safe to narrow to, before narrowing anyway. So I think all is ok. On 7 Apr 2009, at 22:12, hendrik at topoi.pooq.com wrote: > On Tue, Apr 07, 2009 at 04:55:12PM +1000, Tony Hosking wrote: >> After all of this -- I may simply be coming back around to your >> original proposal -- why not simply declare: >> >> TaggedInteger.T = REFANY; > > You'd be adding a range of integers to the set of things a REFANY > could > hold. Might that enable one to pass these integers as REFANYs to > existing code that isn't expecting it? Might code that checks its > input > for suitable preconditions then let this case slide? Or would any > test > that checks that a REFANY holds an appropriate reference or NIL > automatically manage to exclude tagged integers, just as it excludes > inappropriate references? > > I don't mind the proposed semantics for REFANY -- if it had been > there from the beginning. But with a lot of existing code in existing > libraries, would it be safer to use a new type for this new meaning? > > You could, of course, stull have an unsafe module that defines > > TaggedInteger.T = NEWTYPEWITHNEWNAME; > > -- hendrik From mika at async.caltech.edu Tue Apr 7 19:12:55 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 07 Apr 2009 10:12:55 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Tue, 07 Apr 2009 22:26:08 +1000." Message-ID: <200904071712.n37HCtda030844@camembert.async.caltech.edu> Tony, I think you have convinced me that what you say is workable. However I share Hendrik's concern that using RT0.RefanyTypecode might hurt some day in the future, even if I think you have shown pretty convincingly that it doesn't hurt today. How about my "second proposal". Do pretty much what you suggest but instead of returning RT0.RefanyTypecode, return TYPECODE(TaggedInteger.T), where TaggedInteger.T is an object type that is declared entirely privately to the TaggedInteger unsafe module... this also gives a completely obvious implementation for pickling the tagged integers. Simply convert them to TaggedInteger.T and pickle that. An implementation that doesn't support tagged integers in pointers could also allocate "real" TaggedInteger.Ts.... not sure that is useful though or if it just confuses. Actually I think it is useful, because it lets you represent the values even if unpickling in a system that doesn't support tagged integers in REFANYs. I would go so far as saying this... I believe it is possible to guarantee that any safe code outside of the TaggedInteger module couldn't distinguish between a REFANY that holds a tagged integer vs. one that holds a reference to a (heap-allocated) TaggedInteger.T. How's that for not breaking the language definition? Hendrik, I think Tony's and my arguments that you can't break any existing code by allowing the squirreling away of integers into REFANYs are pretty solid. Pre-existing code simply can't do anything useful with unrevealed REFANYs. There are also good reasons for permitting this oddness (vide Smalltalk and Scheme small integers). Mika Tony Hosking writes: >You can't do anything directly with a REFANY. To use it you need to >narrow to a concrete type. We would disallow that for tagged values >with a run-time check. Existing code needs to check (using ISTYPE or >TYPECASE), or know by design, what type is safe to narrow to, before >narrowing anyway. So I think all is ok. > >On 7 Apr 2009, at 22:12, hendrik at topoi.pooq.com wrote: > >> On Tue, Apr 07, 2009 at 04:55:12PM +1000, Tony Hosking wrote: >>> After all of this -- I may simply be coming back around to your >>> original proposal -- why not simply declare: >>> >>> TaggedInteger.T = REFANY; >> >> You'd be adding a range of integers to the set of things a REFANY >> could >> hold. Might that enable one to pass these integers as REFANYs to >> existing code that isn't expecting it? Might code that checks its >> input >> for suitable preconditions then let this case slide? Or would any >> test >> that checks that a REFANY holds an appropriate reference or NIL >> automatically manage to exclude tagged integers, just as it excludes >> inappropriate references? >> >> I don't mind the proposed semantics for REFANY -- if it had been >> there from the beginning. But with a lot of existing code in existing >> libraries, would it be safer to use a new type for this new meaning? >> >> You could, of course, stull have an unsafe module that defines >> >> TaggedInteger.T = NEWTYPEWITHNEWNAME; >> >> -- hendrik From rodney.m.bates at cox.net Tue Apr 7 18:11:48 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Tue, 07 Apr 2009 11:11:48 -0500 Subject: [M3devel] small objects In-Reply-To: <40B7AD71-FBDD-4321-837F-D294DD4A3D45@cs.purdue.edu> References: <200903300333.n2U3XBME062502@camembert.async.caltech.edu> <49D95E70.6000004@wichita.edu> <40B7AD71-FBDD-4321-837F-D294DD4A3D45@cs.purdue.edu> Message-ID: <49DB7B44.2000000@cox.net> Tagged types and object type hierarchies: At first, I was imagining that you could create an object subtype of a TAGGED type: (* An untagged hierarchy: *) TYPE O1 = OBJECT F1: INTEGER END; TYPE O2 = O1 OBJECT F2: CHAR END; TYPE O3 = O2 OBJECT F3: BOOLEAN END: (* Tag each one directly: *) TYPE TO1 = TAGGED O1; TYPE TO2 = TAGGED O2; TYPE TO3 = TAGGED O3; (* A tagged hierarchy: *) TYPE TO2S = TO1 OBJECT F2: CHAR END; TYPE TO3S = TO2S OBJECT F3: BOOLEAN END; Is TO2S = TO2 and TO3S = TO3? Is O2 <: TO2S and O3 <: TO3S? Therein lies tar. The type equality and subtype relations are getting awfully elaborate for a language that advertises relative simplicity. Then I thought about two parallel hierarchies, one tagged and one not, as Tony's second proposal. But that leaves it awfully inconvenient to have both a tagged and untagged counterpart that are otherwise the same, and you need the untagged counterpart to do ISTYPE/NARROW/TYPECASE/:= to get the "definitely-a-heap-reference" value out of a tagged type. If I read it right, Tony's first proposal does not allow to subclass an already tagged type (i.e., no "tagged hierarchy" as above). Is that what you meant, Tony? If so, I think this is enough, and avoids the complicated type equality and subtype relations. A separate issue: On the INTEGER side of this, I think we need a builtin type that is an implementation-defined subrange of INTEGER, that can hold just the integer values a tagged type can hold. Maybe "TAG"? (Actually, this name is a poor choice, since it's not the tag itself, but it's the best I can think right now, so I will use it in discussion). If we really want to constrain the implementation to always use exactly the low bit as the tag, then CARDINAL would do for this. A new builtin type would leave open other tagging representations with other ranges of representable integers, as well as the low-bit tag with signed integers. Then we could also allow ISTYPE(x, TAG), etc. to get the "definitely-an- integer" value out. This gives fully type-safe support for small objects, which I really prefer, if not too complicated. Tony Hosking wrote: > I like the notion of having a TAGGED INTEGER type that is a hybrid > ordinal/reference. > > Subtyping rules for references would now be as follows: > > NULL <: REF T <: REFANY > TAGGED INTEGER <: REF T <: REFANY > > ROOT <: REFANY > NULL <: T OBJECT ... END <: T > TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: REFANY, not > T <: ADDRESS) > > Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference > type. Values of TAGGED INTEGER are non-pointer values similar to the > value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and NARROW(x, > TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to ISTYPE(x, > NULL), NARROW(x, NULL), and TYPECODE(NULL). > > Because TAGGED INTEGER is an ordinal we can extract the integer value > it holds using ORD(x). > Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED > INTEGER). > > ***The only problem with this scheme is how to efficiently perform > run-time tests for dereferencing NULL, and TAGGED INTEGER?*** > > So, here is a slightly less elegant alternative that is probably > straightforward to implement. Introduce a separate TAGGED hierarchy. > > NULL <: REF T <: REFANY > NULL <: UNTRACED REF T <: ADDRESS > TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY > > Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. > > ROOT <: REFANY > TAGGED ROOT <: TAGGED REFANY > NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS > TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY > > Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED > REFANY. > > This way, tagged references only need a run-time test for the tag on > dereference (we can throw an "attempt to dereference TAGGED INTEGER" > at run time, just like we throw "attempt to dereference NIL" for > untagged references). This check can be a straightforward test of the > low bit tag. Of course, the weird thing here is now that we don't > have a single NULL value for TAGGED references --- we have multiple > null values VAL(x, TAGGED INTEGER). Instead of asking "x == NIL" we > must ask "ISTYPE(x, TAGGED INTEGER)". > > Of course, because TAGGED INTEGER is an ordinal, we can also perform > the usual ordinal operations like INC(x), DEC(x), wherever x is typed > TAGGED INTEGER. > From mika at async.caltech.edu Tue Apr 7 20:33:05 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 07 Apr 2009 11:33:05 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Tue, 07 Apr 2009 11:11:48 CDT." <49DB7B44.2000000@cox.net> Message-ID: <200904071833.n37IX5Hg033221@camembert.async.caltech.edu> So following my previous email, I suggest the following, which doesn't change the language definition at all: INTERFACE TaggedInteger; IMPORT Word; TYPE T <: REFANY; V = [ TaggedMin .. TaggedMax ]; CONST TaggedMin = -Word.Shift(1,BITSIZE(REFANY)-2); TaggedMax = Word.Shift(1,BITSIZE(REFANY)-2) - 1; PROCECURE Extract(t : T) : V; PROCEDURE New(v : V) : T; (* ...the usual generic support routines... *) END TaggedInteger. The compiler, runtime, and the implementation of this interface would be responsible for hiding the values in REFANYs, doing the correct thing for NARROW, ISTYPE, TYPECASE, TYPECODE, # and =... What functionality is missing? I think the compiler/runtime changes are pretty much the same no matter which of the proposals you go with... Mika "Rodney M. Bates" writes: >Tagged types and object type hierarchies: > >At first, I was imagining that you could create >an object subtype of a TAGGED type: > >(* An untagged hierarchy: *) >TYPE O1 = OBJECT F1: INTEGER END; >TYPE O2 = O1 OBJECT F2: CHAR END; >TYPE O3 = O2 OBJECT F3: BOOLEAN END: > >(* Tag each one directly: *) >TYPE TO1 = TAGGED O1; >TYPE TO2 = TAGGED O2; >TYPE TO3 = TAGGED O3; > >(* A tagged hierarchy: *) >TYPE TO2S = TO1 OBJECT F2: CHAR END; >TYPE TO3S = TO2S OBJECT F3: BOOLEAN END; > >Is TO2S = TO2 and TO3S = TO3? > >Is O2 <: TO2S and O3 <: TO3S? > >Therein lies tar. The type equality and subtype relations are getting >awfully elaborate for a language that advertises relative simplicity. > >Then I thought about two parallel hierarchies, one tagged and one not, >as Tony's second proposal. But that leaves it awfully inconvenient >to have both a tagged and untagged counterpart that are otherwise the >same, and you need the untagged counterpart to do ISTYPE/NARROW/TYPECASE/:= >to get the "definitely-a-heap-reference" value out of a tagged type. > >If I read it right, Tony's first proposal does not allow to subclass an >already tagged type (i.e., no "tagged hierarchy" as above). Is that >what you meant, Tony? If so, I think this is enough, and avoids the >complicated type equality and subtype relations. > >A separate issue: > >On the INTEGER side of this, I think we need a builtin type that is an >implementation-defined subrange of INTEGER, that can hold just the >integer values a tagged type can hold. Maybe "TAG"? (Actually, this >name is a poor choice, since it's not the tag itself, but it's the best >I can think right now, so I will use it in discussion). > >If we really want to constrain the implementation to always use exactly >the low bit as the tag, then CARDINAL would do for this. A new builtin >type would leave open other tagging representations with other ranges of >representable integers, as well as the low-bit tag with signed integers. > >Then we could also allow ISTYPE(x, TAG), etc. to get the "definitely-an- >integer" value out. > >This gives fully type-safe support for small objects, which I really >prefer, if not too complicated. > > > >Tony Hosking wrote: >> I like the notion of having a TAGGED INTEGER type that is a hybrid >> ordinal/reference. >> >> Subtyping rules for references would now be as follows: >> >> NULL <: REF T <: REFANY >> TAGGED INTEGER <: REF T <: REFANY >> >> ROOT <: REFANY >> NULL <: T OBJECT ... END <: T >> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: REFANY, not >> T <: ADDRESS) >> >> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >> type. Values of TAGGED INTEGER are non-pointer values similar to the >> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and NARROW(x, >> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to ISTYPE(x, >> NULL), NARROW(x, NULL), and TYPECODE(NULL). >> >> Because TAGGED INTEGER is an ordinal we can extract the integer value >> it holds using ORD(x). >> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >> INTEGER). >> >> ***The only problem with this scheme is how to efficiently perform >> run-time tests for dereferencing NULL, and TAGGED INTEGER?*** >> >> So, here is a slightly less elegant alternative that is probably >> straightforward to implement. Introduce a separate TAGGED hierarchy. >> >> NULL <: REF T <: REFANY >> NULL <: UNTRACED REF T <: ADDRESS >> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >> >> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >> >> ROOT <: REFANY >> TAGGED ROOT <: TAGGED REFANY >> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >> >> Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED >> REFANY. >> >> This way, tagged references only need a run-time test for the tag on >> dereference (we can throw an "attempt to dereference TAGGED INTEGER" >> at run time, just like we throw "attempt to dereference NIL" for >> untagged references). This check can be a straightforward test of the >> low bit tag. Of course, the weird thing here is now that we don't >> have a single NULL value for TAGGED references --- we have multiple >> null values VAL(x, TAGGED INTEGER). Instead of asking "x == NIL" we >> must ask "ISTYPE(x, TAGGED INTEGER)". >> >> Of course, because TAGGED INTEGER is an ordinal, we can also perform >> the usual ordinal operations like INC(x), DEC(x), wherever x is typed >> TAGGED INTEGER. >> From hendrik at topoi.pooq.com Tue Apr 7 23:28:53 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 7 Apr 2009 17:28:53 -0400 Subject: [M3devel] small objects In-Reply-To: <200904071712.n37HCtda030844@camembert.async.caltech.edu> References: <200904071712.n37HCtda030844@camembert.async.caltech.edu> Message-ID: <20090407212853.GB32252@topoi.pooq.com> On Tue, Apr 07, 2009 at 10:12:55AM -0700, Mika Nystrom wrote: > Tony, > > I think you have convinced me that what you say is workable. > > However I share Hendrik's concern that using RT0.RefanyTypecode > might hurt some day in the future, even if I think you have shown > pretty convincingly that it doesn't hurt today. I share this concern :-) > How about my "second > proposal". Do pretty much what you suggest but instead of returning > RT0.RefanyTypecode, return TYPECODE(TaggedInteger.T), where > TaggedInteger.T is an object type that is declared entirely privately > to the TaggedInteger unsafe module... this also gives a completely > obvious implementation for pickling the tagged integers. Simply > convert them to TaggedInteger.T and pickle that. An implementation > that doesn't support tagged integers in pointers could also allocate > "real" TaggedInteger.Ts.... not sure that is useful though or if > it just confuses. Actually I think it is useful, because it lets > you represent the values even if unpickling in a system that doesn't > support tagged integers in REFANYs. That may even work. It would take some thinking to be sure it always works, though. And ... could the "real" TaggedInteger.T's be used even when the integers that would be packed into pointers end up being out-of-bounds? > > I would go so far as saying this... I believe it is possible to > guarantee that any safe code outside of the TaggedInteger module > couldn't distinguish between a REFANY that holds a tagged integer > vs. one that holds a reference to a (heap-allocated) TaggedInteger.T. > How's that for not breaking the language definition? I agree. > > Hendrik, I think Tony's and my arguments that you can't break any > existing code by allowing the squirreling away of integers into > REFANYs are pretty solid. Pre-existing code simply can't do anything > useful with unrevealed REFANYs. There are also good reasons for > permitting this oddness (vide Smalltalk and Scheme small integers). > > Mika From hendrik at topoi.pooq.com Tue Apr 7 23:31:12 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 7 Apr 2009 17:31:12 -0400 Subject: [M3devel] small objects In-Reply-To: <49DB7B44.2000000@cox.net> References: <200903300333.n2U3XBME062502@camembert.async.caltech.edu> <49D95E70.6000004@wichita.edu> <40B7AD71-FBDD-4321-837F-D294DD4A3D45@cs.purdue.edu> <49DB7B44.2000000@cox.net> Message-ID: <20090407213112.GC32252@topoi.pooq.com> On Tue, Apr 07, 2009 at 11:11:48AM -0500, Rodney M. Bates wrote: > > A separate issue: > > On the INTEGER side of this, I think we need a builtin type that is an > implementation-defined subrange of INTEGER, that can hold just the > integer values a tagged type can hold. Maybe "TAG"? (Actually, this > name is a poor choice, since it's not the tag itself, but it's the best > I can think right now, so I will use it in discussion). Choosing good names is always difficult. -- hendrik From mika at async.caltech.edu Wed Apr 8 00:14:08 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 07 Apr 2009 15:14:08 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Tue, 07 Apr 2009 17:25:25 EDT." <20090407212524.GA32252@topoi.pooq.com> Message-ID: <200904072214.n37ME8Pj039105@camembert.async.caltech.edu> > >I'm inclined to accept these arguments. Now it's time to come up with >really good names for these things. > >-- hendrik Smalltalk punnily calls them "SmallIntegers". In Scheme they are "fixnums". Oh... I should add, if Tony can figure out a way to do what I proposed, an advantage of providing the interface is that a trivial, safe implementation can be used for compatibility with older compilers. (Yes I still sometimes use PM3 even though I am in fact slowly converting.) Mika From jay.krell at cornell.edu Wed Apr 8 03:03:06 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 8 Apr 2009 01:03:06 +0000 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: <20090406175119.5nknbzf9dwkcwkks@mail.elegosoft.com> References: <200904061532.n36FWunc087102@camembert.async.caltech.edu> <20090406175119.5nknbzf9dwkcwkks@mail.elegosoft.com> Message-ID: Relinking upon install I still think provides desired results and is not a terrible idea, but it is more work to implement. I think the perf is probably acceptable. I don't like to expose too many options to uninformed users, but making this an option might be good. It will have an acceptable default, which makes it being an option much less bad. It's not just one option. There is: 1) using the local machine's install point -- /usr/local/cm3/lib, 2) vs. using $ORIGIN/../lib. Not available on all systems. 3) vs. using package store paths 4) vs. using source tree paths and they can be combined, in various orders. Plus Darwin is different, though maybe Darwin 10.5 is the same. (certainly not pre-10.5 though). I also still think this is related to "buildlocal" vs. " buildship". In fact that is already partly accounted for. I think I didn't understand the full state of things. [I think] You were always getting big runpaths. [I think] They were either to installed libraries or uninstalled libraries. If they were to uinstalled binaries, you could not ship -- buildlocal. [I think] Now we are moving toward always small runpaths, always pointing to installed libraries. This is dubious for buildlocal. [I think] Buildlocal should probably retain its old behavior -- big runpaths, into the source tree. Or maybe a list of paths, source tree followed by install tree. So user might build some of his own shared libraries, but not necessarily all. I should set that -Wl,-R thing based on local vs. global. I didn't look into how to detect that. More later. Yes, this is a more general question of how to find dependant shared libraries. I don't think anyone has solved it all that well, nor do I believe we will, but there are still some better and worse options. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.m.bates at cox.net Wed Apr 8 03:49:46 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Tue, 07 Apr 2009 20:49:46 -0500 Subject: [M3devel] small objects In-Reply-To: <200904071712.n37HCtda030844@camembert.async.caltech.edu> References: <200904071712.n37HCtda030844@camembert.async.caltech.edu> Message-ID: <49DC02BA.8080900@cox.net> Mika Nystrom wrote: > Tony, > > I think you have convinced me that what you say is workable. > > However I share Hendrik's concern that using RT0.RefanyTypecode > might hurt some day in the future, even if I think you have shown > pretty convincingly that it doesn't hurt today. How about my "second > proposal". Do pretty much what you suggest but instead of returning > RT0.RefanyTypecode, return TYPECODE(TaggedInteger.T), where > TaggedInteger.T is an object type that is declared entirely privately > to the TaggedInteger unsafe module... this also gives a completely > obvious implementation for pickling the tagged integers. Simply > convert them to TaggedInteger.T and pickle that. An implementation > that doesn't support tagged integers in pointers could also allocate > "real" TaggedInteger.Ts.... not sure that is useful though or if > it just confuses. Actually I think it is useful, because it lets > you represent the values even if unpickling in a system that doesn't > support tagged integers in REFANYs. > > I would go so far as saying this... I believe it is possible to > guarantee that any safe code outside of the TaggedInteger module > couldn't distinguish between a REFANY that holds a tagged integer > vs. one that holds a reference to a (heap-allocated) TaggedInteger.T. > How's that for not breaking the language definition? > > Hendrik, I think Tony's and my arguments that you can't break any > existing code by allowing the squirreling away of integers into > REFANYs are pretty solid. Pre-existing code simply can't do anything > useful with unrevealed REFANYs. This is only true of _unrevealed opaque subtypes_ of REFANY, not of REFANY itself. There is lots of existing code that uses REFANY, and there, ISTYPE, NARROW, TYPECASE, and assigment can be and regularly are used on it. It is essential not to alter the semantics there. Aside from actual semantic changes, I agree with Tony that we should not burden any existing type with additional runtime work. Even though I expect small objects to support big performance gains in certain important cases, non-tagged references will still greatly predominate in most code. Create new type(s) for tagged references. > There are also good reasons for > permitting this oddness (vide Smalltalk and Scheme small integers). > From hosking at cs.purdue.edu Wed Apr 8 04:26:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 8 Apr 2009 12:26:57 +1000 Subject: [M3devel] small objects In-Reply-To: <49DC02BA.8080900@cox.net> References: <200904071712.n37HCtda030844@camembert.async.caltech.edu> <49DC02BA.8080900@cox.net> Message-ID: <3B067900-F4D0-430A-A328-38C1F548B97F@cs.purdue.edu> On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: > Mika Nystrom wrote: >> >> Hendrik, I think Tony's and my arguments that you can't break any >> existing code by allowing the squirreling away of integers into >> REFANYs are pretty solid. Pre-existing code simply can't do anything >> useful with unrevealed REFANYs. > > This is only true of _unrevealed opaque subtypes_ of REFANY, > not of REFANY itself. There is lots of existing code that uses > REFANY, > and there, ISTYPE, NARROW, TYPECASE, and assigment can be and > regularly are used on it. It is essential not to alter the > semantics there. Pre-existing code won't be able to do anything useful with tagged REFANYs: Suppose we have VAR r: REFANY = SmallInteger.FromInt(0); then ISTYPE(r, REFANY) => TRUE ISTYPE(r, T) => FALSE for any T # REFANY Similarly, for TYPECASE, r will only trigger the REFANY branch. NARROW(r, REFANY) => r NARROW(r, T) => run-time error for any T #REFANY VAR x: REFANY => assignment succeeds VAR x: T := r => run-time error for any T # REFANY (because of implicit NARROW) It is impossible to dereference an expression statically typed as REFANY, so there is no need for a "tagged" check on dereference. Because a tagged REFANY cannot be assigned to anything other than something typed REFANY, it can never propagate to a place where it can be dereferenced. > Aside from actual semantic changes, I agree with Tony that we should > not burden any existing type with additional runtime work. Even > though > I expect small objects to support big performance gains in certain > important cases, non-tagged references will still greatly predominate > in most code. Create new type(s) for tagged references. I'm not sure that we are seeing any semantic changes at all. And with Mika's definition of SmallInteger.T as a "boxed" INTEGER object (actually it would be a subrange for values that fit into BITSIZE(Word.T)-1 bits), it is essentially transparent. It just happens to be a run-time optimization that unboxes the INTEGER value. I think I can implement the compiler and run-time support for this very quickly. From mika at async.caltech.edu Wed Apr 8 05:22:21 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 07 Apr 2009 20:22:21 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Wed, 08 Apr 2009 12:26:57 +1000." <3B067900-F4D0-430A-A328-38C1F548B97F@cs.purdue.edu> Message-ID: <200904080322.n383MLuu048696@camembert.async.caltech.edu> Tony Hosking writes: ... > >It is impossible to dereference an expression statically typed as >REFANY, so there is no need for a "tagged" check on dereference. >Because a tagged REFANY cannot be assigned to anything other than >something typed REFANY, it can never propagate to a place where it can >be dereferenced. ... But it's correct, isn't it, that you get an extra one-bit check for ISTYPE, TYPECASE, TYPECODE, and NARROW? There's no problem with dereferencing, nor is there a problem with assignment. No need to introduce overhead for either of those, since dereferencing can't happen and assignment is transparent (or an implicit NARROW). I was going to say to Rodney that I think that Modula-3 programmers know that using REFANY does cause some overhead (it must), and in any case the normal ISTYPE code is going to be hundreds of times slower than the single-bit check, and no one (except me) seems to have had any problem with this so far. So yes, the change does affect existing code, but only code that's already using REFANY, ISTYPE, TYPECASE, and the extra overhead is very minor compared to the work ISTYPE and TYPECASE are already doing. I think I really like the idea of boxing it in this other opaque type if that doesn't cause any problems, specifically because it doesn't make any semantic change to the language at all. Actually, it is important for the application of embedded interpreters that these tagged types be compatible with a standard REFANY. The whole point is to be able to write a fast interpreter that deals in normal Modula-3 types and not in a special parallel hierarchy... Look at how the various languages embedded in Java (JScheme, Groovy, Jython(?)) do these things: it's really pretty nifty. But *they* can't do efficient small integers! Mika From hendrik at topoi.pooq.com Wed Apr 8 05:38:04 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 7 Apr 2009 23:38:04 -0400 Subject: [M3devel] small objects In-Reply-To: <92E0969B-63C7-43BE-A501-B78A5E520B55@cs.purdue.edu> References: <200904062003.n36K3381094096@camembert.async.caltech.edu> <92E0969B-63C7-43BE-A501-B78A5E520B55@cs.purdue.edu> Message-ID: <20090408033804.GA2137@topoi.pooq.com> On Tue, Apr 07, 2009 at 12:03:35PM +1000, Tony Hosking wrote: > On 7 Apr 2009, at 06:03, Mika Nystrom wrote: > > > >Yes I think maybe this is what Tony is worried about. But let's > >just change the definition of REFANY to include anything with the > >LSB set...? > > But then a "NULL" check needs to both test for zero and test for lsb > set. I am not comfortable with this. Nor am I, for both efficiency and conceptual reasons. AN INTEGER isn't a reference, and we shouldn't treat it as if it were. So I'd like a separate type. REFANY is for references. It's bad enough that NIL is in there, too. Except for major incompatibility with almost all past software, I'd like to consider having separate types for pointers that can be NIL and those that can't. But that's too much a deviation from the existing language (and cause all kinds of troubles with variables that are declared before they are initialised, a discussion I've had here sometime last year). -- hendrik. From hendrik at topoi.pooq.com Wed Apr 8 05:42:26 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 7 Apr 2009 23:42:26 -0400 Subject: [M3devel] small objects In-Reply-To: <3B067900-F4D0-430A-A328-38C1F548B97F@cs.purdue.edu> References: <200904071712.n37HCtda030844@camembert.async.caltech.edu> <49DC02BA.8080900@cox.net> <3B067900-F4D0-430A-A328-38C1F548B97F@cs.purdue.edu> Message-ID: <20090408034226.GB2137@topoi.pooq.com> On Wed, Apr 08, 2009 at 12:26:57PM +1000, Tony Hosking wrote: > > I'm not sure that we are seeing any semantic changes at all. And with > Mika's definition of SmallInteger.T as a "boxed" INTEGER object > (actually it would be a subrange for values that fit into > BITSIZE(Word.T)-1 bits), it is essentially transparent. It just > happens to be a run-time optimization that unboxes the INTEGER value. You should also be able to box a CARDINAL. Isn't that a subrange of integers that can be encoded in the right bit width? Hardwarewise, it would be decoded with a logical shift instead of an arithmetic shift. -- hendrik P.S. Apologies for the word "Hardwarewise". It's late here, and I don't have enough brain left for both English and technical content. -- hendrik From mika at async.caltech.edu Wed Apr 8 05:51:24 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 07 Apr 2009 20:51:24 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Tue, 07 Apr 2009 23:42:26 EDT." <20090408034226.GB2137@topoi.pooq.com> Message-ID: <200904080351.n383pOeR049888@camembert.async.caltech.edu> hendrik at topoi.pooq.com writes: >On Wed, Apr 08, 2009 at 12:26:57PM +1000, Tony Hosking wrote: >> >> I'm not sure that we are seeing any semantic changes at all. And with >> Mika's definition of SmallInteger.T as a "boxed" INTEGER object >> (actually it would be a subrange for values that fit into >> BITSIZE(Word.T)-1 bits), it is essentially transparent. It just >> happens to be a run-time optimization that unboxes the INTEGER value. > >You should also be able to box a CARDINAL. Isn't that a subrange of >integers that can be encoded in the right bit width? Hardwarewise, it >would be decoded with a logical shift instead of an arithmetic shift. I think you can do either, but not both... a REFANY containing 0xffffffff stands for either the boxed CARDINAL 2,147,483,647 or the boxed INTEGER -1. It can't really be both... I think INTEGERs are more useful, since you can get [0..2^30-1] in there? > >-- hendrik > >P.S. Apologies for the word "Hardwarewise". It's late here, and I >don't have enough brain left for both English and technical content. > >-- hendrik From hosking at cs.purdue.edu Wed Apr 8 05:55:00 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 8 Apr 2009 13:55:00 +1000 Subject: [M3devel] small objects In-Reply-To: <200904080322.n383MLuu048696@camembert.async.caltech.edu> References: <200904080322.n383MLuu048696@camembert.async.caltech.edu> Message-ID: <5B98E111-7E4F-4FC7-9B8C-2281CEBCDE6C@cs.purdue.edu> On 8 Apr 2009, at 13:22, Mika Nystrom wrote: > Tony Hosking writes: > ... >> >> It is impossible to dereference an expression statically typed as >> REFANY, so there is no need for a "tagged" check on dereference. >> Because a tagged REFANY cannot be assigned to anything other than >> something typed REFANY, it can never propagate to a place where it >> can >> be dereferenced. > ... > > But it's correct, isn't it, that you get an extra one-bit check for > ISTYPE, TYPECASE, TYPECODE, and NARROW? There's no problem with > dereferencing, nor is there a problem with assignment. No need to > introduce overhead for either of those, since dereferencing can't > happen and assignment is transparent (or an implicit NARROW). Correct. > I was going to say to Rodney that I think that Modula-3 programmers > know that using REFANY does cause some overhead (it must), and in > any case the normal ISTYPE code is going to be hundreds of times > slower than the single-bit check, and no one (except me) seems to > have had any problem with this so far. Right. > So yes, the change does affect existing code, but only code that's > already using REFANY, ISTYPE, TYPECASE, and the extra overhead is > very minor compared to the work ISTYPE and TYPECASE are already > doing. It affects only performance. Existing code won't know about SmallInteger.T, so will never test for that type. > I think I really like the idea of boxing it in this other opaque > type if that doesn't cause any problems, specifically because it > doesn't make any semantic change to the language at all. Yeah. It should probably be BRANDED REF [FIRST(INTEGER) DIV 2 .. LAST(INTEGER) DIV 2] instead of an object type. I don't want to think about having "builtin" methods that apply to this type. I'd rather implement it like the builtin Word.T operations. I think the following interface is about right: INTERFACE ValRef; TYPE T <: REFANY; CONST First = FIRST(INTEGER) DIV 2; Last = LAST(INTEGER) DIV 2; TYPE Range = [First .. Last]; PROCEDURE New(val: Range): T; PROCEDURE Val(ref: T): Range; END ValRef. On further thought, the notion that someone could do RTAllocator.NewTraced(TYPECODE(ValRef.T)) makes me a little nervous. We would need to intercept that in RTAllocator.NewTraced and return ValRef.New(0). Of course, there is no way to create any ValRef.T that has a value other than 0 in this way. The pickler would need to have a pickle special for TYPECODE(ValRef.T) that simply extracts the value as the pickled representation, and invokes ValRef.New(value) when unpickliing. > Actually, it is important for the application of embedded interpreters > that these tagged types be compatible with a standard REFANY. The > whole point is to be able to write a fast interpreter that deals > in normal Modula-3 types and not in a special parallel hierarchy... > Look at how the various languages embedded in Java (JScheme, Groovy, > Jython(?)) do these things: it's really pretty nifty. But *they* > can't do efficient small integers! Indeed. From hendrik at topoi.pooq.com Wed Apr 8 05:54:20 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 7 Apr 2009 23:54:20 -0400 Subject: [M3devel] trackOutside and trackOffScreen behave strangely. Message-ID: <20090408035419.GA2391@topoi.pooq.com> I'm trying to track the mouse. I set a cage like: VBT.SetCage(self, VBT.CageFromPosition(cd.cp, trackOutside := TRUE)); and it would not track the mouse when it was outside my window, but still on the screen. But when I coded VBT.SetCage(self, VBT.CageFromPosition(cd.cp, trackOutside := TRUE, trackOffScreen := TRUE)); it suddenly started tracking properly, following the mouse outside the window. The mouse pointer never left the screen during either test. It can't. In case it makes a difference, I'm using icewm on Xorg on a Debian Lenny system on an 32-bit AMD processor. -- hendrik. From wagner at elegosoft.com Wed Apr 8 08:43:32 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 08 Apr 2009 08:43:32 +0200 Subject: [M3devel] installation archives for AMD64_LINUX for test and tinderbox status Message-ID: <20090408084332.k76kazqnc4804cwc@mail.elegosoft.com> I've made some small extensions to the installer and to the packaging script make-bin-dist-min.sh (which is now wrongly named), so that they both use Jay's new style config files by default. The old behaviour is still available with some switches. The archives are in the uploaded-archives section of www.opencm3.net: -rw-rw-r-- 1 wagner m3 24568485 2009-04-08 08:24 cm3-bin-core-POSIX-AMD64_LINUX-d5.7.1.tgz -rw-rw-r-- 1 wagner m3 59741158 2009-04-08 08:24 cm3-bin-std-POSIX-AMD64_LINUX-d5.7.1.tgz I haven't really tested them; would anybody care to try one of these? They are rather huge; one contains the core distribution and one the complete std package set in binary format. But it seems to be consensus that large archives containing everything is preferred to small archives with more complex installation. I know that the cminstall program doesn't now do much except copying the files to their destination and checking for diskspace (which may still be wrong, by the way), but it still _could_ also perform customizations and install patches etc. So it's no big overhead, and this way the migration will be easier especially regarding the automated regression scripts. If nobody objects, we can use these for a new release in some weeks. If you think this isn't really useful, please don't hesitate to say so, too. Regarding tinderbox, I haven't been able to log into the administration pages yet, but Michael will surely fix that today. Some basic things are working, but some documentation and configuraion seems to be lost. I'll see what I can restore. I'll be on holiday starting tomorrow, but I'll take my notebook with me and hope for some good connections ;-) CVSup isn't installed yet, which is why the FreeBSD tests from Elego are still missing. Michael will probably work on it next week. Thanks for your help and patience, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From carson at taltos.org Wed Apr 8 11:39:18 2009 From: carson at taltos.org (Carson Gaspar) Date: Wed, 08 Apr 2009 02:39:18 -0700 Subject: [M3devel] What happened to Utypes.i3? Message-ID: <49DC70C6.1000600@taltos.org> Trying to use the recently uploaded 5.7.1 Linux packages, Utypes.i3 has been gutted. Breaking cvsup. Again. Specifically, dev_t, mode_t, ino_t, etc. are all gone. Can someone comment on what's going on with these interfaces? Is there a method behind the path of destruction being left? -- Carson From jay.krell at cornell.edu Wed Apr 8 12:44:09 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 8 Apr 2009 10:44:09 +0000 Subject: [M3devel] What happened to Utypes.i3? In-Reply-To: <49DC70C6.1000600@taltos.org> References: <49DC70C6.1000600@taltos.org> Message-ID: m3-libs/m3core/src/Unix/*/*.i3 was a very large chunk of tedious error-prone dangerous (if errors occur) mostly dead platform specific code. It was one of the largest things to work on when porting to a new platform, and largely wasted work. (The other pieces are debugging whatever goes wrong, that's about it, porting is often pretty easy..) It is drastically reduced now, and often replaced by much safer C code. There is still a little more to do here. dev_t, mode_t, ino_t, were mosty only used along with stat. Those uses are gone. This is the exact danger however -- of breaking Modula-3 code outside the cm3 tree, that uses "low level" non-Modula-3 interfaces. Anything that just uses the higher level Modula-3 interfaces is not broken. I'll have to look at cvsup and see if it is easy to make the same sort of transform -- replace small pieces of Modula-3 that are dependent on tedious error prone Modula-3 with small portable C wrappers. If the only problem is really those three types, they can be restored, reluctantly. I'd much rather change cvsup to not use them. - Jay > Date: Wed, 8 Apr 2009 02:39:18 -0700 > From: carson at taltos.org > To: m3devel at elegosoft.com > Subject: [M3devel] What happened to Utypes.i3? > > Trying to use the recently uploaded 5.7.1 Linux packages, Utypes.i3 has > been gutted. Breaking cvsup. Again. Specifically, dev_t, mode_t, ino_t, > etc. are all gone. > > Can someone comment on what's going on with these interfaces? Is there a > method behind the path of destruction being left? > > -- > Carson -------------- next part -------------- An HTML attachment was scrubbed... URL: From carson at taltos.org Wed Apr 8 12:57:11 2009 From: carson at taltos.org (Carson Gaspar) Date: Wed, 08 Apr 2009 03:57:11 -0700 Subject: [M3devel] What happened to Utypes.i3? In-Reply-To: <49DC70C6.1000600@taltos.org> References: <49DC70C6.1000600@taltos.org> Message-ID: <49DC8307.7060906@taltos.org> Similarly, 5.7.0 and 5.7.1 are both missing TextF.i3, also breaking cvsup. *sigh* Carson Gaspar wrote: > Trying to use the recently uploaded 5.7.1 Linux packages, Utypes.i3 has > been gutted. Breaking cvsup. Again. Specifically, dev_t, mode_t, ino_t, > etc. are all gone. > > Can someone comment on what's going on with these interfaces? Is there a > method behind the path of destruction being left? > From carson at taltos.org Wed Apr 8 13:04:48 2009 From: carson at taltos.org (Carson Gaspar) Date: Wed, 08 Apr 2009 04:04:48 -0700 Subject: [M3devel] What happened to Utypes.i3? In-Reply-To: References: <49DC70C6.1000600@taltos.org> Message-ID: <49DC84D0.4030701@taltos.org> Jay wrote: > I'll have to look at cvsup and see if it is easy to make the same sort > of transform -- replace small pieces of Modula-3 that are dependent on > tedious error prone Modula-3 with small portable C wrappers. > > If the only problem is really those three types, they can be restored, > reluctantly. > I'd much rather change cvsup to not use them. The problems are larger that just those, sadly, as a build attempt will quickly reveal. The universe would be very happy to have a working, maintained modula-3 compiler that would build cvsup. Whether that involves more patches to cvsup or changes to cm3, either way it would be a Good Thing(tm). Sadly, my almost non-extant modula-3 foo isn't up to the task, or I'd volunteer. Given my deadlines, I'm going to punt and try and get 5.4.0 to work and give up a clean 64-bit version. -- Carson From jay.krell at cornell.edu Wed Apr 8 14:27:21 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 8 Apr 2009 12:27:21 +0000 Subject: [M3devel] What happened to Utypes.i3? In-Reply-To: <49DC8307.7060906@taltos.org> References: <49DC70C6.1000600@taltos.org> <49DC8307.7060906@taltos.org> Message-ID: I thought TextF got deleted way back in 4.1, when Unicode support came in. I can look later...probably not Wednesday or Thursday though. - Jay > Date: Wed, 8 Apr 2009 03:57:11 -0700 > From: carson at taltos.org > To: m3devel at elegosoft.com > Subject: Re: [M3devel] What happened to Utypes.i3? > > Similarly, 5.7.0 and 5.7.1 are both missing TextF.i3, also breaking > cvsup. *sigh* > > Carson Gaspar wrote: > > Trying to use the recently uploaded 5.7.1 Linux packages, Utypes.i3 has > > been gutted. Breaking cvsup. Again. Specifically, dev_t, mode_t, ino_t, > > etc. are all gone. > > > > Can someone comment on what's going on with these interfaces? Is there a > > method behind the path of destruction being left? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carson at taltos.org Wed Apr 8 14:42:36 2009 From: carson at taltos.org (Carson Gaspar) Date: Wed, 08 Apr 2009 05:42:36 -0700 Subject: [M3devel] What happened to Utypes.i3? In-Reply-To: References: <49DC70C6.1000600@taltos.org> <49DC8307.7060906@taltos.org> Message-ID: <49DC9BBC.5040600@taltos.org> Jay wrote: > I thought TextF got deleted way back in 4.1, when Unicode support came in. > I can look later...probably not Wednesday or Thursday though. It's in my 31-Jan-2009 CVS checkout... and is in the 5.4.0 tarball. -- Carson From wagner at elegosoft.com Wed Apr 8 14:51:15 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 08 Apr 2009 14:51:15 +0200 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: References: <200904061532.n36FWunc087102@camembert.async.caltech.edu> <20090406175119.5nknbzf9dwkcwkks@mail.elegosoft.com> Message-ID: <20090408145115.hgx4t0to0o4s0gg0@mail.elegosoft.com> Quoting Jay : > > Relinking upon install I still think provides desired results and > is not a terrible idea, but it is more work to implement. > I think the perf is probably acceptable. > > I don't like to expose too many options to uninformed users, but > making this an option might be good. It will have an acceptable default, > which makes it being an option much less bad. I'm still not convinced that this is the correct behaviour. I find the whole concept of fixed location paths questionable. I'll have to relink my libraries for every location change. Seems simply wrong to me :-/ > It's not just one option. > There is: > 1) using the local machine's install point -- /usr/local/cm3/lib, > 2) vs. using $ORIGIN/../lib. > Not available on all systems. > 3) vs. using package store paths This should be the default IMHO. And no relinking by default. Better still remove the paths completely from the libraries. Others will probably disagree ;-) Olaf > 4) vs. using source tree paths > > > > > and they can be combined, in various orders. > > > > > Plus Darwin is different, though maybe Darwin 10.5 is the same. > (certainly not pre-10.5 though). > > > > > > I also still think this is related to "buildlocal" vs. " buildship". > In fact that is already partly accounted for. > > > > > I think I didn't understand the full state of things. > > > > > [I think] You were always getting big runpaths. > [I think] They were either to installed libraries or uninstalled libraries. > > If they were to uinstalled binaries, you could not ship -- buildlocal. > [I think] Now we are moving toward always small runpaths, always > pointing to installed libraries. This is dubious for buildlocal. > > > > > [I think] Buildlocal should probably retain its old behavior -- big > runpaths, into > the source tree. Or maybe a list of paths, source tree followed by > install tree. > So user might build some of his own shared libraries, but not > necessarily all. > > > > > I should set that -Wl,-R thing based on local vs. global. > I didn't look into how to detect that. > > > > > More later. > > > > > > Yes, this is a more general question of how to find dependant shared > libraries. > > I don't think anyone has solved it all that well, nor do I believe > we will, but there are still some better and worse options. > > > > > - 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 Wed Apr 8 22:08:09 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 08 Apr 2009 15:08:09 -0500 Subject: [M3devel] small objects Message-ID: <49DD0429.5000306@cox.net> Here are two integrated proposals for language changes to allow small objects, while preserving the principles of the language. Neither of them changes the semantics of any existing type or burdens any existing code with extra runtime computation. The unsafe proposal: This is a much simpler proposal. It could also be used in more general ways than just using a tag bit to distinguish a true pointer from an in-word value. This is at the cost of requiring unsafe coding techniques in a module implementing the abstraction, which also inevitably means implementation-dependent too. Using it for small objects as discussed still requires the garbage collector not to be confused by trying to trace a reference with a misaligned value. There is a new builtin type OPAQUE. The only things you can do with it in safe code are copy values around (assigment, pass by VALUE, RETURN, etc.) and make reference bindings to it (pass by reference, WITH bindings). Not that this ia a _lot_ more opaque than opaque types. OPAQUE is known to be the same size as Word.T. In unsafe code, you can use this fact to LOOPHOLE it to anything you want and bit-twiddle to your heart's content from there. So an unsafe module could implement procedures that take OPAQUE parameters. Variation: Allow an opaque subtype of OPAQUE, which can be revealed to be any type with statically the same size. This would make it possible to prevent client code from mixing up two different unrelated abstractions that both happened to use OPAQUE. In fact, without this, the proposal really fails to preserve the existing principles of safe/unsafe code. This would require that the revelation be BRANDED, which would either mean restricting the revelation to a reference type (which could still be LOOPHOLEd to anything else) or allowing other types to be BRANDED. Example: INTERFACE ADT; TYPE T <: OPAQUE; PROCEDURE P (x:T); ... END ADT UNSAFE MODULE ADT; TYPE R = RECORD ... END; REVEAL T = BRANDED REF R; PROCEDURE P (x:T) VAR I: INTEGER; BEGIN IF LOOPHOLE(x,INTEGER) MOD 2 # 0 THEN I := Word.Shift(LOOPHOLE(x,INTEGER),-1); (* Use integer value I ... *) ELSE (* Use reference value x, according to its declared type. Prior to the check above, we couldn't afford to risk doing anything with it. ... *) END (* IF *); END P; ... END ADT; The safe proposal: This is more complicated and less general, but allows small object abstractions to be done in an entirely safe and implementation- independent way. It abstracts away all the bit-level representation questions. There is a new type TAG, which is a subrange of INTEGER, with implementation-defined bounds (which would then be accessible by FIRST/LAST). There is a new type constructor TAGGED. If T is any traced reference type or any untraced object type, TAGGED T defines a type, called a _tagged_ type, whose value set is the union of the value sets of TAG and T. TAG <: TAGGED T and T <: TAGGED T. There are no other subtype relations involving TAGGED T. Values of a tagged type can be copied and bound-to. The static rules for ISTYPE, NARROW, TYPECASE, and assignability of a type to a type are liberalized to allow their application to a tagged type, and to allow the type to be checked/converted-to to be any subtype of the tagged type. Already existing rules would require a runtime check that the value is a member of the stated type. No other operations are possible on a tagged type. A tagged type is not a reference type and does not have a typecode. Example: INTERFACE ADT; TYPE Op <: REFANY; TYPE T = TAGGED Op; PROCEDURE P (x:T); ... END ADT MODULE ADT; TYPE R = RECORD ... END; REVEAL Op = BRANDED REF R; PROCEDURE P (x:T) BEGIN TYPECASE x OF TAG (I) => (* Use integer value I ... *) | Op (RR) => (* Use reference value RR ... *) END (* IF *); END P; ... END ADT; Note: TAG is like CARDINAL in that it is "just like" a subrange of INTEGER, but not equal to that subrange. This enabled pickles to change the size of values of type TAG and of tagged types, as it now does with CARDINAL. Variation: The 4 runtime-checking operations can also be applied to any ordinal type and can check that an ordinal or tagged type has a value belonging to any subrange of the base type (or maybe just of the type being narrowed). This is pure fluff (well, maybe it is syntactic sugar), but adds some consistency and has a real use: How many times have I coded the following? IF FIRST(SomeOrdinalType <= x AND x <= LAST(SomeOrdinalType) THEN ... or worse, IF FIRST(SomeOrdinalType <= F(x) AND F(x) <= LAST(SomeOrdinalType) THEN ... which I then feel morally obligated to recode using a local variable or WITH-temp to eliminate the duplicated calls F(x). It could then become: IF ISTYPE (F(x), SomeOrdinalType) THEN ... From rodney.m.bates at cox.net Wed Apr 8 22:13:33 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 08 Apr 2009 15:13:33 -0500 Subject: [M3devel] What happened to Utypes.i3? In-Reply-To: References: <49DC70C6.1000600@taltos.org> <49DC8307.7060906@taltos.org> Message-ID: <49DD056D.5050205@cox.net> TextF is still sitting out there in the CM3 repository, but what it declares is a lie in CM3. If you try to use it to compile code that assumes the PM3 text representation in CM3, something bad will surely happen. Probably a link-time failure because of contradictory revelations, or something. Such code will inevitably have to be modified to get it to compile and work in CM3. TextF is also unused in the CM3 repo. Jay wrote: > I thought TextF got deleted way back in 4.1, when Unicode support came in > From rodney.m.bates at cox.net Thu Apr 9 02:15:21 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 08 Apr 2009 19:15:21 -0500 Subject: [M3devel] small objects In-Reply-To: <3B067900-F4D0-430A-A328-38C1F548B97F@cs.purdue.edu> References: <200904071712.n37HCtda030844@camembert.async.caltech.edu> <49DC02BA.8080900@cox.net> <3B067900-F4D0-430A-A328-38C1F548B97F@cs.purdue.edu> Message-ID: <49DD3E19.20209@cox.net> Tony Hosking wrote: > On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: > >> Mika Nystrom wrote: >>> >>> Hendrik, I think Tony's and my arguments that you can't break any >>> existing code by allowing the squirreling away of integers into >>> REFANYs are pretty solid. Pre-existing code simply can't do anything >>> useful with unrevealed REFANYs. >> >> This is only true of _unrevealed opaque subtypes_ of REFANY, >> not of REFANY itself. There is lots of existing code that uses REFANY, >> and there, ISTYPE, NARROW, TYPECASE, and assigment can be and >> regularly are used on it. It is essential not to alter the >> semantics there. > > Pre-existing code won't be able to do anything useful with tagged > REFANYs: > > Suppose we have > > VAR r: REFANY = SmallInteger.FromInt(0); > > then > > ISTYPE(r, REFANY) => TRUE > ISTYPE(r, T) => FALSE for any T # REFANY > > Similarly, for TYPECASE, r will only trigger the REFANY branch. > > NARROW(r, REFANY) => r > NARROW(r, T) => run-time error for any T #REFANY > > VAR x: REFANY => assignment succeeds > VAR x: T := r => run-time error for any T # REFANY (because of > implicit NARROW) I think I am getting a bit lost in all the proposals, variations, counterproposals, etc., but from this argument I am inferring that your plan is that only variables declared REFANY and not any proper subtype of REFANY can ever have a value with a tag bit set? Then the 4 narrowing operations, when and only when applied to an expression of static type REFANY, would change to make a runtime check for a tag bit and fail if it's set? It would take this to prevent a tagged value from getting into a variable declared a proper subtype of REFANY, which can be dereferenced. This would preclude making your abstract data type an opaque subtype of REFANY, and would mean all supposedly unrelated ADT modules that used the tag technique could be broken by client code that mixed up the REFANY values of one of them with those of another. I consider this a definite breach of Modula-3's otherwise bulletproof type safety. > > It is impossible to dereference an expression statically typed as > REFANY, so there is no need for a "tagged" check on dereference. > Because a tagged REFANY cannot be assigned to anything other than > something typed REFANY, it can never propagate to a place where it can > be dereferenced. > >> Aside from actual semantic changes, I agree with Tony that we should >> not burden any existing type with additional runtime work. Even though >> I expect small objects to support big performance gains in certain >> important cases, non-tagged references will still greatly predominate >> in most code. Create new type(s) for tagged references. > > I'm not sure that we are seeing any semantic changes at all. And with > Mika's definition of SmallInteger.T as a "boxed" INTEGER object > (actually it would be a subrange for values that fit into > BITSIZE(Word.T)-1 bits), it is essentially transparent. It just > happens to be a run-time optimization that unboxes the INTEGER value. > > > I think I can implement the compiler and run-time support for this > very quickly. > > From mika at async.caltech.edu Thu Apr 9 02:23:12 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 08 Apr 2009 17:23:12 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Wed, 08 Apr 2009 15:08:09 CDT." <49DD0429.5000306@cox.net> Message-ID: <200904090023.n390NC2b096664@camembert.async.caltech.edu> Hmm, if you're going to do something along these lines, isn't the logical thing to do to introduce a new root of the (traced) type system, that is REFANY <: REFORINT SMALLINT = [MinSmallInteger .. MaxSmallInteger] SMALLINT <: REFORINT a REFORINT can be a REFANY or a small integer. It stands to reason that it is a supertype of REFANY as well as of SMALLINT, because isn't that exactly what we're looking for? The problem with this proposal (as well as both of yours) is that you get to go through and inspect all existing code that takes REFANY and wonder whether maybe it should take REFORINT instead.... The proposal that Tony and I seem to have agreed on, on the other hand, allows the implementation to hide small integers completely transparently in the already existing REFANY, at the cost of an LSB check on a number of operations, such as ISTYPE, TYPECASE, etc., to any REFANY. I maintain the following: I. Since hiding integers in REFANY is intended to be entirely transparent, you could have it as a compile or even run-time option. Yes, ok this is ugly. II.Assume we go with REFORINT, or OPAQUE, or TAGGED. What existing uses of REFANY, in any code of importance, is going to stay REFANY, and what uses will we want to convert to the new types? I would suggest considering the following argument: A. The new types are strictly more useful than REFANY; they can represent more values because they can represent all of REFANY plus other values (after all that was the point all along). B. Existing uses of REFANY are either 1. uses of REFANY because the code is intended to be very generic. Programmers will want to migrate such code to the new type, so that they can process the new type as well (since the code is generic it should work for either). 2. uses of REFANY because the programmer was too lazy to instantiate a generic for his specific type and decided to cast the values to REFANY (e.g., to insert in a RefList) and back. Such programmers deserve what they get. I conclude that code that continues to want to use REFANY rather than the new type is code that is not performance sensitive. Hence, I conclude that using REFANY directly to represent small integers is as reasonable as introducing a new type, and does it with less work, both in updating the language definition and in updating all the libraries in libm3 and elsewhere. What current uses of REFANY do not fit the cases in II.B.? Some trickery to simulate multiple inheritance? Even in those you should have created a common supertype, I think. Mika "Rodney M. Bates" writes: >Here are two integrated proposals for language changes to allow small >objects, while preserving the principles of the language. Neither of >them changes the semantics of any existing type or burdens any >existing code with extra runtime computation. > >The unsafe proposal: > >This is a much simpler proposal. It could also be used in more >general ways than just using a tag bit to distinguish a true pointer >from an in-word value. This is at the cost of requiring unsafe coding >techniques in a module implementing the abstraction, which also >inevitably means implementation-dependent too. Using it for small >objects as discussed still requires the garbage collector not to be >confused by trying to trace a reference with a misaligned value. > >There is a new builtin type OPAQUE. The only things you can do with >it in safe code are copy values around (assigment, pass by VALUE, >RETURN, etc.) and make reference bindings to it (pass by reference, >WITH bindings). Not that this ia a _lot_ more opaque than opaque >types. > >OPAQUE is known to be the same size as Word.T. In unsafe code, you >can use this fact to LOOPHOLE it to anything you want and bit-twiddle >to your heart's content from there. So an unsafe module could >implement procedures that take OPAQUE parameters. > >Variation: > >Allow an opaque subtype of OPAQUE, which can be revealed to be any >type with statically the same size. This would make it possible to >prevent client code from mixing up two different unrelated >abstractions that both happened to use OPAQUE. In fact, without this, >the proposal really fails to preserve the existing principles of >safe/unsafe code. This would require that the revelation be BRANDED, >which would either mean restricting the revelation to a reference type >(which could still be LOOPHOLEd to anything else) or allowing other >types to be BRANDED. > >Example: > >INTERFACE ADT; > TYPE T <: OPAQUE; > PROCEDURE P (x:T); > ... >END ADT > >UNSAFE MODULE ADT; > TYPE R = RECORD ... END; > REVEAL T = BRANDED REF R; > > PROCEDURE P (x:T) > VAR I: INTEGER; > BEGIN > IF LOOPHOLE(x,INTEGER) MOD 2 # 0 > THEN > I := Word.Shift(LOOPHOLE(x,INTEGER),-1); > (* Use integer value I ... *) > ELSE > (* Use reference value x, according to its declared type. > Prior to the check above, we couldn't afford to risk > doing anything with it. ... *) > END (* IF *); > END P; > ... >END ADT; > >The safe proposal: > >This is more complicated and less general, but allows small object >abstractions to be done in an entirely safe and implementation- >independent way. It abstracts away all the bit-level representation >questions. > >There is a new type TAG, which is a subrange of INTEGER, with >implementation-defined bounds (which would then be accessible by >FIRST/LAST). > >There is a new type constructor TAGGED. If T is any traced reference >type or any untraced object type, TAGGED T defines a type, called a >_tagged_ type, whose value set is the union of the value sets of TAG >and T. > >TAG <: TAGGED T and T <: TAGGED T. > >There are no other subtype relations involving TAGGED T. > >Values of a tagged type can be copied and bound-to. > >The static rules for ISTYPE, NARROW, TYPECASE, and assignability of a >type to a type are liberalized to allow their application to a tagged >type, and to allow the type to be checked/converted-to to be any >subtype of the tagged type. Already existing rules would require a >runtime check that the value is a member of the stated type. > >No other operations are possible on a tagged type. A tagged type is >not a reference type and does not have a typecode. > >Example: > >INTERFACE ADT; > TYPE Op <: REFANY; > TYPE T = TAGGED Op; > PROCEDURE P (x:T); > ... >END ADT > >MODULE ADT; > TYPE R = RECORD ... END; > REVEAL Op = BRANDED REF R; > > PROCEDURE P (x:T) > BEGIN > TYPECASE x > OF TAG (I) > => (* Use integer value I ... *) > | Op (RR) > => (* Use reference value RR ... *) > END (* IF *); > END P; > ... >END ADT; > >Note: TAG is like CARDINAL in that it is "just like" a subrange of >INTEGER, but not equal to that subrange. This enabled pickles to >change the size of values of type TAG and of tagged types, as it now >does with CARDINAL. > >Variation: > >The 4 runtime-checking operations can also be applied to any ordinal >type and can check that an ordinal or tagged type has a value >belonging to any subrange of the base type (or maybe just of the type >being narrowed). This is pure fluff (well, maybe it is syntactic >sugar), but adds some consistency and has a real use: > >How many times have I coded the following? > >IF FIRST(SomeOrdinalType <= x AND x <= LAST(SomeOrdinalType) THEN ... > >or worse, > >IF FIRST(SomeOrdinalType <= F(x) AND F(x) <= LAST(SomeOrdinalType) THEN ... > >which I then feel morally obligated to recode using a local variable or >WITH-temp to eliminate the duplicated calls F(x). > >It could then become: > >IF ISTYPE (F(x), SomeOrdinalType) THEN ... > > > > > > From mika at async.caltech.edu Thu Apr 9 02:38:23 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 08 Apr 2009 17:38:23 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Wed, 08 Apr 2009 19:15:21 CDT." <49DD3E19.20209@cox.net> Message-ID: <200904090038.n390cNsg097270@camembert.async.caltech.edu> Hmm, ok, there's one big difference between what you're saying and what Tony and I have been talking about. (I think your understanding sounds pretty correct.) You want to do objects other than small integers. Like what? And why? I was thinking the trick would apply only to one specific type of integer. Hmm, so your idea is to statically determine what type the references can have if they are non-references. So you are thinking to put various kinds of subranges into the "TAGGED" types. But you have to be able to determine, statically, which subrange it is... am I understanding this correctly? Mika "Rodney M. Bates" writes: >Tony Hosking wrote: >> On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: >> >>> Mika Nystrom wrote: >>>> >>>> Hendrik, I think Tony's and my arguments that you can't break any >>>> existing code by allowing the squirreling away of integers into >>>> REFANYs are pretty solid. Pre-existing code simply can't do anything >>>> useful with unrevealed REFANYs. >>> >>> This is only true of _unrevealed opaque subtypes_ of REFANY, >>> not of REFANY itself. There is lots of existing code that uses REFANY, >>> and there, ISTYPE, NARROW, TYPECASE, and assigment can be and >>> regularly are used on it. It is essential not to alter the >>> semantics there. >> >> Pre-existing code won't be able to do anything useful with tagged >> REFANYs: >> >> Suppose we have >> >> VAR r: REFANY = SmallInteger.FromInt(0); >> >> then >> >> ISTYPE(r, REFANY) => TRUE >> ISTYPE(r, T) => FALSE for any T # REFANY >> >> Similarly, for TYPECASE, r will only trigger the REFANY branch. >> >> NARROW(r, REFANY) => r >> NARROW(r, T) => run-time error for any T #REFANY >> >> VAR x: REFANY => assignment succeeds >> VAR x: T := r => run-time error for any T # REFANY (because of >> implicit NARROW) > >I think I am getting a bit lost in all the proposals, variations, >counterproposals, etc., but >from this argument I am inferring that your plan is that only variables >declared REFANY >and not any proper subtype of REFANY can ever have a value with a tag >bit set? Then >the 4 narrowing operations, when and only when applied to an expression >of static >type REFANY, would change to make a runtime check for a tag bit and fail >if it's set? >It would take this to prevent a tagged value from getting into a >variable declared a >proper subtype of REFANY, which can be dereferenced. > >This would preclude making your abstract data type an opaque subtype of >REFANY, >and would mean all supposedly unrelated ADT modules that used the tag >technique >could be broken by client code that mixed up the REFANY values of one of >them with >those of another. I consider this a definite breach of Modula-3's >otherwise bulletproof >type safety. >> >> It is impossible to dereference an expression statically typed as >> REFANY, so there is no need for a "tagged" check on dereference. >> Because a tagged REFANY cannot be assigned to anything other than >> something typed REFANY, it can never propagate to a place where it can >> be dereferenced. >> >>> Aside from actual semantic changes, I agree with Tony that we should >>> not burden any existing type with additional runtime work. Even though >>> I expect small objects to support big performance gains in certain >>> important cases, non-tagged references will still greatly predominate >>> in most code. Create new type(s) for tagged references. >> >> I'm not sure that we are seeing any semantic changes at all. And with >> Mika's definition of SmallInteger.T as a "boxed" INTEGER object >> (actually it would be a subrange for values that fit into >> BITSIZE(Word.T)-1 bits), it is essentially transparent. It just >> happens to be a run-time optimization that unboxes the INTEGER value. >> >> >> I think I can implement the compiler and run-time support for this >> very quickly. >> >> From hosking at cs.purdue.edu Thu Apr 9 03:39:50 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 9 Apr 2009 11:39:50 +1000 Subject: [M3devel] What happened to Utypes.i3? In-Reply-To: <49DD056D.5050205@cox.net> References: <49DC70C6.1000600@taltos.org> <49DC8307.7060906@taltos.org> <49DD056D.5050205@cox.net> Message-ID: <83F0F22E-19BA-493D-9185-2107A92D29C4@cs.purdue.edu> TextF is not part of the installed code-base for m3core. The old source is there, but does not get built. I know I have built CVS up since *after* TextF went away. There were a few minor patches needed. Of course, that was all before Utypes got pruned away. I really don't think it can possibly be too hard to build CVSup against the current CM3 head. Yes, there may be some declarations needed for various Unix foibles, but ideally we could hide those away behind C helper code as Jay suggests. On 9 Apr 2009, at 06:13, Rodney M. Bates wrote: > TextF is still sitting out there in the CM3 repository, but what it > declares is a lie in CM3. If you try to use it to compile code that > assumes the PM3 text representation in CM3, something bad > will surely happen. Probably a link-time failure because of > contradictory revelations, or something. Such code will inevitably > have to be modified to get it to compile and work in CM3. > TextF is also unused in the CM3 repo. > Jay wrote: >> I thought TextF got deleted way back in 4.1, when Unicode support >> came in >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Apr 9 03:51:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 9 Apr 2009 11:51:36 +1000 Subject: [M3devel] small objects In-Reply-To: <49DD3E19.20209@cox.net> References: <200904071712.n37HCtda030844@camembert.async.caltech.edu> <49DC02BA.8080900@cox.net> <3B067900-F4D0-430A-A328-38C1F548B97F@cs.purdue.edu> <49DD3E19.20209@cox.net> Message-ID: <8AA8B3CE-12D0-45E3-8F24-5B2A6FED13CF@cs.purdue.edu> On 9 Apr 2009, at 10:15, Rodney M. Bates wrote: > I think I am getting a bit lost in all the proposals, variations, > counterproposals, etc., but > from this argument I am inferring that your plan is that only > variables declared REFANY > and not any proper subtype of REFANY can ever have a value with a > tag bit set? Then > the 4 narrowing operations, when and only when applied to an > expression of static > type REFANY, would change to make a runtime check for a tag bit and > fail if it's set? > It would take this to prevent a tagged value from getting into a > variable declared a > proper subtype of REFANY, which can be dereferenced. Yes, that's the minimalist proposal that Mika initiated and I refined slightly to handle TYPECODE. > This would preclude making your abstract data type an opaque subtype > of REFANY, > and would mean all supposedly unrelated ADT modules that used the > tag technique > could be broken by client code that mixed up the REFANY values of > one of them with > those of another. I consider this a definite breach of Modula-3's > otherwise bulletproof > type safety. Umm. I don't see how they can "break". Can you offer a scenario? Either a REFANY is tagged or it is not. "Unrelated ADT modules that use the tag technique" would all still work. Are you saying you want a way to stamp out differently typed tagged REFANYs? Seems a little tricky given that we are proposing just a single bit to distinguish tagged from untagged REFANY. Unless you propose a completely static type constructor that stamps out different tagged reference types that are completely unrelated, and cannot be stored in a REFANY? But that breaks the whole purpose of tagging which is to support values embedded in references. From hosking at cs.purdue.edu Thu Apr 9 03:57:35 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 9 Apr 2009 11:57:35 +1000 Subject: [M3devel] small objects In-Reply-To: <200904090023.n390NC2b096664@camembert.async.caltech.edu> References: <200904090023.n390NC2b096664@camembert.async.caltech.edu> Message-ID: Thanks Mika, nicely summarised. I'll just add that from the language design perspective we have made no change. The only thing we are doing is introducing a run-time *optimisation* that allows things that look like: T = BRANDED "SmallInt.T" REF [FIRST(INTEGER) DIV 2.. LAST(INTEGER) DIV 2] to be *represented* by the run-time system as a tagged reference by packing the value into the non-tag bits of the reference. The main thing to protect against is that someone bypasses the opaque definition of this type as <: REFANY and actually allocates a heap value of the above type. The only way to do that is to use RTAllocator.NewTraced(tc) with TYPECODE(T). The run-time system can explicitly check for that in RTAllocator and return a properly tagged reference. On 9 Apr 2009, at 10:23, Mika Nystrom wrote: > Hmm, if you're going to do something along these lines, isn't the > logical > thing to do to introduce a new root of the (traced) type system, that > is > > REFANY <: REFORINT > SMALLINT = [MinSmallInteger .. MaxSmallInteger] > SMALLINT <: REFORINT > > a REFORINT can be a REFANY or a small integer. It stands to reason > that > it is a supertype of REFANY as well as of SMALLINT, because isn't > that exactly what we're looking for? > > The problem with this proposal (as well as both of yours) is that > you get to go through and inspect all existing code that takes > REFANY and wonder whether maybe it should take REFORINT instead.... > > The proposal that Tony and I seem to have agreed on, on the other > hand, allows the implementation to hide small integers completely > transparently in the already existing REFANY, at the cost of an LSB > check on a number of operations, such as ISTYPE, TYPECASE, etc., > to any REFANY. > > I maintain the following: > > I. Since hiding integers in REFANY is intended to be entirely > transparent, you could have it as a compile or even run-time > option. Yes, ok this is ugly. > > II.Assume we go with REFORINT, or OPAQUE, or TAGGED. What existing > uses of REFANY, in any code of importance, is going to stay > REFANY, and what uses will we want to convert to the new types? > > I would suggest considering the following argument: > > A. The new types are strictly more useful than REFANY; they can > represent more values because they can represent all of REFANY > plus other values (after all that was the point all along). > > B. Existing uses of REFANY are either > 1. uses of REFANY because the code is intended to be very generic. > Programmers will want to migrate such code to the new type, > so that they can process the new type as well (since the code > is > generic it should work for either). > 2. uses of REFANY because the programmer was too lazy to > instantiate > a generic for his specific type and decided to cast the values > to REFANY (e.g., to insert in a RefList) and back. Such > programmers > deserve what they get. > > I conclude that code that continues to want to use REFANY rather > than the new type is code that is not performance sensitive. Hence, > I conclude that using REFANY directly to represent small integers > is as reasonable as introducing a new type, and does it with less > work, > both in updating the language definition and in updating all the > libraries in libm3 and elsewhere. > > What current uses of REFANY do not fit the cases in II.B.? Some > trickery to simulate multiple inheritance? Even in those you should > have created a common supertype, I think. > > Mika > > "Rodney M. Bates" writes: >> Here are two integrated proposals for language changes to allow small >> objects, while preserving the principles of the language. Neither of >> them changes the semantics of any existing type or burdens any >> existing code with extra runtime computation. >> >> The unsafe proposal: >> >> This is a much simpler proposal. It could also be used in more >> general ways than just using a tag bit to distinguish a true pointer >> from an in-word value. This is at the cost of requiring unsafe >> coding >> techniques in a module implementing the abstraction, which also >> inevitably means implementation-dependent too. Using it for small >> objects as discussed still requires the garbage collector not to be >> confused by trying to trace a reference with a misaligned value. >> >> There is a new builtin type OPAQUE. The only things you can do with >> it in safe code are copy values around (assigment, pass by VALUE, >> RETURN, etc.) and make reference bindings to it (pass by reference, >> WITH bindings). Not that this ia a _lot_ more opaque than opaque >> types. >> >> OPAQUE is known to be the same size as Word.T. In unsafe code, you >> can use this fact to LOOPHOLE it to anything you want and bit-twiddle >> to your heart's content from there. So an unsafe module could >> implement procedures that take OPAQUE parameters. >> >> Variation: >> >> Allow an opaque subtype of OPAQUE, which can be revealed to be any >> type with statically the same size. This would make it possible to >> prevent client code from mixing up two different unrelated >> abstractions that both happened to use OPAQUE. In fact, without >> this, >> the proposal really fails to preserve the existing principles of >> safe/unsafe code. This would require that the revelation be BRANDED, >> which would either mean restricting the revelation to a reference >> type >> (which could still be LOOPHOLEd to anything else) or allowing other >> types to be BRANDED. >> >> Example: >> >> INTERFACE ADT; >> TYPE T <: OPAQUE; >> PROCEDURE P (x:T); >> ... >> END ADT >> >> UNSAFE MODULE ADT; >> TYPE R = RECORD ... END; >> REVEAL T = BRANDED REF R; >> >> PROCEDURE P (x:T) >> VAR I: INTEGER; >> BEGIN >> IF LOOPHOLE(x,INTEGER) MOD 2 # 0 >> THEN >> I := Word.Shift(LOOPHOLE(x,INTEGER),-1); >> (* Use integer value I ... *) >> ELSE >> (* Use reference value x, according to its declared type. >> Prior to the check above, we couldn't afford to risk >> doing anything with it. ... *) >> END (* IF *); >> END P; >> ... >> END ADT; >> >> The safe proposal: >> >> This is more complicated and less general, but allows small object >> abstractions to be done in an entirely safe and implementation- >> independent way. It abstracts away all the bit-level representation >> questions. >> >> There is a new type TAG, which is a subrange of INTEGER, with >> implementation-defined bounds (which would then be accessible by >> FIRST/LAST). >> >> There is a new type constructor TAGGED. If T is any traced reference >> type or any untraced object type, TAGGED T defines a type, called a >> _tagged_ type, whose value set is the union of the value sets of TAG >> and T. >> >> TAG <: TAGGED T and T <: TAGGED T. >> >> There are no other subtype relations involving TAGGED T. >> >> Values of a tagged type can be copied and bound-to. >> >> The static rules for ISTYPE, NARROW, TYPECASE, and assignability of a >> type to a type are liberalized to allow their application to a tagged >> type, and to allow the type to be checked/converted-to to be any >> subtype of the tagged type. Already existing rules would require a >> runtime check that the value is a member of the stated type. >> >> No other operations are possible on a tagged type. A tagged type is >> not a reference type and does not have a typecode. >> >> Example: >> >> INTERFACE ADT; >> TYPE Op <: REFANY; >> TYPE T = TAGGED Op; >> PROCEDURE P (x:T); >> ... >> END ADT >> >> MODULE ADT; >> TYPE R = RECORD ... END; >> REVEAL Op = BRANDED REF R; >> >> PROCEDURE P (x:T) >> BEGIN >> TYPECASE x >> OF TAG (I) >> => (* Use integer value I ... *) >> | Op (RR) >> => (* Use reference value RR ... *) >> END (* IF *); >> END P; >> ... >> END ADT; >> >> Note: TAG is like CARDINAL in that it is "just like" a subrange of >> INTEGER, but not equal to that subrange. This enabled pickles to >> change the size of values of type TAG and of tagged types, as it now >> does with CARDINAL. >> >> Variation: >> >> The 4 runtime-checking operations can also be applied to any ordinal >> type and can check that an ordinal or tagged type has a value >> belonging to any subrange of the base type (or maybe just of the type >> being narrowed). This is pure fluff (well, maybe it is syntactic >> sugar), but adds some consistency and has a real use: >> >> How many times have I coded the following? >> >> IF FIRST(SomeOrdinalType <= x AND x <= LAST(SomeOrdinalType) THEN ... >> >> or worse, >> >> IF FIRST(SomeOrdinalType <= F(x) AND F(x) <= LAST(SomeOrdinalType) >> THEN ... >> >> which I then feel morally obligated to recode using a local >> variable or >> WITH-temp to eliminate the duplicated calls F(x). >> >> It could then become: >> >> IF ISTYPE (F(x), SomeOrdinalType) THEN ... >> >> >> >> >> >> From rodney.m.bates at cox.net Thu Apr 9 04:13:47 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 08 Apr 2009 21:13:47 -0500 Subject: [M3devel] small objects In-Reply-To: <200904090038.n390cNsg097270@camembert.async.caltech.edu> References: <200904090038.n390cNsg097270@camembert.async.caltech.edu> Message-ID: <49DD59DB.4050404@cox.net> Mika Nystrom wrote: > Hmm, ok, there's one big difference between what you're saying and > what Tony and I have been talking about. (I think your understanding > sounds pretty correct.) > > You want to do objects other than small integers. Like what? And why? > I was thinking the trick would apply only to one specific type of integer. > Yes, I want a language mechanism that can be used by various modules to implement various abstract data types, each of which can perform the sometimes dramatic space optimization of putting values that are common and will fit directly in the word. One module I spoke of implements general sets of integers with dynamically variable and sometimes large range. This differs from the builtin SET OF.., which must have a static (and probably relatively small) base subrange. Thus the general, heap-allocated values contain open arrays of Word.T, treated as sets, or if you prefer, packed arrays of booleans, although I manipulate them with bit-twiddling operations from Word. There is another, static-sized, heap-allocated object in front of each array, containing biases on what bits correspond to what integers in the abstract set, etc. It all works fine now, but the usage pattern of some clients has a high percentage very small sets that would fit in a word, and there would be an 11-to-1 space savings if that could be done. BTW, there are also two different kinds of heap objects, one that represents a range set by just its bounds. So I am TYPECASEing these already. It would be very convenient if I could just add another alternative to the TYPECASE for in-word values. In another case, I need truly dynamically variable sized arrays of integers in [0..15], and the great majority are 7 elements or less, which would fit directly in the word, but I still the need full generality to be available, so it's open arrays all the time, with three additional words each. If you can pack a union of a pointer and an integer into a word and can separate them with runtime checks, then you can use the separated integer any way you want, with bit twiddling, type conversions, LOOPHOLE, or whatever. That is what I am trying to get, not just Smalltalk-like integers. Note that Smalltalk has zero static typing, so only one internal representation must do for the union of all possible values in the language. In Modula-3, it would be very inconsistent with the language's philosophy to be this restricted. > Hmm, so your idea is to statically determine what type the references > can have if they are non-references. So you are thinking to put various > kinds of subranges into the "TAGGED" types. But you have to be able to > determine, statically, which subrange it is... am I understanding this > correctly? > From the language, all I want is to be able to dynamically determine whether it is a true pointer to a heap object or a value stored directly in the word, while preserving the safety principles and the semantics of everything already there. So I want some new types, different from any existing types, that statically are known to hold this kind of valueset union and can be converted/assigned to a variable of existing type that is statically known to be either a pointer or an integer (but not both), with a suitable runtime check. It is also necessary to have a way to do this without risking a runtime error, if your code doesn't know yet which kind of value it has. Various ADT modules can take it from there. > Mika > > "Rodney M. Bates" writes: > >> Tony Hosking wrote: >> >>> On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: >>> >>> >>>> Mika Nystrom wrote: >>>> >>>>> Hendrik, I think Tony's and my arguments that you can't break any >>>>> existing code by allowing the squirreling away of integers into >>>>> REFANYs are pretty solid. Pre-existing code simply can't do anything >>>>> useful with unrevealed REFANYs. >>>>> >>>> This is only true of _unrevealed opaque subtypes_ of REFANY, >>>> not of REFANY itself. There is lots of existing code that uses REFANY, >>>> and there, ISTYPE, NARROW, TYPECASE, and assigment can be and >>>> regularly are used on it. It is essential not to alter the >>>> semantics there. >>>> >>> Pre-existing code won't be able to do anything useful with tagged >>> REFANYs: >>> >>> Suppose we have >>> >>> VAR r: REFANY = SmallInteger.FromInt(0); >>> >>> then >>> >>> ISTYPE(r, REFANY) => TRUE >>> ISTYPE(r, T) => FALSE for any T # REFANY >>> >>> Similarly, for TYPECASE, r will only trigger the REFANY branch. >>> >>> NARROW(r, REFANY) => r >>> NARROW(r, T) => run-time error for any T #REFANY >>> >>> VAR x: REFANY => assignment succeeds >>> VAR x: T := r => run-time error for any T # REFANY (because of >>> implicit NARROW) >>> >> I think I am getting a bit lost in all the proposals, variations, >> counterproposals, etc., but >> > >from this argument I am inferring that your plan is that only variables > >> declared REFANY >> and not any proper subtype of REFANY can ever have a value with a tag >> bit set? Then >> the 4 narrowing operations, when and only when applied to an expression >> of static >> type REFANY, would change to make a runtime check for a tag bit and fail >> if it's set? >> It would take this to prevent a tagged value from getting into a >> variable declared a >> proper subtype of REFANY, which can be dereferenced. >> >> This would preclude making your abstract data type an opaque subtype of >> REFANY, >> and would mean all supposedly unrelated ADT modules that used the tag >> technique >> could be broken by client code that mixed up the REFANY values of one of >> them with >> those of another. I consider this a definite breach of Modula-3's >> otherwise bulletproof >> type safety. >> >>> It is impossible to dereference an expression statically typed as >>> REFANY, so there is no need for a "tagged" check on dereference. >>> Because a tagged REFANY cannot be assigned to anything other than >>> something typed REFANY, it can never propagate to a place where it can >>> be dereferenced. >>> >>> >>>> Aside from actual semantic changes, I agree with Tony that we should >>>> not burden any existing type with additional runtime work. Even though >>>> I expect small objects to support big performance gains in certain >>>> important cases, non-tagged references will still greatly predominate >>>> in most code. Create new type(s) for tagged references. >>>> >>> I'm not sure that we are seeing any semantic changes at all. And with >>> Mika's definition of SmallInteger.T as a "boxed" INTEGER object >>> (actually it would be a subrange for values that fit into >>> BITSIZE(Word.T)-1 bits), it is essentially transparent. It just >>> happens to be a run-time optimization that unboxes the INTEGER value. >>> >>> >>> I think I can implement the compiler and run-time support for this >>> very quickly. >>> >>> >>> > > From hosking at cs.purdue.edu Thu Apr 9 05:01:13 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 9 Apr 2009 13:01:13 +1000 Subject: [M3devel] small objects In-Reply-To: <49DD59DB.4050404@cox.net> References: <200904090038.n390cNsg097270@camembert.async.caltech.edu> <49DD59DB.4050404@cox.net> Message-ID: <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> Sounds like you want something like: TAGGED REFANY FOR T where T must be a type that fits into BITS(REFANY)-1? Branding could be used to prevent mixing otherwise structurally equivalent TAGGED REFANY. TAGGED BRANDED REFANY FOR T Where this breaks down is what are the subtyping rules, since I assume you'd like to store these in a REFANY and dynamically test for the appropriate tagged type: TAGGED REFANY FOR T <: REFANY But then how do we distinguish all the different TAGGED REFANY from each other at run-time? On 9 Apr 2009, at 12:13, Rodney M. Bates wrote: > Mika Nystrom wrote: >> Hmm, ok, there's one big difference between what you're saying and >> what Tony and I have been talking about. (I think your understanding >> sounds pretty correct.) >> >> You want to do objects other than small integers. Like what? And >> why? >> I was thinking the trick would apply only to one specific type of >> integer. >> > > Yes, I want a language mechanism that can be used by various > modules to implement various abstract data types, each of which > can perform the sometimes dramatic space optimization of putting > values that are common and will fit directly in the word. > One module I spoke of implements general sets of integers with > dynamically variable and sometimes large range. This differs from > the builtin SET OF.., which must have a static (and probably > relatively > small) base subrange. Thus the general, heap-allocated values contain > open arrays of Word.T, treated as sets, or if you prefer, packed > arrays > of booleans, although I manipulate them with bit-twiddling operations > from Word. > There is another, static-sized, heap-allocated object in front of > each array, > containing biases on what bits correspond to what integers in the > abstract set, etc. It all works fine now, but the usage pattern of > some > clients has a high percentage very small sets that would fit in a > word, > and there would be an 11-to-1 space savings if that could be done. > BTW, there are also two different kinds of heap objects, one that > represents a range set by just its bounds. So I am TYPECASEing > these already. It would be very convenient if I could just add > another > alternative to the TYPECASE for in-word values. > > In another case, I need truly dynamically variable sized arrays of > integers in [0..15], and the great majority are 7 elements or less, > which would fit directly in the word, but I still the need full > generality > to be available, so it's open arrays all the time, with three > additional > words each. > > If you can pack a union of a pointer and an integer into a word and > can separate them with runtime checks, then you can use the > separated integer any way you want, with bit twiddling, type > conversions, > LOOPHOLE, or whatever. That is what I am trying to get, not just > Smalltalk-like integers. > Note that Smalltalk has zero static typing, so only one internal > representation must do for the union of all possible values in > the language. In Modula-3, it would be very inconsistent with > the language's philosophy to be this restricted. >> Hmm, so your idea is to statically determine what type the references >> can have if they are non-references. So you are thinking to put >> various >> kinds of subranges into the "TAGGED" types. But you have to be >> able to >> determine, statically, which subrange it is... am I understanding >> this >> correctly? >> > > From the language, all I want is to be able to dynamically determine > whether it is a true pointer to a heap object or a value stored > directly in the word, while preserving the safety principles and > the semantics of everything already there. So I want some new > types, different from any existing types, that statically are known > to hold this kind of valueset union and can be converted/assigned > to a variable of existing type that is statically known to be either a > pointer or an integer (but not both), with a suitable runtime check. > It is also necessary to have a way to do this without risking a > runtime > error, if your code doesn't know yet which kind of value it has. > Various ADT modules can take it from there. >> Mika >> >> "Rodney M. Bates" writes: >> >>> Tony Hosking wrote: >>> >>>> On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: >>>> >>>> >>>>> Mika Nystrom wrote: >>>>> >>>>>> Hendrik, I think Tony's and my arguments that you can't break any >>>>>> existing code by allowing the squirreling away of integers into >>>>>> REFANYs are pretty solid. Pre-existing code simply can't do >>>>>> anything >>>>>> useful with unrevealed REFANYs. >>>>>> >>>>> This is only true of _unrevealed opaque subtypes_ of REFANY, >>>>> not of REFANY itself. There is lots of existing code that uses >>>>> REFANY, >>>>> and there, ISTYPE, NARROW, TYPECASE, and assigment can be and >>>>> regularly are used on it. It is essential not to alter the >>>>> semantics there. >>>>> >>>> Pre-existing code won't be able to do anything useful with tagged >>>> REFANYs: >>>> >>>> Suppose we have >>>> >>>> VAR r: REFANY = SmallInteger.FromInt(0); >>>> >>>> then >>>> >>>> ISTYPE(r, REFANY) => TRUE >>>> ISTYPE(r, T) => FALSE for any T # REFANY >>>> >>>> Similarly, for TYPECASE, r will only trigger the REFANY branch. >>>> >>>> NARROW(r, REFANY) => r >>>> NARROW(r, T) => run-time error for any T #REFANY >>>> >>>> VAR x: REFANY => assignment succeeds >>>> VAR x: T := r => run-time error for any T # REFANY (because of >>>> implicit NARROW) >>>> >>> I think I am getting a bit lost in all the proposals, variations, >>> counterproposals, etc., but >>> >> >from this argument I am inferring that your plan is that only >> variables >>> declared REFANY >>> and not any proper subtype of REFANY can ever have a value with a >>> tag bit set? Then >>> the 4 narrowing operations, when and only when applied to an >>> expression of static >>> type REFANY, would change to make a runtime check for a tag bit >>> and fail if it's set? >>> It would take this to prevent a tagged value from getting into a >>> variable declared a >>> proper subtype of REFANY, which can be dereferenced. >>> >>> This would preclude making your abstract data type an opaque >>> subtype of REFANY, >>> and would mean all supposedly unrelated ADT modules that used the >>> tag technique >>> could be broken by client code that mixed up the REFANY values of >>> one of them with >>> those of another. I consider this a definite breach of Modula-3's >>> otherwise bulletproof >>> type safety. >>>> It is impossible to dereference an expression statically typed as >>>> REFANY, so there is no need for a "tagged" check on dereference. >>>> Because a tagged REFANY cannot be assigned to anything other than >>>> something typed REFANY, it can never propagate to a place where >>>> it can be dereferenced. >>>> >>>> >>>>> Aside from actual semantic changes, I agree with Tony that we >>>>> should >>>>> not burden any existing type with additional runtime work. Even >>>>> though >>>>> I expect small objects to support big performance gains in certain >>>>> important cases, non-tagged references will still greatly >>>>> predominate >>>>> in most code. Create new type(s) for tagged references. >>>>> >>>> I'm not sure that we are seeing any semantic changes at all. And >>>> with Mika's definition of SmallInteger.T as a "boxed" INTEGER >>>> object (actually it would be a subrange for values that fit into >>>> BITSIZE(Word.T)-1 bits), it is essentially transparent. It just >>>> happens to be a run-time optimization that unboxes the INTEGER >>>> value. >>>> >>>> >>>> I think I can implement the compiler and run-time support for >>>> this very quickly. >>>> >>>> >>>> >> >> From jay.krell at cornell.edu Thu Apr 9 05:59:02 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 9 Apr 2009 03:59:02 +0000 Subject: [M3devel] small objects In-Reply-To: <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> References: <200904090038.n390cNsg097270@camembert.async.caltech.edu> <49DD59DB.4050404@cox.net> <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> Message-ID: Um, what do folks think of, like: struct { void* Type; union { size_t Integer; void* Pointer; } Value; } Variant; ? You know -- something that is two pointers, one pointer for the type, one for the value or integer? void* Type would actually be a pointer to something actually defined and elaborate. Obviously this is twice as large, not as small as it could be, but much more general and portable. No need to determine how many of bits can be the tag. And hope/assume for perf that such a small struct is passed in registers. On x86/NT 4 and 8 byte structs I think are. Type could also be an integer, index into some table, with some predefined values. #define TYPE_INTEGER 0 #define TYPE_FLOAT 1 #define TYPE_DOUBLE 2 #define TYPE_ADDRESS 3 more generally the union would have a float, and maybe a double on 64bit platforms. OR, on 64bit platforms, you probably can, with some porting work, dedicate a whole 8 bits or so to a type index, and still the thing in one "word". How many bits of address space does any 64bit platform these days or forseeable future actually implement? But 32 bits doesn't seem big enough to afford that, and still this is a portability problem -- anything less than a full pointer. - Jay > From: hosking at cs.purdue.edu > To: rodney.m.bates at cox.net > Date: Thu, 9 Apr 2009 13:01:13 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] small objects > > Sounds like you want something like: > > TAGGED REFANY FOR T > > where T must be a type that fits into BITS(REFANY)-1? > > Branding could be used to prevent mixing otherwise structurally > equivalent TAGGED REFANY. > > TAGGED BRANDED REFANY FOR T > > Where this breaks down is what are the subtyping rules, since I assume > you'd like to store these in a REFANY and dynamically test for the > appropriate tagged type: > > TAGGED REFANY FOR T <: REFANY > > But then how do we distinguish all the different TAGGED REFANY from > each other at run-time? > > On 9 Apr 2009, at 12:13, Rodney M. Bates wrote: > > > Mika Nystrom wrote: > >> Hmm, ok, there's one big difference between what you're saying and > >> what Tony and I have been talking about. (I think your understanding > >> sounds pretty correct.) > >> > >> You want to do objects other than small integers. Like what? And > >> why? > >> I was thinking the trick would apply only to one specific type of > >> integer. > >> > > > > Yes, I want a language mechanism that can be used by various > > modules to implement various abstract data types, each of which > > can perform the sometimes dramatic space optimization of putting > > values that are common and will fit directly in the word. > > One module I spoke of implements general sets of integers with > > dynamically variable and sometimes large range. This differs from > > the builtin SET OF.., which must have a static (and probably > > relatively > > small) base subrange. Thus the general, heap-allocated values contain > > open arrays of Word.T, treated as sets, or if you prefer, packed > > arrays > > of booleans, although I manipulate them with bit-twiddling operations > > from Word. > > There is another, static-sized, heap-allocated object in front of > > each array, > > containing biases on what bits correspond to what integers in the > > abstract set, etc. It all works fine now, but the usage pattern of > > some > > clients has a high percentage very small sets that would fit in a > > word, > > and there would be an 11-to-1 space savings if that could be done. > > BTW, there are also two different kinds of heap objects, one that > > represents a range set by just its bounds. So I am TYPECASEing > > these already. It would be very convenient if I could just add > > another > > alternative to the TYPECASE for in-word values. > > > > In another case, I need truly dynamically variable sized arrays of > > integers in [0..15], and the great majority are 7 elements or less, > > which would fit directly in the word, but I still the need full > > generality > > to be available, so it's open arrays all the time, with three > > additional > > words each. > > > > If you can pack a union of a pointer and an integer into a word and > > can separate them with runtime checks, then you can use the > > separated integer any way you want, with bit twiddling, type > > conversions, > > LOOPHOLE, or whatever. That is what I am trying to get, not just > > Smalltalk-like integers. > > Note that Smalltalk has zero static typing, so only one internal > > representation must do for the union of all possible values in > > the language. In Modula-3, it would be very inconsistent with > > the language's philosophy to be this restricted. > >> Hmm, so your idea is to statically determine what type the references > >> can have if they are non-references. So you are thinking to put > >> various > >> kinds of subranges into the "TAGGED" types. But you have to be > >> able to > >> determine, statically, which subrange it is... am I understanding > >> this > >> correctly? > >> > > > > From the language, all I want is to be able to dynamically determine > > whether it is a true pointer to a heap object or a value stored > > directly in the word, while preserving the safety principles and > > the semantics of everything already there. So I want some new > > types, different from any existing types, that statically are known > > to hold this kind of valueset union and can be converted/assigned > > to a variable of existing type that is statically known to be either a > > pointer or an integer (but not both), with a suitable runtime check. > > It is also necessary to have a way to do this without risking a > > runtime > > error, if your code doesn't know yet which kind of value it has. > > Various ADT modules can take it from there. > >> Mika > >> > >> "Rodney M. Bates" writes: > >> > >>> Tony Hosking wrote: > >>> > >>>> On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: > >>>> > >>>> > >>>>> Mika Nystrom wrote: > >>>>> > >>>>>> Hendrik, I think Tony's and my arguments that you can't break any > >>>>>> existing code by allowing the squirreling away of integers into > >>>>>> REFANYs are pretty solid. Pre-existing code simply can't do > >>>>>> anything > >>>>>> useful with unrevealed REFANYs. > >>>>>> > >>>>> This is only true of _unrevealed opaque subtypes_ of REFANY, > >>>>> not of REFANY itself. There is lots of existing code that uses > >>>>> REFANY, > >>>>> and there, ISTYPE, NARROW, TYPECASE, and assigment can be and > >>>>> regularly are used on it. It is essential not to alter the > >>>>> semantics there. > >>>>> > >>>> Pre-existing code won't be able to do anything useful with tagged > >>>> REFANYs: > >>>> > >>>> Suppose we have > >>>> > >>>> VAR r: REFANY = SmallInteger.FromInt(0); > >>>> > >>>> then > >>>> > >>>> ISTYPE(r, REFANY) => TRUE > >>>> ISTYPE(r, T) => FALSE for any T # REFANY > >>>> > >>>> Similarly, for TYPECASE, r will only trigger the REFANY branch. > >>>> > >>>> NARROW(r, REFANY) => r > >>>> NARROW(r, T) => run-time error for any T #REFANY > >>>> > >>>> VAR x: REFANY => assignment succeeds > >>>> VAR x: T := r => run-time error for any T # REFANY (because of > >>>> implicit NARROW) > >>>> > >>> I think I am getting a bit lost in all the proposals, variations, > >>> counterproposals, etc., but > >>> > >> >from this argument I am inferring that your plan is that only > >> variables > >>> declared REFANY > >>> and not any proper subtype of REFANY can ever have a value with a > >>> tag bit set? Then > >>> the 4 narrowing operations, when and only when applied to an > >>> expression of static > >>> type REFANY, would change to make a runtime check for a tag bit > >>> and fail if it's set? > >>> It would take this to prevent a tagged value from getting into a > >>> variable declared a > >>> proper subtype of REFANY, which can be dereferenced. > >>> > >>> This would preclude making your abstract data type an opaque > >>> subtype of REFANY, > >>> and would mean all supposedly unrelated ADT modules that used the > >>> tag technique > >>> could be broken by client code that mixed up the REFANY values of > >>> one of them with > >>> those of another. I consider this a definite breach of Modula-3's > >>> otherwise bulletproof > >>> type safety. > >>>> It is impossible to dereference an expression statically typed as > >>>> REFANY, so there is no need for a "tagged" check on dereference. > >>>> Because a tagged REFANY cannot be assigned to anything other than > >>>> something typed REFANY, it can never propagate to a place where > >>>> it can be dereferenced. > >>>> > >>>> > >>>>> Aside from actual semantic changes, I agree with Tony that we > >>>>> should > >>>>> not burden any existing type with additional runtime work. Even > >>>>> though > >>>>> I expect small objects to support big performance gains in certain > >>>>> important cases, non-tagged references will still greatly > >>>>> predominate > >>>>> in most code. Create new type(s) for tagged references. > >>>>> > >>>> I'm not sure that we are seeing any semantic changes at all. And > >>>> with Mika's definition of SmallInteger.T as a "boxed" INTEGER > >>>> object (actually it would be a subrange for values that fit into > >>>> BITSIZE(Word.T)-1 bits), it is essentially transparent. It just > >>>> happens to be a run-time optimization that unboxes the INTEGER > >>>> value. > >>>> > >>>> > >>>> I think I can implement the compiler and run-time support for > >>>> this very quickly. > >>>> > >>>> > >>>> > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Apr 9 06:22:52 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 9 Apr 2009 14:22:52 +1000 Subject: [M3devel] small objects In-Reply-To: References: <200904090038.n390cNsg097270@camembert.async.caltech.edu> <49DD59DB.4050404@cox.net> <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> Message-ID: <6DADF96B-7A17-45E8-8084-48A66372ED2D@cs.purdue.edu> I don't know what you are saving over just allocating: NEW(OBJECT i: INTEGER END) NEW(OBJECT r: REFANY END) Each is only 2 words: one for the object header and the other for the value. On 9 Apr 2009, at 13:59, Jay wrote: > Um, what do folks think of, like: > > struct > { > void* Type; > union > { > size_t Integer; > void* Pointer; > } Value; > } Variant; > > ? > You know -- something that is two pointers, one pointer for the > type, one for the value or integer? > void* Type would actually be a pointer to something actually defined > and elaborate. > > Obviously this is twice as large, not as small as it could be, but > much more general and portable. No need to determine how many of > bits can be the tag. > > And hope/assume for perf that such a small struct is passed in > registers. > On x86/NT 4 and 8 byte structs I think are. > > Type could also be an integer, index into some table, with some > predefined values. > #define TYPE_INTEGER 0 > #define TYPE_FLOAT 1 > #define TYPE_DOUBLE 2 > #define TYPE_ADDRESS 3 > > more generally the union would have a float, and maybe a double on > 64bit platforms. > > OR, on 64bit platforms, you probably can, with some porting work, > dedicate a whole 8 bits or so to a type index, and still the thing > in one "word". How many bits of address space does any 64bit > platform these days or forseeable future actually implement? > > But 32 bits doesn't seem big enough to afford that, and still this > is a portability problem -- anything less than a full pointer. > > - Jay > > > > From: hosking at cs.purdue.edu > > To: rodney.m.bates at cox.net > > Date: Thu, 9 Apr 2009 13:01:13 +1000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] small objects > > > > Sounds like you want something like: > > > > TAGGED REFANY FOR T > > > > where T must be a type that fits into BITS(REFANY)-1? > > > > Branding could be used to prevent mixing otherwise structurally > > equivalent TAGGED REFANY. > > > > TAGGED BRANDED REFANY FOR T > > > > Where this breaks down is what are the subtyping rules, since I > assume > > you'd like to store these in a REFANY and dynamically test for the > > appropriate tagged type: > > > > TAGGED REFANY FOR T <: REFANY > > > > But then how do we distinguish all the different TAGGED REFANY from > > each other at run-time? > > > > On 9 Apr 2009, at 12:13, Rodney M. Bates wrote: > > > > > Mika Nystrom wrote: > > >> Hmm, ok, there's one big difference between what you're saying > and > > >> what Tony and I have been talking about. (I think your > understanding > > >> sounds pretty correct.) > > >> > > >> You want to do objects other than small integers. Like what? And > > >> why? > > >> I was thinking the trick would apply only to one specific type of > > >> integer. > > >> > > > > > > Yes, I want a language mechanism that can be used by various > > > modules to implement various abstract data types, each of which > > > can perform the sometimes dramatic space optimization of putting > > > values that are common and will fit directly in the word. > > > One module I spoke of implements general sets of integers with > > > dynamically variable and sometimes large range. This differs from > > > the builtin SET OF.., which must have a static (and probably > > > relatively > > > small) base subrange. Thus the general, heap-allocated values > contain > > > open arrays of Word.T, treated as sets, or if you prefer, packed > > > arrays > > > of booleans, although I manipulate them with bit-twiddling > operations > > > from Word. > > > There is another, static-sized, heap-allocated object in front of > > > each array, > > > containing biases on what bits correspond to what integers in the > > > abstract set, etc. It all works fine now, but the usage pattern of > > > some > > > clients has a high percentage very small sets that would fit in a > > > word, > > > and there would be an 11-to-1 space savings if that could be done. > > > BTW, there are also two different kinds of heap objects, one that > > > represents a range set by just its bounds. So I am TYPECASEing > > > these already. It would be very convenient if I could just add > > > another > > > alternative to the TYPECASE for in-word values. > > > > > > In another case, I need truly dynamically variable sized arrays of > > > integers in [0..15], and the great majority are 7 elements or > less, > > > which would fit directly in the word, but I still the need full > > > generality > > > to be available, so it's open arrays all the time, with three > > > additional > > > words each. > > > > > > If you can pack a union of a pointer and an integer into a word > and > > > can separate them with runtime checks, then you can use the > > > separated integer any way you want, with bit twiddling, type > > > conversions, > > > LOOPHOLE, or whatever. That is what I am trying to get, not just > > > Smalltalk-like integers. > > > Note that Smalltalk has zero static typing, so only one internal > > > representation must do for the union of all possible values in > > > the language. In Modula-3, it would be very inconsistent with > > > the language's philosophy to be this restricted. > > >> Hmm, so your idea is to statically determine what type the > references > > >> can have if they are non-references. So you are thinking to put > > >> various > > >> kinds of subranges into the "TAGGED" types. But you have to be > > >> able to > > >> determine, statically, which subrange it is... am I understanding > > >> this > > >> correctly? > > >> > > > > > > From the language, all I want is to be able to dynamically > determine > > > whether it is a true pointer to a heap object or a value stored > > > directly in the word, while preserving the safety principles and > > > the semantics of everything already there. So I want some new > > > types, different from any existing types, that statically are > known > > > to hold this kind of valueset union and can be converted/assigned > > > to a variable of existing type that is statically known to be > either a > > > pointer or an integer (but not both), with a suitable runtime > check. > > > It is also necessary to have a way to do this without risking a > > > runtime > > > error, if your code doesn't know yet which kind of value it has. > > > Various ADT modules can take it from there. > > >> Mika > > >> > > >> "Rodney M. Bates" writes: > > >> > > >>> Tony Hosking wrote: > > >>> > > >>>> On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: > > >>>> > > >>>> > > >>>>> Mika Nystrom wrote: > > >>>>> > > >>>>>> Hendrik, I think Tony's and my arguments that you can't > break any > > >>>>>> existing code by allowing the squirreling away of integers > into > > >>>>>> REFANYs are pretty solid. Pre-existing code simply can't do > > >>>>>> anything > > >>>>>> useful with unrevealed REFANYs. > > >>>>>> > > >>>>> This is only true of _unrevealed opaque subtypes_ of REFANY, > > >>>>> not of REFANY itself. There is lots of existing code that uses > > >>>>> REFANY, > > >>>>> and there, ISTYPE, NARROW, TYPECASE, and assigment can be and > > >>>>> regularly are used on it. It is essential not to alter the > > >>>>> semantics there. > > >>>>> > > >>>> Pre-existing code won't be able to do anything useful with > tagged > > >>>> REFANYs: > > >>>> > > >>>> Suppose we have > > >>>> > > >>>> VAR r: REFANY = SmallInteger.FromInt(0); > > >>>> > > >>>> then > > >>>> > > >>>> ISTYPE(r, REFANY) => TRUE > > >>>> ISTYPE(r, T) => FALSE for any T # REFANY > > >>>> > > >>>> Similarly, for TYPECASE, r will only trigger the REFANY branch. > > >>>> > > >>>> NARROW(r, REFANY) => r > > >>>> NARROW(r, T) => run-time error for any T #REFANY > > >>>> > > >>>> VAR x: REFANY => assignment succeeds > > >>>> VAR x: T := r => run-time error for any T # REFANY (because of > > >>>> implicit NARROW) > > >>>> > > >>> I think I am getting a bit lost in all the proposals, > variations, > > >>> counterproposals, etc., but > > >>> > > >> >from this argument I am inferring that your plan is that only > > >> variables > > >>> declared REFANY > > >>> and not any proper subtype of REFANY can ever have a value > with a > > >>> tag bit set? Then > > >>> the 4 narrowing operations, when and only when applied to an > > >>> expression of static > > >>> type REFANY, would change to make a runtime check for a tag bit > > >>> and fail if it's set? > > >>> It would take this to prevent a tagged value from getting into a > > >>> variable declared a > > >>> proper subtype of REFANY, which can be dereferenced. > > >>> > > >>> This would preclude making your abstract data type an opaque > > >>> subtype of REFANY, > > >>> and would mean all supposedly unrelated ADT modules that used > the > > >>> tag technique > > >>> could be broken by client code that mixed up the REFANY values > of > > >>> one of them with > > >>> those of another. I consider this a definite breach of > Modula-3's > > >>> otherwise bulletproof > > >>> type safety. > > >>>> It is impossible to dereference an expression statically > typed as > > >>>> REFANY, so there is no need for a "tagged" check on > dereference. > > >>>> Because a tagged REFANY cannot be assigned to anything other > than > > >>>> something typed REFANY, it can never propagate to a place where > > >>>> it can be dereferenced. > > >>>> > > >>>> > > >>>>> Aside from actual semantic changes, I agree with Tony that we > > >>>>> should > > >>>>> not burden any existing type with additional runtime work. > Even > > >>>>> though > > >>>>> I expect small objects to support big performance gains in > certain > > >>>>> important cases, non-tagged references will still greatly > > >>>>> predominate > > >>>>> in most code. Create new type(s) for tagged references. > > >>>>> > > >>>> I'm not sure that we are seeing any semantic changes at all. > And > > >>>> with Mika's definition of SmallInteger.T as a "boxed" INTEGER > > >>>> object (actually it would be a subrange for values that fit > into > > >>>> BITSIZE(Word.T)-1 bits), it is essentially transparent. It just > > >>>> happens to be a run-time optimization that unboxes the INTEGER > > >>>> value. > > >>>> > > >>>> > > >>>> I think I can implement the compiler and run-time support for > > >>>> this very quickly. > > >>>> > > >>>> > > >>>> > > >> > > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 9 07:36:49 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 9 Apr 2009 05:36:49 +0000 Subject: [M3devel] small objects In-Reply-To: <6DADF96B-7A17-45E8-8084-48A66372ED2D@cs.purdue.edu> References: <200904090038.n390cNsg097270@camembert.async.caltech.edu> <49DD59DB.4050404@cox.net> <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> <6DADF96B-7A17-45E8-8084-48A66372ED2D@cs.purdue.edu> Message-ID: The heap allocation and pressure on the garbage collector -- such a small struct is reasonably efficient to pass around by value. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Thu, 9 Apr 2009 14:22:52 +1000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] small objects I don't know what you are saving over just allocating: NEW(OBJECT i: INTEGER END) NEW(OBJECT r: REFANY END) Each is only 2 words: one for the object header and the other for the value. On 9 Apr 2009, at 13:59, Jay wrote: Um, what do folks think of, like: struct { void* Type; union { size_t Integer; void* Pointer; } Value; } Variant; ? You know -- something that is two pointers, one pointer for the type, one for the value or integer? void* Type would actually be a pointer to something actually defined and elaborate. Obviously this is twice as large, not as small as it could be, but much more general and portable. No need to determine how many of bits can be the tag. And hope/assume for perf that such a small struct is passed in registers. On x86/NT 4 and 8 byte structs I think are. Type could also be an integer, index into some table, with some predefined values. #define TYPE_INTEGER 0 #define TYPE_FLOAT 1 #define TYPE_DOUBLE 2 #define TYPE_ADDRESS 3 more generally the union would have a float, and maybe a double on 64bit platforms. OR, on 64bit platforms, you probably can, with some porting work, dedicate a whole 8 bits or so to a type index, and still the thing in one "word". How many bits of address space does any 64bit platform these days or forseeable future actually implement? But 32 bits doesn't seem big enough to afford that, and still this is a portability problem -- anything less than a full pointer. - Jay > From: hosking at cs.purdue.edu > To: rodney.m.bates at cox.net > Date: Thu, 9 Apr 2009 13:01:13 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] small objects > > Sounds like you want something like: > > TAGGED REFANY FOR T > > where T must be a type that fits into BITS(REFANY)-1? > > Branding could be used to prevent mixing otherwise structurally > equivalent TAGGED REFANY. > > TAGGED BRANDED REFANY FOR T > > Where this breaks down is what are the subtyping rules, since I assume > you'd like to store these in a REFANY and dynamically test for the > appropriate tagged type: > > TAGGED REFANY FOR T <: REFANY > > But then how do we distinguish all the different TAGGED REFANY from > each other at run-time? > > On 9 Apr 2009, at 12:13, Rodney M. Bates wrote: > > > Mika Nystrom wrote: > >> Hmm, ok, there's one big difference between what you're saying and > >> what Tony and I have been talking about. (I think your understanding > >> sounds pretty correct.) > >> > >> You want to do objects other than small integers. Like what? And > >> why? > >> I was thinking the trick would apply only to one specific type of > >> integer. > >> > > > > Yes, I want a language mechanism that can be used by various > > modules to implement various abstract data types, each of which > > can perform the sometimes dramatic space optimization of putting > > values that are common and will fit directly in the word. > > One module I spoke of implements general sets of integers with > > dynamically variable and sometimes large range. This differs from > > the builtin SET OF.., which must have a static (and probably > > relatively > > small) base subrange. Thus the general, heap-allocated values contain > > open arrays of Word.T, treated as sets, or if you prefer, packed > > arrays > > of booleans, although I manipulate them with bit-twiddling operations > > from Word. > > There is another, static-sized, heap-allocated object in front of > > each array, > > containing biases on what bits correspond to what integers in the > > abstract set, etc. It all works fine now, but the usage pattern of > > some > > clients has a high percentage very small sets that would fit in a > > word, > > and there would be an 11-to-1 space savings if that could be done. > > BTW, there are also two different kinds of heap objects, one that > > represents a range set by just its bounds. So I am TYPECASEing > > these already. It would be very convenient if I could just add > > another > > alternative to the TYPECASE for in-word values. > > > > In another case, I need truly dynamically variable sized arrays of > > integers in [0..15], and the great majority are 7 elements or less, > > which would fit directly in the word, but I still the need full > > generality > > to be available, so it's open arrays all the time, with three > > additional > > words each. > > > > If you can pack a union of a pointer and an integer into a word and > > can separate them with runtime checks, then you can use the > > separated integer any way you want, with bit twiddling, type > > conversions, > > LOOPHOLE, or whatever. That is what I am trying to get, not just > > Smalltalk-like integers. > > Note that Smalltalk has zero static typing, so only one internal > > representation must do for the union of all possible values in > > the language. In Modula-3, it would be very inconsistent with > > the language's philosophy to be this restricted. > >> Hmm, so your idea is to statically determine what type the references > >> can have if they are non-references. So you are thinking to put > >> various > >> kinds of subranges into the "TAGGED" types. But you have to be > >> able to > >> determine, statically, which subrange it is... am I understanding > >> this > >> correctly? > >> > > > > From the language, all I want is to be able to dynamically determine > > whether it is a true pointer to a heap object or a value stored > > directly in the word, while preserving the safety principles and > > the semantics of everything already there. So I want some new > > types, different from any existing types, that statically are known > > to hold this kind of valueset union and can be converted/assigned > > to a variable of existing type that is statically known to be either a > > pointer or an integer (but not both), with a suitable runtime check. > > It is also necessary to have a way to do this without risking a > > runtime > > error, if your code doesn't know yet which kind of value it has. > > Various ADT modules can take it from there. > >> Mika > >> > >> "Rodney M. Bates" writes: > >> > >>> Tony Hosking wrote: > >>> > >>>> On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: > >>>> > >>>> > >>>>> Mika Nystrom wrote: > >>>>> > >>>>>> Hendrik, I think Tony's and my arguments that you can't break any > >>>>>> existing code by allowing the squirreling away of integers into > >>>>>> REFANYs are pretty solid. Pre-existing code simply can't do > >>>>>> anything > >>>>>> useful with unrevealed REFANYs. > >>>>>> > >>>>> This is only true of _unrevealed opaque subtypes_ of REFANY, > >>>>> not of REFANY itself. There is lots of existing code that uses > >>>>> REFANY, > >>>>> and there, ISTYPE, NARROW, TYPECASE, and assigment can be and > >>>>> regularly are used on it. It is essential not to alter the > >>>>> semantics there. > >>>>> > >>>> Pre-existing code won't be able to do anything useful with tagged > >>>> REFANYs: > >>>> > >>>> Suppose we have > >>>> > >>>> VAR r: REFANY = SmallInteger.FromInt(0); > >>>> > >>>> then > >>>> > >>>> ISTYPE(r, REFANY) => TRUE > >>>> ISTYPE(r, T) => FALSE for any T # REFANY > >>>> > >>>> Similarly, for TYPECASE, r will only trigger the REFANY branch. > >>>> > >>>> NARROW(r, REFANY) => r > >>>> NARROW(r, T) => run-time error for any T #REFANY > >>>> > >>>> VAR x: REFANY => assignment succeeds > >>>> VAR x: T := r => run-time error for any T # REFANY (because of > >>>> implicit NARROW) > >>>> > >>> I think I am getting a bit lost in all the proposals, variations, > >>> counterproposals, etc., but > >>> > >> >from this argument I am inferring that your plan is that only > >> variables > >>> declared REFANY > >>> and not any proper subtype of REFANY can ever have a value with a > >>> tag bit set? Then > >>> the 4 narrowing operations, when and only when applied to an > >>> expression of static > >>> type REFANY, would change to make a runtime check for a tag bit > >>> and fail if it's set? > >>> It would take this to prevent a tagged value from getting into a > >>> variable declared a > >>> proper subtype of REFANY, which can be dereferenced. > >>> > >>> This would preclude making your abstract data type an opaque > >>> subtype of REFANY, > >>> and would mean all supposedly unrelated ADT modules that used the > >>> tag technique > >>> could be broken by client code that mixed up the REFANY values of > >>> one of them with > >>> those of another. I consider this a definite breach of Modula-3's > >>> otherwise bulletproof > >>> type safety. > >>>> It is impossible to dereference an expression statically typed as > >>>> REFANY, so there is no need for a "tagged" check on dereference. > >>>> Because a tagged REFANY cannot be assigned to anything other than > >>>> something typed REFANY, it can never propagate to a place where > >>>> it can be dereferenced. > >>>> > >>>> > >>>>> Aside from actual semantic changes, I agree with Tony that we > >>>>> should > >>>>> not burden any existing type with additional runtime work. Even > >>>>> though > >>>>> I expect small objects to support big performance gains in certain > >>>>> important cases, non-tagged references will still greatly > >>>>> predominate > >>>>> in most code. Create new type(s) for tagged references. > >>>>> > >>>> I'm not sure that we are seeing any semantic changes at all. And > >>>> with Mika's definition of SmallInteger.T as a "boxed" INTEGER > >>>> object (actually it would be a subrange for values that fit into > >>>> BITSIZE(Word.T)-1 bits), it is essentially transparent. It just > >>>> happens to be a run-time optimization that unboxes the INTEGER > >>>> value. > >>>> > >>>> > >>>> I think I can implement the compiler and run-time support for > >>>> this very quickly. > >>>> > >>>> > >>>> > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Apr 9 13:55:39 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 9 Apr 2009 07:55:39 -0400 Subject: [M3devel] small objects In-Reply-To: References: <200904090038.n390cNsg097270@camembert.async.caltech.edu> <49DD59DB.4050404@cox.net> <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> <6DADF96B-7A17-45E8-8084-48A66372ED2D@cs.purdue.edu> Message-ID: <20090409115539.GA12685@topoi.pooq.com> On Thu, Apr 09, 2009 at 05:36:49AM +0000, Jay wrote: > > The heap allocation and pressure on the garbage collector -- such a small struct is reasonably efficient to pass around by value. > Generalizing: So one thing wanted is disjoint unions, like the ones Algol 68 has. The advantage of this and types with multiple subtypes is the lack of reference overhead. This suggests that if I ever get around to data structure optimisation in my Algol 68 compiler, I should implement unions between small data types and references to aligned data by the low-order bit method. And this provided an implementation technique for compact pointer/integer punning that works on machines where all bit patterns are valid object pointers. (Are there still any of these around? The last one I used was a CDC CYBER in the 70's) -- hendrik > > > - Jay > > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Thu, 9 Apr 2009 14:22:52 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] small objects > > > > > I don't know what you are saving over just allocating: > > > NEW(OBJECT i: INTEGER END) > NEW(OBJECT r: REFANY END) > > > Each is only 2 words: one for the object header and the other for the value > > > - Jay From mika at async.caltech.edu Thu Apr 9 16:10:44 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 09 Apr 2009 07:10:44 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Thu, 09 Apr 2009 13:01:13 +1000." <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> Message-ID: <200904091410.n39EAiQ4028393@camembert.async.caltech.edu> I don't know why we're having such a tough time understanding each other here :-) I think that what Rodney says is that he wants (in pseudo-modula-2 syntax): T = CASE LSB OF 1 : SmallInt | 0 : U END; SmallInt = [SmallMin..SmallMax]; for any reference type U. That is what TAGGED U would mean, no? Maybe it should be called INTUNION U or INTVARIANT U And then he wants to be able to have just U as well (so it's optional). I.e., no type safety for the SmallInt (beyond the fact that it range checks etc), but the full range of Modula-3 reference types and type checking if it's a reference. The only problem I have with this (except for the changes necessary to Modula-3) is that it can't be held in a REFANY, and that's part of the design. Of course we could go halfway and let it be held in a REFANY, but then you get the runtime LSB check again, for all instances of REFANY, but maybe it doesn't break anything else. Although you do in any case get LSB checks all over the place (in safe code!) where the TAGGED U is revealed to be a TAGGED U. Note that, as we probably all know, the Modula-3 designers expressly considered, and rejected, full variant records. Mika Tony Hosking writes: >Sounds like you want something like: > >TAGGED REFANY FOR T > >where T must be a type that fits into BITS(REFANY)-1? > >Branding could be used to prevent mixing otherwise structurally >equivalent TAGGED REFANY. > >TAGGED BRANDED REFANY FOR T > >Where this breaks down is what are the subtyping rules, since I assume >you'd like to store these in a REFANY and dynamically test for the >appropriate tagged type: > >TAGGED REFANY FOR T <: REFANY > >But then how do we distinguish all the different TAGGED REFANY from >each other at run-time? > >On 9 Apr 2009, at 12:13, Rodney M. Bates wrote: > >> Mika Nystrom wrote: >>> Hmm, ok, there's one big difference between what you're saying and >>> what Tony and I have been talking about. (I think your understanding >>> sounds pretty correct.) >>> >>> You want to do objects other than small integers. Like what? And >>> why? >>> I was thinking the trick would apply only to one specific type of >>> integer. >> >> >> Yes, I want a language mechanism that can be used by various >> modules to implement various abstract data types, each of which >> can perform the sometimes dramatic space optimization of putting >> values that are common and will fit directly in the word. >> One module I spoke of implements general sets of integers with >> dynamically variable and sometimes large range. This differs from >> the builtin SET OF.., which must have a static (and probably >> relatively >> small) base subrange. Thus the general, heap-allocated values contain >> open arrays of Word.T, treated as sets, or if you prefer, packed >> arrays >> of booleans, although I manipulate them with bit-twiddling operations >> from Word. >> There is another, static-sized, heap-allocated object in front of >> each array, >> containing biases on what bits correspond to what integers in the >> abstract set, etc. It all works fine now, but the usage pattern of >> some >> clients has a high percentage very small sets that would fit in a >> word, >> and there would be an 11-to-1 space savings if that could be done. >> BTW, there are also two different kinds of heap objects, one that >> represents a range set by just its bounds. So I am TYPECASEing >> these already. It would be very convenient if I could just add >> another >> alternative to the TYPECASE for in-word values. >> >> In another case, I need truly dynamically variable sized arrays of >> integers in [0..15], and the great majority are 7 elements or less, >> which would fit directly in the word, but I still the need full >> generality >> to be available, so it's open arrays all the time, with three >> additional >> words each. >> >> If you can pack a union of a pointer and an integer into a word and >> can separate them with runtime checks, then you can use the >> separated integer any way you want, with bit twiddling, type >> conversions, >> LOOPHOLE, or whatever. That is what I am trying to get, not just >> Smalltalk-like integers. >> Note that Smalltalk has zero static typing, so only one internal >> representation must do for the union of all possible values in >> the language. In Modula-3, it would be very inconsistent with >> the language's philosophy to be this restricted. >>> Hmm, so your idea is to statically determine what type the references >>> can have if they are non-references. So you are thinking to put >>> various >>> kinds of subranges into the "TAGGED" types. But you have to be >>> able to >>> determine, statically, which subrange it is... am I understanding >>> this >>> correctly? >>> >> >> From the language, all I want is to be able to dynamically determine >> whether it is a true pointer to a heap object or a value stored >> directly in the word, while preserving the safety principles and >> the semantics of everything already there. So I want some new >> types, different from any existing types, that statically are known >> to hold this kind of valueset union and can be converted/assigned >> to a variable of existing type that is statically known to be either a >> pointer or an integer (but not both), with a suitable runtime check. >> It is also necessary to have a way to do this without risking a >> runtime >> error, if your code doesn't know yet which kind of value it has. >> Various ADT modules can take it from there. >>> Mika >>> >>> "Rodney M. Bates" writes: >>> >>>> Tony Hosking wrote: >>>> >>>>> On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: >>>>> >>>>> >>>>>> Mika Nystrom wrote: >>>>>> >>>>>>> Hendrik, I think Tony's and my arguments that you can't break any >>>>>>> existing code by allowing the squirreling away of integers into >>>>>>> REFANYs are pretty solid. Pre-existing code simply can't do >>>>>>> anything >>>>>>> useful with unrevealed REFANYs. >>>>>>> >>>>>> This is only true of _unrevealed opaque subtypes_ of REFANY, >>>>>> not of REFANY itself. There is lots of existing code that uses >>>>>> REFANY, >>>>>> and there, ISTYPE, NARROW, TYPECASE, and assigment can be and >>>>>> regularly are used on it. It is essential not to alter the >>>>>> semantics there. >>>>>> >>>>> Pre-existing code won't be able to do anything useful with tagged >>>>> REFANYs: >>>>> >>>>> Suppose we have >>>>> >>>>> VAR r: REFANY = SmallInteger.FromInt(0); >>>>> >>>>> then >>>>> >>>>> ISTYPE(r, REFANY) => TRUE >>>>> ISTYPE(r, T) => FALSE for any T # REFANY >>>>> >>>>> Similarly, for TYPECASE, r will only trigger the REFANY branch. >>>>> >>>>> NARROW(r, REFANY) => r >>>>> NARROW(r, T) => run-time error for any T #REFANY >>>>> >>>>> VAR x: REFANY => assignment succeeds >>>>> VAR x: T := r => run-time error for any T # REFANY (because of >>>> implicit NARROW) >>>>> >>>> I think I am getting a bit lost in all the proposals, variations, >>>> counterproposals, etc., but >>>> >>> >from this argument I am inferring that your plan is that only >>> variables >>>> declared REFANY >>>> and not any proper subtype of REFANY can ever have a value with a >>>> tag bit set? Then >>>> the 4 narrowing operations, when and only when applied to an >>>> expression of static >>>> type REFANY, would change to make a runtime check for a tag bit >>>> and fail if it's set? >>>> It would take this to prevent a tagged value from getting into a >>>> variable declared a >>>> proper subtype of REFANY, which can be dereferenced. >>>> >>>> This would preclude making your abstract data type an opaque >>>> subtype of REFANY, >>>> and would mean all supposedly unrelated ADT modules that used the >>>> tag technique >>>> could be broken by client code that mixed up the REFANY values of >>>> one of them with >>>> those of another. I consider this a definite breach of Modula-3's >>>> otherwise bulletproof >>>> type safety. >>>>> It is impossible to dereference an expression statically typed as >>>>> REFANY, so there is no need for a "tagged" check on dereference. >>>>> Because a tagged REFANY cannot be assigned to anything other than >>>>> something typed REFANY, it can never propagate to a place where >>>>> it can be dereferenced. >>>>> >>>>> >>>>>> Aside from actual semantic changes, I agree with Tony that we >>>>>> should >>>>>> not burden any existing type with additional runtime work. Even >>>>>> though >>>>>> I expect small objects to support big performance gains in certain >>>>>> important cases, non-tagged references will still greatly >>>>>> predominate >>>>>> in most code. Create new type(s) for tagged references. >>>>>> >>>>> I'm not sure that we are seeing any semantic changes at all. And >>>>> with Mika's definition of SmallInteger.T as a "boxed" INTEGER >>>>> object (actually it would be a subrange for values that fit into >>>>> BITSIZE(Word.T)-1 bits), it is essentially transparent. It just >>>>> happens to be a run-time optimization that unboxes the INTEGER >>>>> value. >>>>> >>>>> >>>>> I think I can implement the compiler and run-time support for >>>>> this very quickly. >>>>> >>>>> >>>>> >>> >>> From mika at async.caltech.edu Thu Apr 9 16:13:38 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 09 Apr 2009 07:13:38 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Thu, 09 Apr 2009 03:59:02 -0000." Message-ID: <200904091413.n39EDcjV028497@camembert.async.caltech.edu> Well the point of what I was suggesting, anyhow, was that it would be very nice to store an integer in a REFANY. A REFANY is only a single word, and I don't think it's practical to expand it to two words. Certainly no more so than requiring an LSB check for certain (hopefully relatively rare) operations on REFANY... Mika Jay writes: >--_a0534b8e-9f94-40d7-a78a-5bfcfeb668e5_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Um=2C what do folks think of=2C like: > >=20 > >struct > >{ > void* Type=3B > > union > > { > size_t Integer=3B > > void* Pointer=3B > > } Value=3B > >} Variant=3B > >=20 > >? > >You know -- something that is two pointers=2C one pointer for the type=2C o= >ne for the value or integer? > >void* Type would actually be a pointer to something actually defined and el= >aborate. > >=20 > >Obviously this is twice as large=2C not as small as it could be=2C but much= > more general and portable. No need to determine how many of bits can be th= >e tag. > >=20 > >And hope/assume for perf that such a small struct is passed in registers. > >On x86/NT 4 and 8 byte structs I think are. > >=20 > >Type could also be an integer=2C index into some table=2C with some predefi= >ned values. > >#define TYPE_INTEGER 0 > >#define TYPE_FLOAT 1 > >#define TYPE_DOUBLE 2 > >#define TYPE_ADDRESS 3 > >=20 > >more generally the union would have a float=2C and maybe a double on 64bit = >platforms. > >=20 > >OR=2C on 64bit platforms=2C you probably can=2C with some porting work=2C d= >edicate a whole 8 bits or so to a type index=2C and still the thing in one = >"word". How many bits of address space does any 64bit platform these days o= >r forseeable future actually implement? > >=20 > >But 32 bits doesn't seem big enough to afford that=2C and still this is a p= >ortability problem -- anything less than a full pointer. > >=20 > > - Jay > >=20 >> From: hosking at cs.purdue.edu >> To: rodney.m.bates at cox.net >> Date: Thu=2C 9 Apr 2009 13:01:13 +1000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] small objects >>=20 >> Sounds like you want something like: >>=20 >> TAGGED REFANY FOR T >>=20 >> where T must be a type that fits into BITS(REFANY)-1? >>=20 >> Branding could be used to prevent mixing otherwise structurally=20 >> equivalent TAGGED REFANY. >>=20 >> TAGGED BRANDED REFANY FOR T >>=20 >> Where this breaks down is what are the subtyping rules=2C since I assume= >=20 >> you'd like to store these in a REFANY and dynamically test for the=20 >> appropriate tagged type: >>=20 >> TAGGED REFANY FOR T <: REFANY >>=20 >> But then how do we distinguish all the different TAGGED REFANY from=20 >> each other at run-time? >>=20 >> On 9 Apr 2009=2C at 12:13=2C Rodney M. Bates wrote: >>=20 >> > Mika Nystrom wrote: >> >> Hmm=2C ok=2C there's one big difference between what you're saying and >> >> what Tony and I have been talking about. (I think your understanding >> >> sounds pretty correct.) >> >> >> >> You want to do objects other than small integers. Like what? And=20 >> >> why? >> >> I was thinking the trick would apply only to one specific type of=20 >> >> integer. >> >> >> > >> > Yes=2C I want a language mechanism that can be used by various >> > modules to implement various abstract data types=2C each of which >> > can perform the sometimes dramatic space optimization of putting >> > values that are common and will fit directly in the word. >> > One module I spoke of implements general sets of integers with >> > dynamically variable and sometimes large range. This differs from >> > the builtin SET OF..=2C which must have a static (and probably=20 >> > relatively >> > small) base subrange. Thus the general=2C heap-allocated values contain >> > open arrays of Word.T=2C treated as sets=2C or if you prefer=2C packed= >=20 >> > arrays >> > of booleans=2C although I manipulate them with bit-twiddling operations >> > from Word. >> > There is another=2C static-sized=2C heap-allocated object in front of=20 >> > each array=2C >> > containing biases on what bits correspond to what integers in the >> > abstract set=2C etc. It all works fine now=2C but the usage pattern of= >=20 >> > some >> > clients has a high percentage very small sets that would fit in a=20 >> > word=2C >> > and there would be an 11-to-1 space savings if that could be done. >> > BTW=2C there are also two different kinds of heap objects=2C one that >> > represents a range set by just its bounds. So I am TYPECASEing >> > these already. It would be very convenient if I could just add=20 >> > another >> > alternative to the TYPECASE for in-word values. >> > >> > In another case=2C I need truly dynamically variable sized arrays of >> > integers in [0..15]=2C and the great majority are 7 elements or less=2C >> > which would fit directly in the word=2C but I still the need full=20 >> > generality >> > to be available=2C so it's open arrays all the time=2C with three=20 >> > additional >> > words each. >> > >> > If you can pack a union of a pointer and an integer into a word and >> > can separate them with runtime checks=2C then you can use the >> > separated integer any way you want=2C with bit twiddling=2C type=20 >> > conversions=2C >> > LOOPHOLE=2C or whatever. That is what I am trying to get=2C not just >> > Smalltalk-like integers. >> > Note that Smalltalk has zero static typing=2C so only one internal >> > representation must do for the union of all possible values in >> > the language. In Modula-3=2C it would be very inconsistent with >> > the language's philosophy to be this restricted. >> >> Hmm=2C so your idea is to statically determine what type the reference= >s >> >> can have if they are non-references. So you are thinking to put=20 >> >> various >> >> kinds of subranges into the "TAGGED" types. But you have to be=20 >> >> able to >> >> determine=2C statically=2C which subrange it is... am I understanding= >=20 >> >> this >> >> correctly? >> >> >> > >> > From the language=2C all I want is to be able to dynamically determine >> > whether it is a true pointer to a heap object or a value stored >> > directly in the word=2C while preserving the safety principles and >> > the semantics of everything already there. So I want some new >> > types=2C different from any existing types=2C that statically are known >> > to hold this kind of valueset union and can be converted/assigned >> > to a variable of existing type that is statically known to be either a >> > pointer or an integer (but not both)=2C with a suitable runtime check. >> > It is also necessary to have a way to do this without risking a=20 >> > runtime >> > error=2C if your code doesn't know yet which kind of value it has. >> > Various ADT modules can take it from there. >> >> Mika >> >> >> >> "Rodney M. Bates" writes: >> >> >> >>> Tony Hosking wrote: >> >>> >> >>>> On 8 Apr 2009=2C at 11:49=2C Rodney M. Bates wrote: >> >>>> >> >>>> >> >>>>> Mika Nystrom wrote: >> >>>>> >> >>>>>> Hendrik=2C I think Tony's and my arguments that you can't break an= >y >> >>>>>> existing code by allowing the squirreling away of integers into >> >>>>>> REFANYs are pretty solid. Pre-existing code simply can't do=20 >> >>>>>> anything >> >>>>>> useful with unrevealed REFANYs. >> >>>>>> >> >>>>> This is only true of _unrevealed opaque subtypes_ of REFANY=2C >> >>>>> not of REFANY itself. There is lots of existing code that uses=20 >> >>>>> REFANY=2C >> >>>>> and there=2C ISTYPE=2C NARROW=2C TYPECASE=2C and assigment can be a= >nd >> >>>>> regularly are used on it. It is essential not to alter the=20 >> >>>>> semantics there. >> >>>>> >> >>>> Pre-existing code won't be able to do anything useful with tagged=20 >> >>>> REFANYs: >> >>>> >> >>>> Suppose we have >> >>>> >> >>>> VAR r: REFANY =3D SmallInteger.FromInt(0)=3B >> >>>> >> >>>> then >> >>>> >> >>>> ISTYPE(r=2C REFANY) =3D> TRUE >> >>>> ISTYPE(r=2C T) =3D> FALSE for any T # REFANY >> >>>> >> >>>> Similarly=2C for TYPECASE=2C r will only trigger the REFANY branch. >> >>>> >> >>>> NARROW(r=2C REFANY) =3D> r >> >>>> NARROW(r=2C T) =3D> run-time error for any T #REFANY >> >>>> >> >>>> VAR x: REFANY =3D> assignment succeeds >> >>>> VAR x: T :=3D r =3D> run-time error for any T # REFANY (because of=20 >> >>>> implicit NARROW) >> >>>> >> >>> I think I am getting a bit lost in all the proposals=2C variations=2C= >=20 >> >>> counterproposals=2C etc.=2C but >> >>> >> >> >from this argument I am inferring that your plan is that only=20 >> >> variables >> >>> declared REFANY >> >>> and not any proper subtype of REFANY can ever have a value with a=20 >> >>> tag bit set? Then >> >>> the 4 narrowing operations=2C when and only when applied to an=20 >> >>> expression of static >> >>> type REFANY=2C would change to make a runtime check for a tag bit=20 >> >>> and fail if it's set? >> >>> It would take this to prevent a tagged value from getting into a=20 >> >>> variable declared a >> >>> proper subtype of REFANY=2C which can be dereferenced. >> >>> >> >>> This would preclude making your abstract data type an opaque=20 >> >>> subtype of REFANY=2C >> >>> and would mean all supposedly unrelated ADT modules that used the=20 >> >>> tag technique >> >>> could be broken by client code that mixed up the REFANY values of=20 >> >>> one of them with >> >>> those of another. I consider this a definite breach of Modula-3's=20 >> >>> otherwise bulletproof >> >>> type safety. >> >>>> It is impossible to dereference an expression statically typed as=20 >> >>>> REFANY=2C so there is no need for a "tagged" check on dereference. >> >>>> Because a tagged REFANY cannot be assigned to anything other than=20 >> >>>> something typed REFANY=2C it can never propagate to a place where=20 >> >>>> it can be dereferenced. >> >>>> >> >>>> >> >>>>> Aside from actual semantic changes=2C I agree with Tony that we=20 >> >>>>> should >> >>>>> not burden any existing type with additional runtime work. Even=20 >> >>>>> though >> >>>>> I expect small objects to support big performance gains in certain >> >>>>> important cases=2C non-tagged references will still greatly=20 >> >>>>> predominate >> >>>>> in most code. Create new type(s) for tagged references. >> >>>>> >> >>>> I'm not sure that we are seeing any semantic changes at all. And=20 >> >>>> with Mika's definition of SmallInteger.T as a "boxed" INTEGER=20 >> >>>> object (actually it would be a subrange for values that fit into=20 >> >>>> BITSIZE(Word.T)-1 bits)=2C it is essentially transparent. It just=20 >> >>>> happens to be a run-time optimization that unboxes the INTEGER=20 >> >>>> value. >> >>>> >> >>>> >> >>>> I think I can implement the compiler and run-time support for=20 >> >>>> this very quickly. >> >>>> >> >>>> >> >>>> >> >> >> >> >>=20 > >--_a0534b8e-9f94-40d7-a78a-5bfcfeb668e5_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Um=2C what do folks think of=2C like:
> =3B
>struct
>{
 =3B =3B =3B void* Type=3B
> =3B =3B =3B union
> =3B =3B =3B {
 =3B =3B =3B =3B =3B = >=3B size_t =3BInteger=3B
> =3B =3B =3B =3B =3B =3B void* Pointer=3B
> =3B =3B =3B =3B } Value=3B
>} =3BVariant=3B
> =3B
>?
>You know -- something that is two pointers=2C one pointer for the type=2C o= >ne for the value or integer?
>void* Type would actually be a pointer to something actually defined and el= >aborate.
> =3B
>Obviously this is twice as large=2C not as small as it could be=2C but much= > more general and portable. No need to determine how many of bits can be th= >e tag.
> =3B
>And hope/assume for perf that such a small struct is passed in registers.R> >On x86/NT 4 and 8 byte structs I think are.
> =3B
>Type could also be an integer=2C index into some table=2C with some predefi= >ned values.
>#define TYPE_INTEGER 0
>#define TYPE_FLOAT 1
>#define TYPE_DOUBLE 2
>#define TYPE_ADDRESS 3
> =3B
>more generally the union would have a float=2C and maybe a double on 64bit = >platforms.
> =3B
>OR=2C on 64bit platforms=2C you probably can=2C with some porting work=2C d= >edicate a whole 8 bits or so to a type index=2C and still the thing in one = >"word". How many bits of address space does any 64bit platform these days o= >r forseeable future actually implement?
> =3B
>But 32 bits doesn't seem big enough to afford that=2C and still this is a p= >ortability problem -- anything less than a full pointer.
> =3B
> =3B- Jay

 =3B
>=3B From: hosking at cs.purdue.edu
>= >=3B To: rodney.m.bates at cox.net
>=3B Date: Thu=2C 9 Apr 2009 13:01:13 += >1000
>=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] s= >mall objects
>=3B
>=3B Sounds like you want something like:
&= >gt=3B
>=3B TAGGED REFANY FOR T
>=3B
>=3B where T must be a= > type that fits into BITS(REFANY)-1?
>=3B
>=3B Branding could be= > used to prevent mixing otherwise structurally
>=3B equivalent TAGGED= > REFANY.
>=3B
>=3B TAGGED BRANDED REFANY FOR T
>=3B
>= >=3B Where this breaks down is what are the subtyping rules=2C since I assum= >e
>=3B you'd like to store these in a REFANY and dynamically test for= > the
>=3B appropriate tagged type:
>=3B
>=3B TAGGED REFANY= > FOR T <=3B: REFANY
>=3B
>=3B But then how do we distinguish a= >ll the different TAGGED REFANY from
>=3B each other at run-time?
&= >gt=3B
>=3B On 9 Apr 2009=2C at 12:13=2C Rodney M. Bates wrote:
>= >=3B
>=3B >=3B Mika Nystrom wrote:
>=3B >=3B>=3B Hmm=2C ok= >=2C there's one big difference between what you're saying and
>=3B >= >=3B>=3B what Tony and I have been talking about. (I think your understand= >ing
>=3B >=3B>=3B sounds pretty correct.)
>=3B >=3B>=3BR>>=3B >=3B>=3B You want to do objects other than small integers. Lik= >e what? And
>=3B >=3B>=3B why?
>=3B >=3B>=3B I was think= >ing the trick would apply only to one specific type of
>=3B >=3B>= >=3B integer.
>=3B >=3B>=3B
>=3B >=3B
>=3B >=3B Yes= >=2C I want a language mechanism that can be used by various
>=3B >= >=3B modules to implement various abstract data types=2C each of which
&g= >t=3B >=3B can perform the sometimes dramatic space optimization of puttin= >g
>=3B >=3B values that are common and will fit directly in the word= >.
>=3B >=3B One module I spoke of implements general sets of integer= >s with
>=3B >=3B dynamically variable and sometimes large range. Thi= >s differs from
>=3B >=3B the builtin SET OF..=2C which must have a s= >tatic (and probably
>=3B >=3B relatively
>=3B >=3B small) ba= >se subrange. Thus the general=2C heap-allocated values contain
>=3B &g= >t=3B open arrays of Word.T=2C treated as sets=2C or if you prefer=2C packed= >
>=3B >=3B arrays
>=3B >=3B of booleans=2C although I manipu= >late them with bit-twiddling operations
>=3B >=3B from Word.
>= >=3B >=3B There is another=2C static-sized=2C heap-allocated object in fro= >nt of
>=3B >=3B each array=2C
>=3B >=3B containing biases on= > what bits correspond to what integers in the
>=3B >=3B abstract set= >=2C etc. It all works fine now=2C but the usage pattern of
>=3B >= >=3B some
>=3B >=3B clients has a high percentage very small sets tha= >t would fit in a
>=3B >=3B word=2C
>=3B >=3B and there would= > be an 11-to-1 space savings if that could be done.
>=3B >=3B BTW=2C= > there are also two different kinds of heap objects=2C one that
>=3B &= >gt=3B represents a range set by just its bounds. So I am TYPECASEing
>= >=3B >=3B these already. It would be very convenient if I could just add <= >BR>>=3B >=3B another
>=3B >=3B alternative to the TYPECASE for i= >n-word values.
>=3B >=3B
>=3B >=3B In another case=2C I need = >truly dynamically variable sized arrays of
>=3B >=3B integers in [0.= >.15]=2C and the great majority are 7 elements or less=2C
>=3B >=3B w= >hich would fit directly in the word=2C but I still the need full
>=3B= > >=3B generality
>=3B >=3B to be available=2C so it's open arrays = >all the time=2C with three
>=3B >=3B additional
>=3B >=3B wo= >rds each.
>=3B >=3B
>=3B >=3B If you can pack a union of a po= >inter and an integer into a word and
>=3B >=3B can separate them wit= >h runtime checks=2C then you can use the
>=3B >=3B separated integer= > any way you want=2C with bit twiddling=2C type
>=3B >=3B conversio= >ns=2C
>=3B >=3B LOOPHOLE=2C or whatever. That is what I am trying to= > get=2C not just
>=3B >=3B Smalltalk-like integers.
>=3B >=3B= > Note that Smalltalk has zero static typing=2C so only one internal
>= >=3B >=3B representation must do for the union of all possible values inR>>=3B >=3B the language. In Modula-3=2C it would be very inconsistent = >with
>=3B >=3B the language's philosophy to be this restricted.
&= >gt=3B >=3B>=3B Hmm=2C so your idea is to statically determine what type= > the references
>=3B >=3B>=3B can have if they are non-references.= > So you are thinking to put
>=3B >=3B>=3B various
>=3B >= >=3B>=3B kinds of subranges into the "TAGGED" types. But you have to be R>>=3B >=3B>=3B able to
>=3B >=3B>=3B determine=2C staticall= >y=2C which subrange it is... am I understanding
>=3B >=3B>=3B thi= >s
>=3B >=3B>=3B correctly?
>=3B >=3B>=3B
>=3B >=3B= >
>=3B >=3B From the language=2C all I want is to be able to dynamica= >lly determine
>=3B >=3B whether it is a true pointer to a heap objec= >t or a value stored
>=3B >=3B directly in the word=2C while preservi= >ng the safety principles and
>=3B >=3B the semantics of everything a= >lready there. So I want some new
>=3B >=3B types=2C different from a= >ny existing types=2C that statically are known
>=3B >=3B to hold thi= >s kind of valueset union and can be converted/assigned
>=3B >=3B to = >a variable of existing type that is statically known to be either a
>= >=3B >=3B pointer or an integer (but not both)=2C with a suitable runtime = >check.
>=3B >=3B It is also necessary to have a way to do this witho= >ut risking a
>=3B >=3B runtime
>=3B >=3B error=2C if your co= >de doesn't know yet which kind of value it has.
>=3B >=3B Various AD= >T modules can take it from there.
>=3B >=3B>=3B Mika
>=3B >= >=3B>=3B
>=3B >=3B>=3B "Rodney M. Bates" writes:
>=3B >=3B= >>=3B
>=3B >=3B>=3B>=3B Tony Hosking wrote:
>=3B >=3B>= >=3B>=3B
>=3B >=3B>=3B>=3B>=3B On 8 Apr 2009=2C at 11:49=2C R= >odney M. Bates wrote:
>=3B >=3B>=3B>=3B>=3B
>=3B >=3B&g= >t=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B>=3B Mika Nystrom wrot= >e:
>=3B >=3B>=3B>=3B>=3B>=3B
>=3B >=3B>=3B>=3B>= >=3B>=3B>=3B Hendrik=2C I think Tony's and my arguments that you can't b= >reak any
>=3B >=3B>=3B>=3B>=3B>=3B>=3B existing code by al= >lowing the squirreling away of integers into
>=3B >=3B>=3B>=3B&g= >t=3B>=3B>=3B REFANYs are pretty solid. Pre-existing code simply can't d= >o
>=3B >=3B>=3B>=3B>=3B>=3B>=3B anything
>=3B >=3B= >>=3B>=3B>=3B>=3B>=3B useful with unrevealed REFANYs.
>=3B &g= >t=3B>=3B>=3B>=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B>=3B= > This is only true of _unrevealed opaque subtypes_ of REFANY=2C
>=3B &= >gt=3B>=3B>=3B>=3B>=3B not of REFANY itself. There is lots of existi= >ng code that uses
>=3B >=3B>=3B>=3B>=3B>=3B REFANY=2C
&g= >t=3B >=3B>=3B>=3B>=3B>=3B and there=2C ISTYPE=2C NARROW=2C TYPECA= >SE=2C and assigment can be and
>=3B >=3B>=3B>=3B>=3B>=3B reg= >ularly are used on it. It is essential not to alter the
>=3B >=3B&g= >t=3B>=3B>=3B>=3B semantics there.
>=3B >=3B>=3B>=3B>=3B&= >gt=3B
>=3B >=3B>=3B>=3B>=3B Pre-existing code won't be able to= > do anything useful with tagged
>=3B >=3B>=3B>=3B>=3B REFANYs= >:
>=3B >=3B>=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B Sup= >pose we have
>=3B >=3B>=3B>=3B>=3B
>=3B >=3B>=3B>= >=3B>=3B VAR r: REFANY =3D SmallInteger.FromInt(0)=3B
>=3B >=3B>= >=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B then
>=3B >=3B>= >=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B ISTYPE(r=2C REFANY) =3D&= >gt=3B TRUE
>=3B >=3B>=3B>=3B>=3B ISTYPE(r=2C T) =3D>=3B FALS= >E for any T # REFANY
>=3B >=3B>=3B>=3B>=3B
>=3B >=3B>= >=3B>=3B>=3B Similarly=2C for TYPECASE=2C r will only trigger the REFANY= > branch.
>=3B >=3B>=3B>=3B>=3B
>=3B >=3B>=3B>=3B>= >=3B NARROW(r=2C REFANY) =3D>=3B r
>=3B >=3B>=3B>=3B>=3B NARR= >OW(r=2C T) =3D>=3B run-time error for any T #REFANY
>=3B >=3B>= >=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B VAR x: REFANY =3D>=3B = >assignment succeeds
>=3B >=3B>=3B>=3B>=3B VAR x: T :=3D r =3D&= >gt=3B run-time error for any T # REFANY (because of
>=3B >=3B>=3B= >>=3B>=3B implicit NARROW)
>=3B >=3B>=3B>=3B>=3B
>=3B = >>=3B>=3B>=3B I think I am getting a bit lost in all the proposals=2C = >variations=2C
>=3B >=3B>=3B>=3B counterproposals=2C etc.=2C but= >
>=3B >=3B>=3B>=3B
>=3B >=3B>=3B >=3Bfrom this argume= >nt I am inferring that your plan is that only
>=3B >=3B>=3B varia= >bles
>=3B >=3B>=3B>=3B declared REFANY
>=3B >=3B>=3B>= >=3B and not any proper subtype of REFANY can ever have a value with a
&= >gt=3B >=3B>=3B>=3B tag bit set? Then
>=3B >=3B>=3B>=3B the= > 4 narrowing operations=2C when and only when applied to an
>=3B >= >=3B>=3B>=3B expression of static
>=3B >=3B>=3B>=3B type REFA= >NY=2C would change to make a runtime check for a tag bit
>=3B >=3B&= >gt=3B>=3B and fail if it's set?
>=3B >=3B>=3B>=3B It would tak= >e this to prevent a tagged value from getting into a
>=3B >=3B>= >=3B>=3B variable declared a
>=3B >=3B>=3B>=3B proper subtype o= >f REFANY=2C which can be dereferenced.
>=3B >=3B>=3B>=3B
>= >=3B >=3B>=3B>=3B This would preclude making your abstract data type a= >n opaque
>=3B >=3B>=3B>=3B subtype of REFANY=2C
>=3B >= >=3B>=3B>=3B and would mean all supposedly unrelated ADT modules that us= >ed the
>=3B >=3B>=3B>=3B tag technique
>=3B >=3B>=3B&g= >t=3B could be broken by client code that mixed up the REFANY values of
= >>=3B >=3B>=3B>=3B one of them with
>=3B >=3B>=3B>=3B tho= >se of another. I consider this a definite breach of Modula-3's
>=3B &= >gt=3B>=3B>=3B otherwise bulletproof
>=3B >=3B>=3B>=3B type s= >afety.
>=3B >=3B>=3B>=3B>=3B It is impossible to dereference a= >n expression statically typed as
>=3B >=3B>=3B>=3B>=3B REFANY= >=2C so there is no need for a "tagged" check on dereference.
>=3B >= >=3B>=3B>=3B>=3B Because a tagged REFANY cannot be assigned to anythin= >g other than
>=3B >=3B>=3B>=3B>=3B something typed REFANY=2C = >it can never propagate to a place where
>=3B >=3B>=3B>=3B>=3B= > it can be dereferenced.
>=3B >=3B>=3B>=3B>=3B
>=3B >= >=3B>=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B>=3B Aside from a= >ctual semantic changes=2C I agree with Tony that we
>=3B >=3B>=3B= >>=3B>=3B>=3B should
>=3B >=3B>=3B>=3B>=3B>=3B not burd= >en any existing type with additional runtime work. Even
>=3B >=3B&g= >t=3B>=3B>=3B>=3B though
>=3B >=3B>=3B>=3B>=3B>=3B I ex= >pect small objects to support big performance gains in certain
>=3B &g= >t=3B>=3B>=3B>=3B>=3B important cases=2C non-tagged references will = >still greatly
>=3B >=3B>=3B>=3B>=3B>=3B predominate
>= >=3B >=3B>=3B>=3B>=3B>=3B in most code. Create new type(s) for tag= >ged references.
>=3B >=3B>=3B>=3B>=3B>=3B
>=3B >=3B&g= >t=3B>=3B>=3B I'm not sure that we are seeing any semantic changes at al= >l. And
>=3B >=3B>=3B>=3B>=3B with Mika's definition of SmallI= >nteger.T as a "boxed" INTEGER
>=3B >=3B>=3B>=3B>=3B object (a= >ctually it would be a subrange for values that fit into
>=3B >=3B&g= >t=3B>=3B>=3B BITSIZE(Word.T)-1 bits)=2C it is essentially transparent. = >It just
>=3B >=3B>=3B>=3B>=3B happens to be a run-time optimi= >zation that unboxes the INTEGER
>=3B >=3B>=3B>=3B>=3B value.<= >BR>>=3B >=3B>=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B
&g= >t=3B >=3B>=3B>=3B>=3B I think I can implement the compiler and run-= >time support for
>=3B >=3B>=3B>=3B>=3B this very quickly.
= >>=3B >=3B>=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B
>= >=3B >=3B>=3B>=3B>=3B
>=3B >=3B>=3B
>=3B >=3B>=3B<= >BR>>=3B
>= > >--_a0534b8e-9f94-40d7-a78a-5bfcfeb668e5_-- From hendrik at topoi.pooq.com Thu Apr 9 16:34:40 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 9 Apr 2009 10:34:40 -0400 Subject: [M3devel] small objects In-Reply-To: <200904091410.n39EAiQ4028393@camembert.async.caltech.edu> References: <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> <200904091410.n39EAiQ4028393@camembert.async.caltech.edu> Message-ID: <20090409143440.GA13374@topoi.pooq.com> On Thu, Apr 09, 2009 at 07:10:44AM -0700, Mika Nystrom wrote: > I don't know why we're having such a tough time understanding each > other here :-) > > I think that what Rodney says is that he wants (in pseudo-modula-2 > syntax): > > T = CASE LSB OF > 1 : SmallInt > | > 0 : U > END; > > SmallInt = [SmallMin..SmallMax]; > > for any reference type U. Yes. That's what I wanted too, originally. I can accept the restriction that the reference type U might be restricted to be REFANY. > > That is what TAGGED U would mean, no? Maybe it should be called > INTUNION U or INTVARIANT U Or even UNION(SmallInt, U)? This would allow several variations on the theme if we were ever to want to go further along this route. But it would not require us to do so. > > And then he wants to be able to have just U as well (so it's > optional). > > I.e., no type safety for the SmallInt (beyond the fact that it > range checks etc), but the full range of Modula-3 reference > types and type checking if it's a reference. > > The only problem I have with this (except for the changes necessary > to Modula-3) is that it can't be held in a REFANY, and that's part > of the design. Much better not to pervert REFANY, but use a new type instead. > > Of course we could go halfway and let it be held in a REFANY, but > then you get the runtime LSB check again, for all instances of > REFANY, I really don't like requiriny a run-time check on REFANY. That's why I want it to be a separate type. > but maybe it doesn't break anything else. Although you do > in any case get LSB checks all over the place (in safe code!) where > the TAGGED U is revealed to be a TAGGED U. > > Note that, as we probably all know, the Modula-3 designers expressly > considered, and rejected, full variant records. Are these the factors they based their decision on? (1) The ones in Pascal are insecure without a lot of run-time checking. (2) Objects and inheritance take care of much of the functionality. (3) The ones in Algol 68 involve copying entire records when construction and deconstructing unions of records. What we're considering not is the case in which (2) provides excessive indirection and garbage-collector load, and in which the copying in (3) is really cheap. There are applications for which this feature could have major effects on efficiency. I have some I'd consider rewriting from C/C++ to Modula 3 if this feature were available. -- hendrik > > Mika > > > Tony Hosking writes: > >Sounds like you want something like: > > > >TAGGED REFANY FOR T > > > >where T must be a type that fits into BITS(REFANY)-1? > > > >Branding could be used to prevent mixing otherwise structurally > >equivalent TAGGED REFANY. > > > >TAGGED BRANDED REFANY FOR T > > > >Where this breaks down is what are the subtyping rules, since I assume > >you'd like to store these in a REFANY and dynamically test for the > >appropriate tagged type: > > > >TAGGED REFANY FOR T <: REFANY > > > >But then how do we distinguish all the different TAGGED REFANY from > >each other at run-time? > > > >On 9 Apr 2009, at 12:13, Rodney M. Bates wrote: > > > >> Mika Nystrom wrote: > >>> Hmm, ok, there's one big difference between what you're saying and > >>> what Tony and I have been talking about. (I think your understanding > >>> sounds pretty correct.) > >>> > >>> You want to do objects other than small integers. Like what? And > >>> why? > >>> I was thinking the trick would apply only to one specific type of > >>> integer. > >> > >> > >> Yes, I want a language mechanism that can be used by various > >> modules to implement various abstract data types, each of which > >> can perform the sometimes dramatic space optimization of putting > >> values that are common and will fit directly in the word. > >> One module I spoke of implements general sets of integers with > >> dynamically variable and sometimes large range. This differs from > >> the builtin SET OF.., which must have a static (and probably > >> relatively > >> small) base subrange. Thus the general, heap-allocated values contain > >> open arrays of Word.T, treated as sets, or if you prefer, packed > >> arrays > >> of booleans, although I manipulate them with bit-twiddling operations > >> from Word. > >> There is another, static-sized, heap-allocated object in front of > >> each array, > >> containing biases on what bits correspond to what integers in the > >> abstract set, etc. It all works fine now, but the usage pattern of > >> some > >> clients has a high percentage very small sets that would fit in a > >> word, > >> and there would be an 11-to-1 space savings if that could be done. > >> BTW, there are also two different kinds of heap objects, one that > >> represents a range set by just its bounds. So I am TYPECASEing > >> these already. It would be very convenient if I could just add > >> another > >> alternative to the TYPECASE for in-word values. > >> > >> In another case, I need truly dynamically variable sized arrays of > >> integers in [0..15], and the great majority are 7 elements or less, > >> which would fit directly in the word, but I still the need full > >> generality > >> to be available, so it's open arrays all the time, with three > >> additional > >> words each. > >> > >> If you can pack a union of a pointer and an integer into a word and > >> can separate them with runtime checks, then you can use the > >> separated integer any way you want, with bit twiddling, type > >> conversions, > >> LOOPHOLE, or whatever. That is what I am trying to get, not just > >> Smalltalk-like integers. > >> Note that Smalltalk has zero static typing, so only one internal > >> representation must do for the union of all possible values in > >> the language. In Modula-3, it would be very inconsistent with > >> the language's philosophy to be this restricted. > >>> Hmm, so your idea is to statically determine what type the references > >>> can have if they are non-references. So you are thinking to put > >>> various > >>> kinds of subranges into the "TAGGED" types. But you have to be > >>> able to > >>> determine, statically, which subrange it is... am I understanding > >>> this > >>> correctly? > >>> > >> > >> From the language, all I want is to be able to dynamically determine > >> whether it is a true pointer to a heap object or a value stored > >> directly in the word, while preserving the safety principles and > >> the semantics of everything already there. So I want some new > >> types, different from any existing types, that statically are known > >> to hold this kind of valueset union and can be converted/assigned > >> to a variable of existing type that is statically known to be either a > >> pointer or an integer (but not both), with a suitable runtime check. > >> It is also necessary to have a way to do this without risking a > >> runtime > >> error, if your code doesn't know yet which kind of value it has. > >> Various ADT modules can take it from there. > >>> Mika > >>> > >>> "Rodney M. Bates" writes: > >>> > >>>> Tony Hosking wrote: > >>>> > >>>>> On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: > >>>>> > >>>>> > >>>>>> Mika Nystrom wrote: > >>>>>> > >>>>>>> Hendrik, I think Tony's and my arguments that you can't break any > >>>>>>> existing code by allowing the squirreling away of integers into > >>>>>>> REFANYs are pretty solid. Pre-existing code simply can't do > >>>>>>> anything > >>>>>>> useful with unrevealed REFANYs. > >>>>>>> > >>>>>> This is only true of _unrevealed opaque subtypes_ of REFANY, > >>>>>> not of REFANY itself. There is lots of existing code that uses > >>>>>> REFANY, > >>>>>> and there, ISTYPE, NARROW, TYPECASE, and assigment can be and > >>>>>> regularly are used on it. It is essential not to alter the > >>>>>> semantics there. > >>>>>> > >>>>> Pre-existing code won't be able to do anything useful with tagged > >>>>> REFANYs: > >>>>> > >>>>> Suppose we have > >>>>> > >>>>> VAR r: REFANY = SmallInteger.FromInt(0); > >>>>> > >>>>> then > >>>>> > >>>>> ISTYPE(r, REFANY) => TRUE > >>>>> ISTYPE(r, T) => FALSE for any T # REFANY > >>>>> > >>>>> Similarly, for TYPECASE, r will only trigger the REFANY branch. > >>>>> > >>>>> NARROW(r, REFANY) => r > >>>>> NARROW(r, T) => run-time error for any T #REFANY > >>>>> > >>>>> VAR x: REFANY => assignment succeeds > >>>>> VAR x: T := r => run-time error for any T # REFANY (because of > >>>> implicit NARROW) > >>>>> > >>>> I think I am getting a bit lost in all the proposals, variations, > >>>> counterproposals, etc., but > >>>> > >>> >from this argument I am inferring that your plan is that only > >>> variables > >>>> declared REFANY > >>>> and not any proper subtype of REFANY can ever have a value with a > >>>> tag bit set? Then > >>>> the 4 narrowing operations, when and only when applied to an > >>>> expression of static > >>>> type REFANY, would change to make a runtime check for a tag bit > >>>> and fail if it's set? > >>>> It would take this to prevent a tagged value from getting into a > >>>> variable declared a > >>>> proper subtype of REFANY, which can be dereferenced. > >>>> > >>>> This would preclude making your abstract data type an opaque > >>>> subtype of REFANY, > >>>> and would mean all supposedly unrelated ADT modules that used the > >>>> tag technique > >>>> could be broken by client code that mixed up the REFANY values of > >>>> one of them with > >>>> those of another. I consider this a definite breach of Modula-3's > >>>> otherwise bulletproof > >>>> type safety. > >>>>> It is impossible to dereference an expression statically typed as > >>>>> REFANY, so there is no need for a "tagged" check on dereference. > >>>>> Because a tagged REFANY cannot be assigned to anything other than > >>>>> something typed REFANY, it can never propagate to a place where > >>>>> it can be dereferenced. > >>>>> > >>>>> > >>>>>> Aside from actual semantic changes, I agree with Tony that we > >>>>>> should > >>>>>> not burden any existing type with additional runtime work. Even > >>>>>> though > >>>>>> I expect small objects to support big performance gains in certain > >>>>>> important cases, non-tagged references will still greatly > >>>>>> predominate > >>>>>> in most code. Create new type(s) for tagged references. > >>>>>> > >>>>> I'm not sure that we are seeing any semantic changes at all. And > >>>>> with Mika's definition of SmallInteger.T as a "boxed" INTEGER > >>>>> object (actually it would be a subrange for values that fit into > >>>>> BITSIZE(Word.T)-1 bits), it is essentially transparent. It just > >>>>> happens to be a run-time optimization that unboxes the INTEGER > >>>>> value. > >>>>> > >>>>> > >>>>> I think I can implement the compiler and run-time support for > >>>>> this very quickly. > >>>>> > >>>>> > >>>>> > >>> > >>> From mika at async.caltech.edu Thu Apr 9 17:27:11 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 09 Apr 2009 08:27:11 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Thu, 09 Apr 2009 10:34:40 EDT." <20090409143440.GA13374@topoi.pooq.com> Message-ID: <200904091527.n39FRBF0031475@camembert.async.caltech.edu> hendrik at topoi.pooq.com writes: >On Thu, Apr 09, 2009 at 07:10:44AM -0700, Mika Nystrom wrote: >> I don't know why we're having such a tough time understanding each >> other here :-) >> >> I think that what Rodney says is that he wants (in pseudo-modula-2 >> syntax): >> >> T = CASE LSB OF >> 1 : SmallInt >> | >> 0 : U >> END; >> >> SmallInt = [SmallMin..SmallMax]; >> >> for any reference type U. > >Yes. That's what I wanted too, originally. I can accept the >restriction that the reference type U might be restricted to be >REFANY. I think this is what Tony says he's implemented, essentially... ... >> >> The only problem I have with this (except for the changes necessary >> to Modula-3) is that it can't be held in a REFANY, and that's part >> of the design. > >Much better not to pervert REFANY, but use a new type instead. Are you sure? I want a type---some type---that can hold "any reference, even a tagged one", and I would rewrite most library code that today takes REFANY to take that instead. Why not? Why would I want to limit it to REFANY when it performs no operations that couldn't legally be performed on TAGGED REFANY. > >> >> Of course we could go halfway and let it be held in a REFANY, but >> then you get the runtime LSB check again, for all instances of >> REFANY, > >I really don't like requiriny a run-time check on REFANY. That's why >I want it to be a separate type. All the operations in question already require (*much* more complicated) run-time checks on REFANY.... and most uses of REFANY still wouldn't require the LSB check. I really think the runtime issue is a non-issue, and as I said above, if it turns out to be a real issue, one can either abandon the change (since the whole thing can be implemented transparently with a library) or else re-root ROOT and all the REF types in a new NOTQUITEREFANY type. This would be a backward-compatible change (in every sense) with Tony's runtime changes: REFANY ; (* Tony's, with the LSB trick *) NOTQUITEREFANY <: REFANY; ROOT <: NOTQUITEREFANY; REF T <: NOTQUITEREFANY; (* for all T *) After that, future, change, people who want to avoid the LSB check on REFANY can instead use NOTQUITEREFANY. I think barely anyone will bother. Come to think of it, Modula-3 doesn't specify that there's no intermediate type between REFANY and ROOT and the other REF T's, so there's no way it could break the current language. In fact you don't have to "reveal" this new type in the language specification at all. It could just be a library type NotQuiteRefany.T. You could then introduce separately, a la Rodney, TAGGED T <: REFANY; (* for all T *) (* but *not* TAGGED T <: NOTQUITEREFANY *) > >> but maybe it doesn't break anything else. Although you do >> in any case get LSB checks all over the place (in safe code!) where >> the TAGGED U is revealed to be a TAGGED U. >> >> Note that, as we probably all know, the Modula-3 designers expressly >> considered, and rejected, full variant records. > >Are these the factors they based their decision on? > >(1) The ones in Pascal are insecure without a lot of run-time checking. > >(2) Objects and inheritance take care of much of the functionality. > >(3) The ones in Algol 68 involve copying entire records when >construction and deconstructing unions of records. (1) and (2) at least. I'll quote: "[talk about runtime errors due to freeing still-used references] Another well-known runtime error is to assign to the tag of a variant record in a way that subverts the type system. Distinguishing subversive assignments from benign assignments in the language definition is error-prone and arbitrary. The objects and classes first introduced in Simula and adopted in Oberon and Object Pascal are more general than variant records, and they are safe, so we have discarded variant records and adopted objects. [talk about objects]" (See Cardelli et al., "The Modula-3 Type System" (c) 1989 ACM.) Mika > >What we're considering not is the case in which (2) provides >excessive indirection and garbage-collector load, and in which >the copying in (3) is really cheap. There are applications >for which this feature could have major effects on efficiency. >I have some I'd consider rewriting from C/C++ to Modula 3 >if this feature were available. > >-- hendrik .... From jay.krell at cornell.edu Thu Apr 9 19:06:21 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 9 Apr 2009 17:06:21 +0000 Subject: [M3devel] FW: cvsup In-Reply-To: <20090409170205.0D1CF60C150@birch.elegosoft.com> References: <20090409170205.0D1CF60C150@birch.elegosoft.com> Message-ID: This is the first time I've used cvs import. Hopefully I don't mess it up much. This is just an initial import with no changes, no attempt to build it, etc. I think that's the right approach. Thanks, - Jay ---------------------------------------- > Date: Thu, 9 Apr 2009 19:02:04 +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/04/09 19:02:04 > > cm3/m3-tools/cvsup > > Update of /usr/cvs/cm3/m3-tools/cvsup > In directory birch:/tmp/cvs-serv5883 > > Log Message: > import cvsup-snap-16.1h > > Status: > > Vendor Tag: cvsup > Release Tags: cvsup-snap-16_1h > > N cm3/m3-tools/cvsup/Blurb > N cm3/m3-tools/cvsup/Install > N cm3/m3-tools/cvsup/License > N cm3/m3-tools/cvsup/Announce > N cm3/m3-tools/cvsup/Makefile > N cm3/m3-tools/cvsup/ChangeLog > N cm3/m3-tools/cvsup/Acknowledgments > N cm3/m3-tools/cvsup/doc/faq_ru.tail > N cm3/m3-tools/cvsup/doc/faq.tail > N cm3/m3-tools/cvsup/doc/faq_ru.faq > N cm3/m3-tools/cvsup/doc/faq.faq > N cm3/m3-tools/cvsup/doc/Protocol > N cm3/m3-tools/cvsup/doc/faqgen.awk > N cm3/m3-tools/cvsup/doc/Makefile > N cm3/m3-tools/cvsup/doc/faq.head > N cm3/m3-tools/cvsup/doc/Checkouts > N cm3/m3-tools/cvsup/doc/Attributes > N cm3/m3-tools/cvsup/doc/faq_ru.head > N cm3/m3-tools/cvsup/doc/images/yelnew.gif > N cm3/m3-tools/cvsup/doc/images/cvsup128.gif > N cm3/m3-tools/cvsup/client/Makefile > N cm3/m3-tools/cvsup/client/src/RegularUpdater.i3 > N cm3/m3-tools/cvsup/client/src/RegularUpdater.m3 > N cm3/m3-tools/cvsup/client/src/exit.pbm > N cm3/m3-tools/cvsup/client/src/TextPortLogger.i3 > N cm3/m3-tools/cvsup/client/src/Receive.i3 > N cm3/m3-tools/cvsup/client/src/TreeList.i3 > N cm3/m3-tools/cvsup/client/src/RsyncUpdater.m3 > N cm3/m3-tools/cvsup/client/src/Auth.i3 > N cm3/m3-tools/cvsup/client/src/SyncQueue.mg > N cm3/m3-tools/cvsup/client/src/SupGUI.m3 > N cm3/m3-tools/cvsup/client/src/tape_play.pbm > N cm3/m3-tools/cvsup/client/src/Version.i3 > N cm3/m3-tools/cvsup/client/src/SupFile.m3 > N cm3/m3-tools/cvsup/client/src/CheckoutUpdater.i3 > N cm3/m3-tools/cvsup/client/src/EventSync.m3 > N cm3/m3-tools/cvsup/client/src/SupFile.i3 > N cm3/m3-tools/cvsup/client/src/CheckoutUpdater.m3 > N cm3/m3-tools/cvsup/client/src/TreeList.m3 > N cm3/m3-tools/cvsup/client/src/Auth.m3 > N cm3/m3-tools/cvsup/client/src/FSClient.i3 > N cm3/m3-tools/cvsup/client/src/TextVBTLogger.i3 > N cm3/m3-tools/cvsup/client/src/CheckoutCreator.m3 > N cm3/m3-tools/cvsup/client/src/cvsup.1 > N cm3/m3-tools/cvsup/client/src/Updater.m3 > N cm3/m3-tools/cvsup/client/src/BackoffTimer.m3 > N cm3/m3-tools/cvsup/client/src/FSClient.m3 > N cm3/m3-tools/cvsup/client/src/disk.pbm > N cm3/m3-tools/cvsup/client/src/RCSUpdater.m3 > N cm3/m3-tools/cvsup/client/src/EventSync.i3 > N cm3/m3-tools/cvsup/client/src/Detailer.i3 > N cm3/m3-tools/cvsup/client/src/cvsup.cat > N cm3/m3-tools/cvsup/client/src/CheckoutCreator.i3 > N cm3/m3-tools/cvsup/client/src/Receive.m3 > N cm3/m3-tools/cvsup/client/src/Main.m3 > N cm3/m3-tools/cvsup/client/src/RegularCreator.i3 > N cm3/m3-tools/cvsup/client/src/FileUpdater.i3 > N cm3/m3-tools/cvsup/client/src/RsyncUpdater.i3 > N cm3/m3-tools/cvsup/client/src/syncqueue.tmpl > N cm3/m3-tools/cvsup/client/src/stop.pbm > N cm3/m3-tools/cvsup/client/src/FileUpdater.m3 > N cm3/m3-tools/cvsup/client/src/TextVBTLogger.m3 > N cm3/m3-tools/cvsup/client/src/SupGUIFake.m3 > N cm3/m3-tools/cvsup/client/src/m3makefile > N cm3/m3-tools/cvsup/client/src/BackoffTimer.i3 > N cm3/m3-tools/cvsup/client/src/RegularCreator.m3 > N cm3/m3-tools/cvsup/client/src/TextPortLogger.m3 > N cm3/m3-tools/cvsup/client/src/SupGUI.i3 > N cm3/m3-tools/cvsup/client/src/Copyright.txt > N cm3/m3-tools/cvsup/client/src/SyncQueue.ig > N cm3/m3-tools/cvsup/client/src/RCSUpdater.i3 > N cm3/m3-tools/cvsup/client/src/Detailer.m3 > N cm3/m3-tools/cvsup/client/src/Updater.i3 > N cm3/m3-tools/cvsup/client/src/info.pbm > N cm3/m3-tools/cvsup/client/src/Fixup.i3 > N cm3/m3-tools/cvsup/client/src/SupGUI.fv > N cm3/m3-tools/cvsup/cvpasswd/Makefile > N cm3/m3-tools/cvsup/cvpasswd/src/Secret.i3 > N cm3/m3-tools/cvsup/cvpasswd/src/Secret.m3 > N cm3/m3-tools/cvsup/cvpasswd/src/Main.m3 > N cm3/m3-tools/cvsup/cvpasswd/src/m3makefile > N cm3/m3-tools/cvsup/cvpasswd/src/Upass.i3 > N cm3/m3-tools/cvsup/cvpasswd/src/cvpasswd.cat > N cm3/m3-tools/cvsup/cvpasswd/src/cvpasswd.1 > N cm3/m3-tools/cvsup/examples/supfile.cvs > N cm3/m3-tools/cvsup/examples/README > N cm3/m3-tools/cvsup/contrib/README > N cm3/m3-tools/cvsup/contrib/cvsup2httplog/cvsup2httplog > N cm3/m3-tools/cvsup/contrib/cvsup2httplog/README > N cm3/m3-tools/cvsup/contrib/cvsupwho/README > N cm3/m3-tools/cvsup/contrib/cvsupwho/cvsupwho > N cm3/m3-tools/cvsup/contrib/cvsupchk/README > N cm3/m3-tools/cvsup/contrib/cvsupchk/cvsupchk > N cm3/m3-tools/cvsup/contrib/cvsup2html/cvsup2html.awk > N cm3/m3-tools/cvsup/contrib/cvsup2html/README > N cm3/m3-tools/cvsup/contrib/cvsuplog2html/README > N cm3/m3-tools/cvsup/contrib/cvsuplog2html/cvsuplog2html > N cm3/m3-tools/cvsup/suplib/Makefile > N cm3/m3-tools/cvsup/suplib/src/RsyncFile.i3 > N cm3/m3-tools/cvsup/suplib/src/RsyncBlock.m3 > N cm3/m3-tools/cvsup/suplib/src/IOWatchDog.m3 > N cm3/m3-tools/cvsup/suplib/src/RCSRevNum.i3 > N cm3/m3-tools/cvsup/suplib/src/FileAttrRep.i3 > N cm3/m3-tools/cvsup/suplib/src/EscapedRd.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSError.i3 > N cm3/m3-tools/cvsup/suplib/src/Merger.ig > N cm3/m3-tools/cvsup/suplib/src/merger.tmpl > N cm3/m3-tools/cvsup/suplib/src/UgzipP.i3 > N cm3/m3-tools/cvsup/suplib/src/GzipRd.m3 > N cm3/m3-tools/cvsup/suplib/src/WatchDog.m3 > N cm3/m3-tools/cvsup/suplib/src/RCSString.m3 > N cm3/m3-tools/cvsup/suplib/src/ErrMsg.m3 > N cm3/m3-tools/cvsup/suplib/src/AuthMD5.i3 > N cm3/m3-tools/cvsup/suplib/src/SplitLogger.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSPhrase.i3 > N cm3/m3-tools/cvsup/suplib/src/MD5.i3 > N cm3/m3-tools/cvsup/suplib/src/DirEntry.i3 > N cm3/m3-tools/cvsup/suplib/src/SupMisc.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSString.i3 > N cm3/m3-tools/cvsup/suplib/src/SupMisc.m3 > N cm3/m3-tools/cvsup/suplib/src/IOWatchDog.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSEdit.i3 > N cm3/m3-tools/cvsup/suplib/src/FileAttr.i3 > N cm3/m3-tools/cvsup/suplib/src/ExecRec.i3 > N cm3/m3-tools/cvsup/suplib/src/Merger.mg > N cm3/m3-tools/cvsup/suplib/src/MySyslog.i3 > N cm3/m3-tools/cvsup/suplib/src/FileStatus.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSAccess.i3 > N cm3/m3-tools/cvsup/suplib/src/TimeStampLogger.i3 > N cm3/m3-tools/cvsup/suplib/src/SysLogger.m3 > N cm3/m3-tools/cvsup/suplib/src/GzipWr.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSDelta.m3 > N cm3/m3-tools/cvsup/suplib/src/DevT.i3 > N cm3/m3-tools/cvsup/suplib/src/TokScan.m3 > N cm3/m3-tools/cvsup/suplib/src/UnixMisc.m3 > N cm3/m3-tools/cvsup/suplib/src/Attic.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSAccess.m3 > N cm3/m3-tools/cvsup/suplib/src/CVTree.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSFile.m3 > N cm3/m3-tools/cvsup/suplib/src/WatchDog.i3 > N cm3/m3-tools/cvsup/suplib/src/RegEx.m3 > N cm3/m3-tools/cvsup/suplib/src/SplitLogger.m3 > N cm3/m3-tools/cvsup/suplib/src/MD5Digest.m3 > N cm3/m3-tools/cvsup/suplib/src/StatusFile.i3 > N cm3/m3-tools/cvsup/suplib/src/Reaper.i3 > N cm3/m3-tools/cvsup/suplib/src/DirEntry.m3 > N cm3/m3-tools/cvsup/suplib/src/Umd5.i3 > N cm3/m3-tools/cvsup/suplib/src/TimeStampLogger.m3 > N cm3/m3-tools/cvsup/suplib/src/FileStatusRaw.i3 > N cm3/m3-tools/cvsup/suplib/src/Attic.m3 > N cm3/m3-tools/cvsup/suplib/src/SupFileRec.m3 > N cm3/m3-tools/cvsup/suplib/src/GzipRd.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSTag.m3 > N cm3/m3-tools/cvsup/suplib/src/FileAttr.m3 > N cm3/m3-tools/cvsup/suplib/src/Ugzip.i3 > N cm3/m3-tools/cvsup/suplib/src/StatusFile.m3 > N cm3/m3-tools/cvsup/suplib/src/MD5Wr.m3 > N cm3/m3-tools/cvsup/suplib/src/ProcTitle.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSDelta.i3 > N cm3/m3-tools/cvsup/suplib/src/RsyncFile.m3 > N cm3/m3-tools/cvsup/suplib/src/EscapedWr.m3 > N cm3/m3-tools/cvsup/suplib/src/RCSDate.m3 > N cm3/m3-tools/cvsup/suplib/src/RCSPhrases.i3 > N cm3/m3-tools/cvsup/suplib/src/CText.i3 > N cm3/m3-tools/cvsup/suplib/src/AuthMD5.m3 > N cm3/m3-tools/cvsup/suplib/src/EscapedWr.i3 > N cm3/m3-tools/cvsup/suplib/src/CVProto.m3 > N cm3/m3-tools/cvsup/suplib/src/Glob.m3 > N cm3/m3-tools/cvsup/suplib/src/EscapedRd.m3 > N cm3/m3-tools/cvsup/suplib/src/RCSPhrases.m3 > N cm3/m3-tools/cvsup/suplib/src/SigHandler.i3 > N cm3/m3-tools/cvsup/suplib/src/UnixMiscC.c > N cm3/m3-tools/cvsup/suplib/src/Uglob.i3 > N cm3/m3-tools/cvsup/suplib/src/LoggerClass.i3 > N cm3/m3-tools/cvsup/suplib/src/Logger.i3 > N cm3/m3-tools/cvsup/suplib/src/GlobTree.i3 > N cm3/m3-tools/cvsup/suplib/src/GlobTree.m3 > N cm3/m3-tools/cvsup/suplib/src/Reaper.m3 > N cm3/m3-tools/cvsup/suplib/src/Logger.m3 > N cm3/m3-tools/cvsup/suplib/src/SigHandler.m3 > N cm3/m3-tools/cvsup/suplib/src/RCSDate.i3 > N cm3/m3-tools/cvsup/suplib/src/UnixMisc.i3 > N cm3/m3-tools/cvsup/suplib/src/CVTree.m3 > N cm3/m3-tools/cvsup/suplib/src/WrLogger.m3 > N cm3/m3-tools/cvsup/suplib/src/LockFile.m3 > N cm3/m3-tools/cvsup/suplib/src/m3makefile > N cm3/m3-tools/cvsup/suplib/src/ChannelMux.i3 > N cm3/m3-tools/cvsup/suplib/src/TokScan.i3 > N cm3/m3-tools/cvsup/suplib/src/ErrMsg.i3 > N cm3/m3-tools/cvsup/suplib/src/ChannelMux.m3 > N cm3/m3-tools/cvsup/suplib/src/FileStatus.m3 > N cm3/m3-tools/cvsup/suplib/src/PathComp.i3 > N cm3/m3-tools/cvsup/suplib/src/MD5Digest.i3 > N cm3/m3-tools/cvsup/suplib/src/GzipError.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSKeyword.i3 > N cm3/m3-tools/cvsup/suplib/src/MD5.m3 > N cm3/m3-tools/cvsup/suplib/src/PathComp.m3 > N cm3/m3-tools/cvsup/suplib/src/GzipError.m3 > N cm3/m3-tools/cvsup/suplib/src/SysLogger.i3 > N cm3/m3-tools/cvsup/suplib/src/FileID.m3 > N cm3/m3-tools/cvsup/suplib/src/MD5Wr.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSPhrase.m3 > N cm3/m3-tools/cvsup/suplib/src/RegEx.i3 > N cm3/m3-tools/cvsup/suplib/src/Glob.i3 > N cm3/m3-tools/cvsup/suplib/src/FileID.i3 > N cm3/m3-tools/cvsup/suplib/src/SupFileRec.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSTag.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSKeyword.m3 > N cm3/m3-tools/cvsup/suplib/src/WrLogger.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSDeltaClass.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSRevNum.m3 > N cm3/m3-tools/cvsup/suplib/src/CVProto.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSFile.i3 > N cm3/m3-tools/cvsup/suplib/src/LockFile.i3 > N cm3/m3-tools/cvsup/suplib/src/Ugzip.m3 > N cm3/m3-tools/cvsup/suplib/src/RsyncBlock.i3 > N cm3/m3-tools/cvsup/suplib/src/GzipWr.m3 > N cm3/m3-tools/cvsup/suplib/src/libmd/md5hl.c > N cm3/m3-tools/cvsup/suplib/src/libmd/md5.h > N cm3/m3-tools/cvsup/suplib/src/libmd/md5c.c > N cm3/m3-tools/cvsup/suplib/src/libmd/m3makefile > N cm3/m3-tools/cvsup/suplib/src/libmd/md5.copyright > N cm3/m3-tools/cvsup/suplib/src/libglob/fnmatch.h > N cm3/m3-tools/cvsup/suplib/src/libglob/fnmatch.c > N cm3/m3-tools/cvsup/suplib/src/libglob/m3makefile > N cm3/m3-tools/cvsup/suplib/src/dev_t_linux/DevTLinux.i3 > N cm3/m3-tools/cvsup/suplib/src/dev_t_linux/m3makefile > N cm3/m3-tools/cvsup/suplib/src/dev_t_linux/DevT.m3 > N cm3/m3-tools/cvsup/suplib/src/POSIX/ProcTitle.m3 > N cm3/m3-tools/cvsup/suplib/src/POSIX/m3makefile > N cm3/m3-tools/cvsup/suplib/src/POSIX/FileAttrOS.m3 > N cm3/m3-tools/cvsup/suplib/src/text_cm3/SupMiscText.m3 > N cm3/m3-tools/cvsup/suplib/src/text_cm3/CText.m3 > N cm3/m3-tools/cvsup/suplib/src/text_cm3/m3makefile > N cm3/m3-tools/cvsup/suplib/src/text_pm3/SupMiscText.m3 > N cm3/m3-tools/cvsup/suplib/src/text_pm3/CText.m3 > N cm3/m3-tools/cvsup/suplib/src/text_pm3/m3makefile > N cm3/m3-tools/cvsup/suplib/src/FreeBSD/UProcTitle.c > N cm3/m3-tools/cvsup/suplib/src/FreeBSD/FileAttrOS.i3 > N cm3/m3-tools/cvsup/suplib/src/FreeBSD/ProcTitle.m3 > N cm3/m3-tools/cvsup/suplib/src/FreeBSD/m3makefile > N cm3/m3-tools/cvsup/suplib/src/FreeBSD/UProcTitle.i3 > N cm3/m3-tools/cvsup/suplib/src/FreeBSD/FileAttrOS.m3 > N cm3/m3-tools/cvsup/suplib/src/dev_t_posix/m3makefile > N cm3/m3-tools/cvsup/suplib/src/dev_t_posix/DevT.m3 > N cm3/m3-tools/cvsup/config/src/m3makefile > N cm3/m3-tools/cvsup/suptcp/Makefile > N cm3/m3-tools/cvsup/suptcp/src/COPYRIGHT > N cm3/m3-tools/cvsup/suptcp/src/README > N cm3/m3-tools/cvsup/suptcp/src/m3makefile > N cm3/m3-tools/cvsup/suptcp/src/POSIX/COPYRIGHT > N cm3/m3-tools/cvsup/suptcp/src/POSIX/SupTCPHackNull.m3 > N cm3/m3-tools/cvsup/suptcp/src/POSIX/SupTCPHack.i3 > N cm3/m3-tools/cvsup/suptcp/src/POSIX/SupTCP.m3 > N cm3/m3-tools/cvsup/suptcp/src/POSIX/SockOptOther.m3 > N cm3/m3-tools/cvsup/suptcp/src/POSIX/SockOpt.i3 > N cm3/m3-tools/cvsup/suptcp/src/POSIX/SupTCPHack.m3 > N cm3/m3-tools/cvsup/suptcp/src/POSIX/SupTCPPosix.i3 > N cm3/m3-tools/cvsup/suptcp/src/POSIX/m3makefile > N cm3/m3-tools/cvsup/suptcp/src/POSIX/SockOptFBSD.m3 > N cm3/m3-tools/cvsup/suptcp/src/common/StreamWrClass.m3 > N cm3/m3-tools/cvsup/suptcp/src/common/COPYRIGHT > N cm3/m3-tools/cvsup/suptcp/src/common/StreamRdClass.m3 > N cm3/m3-tools/cvsup/suptcp/src/common/TCPMisc.i3 > N cm3/m3-tools/cvsup/suptcp/src/common/StreamRd.i3 > N cm3/m3-tools/cvsup/suptcp/src/common/SupConnRW.i3 > N cm3/m3-tools/cvsup/suptcp/src/common/SupConnFD.i3 > N cm3/m3-tools/cvsup/suptcp/src/common/SupErrno.i3 > N cm3/m3-tools/cvsup/suptcp/src/common/m3makefile > N cm3/m3-tools/cvsup/suptcp/src/common/SupTCP.i3 > N cm3/m3-tools/cvsup/suptcp/src/common/StreamWrClass.i3 > N cm3/m3-tools/cvsup/suptcp/src/common/SupErrnoC.c > N cm3/m3-tools/cvsup/suptcp/src/common/StreamWr.i3 > N cm3/m3-tools/cvsup/suptcp/src/common/SupConnRW.m3 > N cm3/m3-tools/cvsup/suptcp/src/common/StreamRdClass.i3 > N cm3/m3-tools/cvsup/quake/cvsup.quake > N cm3/m3-tools/cvsup/server/Makefile > N cm3/m3-tools/cvsup/server/src/ClassDB.m3 > N cm3/m3-tools/cvsup/server/src/ClientClass.i3 > N cm3/m3-tools/cvsup/server/src/FSServer.m3 > N cm3/m3-tools/cvsup/server/src/cvsupd.cat > N cm3/m3-tools/cvsup/server/src/Passwd.i3 > N cm3/m3-tools/cvsup/server/src/Version.i3 > N cm3/m3-tools/cvsup/server/src/ClientClass.m3 > N cm3/m3-tools/cvsup/server/src/cvsupd.class.cat > N cm3/m3-tools/cvsup/server/src/FSServerU.m3 > N cm3/m3-tools/cvsup/server/src/FSServer.i3 > N cm3/m3-tools/cvsup/server/src/AccessRules.i3 > N cm3/m3-tools/cvsup/server/src/ParsedDelta.m3 > N cm3/m3-tools/cvsup/server/src/Main.m3 > N cm3/m3-tools/cvsup/server/src/cvsupd.8 > N cm3/m3-tools/cvsup/server/src/AccessRules.m3 > N cm3/m3-tools/cvsup/server/src/TreeComp.i3 > N cm3/m3-tools/cvsup/server/src/ClassDB.i3 > N cm3/m3-tools/cvsup/server/src/FileInfo.i3 > N cm3/m3-tools/cvsup/server/src/Passwd.m3 > N cm3/m3-tools/cvsup/server/src/m3makefile > N cm3/m3-tools/cvsup/server/src/FileInfo.m3 > N cm3/m3-tools/cvsup/server/src/RCSComp.i3 > N cm3/m3-tools/cvsup/server/src/ParsedDelta.i3 > N cm3/m3-tools/cvsup/server/src/cvsupd.class.5 > N cm3/m3-tools/cvsup/server/src/TreeComp.m3 > N cm3/m3-tools/cvsup/server/src/RCSComp.m3 > N cm3/m3-tools/cvsup/server/src/FSServerRep.i3 > > No conflicts created by this import > From hendrik at topoi.pooq.com Thu Apr 9 21:43:37 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 9 Apr 2009 15:43:37 -0400 Subject: [M3devel] small objects In-Reply-To: <200904091527.n39FRBF0031475@camembert.async.caltech.edu> References: <20090409143440.GA13374@topoi.pooq.com> <200904091527.n39FRBF0031475@camembert.async.caltech.edu> Message-ID: <20090409194337.GA14441@topoi.pooq.com> On Thu, Apr 09, 2009 at 08:27:11AM -0700, Mika Nystrom wrote: > > hendrik at topoi.pooq.com writes: > >> > >> Note that, as we probably all know, the Modula-3 designers expressly > >> considered, and rejected, full variant records. > > > >Are these the factors they based their decision on? > > > >(1) The ones in Pascal are insecure without a lot of run-time checking. > > > >(2) Objects and inheritance take care of much of the functionality. > > > >(3) The ones in Algol 68 involve copying entire records when > >construction and deconstructing unions of records. > > (1) and (2) at least. I'll quote: > > "[talk about runtime errors due to freeing still-used references] > > Another well-known runtime error is to assign to the tag of a variant > record in a way that subverts the type system. Distinguishing > subversive assignments from benign assignments in the language > definition is error-prone and arbitrary. If I recall the Pascal definition correctly, the only assignment that was allowed to the tag of a variant was to assign the entire record, including the tag and the variant. I don't know of any Pascal compiler that even tries to check this. > The objects and classes > first introduced in Simula and adopted in Oberon and Object Pascal > are more general than variant records, and they are safe, so we > have discarded variant records and adopted objects. > > [talk about objects]" > > (See Cardelli et al., "The Modula-3 Type System" (c) 1989 ACM.) > > Mika > > > > >What we're considering not is the case in which (2) provides > >excessive indirection and garbage-collector load, and in which > >the copying in (3) is really cheap. There are applications > >for which this feature could have major effects on efficiency. > >I have some I'd consider rewriting from C/C++ to Modula 3 > >if this feature were available. > > > >-- hendrik > .... From martinbishop at bellsouth.net Thu Apr 9 22:28:58 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Thu, 09 Apr 2009 15:28:58 -0500 Subject: [M3devel] CM3 Release Message-ID: <49DE5A8A.5070307@bellsouth.net> A few days ago there was more talk of a proper "release" for CM3. I think this is very important. Even if this proper release is just full binary versions, I think it would make a big difference. These could then be used to make .deb packages for Debian/Ubuntu, and hopefully other Linux/BSD distributions. Does the Windows version come with an installer? If not, I think it should. Also, along with easy to install releases, I think a good book/tutorial should be available online for Modula-3. We already know Nelson's book is caught up with copyright stuff, but I wonder if the same is true for Harbison's book? If neither can be released online, perhaps we should try to improve the existing tutorial? (http://www.opencm3.net/doc/tutorial/m3/m3_toc.html) A lot of people right off Modula-3 as being dead because they don't even know that a good, free implementation like CM3 exists. I think the above ideas would help. From jay.krell at cornell.edu Thu Apr 9 23:53:20 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 9 Apr 2009 21:53:20 +0000 Subject: [M3devel] CM3 Release In-Reply-To: <49DE5A8A.5070307@bellsouth.net> References: <49DE5A8A.5070307@bellsouth.net> Message-ID: Historically the Windows version came with the command line cminstall. It also looked in the registry for stuff. A GUI installer that is just a glorofied unzipper is easy enough and I agree has some value. I put one together a few weeks ago. Something that does a little more to find the compiler/linker or setup a "shortcut" to a command line with environment variables might be nice. >> Even if this proper release is just full binary versions, I think it >> would make a big difference. These could then be used to make .deb Uploaded-archives already exists, with a bunch of fairly current archives.. Try them? (Thanks to Carson for trying them, wrt cvsup; I'm addressing that.) >>>>>> Just does qualifies as a release anyway? <<<<<<< More testing?? What are people's thoughts/abilities/experience on getting into: *BSD ports -- well, FreeBSD already has ezm3, that counts for something Debian, Ubuntu, Suse, Fedora, etc. repositories? You need to wrangle an approved developer into submitting the package? Olaf is clearly working on something here -- improving cminstall. I'm working on: get cvsup building, this won't take long Debugging the formsedit crash; this might take long. Moving FreeBSD/x86 to new smaller Unix/*.i3 files. This shouldn't take long. Bootstrapping from whatever platform I first did yielded invalid assembly. I'm going to try from Cygwin instead before I debug further -- something simple about how the PIC "get PC" stub's section is generated..linkonce or not, I tried editing it with Perl to match C compiler output but got it wrong. This will leave I386_DARWIN, AMD64_DARWIN as the main holdouts -- I don't have hardware for them (yet). Fixing up issues around paths to shared libraries, $ORIGIN, etc. - Like, restore buildlocal to old behavior; keep buildglobal with new behavior - move FreeBSD/x86 to use $ORIGIN with buildglobal After that, I'll probably introduce new platforms I386_LINUX, I386_FREEBSD, SPARC32_SOLARIS, I386_NT, I386_CYGWIN, I386_MINGW that are equivalent to today's LINUXLIBC6, FreeBSD4, SOLgnu/SOLsun, NT386, NT386GNU, NT386MINGNU. And put together some "boot" archives that factor out C ABI issues, OS major version variants, are very cross buildable, and produce not just cm3, but "everything" -- you compile the C and link on the target system. This way, perhaps, a lot of producing a release can fully automated on one build host. (And after all that, maybe get back to ARM_LINUX_OLDABI_UCLIBC or whatever it should be called...but a new ARM device is en route, maybe ARM_LINUX_NEWABI_GLIBC. :)) I also need to get m3gdb and cm3ide into my releases, that's comes before introducing new platform names. This entire list is not required for making a release, but m3gdb and cm3ide probably are. Some of the uploaded archives should be updated too, such as SPARC32_{LINUX,OPENBSD}. There's also a bunch of other ports I'd like to get through but they don't block a release. We should maybe split platforms into "tier 1" and "tier 2". Just because I released something, doesn't make it to tier 1. :) Tier 2 can be missing from a release or having bugs, without holding up other releases. - Jay > Date: Thu, 9 Apr 2009 15:28:58 -0500 > From: martinbishop at bellsouth.net > To: m3devel at elegosoft.com > Subject: [M3devel] CM3 Release > > A few days ago there was more talk of a proper "release" for CM3. I > think this is very important. > > Even if this proper release is just full binary versions, I think it > would make a big difference. These could then be used to make .deb > packages for Debian/Ubuntu, and hopefully other Linux/BSD distributions. > > Does the Windows version come with an installer? If not, I think it should. > > Also, along with easy to install releases, I think a good book/tutorial > should be available online for Modula-3. We already know Nelson's book > is caught up with copyright stuff, but I wonder if the same is true for > Harbison's book? > > If neither can be released online, perhaps we should try to improve the > existing tutorial? (http://www.opencm3.net/doc/tutorial/m3/m3_toc.html) > > A lot of people right off Modula-3 as being dead because they don't even > know that a good, free implementation like CM3 exists. I think the > above ideas would help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.m.bates at cox.net Fri Apr 10 00:13:52 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Thu, 09 Apr 2009 17:13:52 -0500 Subject: [M3devel] small objects In-Reply-To: <200904091527.n39FRBF0031475@camembert.async.caltech.edu> References: <200904091527.n39FRBF0031475@camembert.async.caltech.edu> Message-ID: <49DE7320.6090506@cox.net> Mika Nystrom wrote: > hendrik at topoi.pooq.com writes: > >> On Thu, Apr 09, 2009 at 07:10:44AM -0700, Mika Nystrom wrote: >> >>> I don't know why we're having such a tough time understanding each >>> other here :-) >>> >>> I think that what Rodney says is that he wants (in pseudo-modula-2 >>> syntax): >>> >>> T = CASE LSB OF >>> 1 : SmallInt >>> | >>> 0 : U >>> END; >>> >>> SmallInt = [SmallMin..SmallMax]; >>> >>> for any reference type U. >>> >> Yes. That's what I wanted too, originally. I can accept the >> restriction that the reference type U might be restricted to be >> REFANY. >> > > I think this is what Tony says he's implemented, essentially... > > ... > >>> The only problem I have with this (except for the changes necessary >>> to Modula-3) is that it can't be held in a REFANY, and that's part >>> of the design. >>> >> Much better not to pervert REFANY, but use a new type instead. >> > > Are you sure? I want a type---some type---that can hold "any > reference, even a tagged one", and I would rewrite most library > code that today takes REFANY to take that instead. Why not? Why > would I want to limit it to REFANY when it performs no operations > that couldn't legally be performed on TAGGED REFANY. > I believe my "safe" proposal would make this very simple, if I am thinking of the kind of library code you are. I envision a container data structure that takes in things and returns them without performing operations on them other than moving them around and storing them, e.g. the ever belabored stack. The values going in and out are declared REFANY, and the client passes in values of some proper subtype of REFANY, which get assigned to the REFANY parameters. When it gets them back, it narrows them to this type. In this pattern, just changing the declared type of the container values from REFANY to TAGGED REFANY would do it. The library code's storage and copying of the values would all work as before, and the client's passing to TAGGED REFANY and later narrowing it to whatever reference type it put in would also work as before, using the extended semantics of assignments and narrowing operations. > >>> Of course we could go halfway and let it be held in a REFANY, but >>> then you get the runtime LSB check again, for all instances of >>> REFANY, >>> >> I really don't like requiriny a run-time check on REFANY. That's why >> I want it to be a separate type. >> > > All the operations in question already require (*much* more > complicated) run-time checks on REFANY.... and most uses of REFANY > still wouldn't require the LSB check. > > I really think the runtime issue is a non-issue, and as I said > above, if it turns out to be a real issue, one can either abandon > the change (since the whole thing can be implemented transparently > with a library) or else re-root ROOT and all the REF types in a new > NOTQUITEREFANY type. This would be a backward-compatible change > (in every sense) with Tony's runtime changes: > > REFANY ; (* Tony's, with the LSB trick *) > > NOTQUITEREFANY <: REFANY; > > ROOT <: NOTQUITEREFANY; > > REF T <: NOTQUITEREFANY; (* for all T *) > > After that, future, change, people who want to avoid the LSB check > on REFANY can instead use NOTQUITEREFANY. I think barely anyone > will bother. > > Come to think of it, Modula-3 doesn't specify that there's no > intermediate type between REFANY and ROOT and the other REF T's, > so there's no way it could break the current language. In > fact you don't have to "reveal" this new type in the language > specification at all. It could just be a library type > NotQuiteRefany.T. > > You could then introduce separately, a la Rodney, > > TAGGED T <: REFANY; (* for all T *) > > (* but *not* TAGGED T <: NOTQUITEREFANY *) > > > >>> but maybe it doesn't break anything else. Although you do >>> in any case get LSB checks all over the place (in safe code!) where >>> the TAGGED U is revealed to be a TAGGED U. >>> >>> Note that, as we probably all know, the Modula-3 designers expressly >>> considered, and rejected, full variant records. >>> >> Are these the factors they based their decision on? >> >> (1) The ones in Pascal are insecure without a lot of run-time checking. >> >> (2) Objects and inheritance take care of much of the functionality. >> >> (3) The ones in Algol 68 involve copying entire records when >> construction and deconstructing unions of records. >> > > (1) and (2) at least. I'll quote: > > "[talk about runtime errors due to freeing still-used references] > > Another well-known runtime error is to assign to the tag of a variant > record in a way that subverts the type system. Distinguishing > subversive assignments from benign assignments in the language > definition is error-prone and arbitrary. The objects and classes > first introduced in Simula and adopted in Oberon and Object Pascal > are more general than variant records, and they are safe, so we > have discarded variant records and adopted objects. > > [talk about objects]" > > (See Cardelli et al., "The Modula-3 Type System" (c) 1989 ACM.) > > Mika > > >> What we're considering not is the case in which (2) provides >> excessive indirection and garbage-collector load, and in which >> the copying in (3) is really cheap. There are applications >> for which this feature could have major effects on efficiency. >> I have some I'd consider rewriting from C/C++ to Modula 3 >> if this feature were available. >> >> -- hendrik >> > .... > > From rodney.m.bates at cox.net Fri Apr 10 00:00:55 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Thu, 09 Apr 2009 17:00:55 -0500 Subject: [M3devel] small objects In-Reply-To: References: <200904090038.n390cNsg097270@camembert.async.caltech.edu> <49DD59DB.4050404@cox.net> <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> Message-ID: <49DE7017.1010902@cox.net> Without language changes, this could be useful. It does use two words instead of one, with always one or the other being wasted. But in my 11-to-1 example, it would give 11-to-2 savings--not to be sneezed at. One limitation it has is, to get the benefit, you have to stored the two-word record itself embedded wherever the pointer would have been, not out in the heap. So it's not a reference type and thus can't be opaque. No type unsafely here, but client code can not be prevented from breaking the abstraction. There are places in the M3 distribution where a non-reference type has a comment (* Treat as opaque *). Jay wrote: > Um, what do folks think of, like: > > struct > { > void* Type; > union > { > size_t Integer; > void* Pointer; > } Value; > } Variant; > > ? > You know -- something that is two pointers, one pointer for the type, > one for the value or integer? > void* Type would actually be a pointer to something actually defined > and elaborate. > > Obviously this is twice as large, not as small as it could be, but > much more general and portable. No need to determine how many of bits > can be the tag. > > And hope/assume for perf that such a small struct is passed in registers. > On x86/NT 4 and 8 byte structs I think are. > > Type could also be an integer, index into some table, with some > predefined values. > #define TYPE_INTEGER 0 > #define TYPE_FLOAT 1 > #define TYPE_DOUBLE 2 > #define TYPE_ADDRESS 3 > > more generally the union would have a float, and maybe a double on > 64bit platforms. > > OR, on 64bit platforms, you probably can, with some porting work, > dedicate a whole 8 bits or so to a type index, and still the thing in > one "word". How many bits of address space does any 64bit platform > these days or forseeable future actually implement? > > But 32 bits doesn't seem big enough to afford that, and still this is > a portability problem -- anything less than a full pointer. > > - Jay From rodney.m.bates at cox.net Thu Apr 9 23:50:45 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Thu, 09 Apr 2009 16:50:45 -0500 Subject: [M3devel] small objects In-Reply-To: <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> References: <200904090038.n390cNsg097270@camembert.async.caltech.edu> <49DD59DB.4050404@cox.net> <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> Message-ID: <49DE6DB5.7080807@cox.net> Tony Hosking wrote: > Sounds like you want something like: > > TAGGED REFANY FOR T > > where T must be a type that fits into BITS(REFANY)-1? Almost. But instead of a union of an arbitrary ordinal type with just REFANY, I want a union of just one ordinal type (TAG, a new language-defined subrange of INTEGER, with implementation-defined bounds) and an arbitrary traced reference or object type. I think just one ordinal type is adequate, but there are advantages to not having it restricted to REFANY, see below. Two tagged types constructed from different reference types are not the same type, have no subtype relation between them, and no assignability between them. This despite the fact that they will have overlapping value sets. There are other places in the language where this happens already. But RefType <: TAGGED RefType and TAG <: TAGGED RefType, so you can assign between a tagged type and either the reference type it is built from, or TAG. When going from the tagged type, these assignments require narrowing operations. Going to a tagged type is allowed by existing assignability rules, and the implementation can simply copy the bits at runtime. > > Branding could be used to prevent mixing otherwise structurally > equivalent TAGGED REFANY. Yes, some kind of branding is essential to allow otherwise structurally equivalent tagged types to be made unique. In my "safe" proposal, you can build a tagged type from a branded reference type, and it will inherit the uniqueness of the branded reference type. This simplifies the implementation, because BRANDED does not need to be extended to a non-reference type. Allowing a tagged type to be constructed from any reference type also means you can construct it from an opaque type if this is what you want, and it will inherit the opaqueness, as well as what's visible, from the opaque type. In unrevealed contexts, you can still narrow it to an integer and you can narrow it to the opaque type, then do whatever operations are visible in the opaque type. Example: TYPE Public = OBJECT METHODS m() END; TYPE Op <: Public; TYPE T = TAGGED Op; VAR VT: T := ... Here, without a revelation, you can do TYPECASE VT OF Op (o) => o.m() ... > > TAGGED BRANDED REFANY FOR T > > Where this breaks down is what are the subtyping rules, since I assume > you'd like to store these in a REFANY and dynamically test for the > appropriate tagged type: No, I do not want to store these in a variable of type REFANY or any other existing type. In fact, I want to forbid it. I want to store them only in a variable declared of a TAGGED type. To get the reference value out of a tagged type, do a NARROW or one of its equivalents and store the result in a REFANY. All the existing reference types and the allowable operations on them are unchanged. Only the narrowing operations make a runtime check of the tag bit. Similarly, for an integer value, narrow it and assign to an INTEGER variable. > > TAGGED REFANY FOR T <: REFANY > > But then how do we distinguish all the different TAGGED REFANY from > each other at run-time? All the tagged types are statically distinct and thus no runtime distinction is needed. The only new RT distinction is whether the value of a single tagged type is a member of TAG or of the underlying RefType. > > On 9 Apr 2009, at 12:13, Rodney M. Bates wrote: > >> Mika Nystrom wrote: >>> Hmm, ok, there's one big difference between what you're saying and >>> what Tony and I have been talking about. (I think your understanding >>> sounds pretty correct.) >>> >>> You want to do objects other than small integers. Like what? And why? >>> I was thinking the trick would apply only to one specific type of >>> integer. >>> >> >> Yes, I want a language mechanism that can be used by various >> modules to implement various abstract data types, each of which >> can perform the sometimes dramatic space optimization of putting >> values that are common and will fit directly in the word. >> One module I spoke of implements general sets of integers with >> dynamically variable and sometimes large range. This differs from >> the builtin SET OF.., which must have a static (and probably relatively >> small) base subrange. Thus the general, heap-allocated values contain >> open arrays of Word.T, treated as sets, or if you prefer, packed arrays >> of booleans, although I manipulate them with bit-twiddling operations >> from Word. >> There is another, static-sized, heap-allocated object in front of >> each array, >> containing biases on what bits correspond to what integers in the >> abstract set, etc. It all works fine now, but the usage pattern of >> some >> clients has a high percentage very small sets that would fit in a word, >> and there would be an 11-to-1 space savings if that could be done. >> BTW, there are also two different kinds of heap objects, one that >> represents a range set by just its bounds. So I am TYPECASEing >> these already. It would be very convenient if I could just add another >> alternative to the TYPECASE for in-word values. >> >> In another case, I need truly dynamically variable sized arrays of >> integers in [0..15], and the great majority are 7 elements or less, >> which would fit directly in the word, but I still the need full >> generality >> to be available, so it's open arrays all the time, with three additional >> words each. >> >> If you can pack a union of a pointer and an integer into a word and >> can separate them with runtime checks, then you can use the >> separated integer any way you want, with bit twiddling, type >> conversions, >> LOOPHOLE, or whatever. That is what I am trying to get, not just >> Smalltalk-like integers. >> Note that Smalltalk has zero static typing, so only one internal >> representation must do for the union of all possible values in >> the language. In Modula-3, it would be very inconsistent with >> the language's philosophy to be this restricted. >>> Hmm, so your idea is to statically determine what type the references >>> can have if they are non-references. So you are thinking to put >>> various >>> kinds of subranges into the "TAGGED" types. But you have to be able to >>> determine, statically, which subrange it is... am I understanding this >>> correctly? >>> >> >> From the language, all I want is to be able to dynamically determine >> whether it is a true pointer to a heap object or a value stored >> directly in the word, while preserving the safety principles and >> the semantics of everything already there. So I want some new >> types, different from any existing types, that statically are known >> to hold this kind of valueset union and can be converted/assigned >> to a variable of existing type that is statically known to be either a >> pointer or an integer (but not both), with a suitable runtime check. >> It is also necessary to have a way to do this without risking a runtime >> error, if your code doesn't know yet which kind of value it has. >> Various ADT modules can take it from there. >>> Mika >>> >>> "Rodney M. Bates" writes: >>> >>>> Tony Hosking wrote: >>>> >>>>> On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: >>>>> >>>>> >>>>>> Mika Nystrom wrote: >>>>>> >>>>>>> Hendrik, I think Tony's and my arguments that you can't break any >>>>>>> existing code by allowing the squirreling away of integers into >>>>>>> REFANYs are pretty solid. Pre-existing code simply can't do >>>>>>> anything >>>>>>> useful with unrevealed REFANYs. >>>>>>> >>>>>> This is only true of _unrevealed opaque subtypes_ of REFANY, >>>>>> not of REFANY itself. There is lots of existing code that uses >>>>>> REFANY, >>>>>> and there, ISTYPE, NARROW, TYPECASE, and assigment can be and >>>>>> regularly are used on it. It is essential not to alter the >>>>>> semantics there. >>>>>> >>>>> Pre-existing code won't be able to do anything useful with tagged >>>>> REFANYs: >>>>> >>>>> Suppose we have >>>>> >>>>> VAR r: REFANY = SmallInteger.FromInt(0); >>>>> >>>>> then >>>>> >>>>> ISTYPE(r, REFANY) => TRUE >>>>> ISTYPE(r, T) => FALSE for any T # REFANY >>>>> >>>>> Similarly, for TYPECASE, r will only trigger the REFANY branch. >>>>> >>>>> NARROW(r, REFANY) => r >>>>> NARROW(r, T) => run-time error for any T #REFANY >>>>> >>>>> VAR x: REFANY => assignment succeeds >>>>> VAR x: T := r => run-time error for any T # REFANY (because of >>>>> implicit NARROW) >>>>> >>>> I think I am getting a bit lost in all the proposals, variations, >>>> counterproposals, etc., but >>>> >>> >from this argument I am inferring that your plan is that only >>> variables >>>> declared REFANY >>>> and not any proper subtype of REFANY can ever have a value with a >>>> tag bit set? Then >>>> the 4 narrowing operations, when and only when applied to an >>>> expression of static >>>> type REFANY, would change to make a runtime check for a tag bit and >>>> fail if it's set? >>>> It would take this to prevent a tagged value from getting into a >>>> variable declared a >>>> proper subtype of REFANY, which can be dereferenced. >>>> >>>> This would preclude making your abstract data type an opaque >>>> subtype of REFANY, >>>> and would mean all supposedly unrelated ADT modules that used the >>>> tag technique >>>> could be broken by client code that mixed up the REFANY values of >>>> one of them with >>>> those of another. I consider this a definite breach of Modula-3's >>>> otherwise bulletproof >>>> type safety. >>>>> It is impossible to dereference an expression statically typed as >>>>> REFANY, so there is no need for a "tagged" check on dereference. >>>>> Because a tagged REFANY cannot be assigned to anything other than >>>>> something typed REFANY, it can never propagate to a place where it >>>>> can be dereferenced. >>>>> >>>>> >>>>>> Aside from actual semantic changes, I agree with Tony that we should >>>>>> not burden any existing type with additional runtime work. Even >>>>>> though >>>>>> I expect small objects to support big performance gains in certain >>>>>> important cases, non-tagged references will still greatly >>>>>> predominate >>>>>> in most code. Create new type(s) for tagged references. >>>>>> >>>>> I'm not sure that we are seeing any semantic changes at all. And >>>>> with Mika's definition of SmallInteger.T as a "boxed" INTEGER >>>>> object (actually it would be a subrange for values that fit into >>>>> BITSIZE(Word.T)-1 bits), it is essentially transparent. It just >>>>> happens to be a run-time optimization that unboxes the INTEGER value. >>>>> >>>>> >>>>> I think I can implement the compiler and run-time support for this >>>>> very quickly. >>>>> >>>>> >>>>> >>> >>> > > From mika at async.caltech.edu Fri Apr 10 02:04:23 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 09 Apr 2009 17:04:23 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Thu, 09 Apr 2009 16:50:45 CDT." <49DE6DB5.7080807@cox.net> Message-ID: <200904100004.n3A04NlY051431@camembert.async.caltech.edu> Sorry to splice together two emails from you, but I feel I've already used up my m3devel quota this week: "Rodney M. Bates" writes: >> Are you sure? I want a type---some type---that can hold "any >> reference, even a tagged one", and I would rewrite most library >> code that today takes REFANY to take that instead. Why not? Why >> would I want to limit it to REFANY when it performs no operations >> that couldn't legally be performed on TAGGED REFANY. >> > >I believe my "safe" proposal would make this very simple, if I am >thinking of the kind of library code you are. > >I envision a container data structure that takes in things and returns >them without performing operations on them other than moving them around >and storing them, e.g. the ever belabored stack. The values going in >and out are declared REFANY, and the client passes in values of >some proper subtype of REFANY, which get assigned to the REFANY >parameters. When it gets them back, it narrows them to this type. > >In this pattern, just changing the declared type of the container values >from REFANY to TAGGED REFANY would do it. The library code's storage ... >> you'd like to store these in a REFANY and dynamically test for the >> appropriate tagged type: > >No, I do not want to store these in a variable of type REFANY or any >other existing type. >In fact, I want to forbid it. I think you are thinking of exactly the same kind of library code. TextRefTbl.T, RefList.T, etc. After the introduction of TAGGED REFANY, what use is there for REFANY? What piece of code can you think of where the cost of the 1-LSB check of TAGGED REFANY outweighs the convenience of being able to process objects of type TAGGED T (for all ref types T) as well as objects of type T? Mika From rodney.m.bates at cox.net Fri Apr 10 19:24:49 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Fri, 10 Apr 2009 12:24:49 -0500 Subject: [M3devel] small objects In-Reply-To: <200904100004.n3A04NlY051431@camembert.async.caltech.edu> References: <200904100004.n3A04NlY051431@camembert.async.caltech.edu> Message-ID: <49DF80E1.10709@cox.net> Mika Nystrom wrote: > Sorry to splice together two emails from you, but I feel I've already > used up my m3devel quota this week: > > "Rodney M. Bates" writes: > >>> Are you sure? I want a type---some type---that can hold "any >>> reference, even a tagged one", and I would rewrite most library >>> code that today takes REFANY to take that instead. Why not? Why >>> would I want to limit it to REFANY when it performs no operations >>> that couldn't legally be performed on TAGGED REFANY. >>> >>> >> I believe my "safe" proposal would make this very simple, if I am >> thinking of the kind of library code you are. >> >> I envision a container data structure that takes in things and returns >> them without performing operations on them other than moving them around >> and storing them, e.g. the ever belabored stack. The values going in >> and out are declared REFANY, and the client passes in values of >> some proper subtype of REFANY, which get assigned to the REFANY >> parameters. When it gets them back, it narrows them to this type. >> >> In this pattern, just changing the declared type of the container values >> > >from REFANY to TAGGED REFANY would do it. The library code's storage > ... > There are two very different kinds of uses of reference and tagged types. The one I speak of above is for the type of the elements inside a container data structure. In this case, it is the client that knows what type the value really is, and will declare it as such. The library ADT module should know as little as possible about it, so it will declare it as REFANY or TAGGED REFANY. Here, you want the most general type possible, just to make the abstraction more versatile. And TAGGED REFANY generalizes it from REFANY. But... > >>> you'd like to store these in a REFANY and dynamically test for the >>> appropriate tagged type: >>> >> No, I do not want to store these in a variable of type REFANY or any >> other existing type. >> In fact, I want to forbid it. >> > > I think you are thinking of exactly the same kind of library code. > TextRefTbl.T, RefList.T, etc. > > After the introduction of TAGGED REFANY, what use is there for > REFANY? What piece of code can you think of where the cost of the > 1-LSB check of TAGGED REFANY outweighs the convenience of being > able to process objects of type TAGGED T (for all ref types T) as > well as objects of type T? > The other use is for the abstract type itself. Forgetting tagged types for a moment, I have never seen an interface/module that uses REFANY for this. Instead, the modules declare their abstract type as some proper subtype of REFANY, usually an opaque type. It would be possible to use just REFANY here of course, but that would require an otherwise unnecessary RT check on the allocated type, every time an operation of the module is called. This is a much more expensive check than a tag check, as has been pointed out in this discussion. But worse, it would sacrifice the static checking that we now have that prevents, at compile time, clients from passing, say a Text.T to some procedure in Atom that expects an Atom.T. If these modules ever wanted to use a tagged type, but the only tagged type were REFANY, we would lose this static checking, because Text.T would have to become equal to Atom.T. In cases where your algorithms don't specifically need dynamic typing, static typing is always much better, because one run of the compiler on the source code will do it. Bugs checked only at runtime require a massive test suit to be coded and then regularly rerun to get even close to the same confidence they've been found. So when using tagged types as the ADT itself,, we need to be able to have a tagged version of whatever proper subtype of REFANY the abstraction needs, including an opaque subtype of REFANY or an opaque subtype of some Public subtype of REFANY. This is why I am adamant that we need to be able to build a tagged type from any traced or object type. And once you do this, keeping REFANY itself unchanged and allowing TAGGED REFANY as one case of a tagged type falls out of the system for free _and_ saves a lot of cases that would otherwise need a new RT check that can never fail, but the language can't know that, because the type system has lost the distinction. I really feel that the fad of all dynamic typing in languages is a huge mistake and that it will someday be recognized as such. In the meantime, we have a language that provides a very extensive set of statically-typed alternatives, while also allowing dynamic typing when you really need it. This is one of Modula-3's best principles. Let's don't erode the static alternatives unnecessarily. > Mika > > From wagner at elegosoft.com Fri Apr 10 20:07:31 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 10 Apr 2009 20:07:31 +0200 Subject: [M3devel] FW: cvsup In-Reply-To: References: <20090409170205.0D1CF60C150@birch.elegosoft.com> Message-ID: <20090410200731.nho013ykaowwc4s0@mail.elegosoft.com> Quoting Jay : > > This is the first time I've used cvs import. > Hopefully I don't mess it up much. > > This is just an initial import with no changes, no attempt to build it, etc. > I think that's the right approach. You should use the latest version from the DCVS repository; it should be much more compatible with the recent CM3. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mika at async.caltech.edu Fri Apr 10 20:35:10 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 10 Apr 2009 11:35:10 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Fri, 10 Apr 2009 12:24:49 CDT." <49DF80E1.10709@cox.net> Message-ID: <200904101835.n3AIZACW001487@camembert.async.caltech.edu> Ahhhh!!!!! Now I get it, Rodney! You're talking about using tagged types "within" Modula-3. I've just been asking for tagged types to do something "that's not Modula-3". I'm completely aware that passing REFANY around is not the "Modula-3 way", and had no intention of making it so. (That's why I keep saying that only lazy people do it, so it doesn't matter.) My desire for storing integers and pointers in the same machine word is not something I thought would ever be useful in Modula-3 itself. But now what you say makes sense to me... you want to build your ADTs with this. Then you do need the full M3 type system "above" your tagged reference. I agree with you on MOST of the following: >I really feel that the fad of all dynamic typing in languages is a huge >mistake and that it will someday be recognized as such. In the >meantime, we have a language that provides a very extensive set >of statically-typed alternatives, while also allowing dynamic typing >when you really need it. This is one of Modula-3's best principles. >Let's don't erode the static alternatives unnecessarily. I program, currently, mostly in Scheme and in Modula-3, (mostly M3) and I am constantly amazed by: 1. The way that Modula-3 programs often are correct the first time they are compiled, even if they haven't been carefully designed. Using the M3 type system can really make your code obviously correct. 2. The way that Scheme programs can sometimes abstract away all sorts of type irrelevancies. In M3 you'd have to have many versions of the same code, or at least many generic instances. This is especially true for "higher-higher order" types, where one type is made from another and that was made from another, etc. (Interpret "type" liberally, please. It's probably just some sort of lambda expression.) Now I agree that untyped languages are probably a fad, and they have set computing back by years or decades(?). Too easy to make mistakes. But there is something of value there, and my feeling is that the best way to take advantage of it is to *combine* the two worlds, rather than trying to come up with some sort of "super language" that incorporates the best of both worlds and somehow manages to step on no one's toes. I'm presenting this as an alternative to type inferencing schemes in environments such as ML. So my idea, my "vision" if you like, is that we embed untyped languages in Modula-3. The parts of the system that need performance or are more convenient to program in the "bondage and discipline" world of Algol get written in Modula-3, and the parts of the system that it is more convenient (all things considered) to program in a typeless environment can be programmed in Scheme (currently, other interpreted languages can be added later if this turns out to be a good idea). But it is clear that the typeless approach of REFANY (REALLYREFANY, including the tagged types) is necessary to implement this layer of the system---if you want to be able to pass data structures seamlessly between the two layers. Maybe that explains better where I'm coming from. I have no intention of using these types for Modula-3 programming :-) However, I do see your point. A facility provided is a facility used, so if there's a very compact way of storing data in pointers, other applications than the ones I have in mind will use them, too, and perhaps lead to an abuse of Modula-3. But I'm not sure if this isn't over the line of legislating programming *style*---if we go down that route, we can do it the Java way and ban UNSAFE as well, so people won't be tempted to program C in Modula-3. In any case, the particular feature that one can hide 31 bits of information in a REFANY (and only a REFANY) can't hurt you if you don't choose to avail yourself of it---in fact it's transparent to people who don't care about it. Ok, an added 2 instructions out of 1,000 on an ISTYPE or TYPECASE of r : REFANY, but come on, that's not really an argument! So I am supportive of making a new type hierarchy TAGGED T for any T. And yes I understand that now---once you have TAGGED T---it is trivial to add a TAGGED REFANY, which you can distinguish from REFANY. I think your arguments for the TAGGED hierarchy are very good. However, I still don't think you have made a good argument *against* being able to hide 31 bits of information in a REFANY. You don't have to use the facility if it doesn't meet your requirements! Please remember that what I've been proposing is not a language change at all but a request that the runtime system and compiler respect a couple of not-difficult-to-ensure properties, so that we may do some new tricks in UNSAFE code. Nothing more than that. Mika P.S. You didn't actually give any examples of code where you would, after *your* proposed change, still use REFANY instead of switching the code to TAGGED REFANY. You said that: >And TAGGED REFANY generalizes it from REFANY. i.e., container code would switch to TAGGED REFANY >The other use is for the abstract type itself. Forgetting tagged >types for a moment, I have never seen an interface/module that >uses REFANY for this. Instead, the modules declare their abstract >type as some proper subtype of REFANY, usually an opaque type. i.e., other code doesn't actually use REFANY! (For what it's worth, your experience here matches mine. Container types (may) use REFANY and ADTs (almost) never do.) So back to my question: where would you use REFANY???? If never, then why bother having the two roots? What you're saying is that after *my* proposed runtime change, *you* will be tempted to abuse REFANY for ADTs. I don't think this is a very good argument against my proposal (but it is a good argument for yours, which is not incompatible with mine but instead expands it). The only thing that makes your proposal slightly incompatible with mine is that you're insisting on having a new distinction between REFANY and TAGGED REFANY, which I am saying will never be used in practice. And both your experience with Modula-3 and mine seem to back up this assertion. "Rodney M. Bates" writes: >Mika Nystrom wrote: >> Sorry to splice together two emails from you, but I feel I've already >> used up my m3devel quota this week: >> >> "Rodney M. Bates" writes: >> >>>> Are you sure? I want a type---some type---that can hold "any >>>> reference, even a tagged one", and I would rewrite most library >>>> code that today takes REFANY to take that instead. Why not? Why >>>> would I want to limit it to REFANY when it performs no operations >>>> that couldn't legally be performed on TAGGED REFANY. >>>> >>>> >>> I believe my "safe" proposal would make this very simple, if I am >>> thinking of the kind of library code you are. >>> >>> I envision a container data structure that takes in things and returns >>> them without performing operations on them other than moving them around >>> and storing them, e.g. the ever belabored stack. The values going in >>> and out are declared REFANY, and the client passes in values of >>> some proper subtype of REFANY, which get assigned to the REFANY >>> parameters. When it gets them back, it narrows them to this type. >>> >>> In this pattern, just changing the declared type of the container values >>> >> >from REFANY to TAGGED REFANY would do it. The library code's storage >> ... >> >There are two very different kinds of uses of reference and >tagged types. The one I speak of above is for the type of the >elements inside a container data structure. In this case, it >is the client that knows what type the value really is, and will >declare it as such. The library ADT module should know as little >as possible about it, so it will declare it as REFANY or >TAGGED REFANY. Here, you want the most general type >possible, just to make the abstraction more versatile. >And TAGGED REFANY generalizes it from REFANY. > >But... >> > > >>>> you'd like to store these in a REFANY and dynamically test for the >>>> appropriate tagged type: >>>> >>> No, I do not want to store these in a variable of type REFANY or any >>> other existing type. >>> In fact, I want to forbid it. >>> >> >> I think you are thinking of exactly the same kind of library code. >> TextRefTbl.T, RefList.T, etc. >> >> After the introduction of TAGGED REFANY, what use is there for >> REFANY? What piece of code can you think of where the cost of the >> 1-LSB check of TAGGED REFANY outweighs the convenience of being >> able to process objects of type TAGGED T (for all ref types T) as >> well as objects of type T? >> >The other use is for the abstract type itself. Forgetting tagged >types for a moment, I have never seen an interface/module that >uses REFANY for this. Instead, the modules declare their abstract >type as some proper subtype of REFANY, usually an opaque type. > >It would be possible to use just REFANY here of course, but that would >require an otherwise unnecessary RT check on the allocated type, >every time an operation of the module is called. This is a much >more expensive check than a tag check, as has been pointed out >in this discussion. > >But worse, it would sacrifice the static checking that we now have >that prevents, at compile time, clients from passing, say a Text.T >to some procedure in Atom that expects an Atom.T. If these modules >ever wanted to use a tagged type, but the only tagged type were >REFANY, we would lose this static checking, because Text.T would >have to become equal to Atom.T. > >In cases where your algorithms don't specifically need dynamic >typing, static typing is always much better, because one run of >the compiler on the source code will do it. Bugs checked >only at runtime require a massive test suit to be coded and then >regularly rerun to get even close to the same confidence they've >been found. > >So when using tagged types as the ADT itself,, we need to be able >to have a tagged version of whatever proper subtype of REFANY >the abstraction needs, including an opaque subtype of REFANY >or an opaque subtype of some Public subtype of REFANY. This is >why I am adamant that we need to be able to build a tagged type >from any traced or object type. > >And once you do this, keeping REFANY itself unchanged and allowing >TAGGED REFANY as one case of a tagged type falls out of the system >for free _and_ saves a lot of cases that would otherwise need a new RT >check that can never fail, but the language can't know that, because >the type system has lost the distinction. > >I really feel that the fad of all dynamic typing in languages is a huge >mistake and that it will someday be recognized as such. In the >meantime, we have a language that provides a very extensive set >of statically-typed alternatives, while also allowing dynamic typing >when you really need it. This is one of Modula-3's best principles. >Let's don't erode the static alternatives unnecessarily. > >> Mika >> >> From mika at async.caltech.edu Fri Apr 10 21:02:07 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 10 Apr 2009 12:02:07 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Fri, 10 Apr 2009 12:24:49 CDT." <49DF80E1.10709@cox.net> Message-ID: <200904101902.n3AJ27UI002559@camembert.async.caltech.edu> Specific proposal. What Rodney said, *except* make REFANY the root of everything. Insert an untagged root with a new name. Rodney himself has said that the uses of REFANY he knows about would be changed to accept the TAGGED type, so I simply propose allowing REFANY to handle the TAGGED type by default, and insert a new root for the untagged types. The structure of the type hierarchy is exactly the same as in Rodney's proposal, but the different naming makes it more backward-compatible. ROOT <: UNTAGGEDREFANY T <: UNTAGGEDREFANY UNTAGGEDREFANY <: REFANY and finally. TAGGED T <: REFANY (* for all T *) The advantages with this proposal are that it does precisely what Rodney is asking for (typesafe ADTs), but it's compatible with Tony's runtime changes in the *current* M3 implementation and it won't require anyone to do a massive search and replace, replacing REFANY with "TAGGED REFANY" in every existing Modula-3 program. Supposed disadvantage: every TYPECASE, NARROW, etc., of REFANY will cost an extra LSB check. Those who feel strongly about that and for some reason *know* that they don't want to process TAGGED types (which may be the empty set), can modify their code to use UNTAGGEDREFANY instead of REFANY. Mika "Rodney M. Bates" writes: >Mika Nystrom wrote: >> Sorry to splice together two emails from you, but I feel I've already >> used up my m3devel quota this week: >> >> "Rodney M. Bates" writes: >> >>>> Are you sure? I want a type---some type---that can hold "any >>>> reference, even a tagged one", and I would rewrite most library >>>> code that today takes REFANY to take that instead. Why not? Why >>>> would I want to limit it to REFANY when it performs no operations >>>> that couldn't legally be performed on TAGGED REFANY. >>>> >>>> >>> I believe my "safe" proposal would make this very simple, if I am >>> thinking of the kind of library code you are. >>> >>> I envision a container data structure that takes in things and returns >>> them without performing operations on them other than moving them around >>> and storing them, e.g. the ever belabored stack. The values going in >>> and out are declared REFANY, and the client passes in values of >>> some proper subtype of REFANY, which get assigned to the REFANY >>> parameters. When it gets them back, it narrows them to this type. >>> >>> In this pattern, just changing the declared type of the container values >>> >> >from REFANY to TAGGED REFANY would do it. The library code's storage >> ... >> >There are two very different kinds of uses of reference and >tagged types. The one I speak of above is for the type of the >elements inside a container data structure. In this case, it >is the client that knows what type the value really is, and will >declare it as such. The library ADT module should know as little >as possible about it, so it will declare it as REFANY or >TAGGED REFANY. Here, you want the most general type >possible, just to make the abstraction more versatile. >And TAGGED REFANY generalizes it from REFANY. > >But... >> > > >>>> you'd like to store these in a REFANY and dynamically test for the >>>> appropriate tagged type: >>>> >>> No, I do not want to store these in a variable of type REFANY or any >>> other existing type. >>> In fact, I want to forbid it. >>> >> >> I think you are thinking of exactly the same kind of library code. >> TextRefTbl.T, RefList.T, etc. >> >> After the introduction of TAGGED REFANY, what use is there for >> REFANY? What piece of code can you think of where the cost of the >> 1-LSB check of TAGGED REFANY outweighs the convenience of being >> able to process objects of type TAGGED T (for all ref types T) as >> well as objects of type T? >> >The other use is for the abstract type itself. Forgetting tagged >types for a moment, I have never seen an interface/module that >uses REFANY for this. Instead, the modules declare their abstract >type as some proper subtype of REFANY, usually an opaque type. > >It would be possible to use just REFANY here of course, but that would >require an otherwise unnecessary RT check on the allocated type, >every time an operation of the module is called. This is a much >more expensive check than a tag check, as has been pointed out >in this discussion. > >But worse, it would sacrifice the static checking that we now have >that prevents, at compile time, clients from passing, say a Text.T >to some procedure in Atom that expects an Atom.T. If these modules >ever wanted to use a tagged type, but the only tagged type were >REFANY, we would lose this static checking, because Text.T would >have to become equal to Atom.T. > >In cases where your algorithms don't specifically need dynamic >typing, static typing is always much better, because one run of >the compiler on the source code will do it. Bugs checked >only at runtime require a massive test suit to be coded and then >regularly rerun to get even close to the same confidence they've >been found. > >So when using tagged types as the ADT itself,, we need to be able >to have a tagged version of whatever proper subtype of REFANY >the abstraction needs, including an opaque subtype of REFANY >or an opaque subtype of some Public subtype of REFANY. This is >why I am adamant that we need to be able to build a tagged type >from any traced or object type. > >And once you do this, keeping REFANY itself unchanged and allowing >TAGGED REFANY as one case of a tagged type falls out of the system >for free _and_ saves a lot of cases that would otherwise need a new RT >check that can never fail, but the language can't know that, because >the type system has lost the distinction. > >I really feel that the fad of all dynamic typing in languages is a huge >mistake and that it will someday be recognized as such. In the >meantime, we have a language that provides a very extensive set >of statically-typed alternatives, while also allowing dynamic typing >when you really need it. This is one of Modula-3's best principles. >Let's don't erode the static alternatives unnecessarily. > >> Mika >> >> From mika at async.caltech.edu Fri Apr 10 21:18:38 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 10 Apr 2009 12:18:38 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Fri, 10 Apr 2009 12:24:49 CDT." <49DF80E1.10709@cox.net> Message-ID: <200904101918.n3AJIcLj003231@camembert.async.caltech.edu> Sigh, I hate sending so many emails to a mailing list. Sorry about the inboxes I'm clogging of people with no interest in this. But I just realized something important, which I think may be decisive in deciding the fate of the name "REFANY" in the addition of new types. Rodney proposes TAGGED T <: TAGGED REFANY T <: REFANY <: TAGGED REFANY I propose TAGGED T <: REFANY T <: UNTAGGEDREFANY <: REFANY Both proposals are identical in the power of the language that results, because they differ merely in naming. Both proposals are also backward-compatible: all existing Modula-3 programs are unchanged by them. However, UNTAGGEDREFANY (mine), is *forward*-compatible as well as backward-compatible. Think about it. The TAGGED REFANY proposal will have the following effect: people will go through all the M3 libraries and replace every or almost every occurrence of REFANY with TAGGED REFANY. The resulting code will not compile with an older compiler! In my proposal, it is the user of the TAGGED types who is responsible for---in new code only!---deciding whether he wants his code to compile both on older and newer M3 systems. If he does, then he can add appropriate implementations for compilers that don't support the TAGGED types (which will be trivial since he has to have those anyway!) The burden of handling change is on the programmer of the special new feature rather than on everyone who has a container module. I'll try to refrain from posting any more messages on this topic now. Mika "Rodney M. Bates" writes: >Mika Nystrom wrote: >> Sorry to splice together two emails from you, but I feel I've already >> used up my m3devel quota this week: >> >> "Rodney M. Bates" writes: >> >>>> Are you sure? I want a type---some type---that can hold "any >>>> reference, even a tagged one", and I would rewrite most library >>>> code that today takes REFANY to take that instead. Why not? Why >>>> would I want to limit it to REFANY when it performs no operations >>>> that couldn't legally be performed on TAGGED REFANY. >>>> >>>> >>> I believe my "safe" proposal would make this very simple, if I am >>> thinking of the kind of library code you are. >>> >>> I envision a container data structure that takes in things and returns >>> them without performing operations on them other than moving them around >>> and storing them, e.g. the ever belabored stack. The values going in >>> and out are declared REFANY, and the client passes in values of >>> some proper subtype of REFANY, which get assigned to the REFANY >>> parameters. When it gets them back, it narrows them to this type. >>> >>> In this pattern, just changing the declared type of the container values >>> >> >from REFANY to TAGGED REFANY would do it. The library code's storage >> ... >> >There are two very different kinds of uses of reference and >tagged types. The one I speak of above is for the type of the >elements inside a container data structure. In this case, it >is the client that knows what type the value really is, and will >declare it as such. The library ADT module should know as little >as possible about it, so it will declare it as REFANY or >TAGGED REFANY. Here, you want the most general type >possible, just to make the abstraction more versatile. >And TAGGED REFANY generalizes it from REFANY. > >But... >> > > >>>> you'd like to store these in a REFANY and dynamically test for the >>>> appropriate tagged type: >>>> >>> No, I do not want to store these in a variable of type REFANY or any >>> other existing type. >>> In fact, I want to forbid it. >>> >> >> I think you are thinking of exactly the same kind of library code. >> TextRefTbl.T, RefList.T, etc. >> >> After the introduction of TAGGED REFANY, what use is there for >> REFANY? What piece of code can you think of where the cost of the >> 1-LSB check of TAGGED REFANY outweighs the convenience of being >> able to process objects of type TAGGED T (for all ref types T) as >> well as objects of type T? >> >The other use is for the abstract type itself. Forgetting tagged >types for a moment, I have never seen an interface/module that >uses REFANY for this. Instead, the modules declare their abstract >type as some proper subtype of REFANY, usually an opaque type. > >It would be possible to use just REFANY here of course, but that would >require an otherwise unnecessary RT check on the allocated type, >every time an operation of the module is called. This is a much >more expensive check than a tag check, as has been pointed out >in this discussion. > >But worse, it would sacrifice the static checking that we now have >that prevents, at compile time, clients from passing, say a Text.T >to some procedure in Atom that expects an Atom.T. If these modules >ever wanted to use a tagged type, but the only tagged type were >REFANY, we would lose this static checking, because Text.T would >have to become equal to Atom.T. > >In cases where your algorithms don't specifically need dynamic >typing, static typing is always much better, because one run of >the compiler on the source code will do it. Bugs checked >only at runtime require a massive test suit to be coded and then >regularly rerun to get even close to the same confidence they've >been found. > >So when using tagged types as the ADT itself,, we need to be able >to have a tagged version of whatever proper subtype of REFANY >the abstraction needs, including an opaque subtype of REFANY >or an opaque subtype of some Public subtype of REFANY. This is >why I am adamant that we need to be able to build a tagged type >from any traced or object type. > >And once you do this, keeping REFANY itself unchanged and allowing >TAGGED REFANY as one case of a tagged type falls out of the system >for free _and_ saves a lot of cases that would otherwise need a new RT >check that can never fail, but the language can't know that, because >the type system has lost the distinction. > >I really feel that the fad of all dynamic typing in languages is a huge >mistake and that it will someday be recognized as such. In the >meantime, we have a language that provides a very extensive set >of statically-typed alternatives, while also allowing dynamic typing >when you really need it. This is one of Modula-3's best principles. >Let's don't erode the static alternatives unnecessarily. > >> Mika >> >> From hosking at cs.purdue.edu Sat Apr 11 00:16:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Apr 2009 08:16:07 +1000 Subject: [M3devel] Fwd: Output from "cron" command References: <200904101323.n3ADNfb4028603@niagara.cs.purdue.edu> Message-ID: <4F3FB486-EE62-4E46-BD8A-8D914710E3BF@cs.purdue.edu> SOLgnu failed again. Begin forwarded message: > From: Tony Hosking > Date: 10 April 2009 23:23:41 GMT+10:00 > To: hosking at cs.purdue.edu > Subject: Output from "cron" command > > Your "cron" job on niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/cron.sh > > produced the following output: > > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-04-10-10-30-04 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara release-build" > > creating log file /tmp/build-cm3-20090410-063006-Rbai0T/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.04.10 06:30:06 -- checkout in progress. > [start checkout 2009.04.10 06:30:09] > cd /tmp/build-cm3-20090410-063006-Rbai0T/build > cvs return value: 0 > [end checkout 2009.04.10 06:50:44] > CHECKOUT_RETURN = 0 > -- > 2009.04.10 06:50:46 -- compile in progress. > [start compile 2009.04.10 06:50:47] > compile return value: 0 > [end compile 2009.04.10 08:11:42] > COMPILE_RETURN = 1 > *** COMPILE FAILED > removing build tree /tmp/build-cm3-20090410-063006-Rbai0T ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-04-10-12-13-48 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" > > creating log file /tmp/build-cm3-20090410-081351-rXaGeZ/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.04.10 08:13:51 -- checkout in progress. > [start checkout 2009.04.10 08:13:53] > cd /tmp/build-cm3-20090410-081351-rXaGeZ/build > cvs return value: 0 > [end checkout 2009.04.10 08:35:16] > CHECKOUT_RETURN = 0 > -- > 2009.04.10 08:35:18 -- compile in progress. > [start compile 2009.04.10 08:35:18] > compile return value: 0 > [end compile 2009.04.10 09:21:41] > COMPILE_RETURN = 0 > 2009.04.10 09:21:45 -- tests in progress. > [start run-tests 2009.04.10 09:21:45] > cd /tmp/build-cm3-20090410-081351-rXaGeZ/build > [end run-tests 2009.04.10 09:21:45] > TESTS_RETURN = 0 > 2009.04.10 09:21:45 -- checkout, compile and test run done. > > --- > > removing build tree /tmp/build-cm3-20090410-081351-rXaGeZ ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > done. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 11 00:20:28 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 10 Apr 2009 22:20:28 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <4F3FB486-EE62-4E46-BD8A-8D914710E3BF@cs.purdue.edu> References: <200904101323.n3ADNfb4028603@niagara.cs.purdue.edu> <4F3FB486-EE62-4E46-BD8A-8D914710E3BF@cs.purdue.edu> Message-ID: Yes, sorry, I made a few slightly bad changes. Like three. All fixed. sizeof short, schedulerposix, ugrp (ugrp not a problem on this platform). Let's wait again, sorry. The config file/cminstall thing I didn't do anything with (before or after). So if that's still broken for you, still needs attention. - Jay ________________________________ > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Sat, 11 Apr 2009 08:16:07 +1000 > Subject: [M3devel] Fwd: Output from "cron" command > > SOLgnu failed again. > > Begin forwarded message: > > From: Tony Hosking> > Date: 10 April 2009 23:23:41 GMT+10:00 > To: hosking at cs.purdue.edu > Subject: Output from "cron" command > > Your "cron" job on niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/cron.sh > > produced the following output: > > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-04-10-10-30-04 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara release-build" > > creating log file /tmp/build-cm3-20090410-063006-Rbai0T/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.04.10 06:30:06 -- checkout in progress. > [start checkout 2009.04.10 06:30:09] > cd /tmp/build-cm3-20090410-063006-Rbai0T/build > cvs return value: 0 > [end checkout 2009.04.10 06:50:44] > CHECKOUT_RETURN = 0 > -- > 2009.04.10 06:50:46 -- compile in progress. > [start compile 2009.04.10 06:50:47] > compile return value: 0 > [end compile 2009.04.10 08:11:42] > COMPILE_RETURN = 1 > *** COMPILE FAILED > removing build tree /tmp/build-cm3-20090410-063006-Rbai0T ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-04-10-12-13-48 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" > > creating log file /tmp/build-cm3-20090410-081351-rXaGeZ/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.04.10 08:13:51 -- checkout in progress. > [start checkout 2009.04.10 08:13:53] > cd /tmp/build-cm3-20090410-081351-rXaGeZ/build > cvs return value: 0 > [end checkout 2009.04.10 08:35:16] > CHECKOUT_RETURN = 0 > -- > 2009.04.10 08:35:18 -- compile in progress. > [start compile 2009.04.10 08:35:18] > compile return value: 0 > [end compile 2009.04.10 09:21:41] > COMPILE_RETURN = 0 > 2009.04.10 09:21:45 -- tests in progress. > [start run-tests 2009.04.10 09:21:45] > cd /tmp/build-cm3-20090410-081351-rXaGeZ/build > [end run-tests 2009.04.10 09:21:45] > TESTS_RETURN = 0 > 2009.04.10 09:21:45 -- checkout, compile and test run done. > > --- > > removing build tree /tmp/build-cm3-20090410-081351-rXaGeZ ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > done. > From jay.krell at cornell.edu Sat Apr 11 00:25:11 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 10 Apr 2009 22:25:11 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <4F3FB486-EE62-4E46-BD8A-8D914710E3BF@cs.purdue.edu> References: <200904101323.n3ADNfb4028603@niagara.cs.purdue.edu> <4F3FB486-EE62-4E46-BD8A-8D914710E3BF@cs.purdue.edu> Message-ID: [was slightly truncated] ---------------------------------------- > From: jay.krell at cornell.edu > The config file/cminstall thing I didn't do anything with (before or after). > So if that's still broken for you, still needs attention. > > > - Jay From hosking at cs.purdue.edu Sat Apr 11 00:25:32 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Apr 2009 08:25:32 +1000 Subject: [M3devel] small objects In-Reply-To: <200904101918.n3AJIcLj003231@camembert.async.caltech.edu> References: <200904101918.n3AJIcLj003231@camembert.async.caltech.edu> Message-ID: <305809AF-0615-4D4F-BCA9-D801991D76ED@cs.purdue.edu> Too many e-mails to digest lately. I take it that Mika's is now definitive. Let me think it through. On 11 Apr 2009, at 05:18, Mika Nystrom wrote: > > Sigh, I hate sending so many emails to a mailing list. Sorry about > the inboxes I'm clogging of people with no interest in this. > > But I just realized something important, which I think may be > decisive in deciding the fate of the name "REFANY" in the addition > of new types. > > Rodney proposes > > TAGGED T <: TAGGED REFANY > T <: REFANY <: TAGGED REFANY > > I propose > > TAGGED T <: REFANY > T <: UNTAGGEDREFANY <: REFANY > > Both proposals are identical in the power of the language that > results, because they differ merely in naming. > > Both proposals are also backward-compatible: all existing Modula-3 > programs are unchanged by them. > > However, UNTAGGEDREFANY (mine), is *forward*-compatible as well > as backward-compatible. > > Think about it. The TAGGED REFANY proposal will have the following > effect: people will go through all the M3 libraries and replace > every or almost every occurrence of REFANY with TAGGED REFANY. The > resulting code will not compile with an older compiler! > > In my proposal, it is the user of the TAGGED types who is responsible > for---in new code only!---deciding whether he wants his code to > compile both on older and newer M3 systems. If he does, then he > can add appropriate implementations for compilers that don't support > the TAGGED types (which will be trivial since he has to have those > anyway!) The burden of handling change is on the programmer of the > special new feature rather than on everyone who has a container > module. > > I'll try to refrain from posting any more messages on this topic now. > > Mika > > "Rodney M. Bates" writes: >> Mika Nystrom wrote: >>> Sorry to splice together two emails from you, but I feel I've >>> already >>> used up my m3devel quota this week: >>> >>> "Rodney M. Bates" writes: >>> >>>>> Are you sure? I want a type---some type---that can hold "any >>>>> reference, even a tagged one", and I would rewrite most library >>>>> code that today takes REFANY to take that instead. Why not? Why >>>>> would I want to limit it to REFANY when it performs no operations >>>>> that couldn't legally be performed on TAGGED REFANY. >>>>> >>>>> >>>> I believe my "safe" proposal would make this very simple, if I am >>>> thinking of the kind of library code you are. >>>> >>>> I envision a container data structure that takes in things and >>>> returns >>>> them without performing operations on them other than moving them >>>> around >>>> and storing them, e.g. the ever belabored stack. The values >>>> going in >>>> and out are declared REFANY, and the client passes in values of >>>> some proper subtype of REFANY, which get assigned to the REFANY >>>> parameters. When it gets them back, it narrows them to this type. >>>> >>>> In this pattern, just changing the declared type of the container >>>> values >>>> >>>> from REFANY to TAGGED REFANY would do it. The library code's >>>> storage >>> ... >>> >> There are two very different kinds of uses of reference and >> tagged types. The one I speak of above is for the type of the >> elements inside a container data structure. In this case, it >> is the client that knows what type the value really is, and will >> declare it as such. The library ADT module should know as little >> as possible about it, so it will declare it as REFANY or >> TAGGED REFANY. Here, you want the most general type >> possible, just to make the abstraction more versatile. >> And TAGGED REFANY generalizes it from REFANY. >> >> But... >>> >> >> >>>>> you'd like to store these in a REFANY and dynamically test for the >>>>> appropriate tagged type: >>>>> >>>> No, I do not want to store these in a variable of type REFANY or >>>> any >>>> other existing type. >>>> In fact, I want to forbid it. >>>> >>> >>> I think you are thinking of exactly the same kind of library code. >>> TextRefTbl.T, RefList.T, etc. >>> >>> After the introduction of TAGGED REFANY, what use is there for >>> REFANY? What piece of code can you think of where the cost of the >>> 1-LSB check of TAGGED REFANY outweighs the convenience of being >>> able to process objects of type TAGGED T (for all ref types T) as >>> well as objects of type T? >>> >> The other use is for the abstract type itself. Forgetting tagged >> types for a moment, I have never seen an interface/module that >> uses REFANY for this. Instead, the modules declare their abstract >> type as some proper subtype of REFANY, usually an opaque type. >> >> It would be possible to use just REFANY here of course, but that >> would >> require an otherwise unnecessary RT check on the allocated type, >> every time an operation of the module is called. This is a much >> more expensive check than a tag check, as has been pointed out >> in this discussion. >> >> But worse, it would sacrifice the static checking that we now have >> that prevents, at compile time, clients from passing, say a Text.T >> to some procedure in Atom that expects an Atom.T. If these modules >> ever wanted to use a tagged type, but the only tagged type were >> REFANY, we would lose this static checking, because Text.T would >> have to become equal to Atom.T. >> >> In cases where your algorithms don't specifically need dynamic >> typing, static typing is always much better, because one run of >> the compiler on the source code will do it. Bugs checked >> only at runtime require a massive test suit to be coded and then >> regularly rerun to get even close to the same confidence they've >> been found. >> >> So when using tagged types as the ADT itself,, we need to be able >> to have a tagged version of whatever proper subtype of REFANY >> the abstraction needs, including an opaque subtype of REFANY >> or an opaque subtype of some Public subtype of REFANY. This is >> why I am adamant that we need to be able to build a tagged type >> from any traced or object type. >> >> And once you do this, keeping REFANY itself unchanged and allowing >> TAGGED REFANY as one case of a tagged type falls out of the system >> for free _and_ saves a lot of cases that would otherwise need a new >> RT >> check that can never fail, but the language can't know that, because >> the type system has lost the distinction. >> >> I really feel that the fad of all dynamic typing in languages is a >> huge >> mistake and that it will someday be recognized as such. In the >> meantime, we have a language that provides a very extensive set >> of statically-typed alternatives, while also allowing dynamic typing >> when you really need it. This is one of Modula-3's best principles. >> Let's don't erode the static alternatives unnecessarily. >> >>> Mika >>> >>> From jay.krell at cornell.edu Sat Apr 11 00:24:28 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 10 Apr 2009 22:24:28 +0000 Subject: [M3devel] "cvsup compat"? (really, general source compat) Message-ID: The subject isn't really the whole subject. cvsup compat? I could make the cvsup source highly compatible with "all" Modula-3 distributions by giving it its own "SupUnix.i3", implemented mostly in C, using INTEGER more and LONGINT less. Even its own SchedulerPosix with Enable/DisableSwitching. It would just, like, IMPORT SupUnix as Unix, IMPORT SupScheduler as SchedulerPosix, leading to the overall source changes being small. Or I could adapt it to current cm3, not compatible with any other older versions or forks (ezm3, pm3, old cm3, etc.) Use LONGINT. Use some of the slightly copying wrappers (Ugrp, Unetdb). Thoughts? Maintaining full source compat in cm3 itself I think is not an option. But almost. At least stat should always return 64bit file sizes. Or at least a 53bit double..I doubt that helps though. Most of the rest of "problems" could be "fixed". Such as by restoring a little bit of header cloning -- more for Ugrp and Unetdb, not Ustat, and verify the correctness in the C code. (because Ustat already has a place to copy an idealized type to, whereas Ugrp and Unetdb don't, unless interfaces altered like I did.) And using INTEGER more and LONGINT less. Not just because older compilers don't support LONGINT, but because code that uses one is not compatible with interfaces that use the other, even on 64bit platforms where they are "the same". (like on 32bit platforms, in C, int* and long* are compatible). I'd have to do more research though, like on ino_t and dev_t. They are 64bits on Linux/AMD64, I don't know if they ever are on any 32bit platforms, in which case LONGINT comes back. (other point here is LONGINT or, really, my preference, INT64 and UINT64 should have been added to the language over 10 years ago, then these would have been smoothed out by now..oh well..or possibly INTEGER and LONGINT should be more source compatible, but I realize there are arguments against some of that -- you could make it so on 64bit, but then a bunch of code would be produced that only compiled on 64bit platforms.) I'll probably go ahead and adapt it to current cm3. The other option can be explored later independently. Could be that nothing but current cm3 matters much. - Jay From jay.krell at cornell.edu Sat Apr 11 00:27:17 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 10 Apr 2009 22:27:17 +0000 Subject: [M3devel] tinderbox summary log Message-ID: This is very minor. The tinderbox summary log doesn't show stuff like: "../src/thread/PTHREAD/ThreadPThread.m3", line 7: symbol redefined (DisableSwitching) 4402 "../src/thread/PTHREAD/ThreadPThread.m3", line 7: symbol redefined (EnableSwitching) 4403 2 errors encountered Or at least the first two lines. If it does find the last, fix is to always show a few lines of "context". But the full log works well enough, the errors occur near the end. Not a big deal. (One might say -- but don't make such errors..but hey, tinderbox is all about catching errors...) - Jay From wagner at elegosoft.com Sat Apr 11 10:46:40 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 11 Apr 2009 10:46:40 +0200 Subject: [M3devel] tinderbox summary log In-Reply-To: References: Message-ID: <20090411104640.7cm9u7utc40oscoc@mail.elegosoft.com> Quoting Jay : > > This is very minor. > > The tinderbox summary log doesn't show stuff like: > > "../src/thread/PTHREAD/ThreadPThread.m3", line 7: symbol > redefined (DisableSwitching) > 4402 "../src/thread/PTHREAD/ThreadPThread.m3", line 7: > symbol redefined (EnableSwitching) > 4403 2 errors encountered > > > Or at least the first two lines. > If it does find the last, fix is to always show a few lines of "context". > > But the full log works well enough, the errors occur near the end. > > Not a big deal. > (One might say -- but don't make such errors..but hey, tinderbox is > all about catching errors...) Anybody here who would like to work on improving and fixing our tinderbox installation on birch again? Michael Anderson has not too much time to spend for cm3, and Ronny, who made the last installation, doesn't work for us anymore. So if you like perl scripting, this would be a great opportunity ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 11 10:55:12 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 11 Apr 2009 10:55:12 +0200 Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN Message-ID: <20090411105512.92784fp7cc0o448k@mail.elegosoft.com> After trying to upgrade cm3 on my notebook to the latest version, I get lots of internal compiler errors.This is on % uname -a Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power Macintosh powerpc ... new source -> compiling RuntimeError.m3 ../src/runtime/common/RuntimeError.m3: In function 'RuntimeError__Tag': ../src/runtime/common/RuntimeError.m3:56: error: type mismatch in binary expression int_32 int_32 word_32 D.252 = D.251 * 4 ../src/runtime/common/RuntimeError.m3:56: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. ... Full log attached. Before you ask, it won't be easy to upgrade Darwin on this notebook, and I surely cannot do this within the next two weeks :-/ Any ideas? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 -------------- /Users/wagner/work/cm3/scripts/do-pkg.sh buildship sysutils m3bundle m3middle m3quake patternmatching cminstall /Users/wagner/work/cm3/scripts/pkgmap.sh -c "cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' " sysutils m3bundle m3middle m3quake patternmatching cminstall === package m3-libs/sysutils === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/sysutils/PPC_DARWIN .M3EXPORTS libsysutils.5.2.dylib libsysutils.5.dylib libsysutils.dylib libsysutils.a libsysutils.m3x .M3WEB ../PPC_DARWIN => /usr/local/cm3/pkg/sysutils/PPC_DARWIN TextTextSeqTbl.i3 TextTextSeqTbl.m3 ../src => /usr/local/cm3/pkg/sysutils/src EnvUtils.i3 EnvUtils.m3 FingerprintFmt.i3 FingerprintFmt.m3 FSUtils.i3 FSUtils.m3 SMsg.i3 SMsg.m3 MsgIF.m3 MsgIF.i3 MsgX.m3 MsgX.i3 ProcessEnv.i3 ProcessEnv.m3 System.i3 System.m3 PathRepr.i3 PathReprCommon.m3 TextUtils.i3 TextReadingUtils.m3 TextReadingUtils.i3 OSSpecials.i3 FastLex.i3 FastLex.m3 Confirmation.i3 Confirmation.m3 DirStack.i3 DirStack.m3 ConnectRdWr.m3 ConnectRdWr.i3 ../src/POSIX => /usr/local/cm3/pkg/sysutils/src/POSIX OSSpecialsPosix.m3 PathReprPosix.m3 SystemPosix.m3 FSUnix_cm3.m3 ../src/cm3 => /usr/local/cm3/pkg/sysutils/src/cm3 TextUtils.m3 ==> m3-libs/sysutils done === package m3-tools/m3bundle === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/m3bundle/PPC_DARWIN .M3EXPORTS .M3WEB ../src => /usr/local/cm3/pkg/m3bundle/src m3bundle.m3 . => /usr/local/cm3/bin m3bundle . => /usr/local/cm3/man/man1 m3bundle.1 ==> m3-tools/m3bundle done === package m3-sys/m3middle === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/m3middle/PPC_DARWIN .M3EXPORTS libm3middle.a libm3middle.m3x .M3WEB ../src/POSIX => /usr/local/cm3/pkg/m3middle/src/POSIX M3Process.m3 CoffTime.i3 CoffTime.m3 ../src => /usr/local/cm3/pkg/m3middle/src Target.i3 Target.m3 TargetMap.i3 TargetMap.m3 TInt.i3 TInt.m3 TWord.m3 TWord.i3 TFloat.i3 TFloat.m3 M3FP.i3 M3FP.m3 M3Buf.i3 M3Buf.m3 M3ID.i3 M3ID.m3 M3Timers.m3 M3Timers.i3 M3File.i3 M3File.m3 M3Process.i3 M3CG.i3 M3CG.m3 M3CG_Ops.i3 M3CG_Check.i3 M3CG_Check.m3 M3CG_Rd.m3 M3CG_Rd.i3 M3CG_Wr.i3 M3CG_Wr.m3 M3CG_Binary.i3 M3CG_Binary.m3 M3CG_BinRd.m3 M3CG_BinRd.i3 M3CG_BinWr.i3 M3CG_BinWr.m3 M3RT.i3 M3RT.m3 ==> m3-sys/m3middle done === package m3-sys/m3quake === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/m3quake/PPC_DARWIN .M3EXPORTS libm3quake.a libm3quake.m3x .M3WEB ../PPC_DARWIN => /usr/local/cm3/pkg/m3quake/PPC_DARWIN QVTbl.m3 QVTbl.i3 QVSeq.i3 QVSeq.m3 QVSeqRep.i3 ../src => /usr/local/cm3/pkg/m3quake/src Quake.i3 Quake.m3 QToken.i3 QToken.m3 QIdent.m3 QIdent.i3 QScanner.i3 QScanner.m3 QCode.i3 QCode.m3 QCompiler.m3 QCompiler.i3 QValue.m3 QValue.i3 QMachine.i3 QMachine.m3 QVal.i3 QVal.m3 MxConfig.i3 MxConfig.m3 ==> m3-sys/m3quake done === package m3-libs/patternmatching === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/patternmatching/PPC_DARWIN .M3EXPORTS libpatternmatching.5.2.dylib libpatternmatching.5.dylib libpatternmatching.dylib libpatternmatching.a libpatternmatching.m3x .M3WEB ../src/libglob => /usr/local/cm3/pkg/patternmatching/src/libglob fnmatch.c ../src => /usr/local/cm3/pkg/patternmatching/src RegEx.i3 RegEx.m3 Uglob.i3 Glob.i3 Glob.m3 GlobTree.i3 GlobTree.m3 ==> m3-libs/patternmatching done === package m3-sys/cminstall === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/cminstall/PPC_DARWIN .M3EXPORTS .M3WEB ../PPC_DARWIN => /usr/local/cm3/pkg/cminstall/PPC_DARWIN Setup.i3 Setup.m3 InstallTarget.i3 ../src => /usr/local/cm3/pkg/cminstall/src Msg.m3 Msg.i3 Text2.i3 Text2.m3 OS.i3 OS.m3 Registry.i3 Main.m3 OSPOSIX.m3 RegistryPOSIX.m3 . => /usr/local/cm3/pkg/cminstall/PPC_DARWIN cminstall ==> m3-sys/cminstall done /Users/wagner/work/cm3/scripts/do-pkg.sh buildship sysutils m3middle m3objfile m3linker m3back m3front m3quake cm3 /Users/wagner/work/cm3/scripts/pkgmap.sh -c "cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' " sysutils m3middle m3objfile m3linker m3back m3front m3quake cm3 === package m3-libs/sysutils === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/sysutils/PPC_DARWIN .M3EXPORTS libsysutils.5.2.dylib libsysutils.5.dylib libsysutils.dylib libsysutils.a libsysutils.m3x .M3WEB ../PPC_DARWIN => /usr/local/cm3/pkg/sysutils/PPC_DARWIN TextTextSeqTbl.i3 TextTextSeqTbl.m3 ../src => /usr/local/cm3/pkg/sysutils/src EnvUtils.i3 EnvUtils.m3 FingerprintFmt.i3 FingerprintFmt.m3 FSUtils.i3 FSUtils.m3 SMsg.i3 SMsg.m3 MsgIF.m3 MsgIF.i3 MsgX.m3 MsgX.i3 ProcessEnv.i3 ProcessEnv.m3 System.i3 System.m3 PathRepr.i3 PathReprCommon.m3 TextUtils.i3 TextReadingUtils.m3 TextReadingUtils.i3 OSSpecials.i3 FastLex.i3 FastLex.m3 Confirmation.i3 Confirmation.m3 DirStack.i3 DirStack.m3 ConnectRdWr.m3 ConnectRdWr.i3 ../src/POSIX => /usr/local/cm3/pkg/sysutils/src/POSIX OSSpecialsPosix.m3 PathReprPosix.m3 SystemPosix.m3 FSUnix_cm3.m3 ../src/cm3 => /usr/local/cm3/pkg/sysutils/src/cm3 TextUtils.m3 ==> m3-libs/sysutils done === package m3-sys/m3middle === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/m3middle/PPC_DARWIN .M3EXPORTS libm3middle.a libm3middle.m3x .M3WEB ../src/POSIX => /usr/local/cm3/pkg/m3middle/src/POSIX M3Process.m3 CoffTime.i3 CoffTime.m3 ../src => /usr/local/cm3/pkg/m3middle/src Target.i3 Target.m3 TargetMap.i3 TargetMap.m3 TInt.i3 TInt.m3 TWord.m3 TWord.i3 TFloat.i3 TFloat.m3 M3FP.i3 M3FP.m3 M3Buf.i3 M3Buf.m3 M3ID.i3 M3ID.m3 M3Timers.m3 M3Timers.i3 M3File.i3 M3File.m3 M3Process.i3 M3CG.i3 M3CG.m3 M3CG_Ops.i3 M3CG_Check.i3 M3CG_Check.m3 M3CG_Rd.m3 M3CG_Rd.i3 M3CG_Wr.i3 M3CG_Wr.m3 M3CG_Binary.i3 M3CG_Binary.m3 M3CG_BinRd.m3 M3CG_BinRd.i3 M3CG_BinWr.i3 M3CG_BinWr.m3 M3RT.i3 M3RT.m3 ==> m3-sys/m3middle done === package m3-sys/m3objfile === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/m3objfile/PPC_DARWIN .M3EXPORTS libm3objfile.a libm3objfile.m3x .M3WEB ../src => /usr/local/cm3/pkg/m3objfile/src Coff.i3 Coff.m3 M3ObjFile.i3 M3ObjFile.m3 MasmObjFile.i3 MasmObjFile.m3 NTObjFile.i3 NTObjFile.m3 ==> m3-sys/m3objfile done === package m3-sys/m3linker === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/m3linker/PPC_DARWIN .M3EXPORTS libm3link.a libm3link.m3x .M3WEB ../src => /usr/local/cm3/pkg/m3linker/src Mx.i3 Mx.m3 MxIn.i3 MxIn.m3 MxOut.i3 MxOut.m3 MxMerge.m3 MxMerge.i3 MxCheck.i3 MxCheck.m3 MxGen.i3 MxGen.m3 MxVS.m3 MxVS.i3 MxRep.i3 MxRep.m3 MxMap.i3 MxMap.m3 MxSet.m3 MxSet.i3 MxVSSet.i3 MxVSSet.m3 MxIO.i3 MxIO.m3 ==> m3-sys/m3linker done === package m3-sys/m3back === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/m3back/PPC_DARWIN .M3EXPORTS libm3back.a libm3back.m3x .M3WEB ../src => /usr/local/cm3/pkg/m3back/src M3x86.i3 M3x86.m3 M3x86Rep.i3 Wrx86.i3 Wrx86.m3 Stackx86.i3 Stackx86.m3 Codex86.i3 Codex86.m3 ==> m3-sys/m3back done === package m3-sys/m3front === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/m3front/PPC_DARWIN .M3EXPORTS libm3front.a libm3front.m3x .M3WEB ../src/types => /usr/local/cm3/pkg/m3front/src/types Type.i3 Type.m3 TypeRep.i3 ArrayType.i3 ArrayType.m3 Brand.i3 Brand.m3 EnumType.i3 EnumType.m3 NamedType.m3 NamedType.i3 ObjectType.i3 ObjectType.m3 OpaqueType.i3 OpaqueType.m3 OpenArrayType.i3 OpenArrayType.m3 PackedType.m3 PackedType.i3 ProcType.i3 ProcType.m3 RecordType.i3 RecordType.m3 RefType.i3 RefType.m3 SetType.m3 SetType.i3 SubrangeType.i3 SubrangeType.m3 TypeFP.i3 TypeFP.m3 TypeTbl.i3 TypeTbl.m3 UserProc.i3 UserProc.m3 ../src/builtinOps => /usr/local/cm3/pkg/m3front/src/builtinOps Abs.i3 Abs.m3 Adr.m3 Adr.i3 AdrSize.i3 AdrSize.m3 BitSize.i3 BitSize.m3 BuiltinOps.i3 BuiltinOps.m3 ByteSize.i3 ByteSize.m3 Cas.m3 Cas.i3 CasP.i3 CasP.m3 Ceiling.m3 Ceiling.i3 Dec.i3 Dec.m3 Dispose.m3 Dispose.i3 First.i3 First.m3 Floatt.i3 Floatt.m3 Floor.i3 Floor.m3 Inc.i3 Inc.m3 IsType.i3 IsType.m3 Last.m3 Last.i3 Loophole.i3 Loophole.m3 Max.m3 Max.i3 Min.i3 Min.m3 Narrow.m3 Narrow.i3 New.m3 New.i3 Number.i3 Number.m3 Ord.m3 Ord.i3 Round.m3 Round.i3 Subarray.i3 Subarray.m3 Trunc.i3 Trunc.m3 Typecode.m3 Typecode.i3 Val.i3 Val.m3 ../src/builtinWord => /usr/local/cm3/pkg/m3front/src/builtinWord WordAnd.m3 WordAnd.i3 WordDivide.i3 WordDivide.m3 WordExtract.i3 WordExtract.m3 WordGE.m3 WordGE.i3 WordGT.i3 WordGT.m3 WordInsert.m3 WordInsert.i3 WordLE.m3 WordLE.i3 WordLT.i3 WordLT.m3 WordMinus.m3 WordMinus.i3 WordMod.i3 WordMod.m3 WordModule.i3 WordModule.m3 WordNot.i3 WordNot.m3 WordOr.i3 WordOr.m3 WordPlus.i3 WordPlus.m3 WordRotate.i3 WordRotate.m3 WordShift.i3 WordShift.m3 WordTimes.i3 WordTimes.m3 WordXor.m3 WordXor.i3 ../src/builtinLong => /usr/local/cm3/pkg/m3front/src/builtinLong LongAnd.i3 LongAnd.m3 LongDivide.i3 LongDivide.m3 LongExtract.i3 LongExtract.m3 LongGE.i3 LongGE.m3 LongGT.m3 LongGT.i3 LongInsert.m3 LongInsert.i3 LongLE.i3 LongLE.m3 LongLT.i3 LongLT.m3 LongMinus.i3 LongMinus.m3 LongMod.i3 LongMod.m3 LongModule.i3 LongModule.m3 LongNot.i3 LongNot.m3 LongOr.m3 LongOr.i3 LongPlus.i3 LongPlus.m3 LongRotate.i3 LongRotate.m3 LongShift.i3 LongShift.m3 LongTimes.i3 LongTimes.m3 LongXor.i3 LongXor.m3 ../src/builtinInfo => /usr/local/cm3/pkg/m3front/src/builtinInfo InfoModule.i3 InfoModule.m3 InfoThisFile.m3 InfoThisFile.i3 InfoThisPath.i3 InfoThisPath.m3 InfoThisLine.i3 InfoThisLine.m3 InfoThisException.i3 InfoThisException.m3 ../src/builtinTypes => /usr/local/cm3/pkg/m3front/src/builtinTypes Addr.i3 Addr.m3 Bool.i3 Bool.m3 BuiltinTypes.m3 BuiltinTypes.i3 Charr.i3 Charr.m3 Card.i3 Card.m3 EReel.i3 EReel.m3 ErrType.i3 ErrType.m3 Int.i3 Int.m3 LInt.i3 LInt.m3 LReel.m3 LReel.i3 Mutex.i3 Mutex.m3 Null.i3 Null.m3 ObjectAdr.m3 ObjectAdr.i3 ObjectRef.m3 ObjectRef.i3 Reel.m3 Reel.i3 Reff.i3 Reff.m3 Textt.m3 Textt.i3 WCharr.i3 WCharr.m3 ../src/exprs => /usr/local/cm3/pkg/m3front/src/exprs Expr.i3 Expr.m3 ExprRep.i3 AddExpr.i3 AddExpr.m3 AddressExpr.i3 AddressExpr.m3 AndExpr.i3 AndExpr.m3 ArrayExpr.m3 ArrayExpr.i3 CallExpr.i3 CallExpr.m3 CastExpr.i3 CastExpr.m3 CheckExpr.i3 CheckExpr.m3 CompareExpr.i3 CompareExpr.m3 ConcatExpr.i3 ConcatExpr.m3 ConsExpr.i3 ConsExpr.m3 DerefExpr.i3 DerefExpr.m3 DivExpr.i3 DivExpr.m3 DivideExpr.i3 DivideExpr.m3 EnumExpr.m3 EnumExpr.i3 EqualExpr.i3 EqualExpr.m3 ExprParse.i3 ExprParse.m3 InExpr.m3 InExpr.i3 IntegerExpr.m3 IntegerExpr.i3 KeywordExpr.m3 KeywordExpr.i3 MethodExpr.m3 MethodExpr.i3 ModExpr.i3 ModExpr.m3 MultiplyExpr.m3 MultiplyExpr.i3 NamedExpr.m3 NamedExpr.i3 NarrowExpr.m3 NarrowExpr.i3 NegateExpr.m3 NegateExpr.i3 NilChkExpr.i3 NilChkExpr.m3 NotExpr.i3 NotExpr.m3 OrExpr.i3 OrExpr.m3 PlusExpr.i3 PlusExpr.m3 ProcExpr.i3 ProcExpr.m3 QualifyExpr.i3 QualifyExpr.m3 RangeExpr.m3 RangeExpr.i3 RecordExpr.m3 RecordExpr.i3 ReelExpr.m3 ReelExpr.i3 SetExpr.m3 SetExpr.i3 SubscriptExpr.i3 SubscriptExpr.m3 SubtractExpr.i3 SubtractExpr.m3 TextExpr.i3 TextExpr.m3 TypeExpr.i3 TypeExpr.m3 VarExpr.i3 VarExpr.m3 ../src/misc => /usr/local/cm3/pkg/m3front/src/misc M3.i3 M3.m3 M3Front.i3 M3Front.m3 M3Compiler.m3 M3Compiler.i3 M3Header.m3 M3Header.i3 M3String.m3 M3String.i3 M3WString.i3 M3WString.m3 Token.i3 Token.m3 Error.m3 Error.i3 Host.m3 Host.i3 Marker.m3 Marker.i3 Scanner.i3 Scanner.m3 Scope.i3 Scope.m3 Coverage.i3 Coverage.m3 ESet.i3 ESet.m3 ProcBody.i3 ProcBody.m3 CG.i3 CG.m3 RunTyme.i3 RunTyme.m3 TipeMap.i3 TipeMap.m3 TipeDesc.i3 TipeDesc.m3 Tracer.i3 Tracer.m3 WebInfo.i3 WebInfo.m3 ../src/stmts => /usr/local/cm3/pkg/m3front/src/stmts Stmt.i3 Stmt.m3 StmtRep.i3 AssertStmt.m3 AssertStmt.i3 AssignStmt.i3 AssignStmt.m3 BlockStmt.i3 BlockStmt.m3 CallStmt.i3 CallStmt.m3 CaseStmt.i3 CaseStmt.m3 DebugStmt.i3 DebugStmt.m3 EvalStmt.i3 EvalStmt.m3 ExitStmt.i3 ExitStmt.m3 ForStmt.i3 ForStmt.m3 IfStmt.i3 IfStmt.m3 LockStmt.m3 LockStmt.i3 LoopStmt.m3 LoopStmt.i3 RaiseStmt.m3 RaiseStmt.i3 RepeatStmt.m3 RepeatStmt.i3 ReturnStmt.i3 ReturnStmt.m3 TryFinStmt.m3 TryFinStmt.i3 TryStmt.i3 TryStmt.m3 TypeCaseStmt.m3 TypeCaseStmt.i3 WhileStmt.i3 WhileStmt.m3 WithStmt.m3 WithStmt.i3 ../src/values => /usr/local/cm3/pkg/m3front/src/values Module.i3 Module.m3 Value.i3 Value.m3 ValueRep.i3 Constant.i3 Constant.m3 Decl.m3 Decl.i3 EnumElt.i3 EnumElt.m3 Exceptionz.i3 Exceptionz.m3 External.i3 External.m3 Field.i3 Field.m3 Formal.i3 Formal.m3 Ident.i3 Ident.m3 Method.m3 Method.i3 Procedure.i3 Procedure.m3 Revelation.m3 Revelation.i3 Tipe.i3 Tipe.m3 Variable.i3 Variable.m3 ==> m3-sys/m3front done === package m3-sys/m3quake === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/m3quake/PPC_DARWIN .M3EXPORTS libm3quake.a libm3quake.m3x .M3WEB ../PPC_DARWIN => /usr/local/cm3/pkg/m3quake/PPC_DARWIN QVTbl.m3 QVTbl.i3 QVSeq.i3 QVSeq.m3 QVSeqRep.i3 ../src => /usr/local/cm3/pkg/m3quake/src Quake.i3 Quake.m3 QToken.i3 QToken.m3 QIdent.m3 QIdent.i3 QScanner.i3 QScanner.m3 QCode.i3 QCode.m3 QCompiler.m3 QCompiler.i3 QValue.m3 QValue.i3 QMachine.i3 QMachine.m3 QVal.i3 QVal.m3 MxConfig.i3 MxConfig.m3 ==> m3-sys/m3quake done === package m3-sys/cm3 === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides new source -> compiling Version.i3 new source -> compiling M3Backend.i3 new source -> compiling Arg.i3 new source -> compiling Utils.i3 new source -> compiling Msg.i3 new source -> compiling M3Backend.m3 new source -> compiling UtilsPosix.m3 new source -> compiling Arg.m3 new source -> compiling M3Path.i3 new source -> compiling M3Loc.i3 new source -> compiling M3Unit.i3 new source -> compiling Builder.i3 new source -> compiling M3Options.i3 new source -> compiling WebFile.i3 new source -> compiling Dirs.i3 new source -> compiling Builder.m3 new source -> compiling Dirs.m3 new source -> compiling M3Build.i3 new source -> compiling M3Build.m3 new source -> compiling M3Loc.m3 new source -> compiling M3Options.m3 new source -> compiling M3Path.m3 new source -> compiling M3Unit.m3 new source -> compiling Makefile.i3 new source -> compiling Makefile.m3 new source -> compiling Msg.m3 new source -> compiling Utils.m3 new source -> compiling WebFile.m3 new source -> compiling Main.m3 new exporters -> recompiling Utils.i3 -> linking cm3 --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/cm3/PPC_DARWIN .M3EXPORTS .M3WEB ../PPC_DARWIN => /usr/local/cm3/pkg/cm3/PPC_DARWIN Version.i3 ../src => /usr/local/cm3/pkg/cm3/src M3Backend.i3 M3Backend.m3 UtilsPosix.m3 Arg.i3 Arg.m3 Builder.m3 Builder.i3 Dirs.i3 Dirs.m3 M3Build.i3 M3Build.m3 M3Loc.i3 M3Loc.m3 M3Options.m3 M3Options.i3 M3Path.i3 M3Path.m3 M3Unit.i3 M3Unit.m3 Makefile.i3 Makefile.m3 Msg.m3 Msg.i3 Utils.i3 Utils.m3 WebFile.i3 WebFile.m3 Main.m3 . => /usr/local/cm3/pkg/cm3/PPC_DARWIN cm3 ==> m3-sys/cm3 done /Users/wagner/work/cm3/scripts/do-pkg.sh build m3cc /Users/wagner/work/cm3/scripts/pkgmap.sh -c "cm3 -build -override -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' " m3cc === package m3-sys/m3cc === +++ cm3 -build -override -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- cd . && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: configure-host | tee -a _m3.log cd . && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: configure-host | tee -a _m3.log make all-recursive Making all in tests Making all in . make[4]: Nothing to be done for `all-am'. Making all in devel make[4]: Nothing to be done for `all'. Making all in mpn make[4]: Nothing to be done for `all'. Making all in mpz make[4]: Nothing to be done for `all'. Making all in mpq make[4]: Nothing to be done for `all'. Making all in mpf make[4]: Nothing to be done for `all'. Making all in rand make[4]: Nothing to be done for `all'. Making all in misc make[4]: Nothing to be done for `all'. Making all in cxx make[4]: Nothing to be done for `all'. Making all in mpbsd make[4]: Nothing to be done for `all'. Making all in mpn make[3]: Nothing to be done for `all'. Making all in mpz make[3]: Nothing to be done for `all'. Making all in mpq make[3]: Nothing to be done for `all'. Making all in mpf make[3]: Nothing to be done for `all'. Making all in printf make[3]: Nothing to be done for `all'. Making all in scanf make[3]: Nothing to be done for `all'. Making all in cxx make[3]: Nothing to be done for `all'. Making all in mpbsd make[3]: Nothing to be done for `all'. Making all in demos Making all in calc make all-am make[5]: Nothing to be done for `all-am'. Making all in expr make[4]: Nothing to be done for `all'. make[4]: Nothing to be done for `all-am'. Making all in tune make[3]: Nothing to be done for `all'. Making all in doc make[3]: Nothing to be done for `all'. make[3]: Nothing to be done for `all-am'. sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./gcc/Makefile > ./gcc/Makefile.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./gcc/Makefile > ./gcc/Makefile.1 ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./gcc/Makefile > ./gcc/Makefile.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./gcc/Makefile > ./gcc/Makefile.1 ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile sed -e 's/^#define HAVE_ICONV 1$//' < ./gcc/Makefile > ./gcc/Makefile.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./gcc/Makefile > ./gcc/Makefile.1 ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile sed -e 's/^#define HAVE_ICONV_H 1$//' < ./gcc/Makefile > ./gcc/Makefile.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./gcc/Makefile > ./gcc/Makefile.1 ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h sed -e 's/^#define HAVE_ICONV 1$//' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h sed -e 's/^#define HAVE_ICONV_H 1$//' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./gcc/config.h > ./gcc/config.h.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./gcc/config.h > ./gcc/config.h.1 ../gcc/move-if-change ./gcc/config.h.1 ./gcc/config.h ../gcc/move-if-change ./gcc/config.h.1 ./gcc/config.h sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./gcc/config.h > ./gcc/config.h.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./gcc/config.h > ./gcc/config.h.1 ../gcc/move-if-change ./gcc/config.h.1 ./gcc/config.h ../gcc/move-if-change ./gcc/config.h.1 ./gcc/config.h sed -e 's/^#define HAVE_ICONV 1$//' < ./gcc/config.h > ./gcc/config.h.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./gcc/config.h > ./gcc/config.h.1 ../gcc/move-if-change ./gcc/config.h.1 ./gcc/config.h ../gcc/move-if-change ./gcc/config.h.1 ./gcc/config.h sed -e 's/^#define HAVE_ICONV_H 1$//' < ./gcc/config.h > ./gcc/config.h.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./gcc/config.h > ./gcc/config.h.1 ../gcc/move-if-change ./gcc/config.h.1 ./gcc/config.h ../gcc/move-if-change ./gcc/config.h.1 ./gcc/config.h sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./libcpp/Makefile > ./libcpp/Makefile.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./libcpp/Makefile > ./libcpp/Makefile.1 ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./libcpp/Makefile > ./libcpp/Makefile.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./libcpp/Makefile > ./libcpp/Makefile.1 ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile sed -e 's/^#define HAVE_ICONV 1$//' < ./libcpp/Makefile > ./libcpp/Makefile.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./libcpp/Makefile > ./libcpp/Makefile.1 ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile sed -e 's/^#define HAVE_ICONV_H 1$//' < ./libcpp/Makefile > ./libcpp/Makefile.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./libcpp/Makefile > ./libcpp/Makefile.1 ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./libcpp/config.h > ./libcpp/config.h.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./libcpp/config.h > ./libcpp/config.h.1 ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./libcpp/config.h > ./libcpp/config.h.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./libcpp/config.h > ./libcpp/config.h.1 ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h sed -e 's/^#define HAVE_ICONV 1$//' < ./libcpp/config.h > ./libcpp/config.h.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./libcpp/config.h > ./libcpp/config.h.1 ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h sed -e 's/^#define HAVE_ICONV_H 1$//' < ./libcpp/config.h > ./libcpp/config.h.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./libcpp/config.h > ./libcpp/config.h.1 ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./mpfr/Makefile > ./mpfr/Makefile.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./mpfr/Makefile > ./mpfr/Makefile.1 ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./mpfr/Makefile > ./mpfr/Makefile.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./mpfr/Makefile > ./mpfr/Makefile.1 ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile sed -e 's/^#define HAVE_ICONV 1$//' < ./mpfr/Makefile > ./mpfr/Makefile.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./mpfr/Makefile > ./mpfr/Makefile.1 ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile sed -e 's/^#define HAVE_ICONV_H 1$//' < ./mpfr/Makefile > ./mpfr/Makefile.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./mpfr/Makefile > ./mpfr/Makefile.1 ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile sed -e 's/^#define HAVE_ICONV 1$//' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile sed -e 's/^#define HAVE_ICONV_H 1$//' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile cd . && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: all-gmp all-mpfr all-build-libiberty all-libiberty all-libdecnumber | tee -a _m3.log cd . && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: all-gmp all-mpfr all-build-libiberty all-libiberty all-libdecnumber | tee -a _m3.log make all-recursive Making all in tests Making all in . make[4]: Nothing to be done for `all-am'. Making all in devel make[4]: Nothing to be done for `all'. Making all in mpn make[4]: Nothing to be done for `all'. Making all in mpz make[4]: Nothing to be done for `all'. Making all in mpq make[4]: Nothing to be done for `all'. Making all in mpf make[4]: Nothing to be done for `all'. Making all in rand make[4]: Nothing to be done for `all'. Making all in misc make[4]: Nothing to be done for `all'. Making all in cxx make[4]: Nothing to be done for `all'. Making all in mpbsd make[4]: Nothing to be done for `all'. Making all in mpn make[3]: Nothing to be done for `all'. Making all in mpz make[3]: Nothing to be done for `all'. Making all in mpq make[3]: Nothing to be done for `all'. Making all in mpf make[3]: Nothing to be done for `all'. Making all in printf make[3]: Nothing to be done for `all'. Making all in scanf make[3]: Nothing to be done for `all'. Making all in cxx make[3]: Nothing to be done for `all'. Making all in mpbsd make[3]: Nothing to be done for `all'. Making all in demos Making all in calc make all-am make[5]: Nothing to be done for `all-am'. Making all in expr make[4]: Nothing to be done for `all'. make[4]: Nothing to be done for `all-am'. Making all in tune make[3]: Nothing to be done for `all'. Making all in doc make[3]: Nothing to be done for `all'. make[3]: Nothing to be done for `all-am'. Making all in tests make[2]: Nothing to be done for `all'. make[2]: Nothing to be done for `all-am'. make[2]: Nothing to be done for `all'. make[2]: Nothing to be done for `all'. make[1]: Nothing to be done for `all'. cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a _m3.log cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a _m3.log cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a _m3.log cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a _m3.log make: `s-modes' is up to date. ==> m3-sys/m3cc done /Users/wagner/work/cm3/scripts/install-cm3-compiler.sh upgrade cp /usr/local/cm3/bin/cm3 /usr/local/cm3/bin/cm3-d5.7.0 cp_if: /usr/local/cm3/bin/cm3cg and /usr/local/cm3/bin/cm3cg-d5.7.0 identical cp /Users/wagner/work/cm3/m3-sys/cm3/PPC_DARWIN/cm3 /usr/local/cm3/bin/cm3-d5.8.0 cp /Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/cm3cg /usr/local/cm3/bin/cm3cg-d5.8.0 cp /usr/local/cm3/bin/cm3-d5.8.0 /usr/local/cm3/bin/cm3 cp /usr/local/cm3/bin/cm3cg-d5.8.0 /usr/local/cm3/bin/cm3cg /Users/wagner/work/cm3/scripts/do-cm3-core.sh realclean /Users/wagner/work/cm3/scripts/pkgmap.sh -k -c "rm -rf PPC_DARWIN" import-libs m3cc m3core libm3 patternmatching sysutils unittest m3middle m3objfile m3linker m3back m3staloneback m3front m3quake cm3 m3scanner m3tools m3cgcat m3cggen m3bundle mklib fix_nl libdump bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles tcl === package m3-win/import-libs === === package omitted on this platform === ==> m3-win/import-libs done === package m3-sys/m3cc === === package omitted on this platform === ==> m3-sys/m3cc done === package m3-libs/m3core === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/m3core done === package m3-libs/libm3 === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/libm3 done === package m3-libs/patternmatching === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/patternmatching done === package m3-libs/sysutils === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/sysutils done === package m3-libs/unittest === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/unittest done === package m3-sys/m3middle === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/m3middle done === package m3-sys/m3objfile === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/m3objfile done === package m3-sys/m3linker === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/m3linker done === package m3-sys/m3back === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/m3back done === package m3-sys/m3staloneback === === package omitted on this platform === ==> m3-sys/m3staloneback done === package m3-sys/m3front === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/m3front done === package m3-sys/m3quake === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/m3quake done === package m3-sys/cm3 === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/cm3 done === package m3-sys/m3scanner === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/m3scanner done === package m3-sys/m3tools === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/m3tools done === package m3-sys/m3cgcat === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/m3cgcat done === package m3-sys/m3cggen === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/m3cggen done === package m3-tools/m3bundle === +++ rm -rf PPC_DARWIN +++ ==> m3-tools/m3bundle done === package m3-sys/mklib === === package omitted on this platform === ==> m3-sys/mklib done === package m3-sys/fix_nl === === package omitted on this platform === ==> m3-sys/fix_nl done === package m3-sys/libdump === === package omitted on this platform === ==> m3-sys/libdump done === package m3-libs/bitvector === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/bitvector done === package m3-libs/digraph === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/digraph done === package m3-libs/parseparams === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/parseparams done === package m3-libs/realgeometry === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/realgeometry done === package m3-libs/set === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/set done === package m3-libs/slisp === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/slisp done === package m3-libs/sortedtableextras === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/sortedtableextras done === package m3-libs/table-list === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/table-list done === package m3-libs/tempfiles === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/tempfiles done === package m3-libs/tcl === === package omitted on this platform === ==> m3-libs/tcl done /Users/wagner/work/cm3/scripts/do-cm3-core.sh buildship /Users/wagner/work/cm3/scripts/pkgmap.sh -c "cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' " import-libs m3cc m3core libm3 patternmatching sysutils unittest m3middle m3objfile m3linker m3back m3staloneback m3front m3quake cm3 m3scanner m3tools m3cgcat m3cggen m3bundle mklib fix_nl libdump bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles tcl === package m3-win/import-libs === === package omitted on this platform === ==> m3-win/import-libs done === package m3-sys/m3cc === === package omitted on this platform === ==> m3-sys/m3cc done === package m3-libs/m3core === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling WordRep.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 ../src/runtime/common/RuntimeError.m3: In function 'RuntimeError__Tag': ../src/runtime/common/RuntimeError.m3:56: error: type mismatch in binary expression int_32 int_32 word_32 D.252 = D.251 * 4 ../src/runtime/common/RuntimeError.m3:56: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 1024 m3cc (aka cm3cg) failed compiling: RuntimeError.mc new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling Scheduler.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling RTHeap.i3 new source -> compiling Cstdlib.i3 new source -> compiling LongRep.i3 new source -> compiling Long.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling Cstddef.i3 new source -> compiling Csetjmp.i3 new source -> compiling RTMachine.i3 new source -> compiling Uucontext.i3 new source -> compiling Usysdep.i3 new source -> compiling Cstdint.i3 new source -> compiling Utypes.i3 new source -> compiling Upthread.i3 new source -> compiling RTHeapRep.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 ../src/runtime/common/RTAllocator.m3: In function 'RTAllocator__CheckTypeFailed': ../src/runtime/common/RTAllocator.m3:181: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 1024 m3cc (aka cm3cg) failed compiling: RTAllocator.mc new source -> compiling RTAllocStats.i3 new source -> compiling Convert.i3 new source -> compiling TextClass.i3 new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 ../src/runtime/common/RTAllocStats.m3: In function 'RTAllocStats__EnableTrace': ../src/runtime/common/RTAllocStats.m3:40: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 1024 m3cc (aka cm3cg) failed compiling: RTAllocStats.mc new source -> compiling TextLiteral.i3 new source -> compiling RTHeap.m3 ../src/runtime/common/RTHeap.m3: In function 'RTHeap__GetDataAdr': ../src/runtime/common/RTHeap.m3:20: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 1024 m3cc (aka cm3cg) failed compiling: RTHeap.mc new source -> compiling RTHeapInfo.i3 new source -> compiling Cstring.i3 -------------- next part -------------- /Users/wagner/work/cm3/scripts/pkgmap.sh -c "cm3 -build -override -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' " m3core === package m3-libs/m3core === +++ cm3 -build -override -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling WordRep.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 ../src/runtime/common/RuntimeError.m3: In function 'RuntimeError__Tag': ../src/runtime/common/RuntimeError.m3:56: error: type mismatch in binary expression int_32 int_32 word_32 D.252 = D.251 * 4 ../src/runtime/common/RuntimeError.m3:56: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling Scheduler.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling RTHeap.i3 new source -> compiling Cstdlib.i3 new source -> compiling LongRep.i3 new source -> compiling Long.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling Cstddef.i3 new source -> compiling Csetjmp.i3 new source -> compiling RTMachine.i3 new source -> compiling Uucontext.i3 new source -> compiling Usysdep.i3 new source -> compiling Cstdint.i3 new source -> compiling Utypes.i3 new source -> compiling Upthread.i3 new source -> compiling RTHeapRep.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 ../src/runtime/common/RTAllocator.m3: In function 'RTAllocator__CheckTypeFailed': ../src/runtime/common/RTAllocator.m3:181: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTAllocStats.i3 new source -> compiling Convert.i3 new source -> compiling TextClass.i3 new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 ../src/runtime/common/RTAllocStats.m3: In function 'RTAllocStats__EnableTrace': ../src/runtime/common/RTAllocStats.m3:40: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling TextLiteral.i3 new source -> compiling RTHeap.m3 ../src/runtime/common/RTHeap.m3: In function 'RTHeap__GetDataAdr': ../src/runtime/common/RTHeap.m3:20: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTHeapInfo.i3 new source -> compiling Cstring.i3 new source -> compiling Thread.i3 new source -> compiling RTPerfTool.i3 new source -> compiling RTParams.i3 new source -> compiling RTHeapInfo.m3 ../src/runtime/common/RTHeapInfo.m3: In function 'RTHeapInfo__Producer': ../src/runtime/common/RTHeapInfo.m3:22: error: type mismatch in binary expression int_32 int_32 word_32 D.343 = M3_AcxOUs_i.6 * 4 ../src/runtime/common/RTHeapInfo.m3:22: error: type mismatch in binary expression int_32 int_32 word_32 D.365 = M3_AcxOUs_i.17 * 4 ../src/runtime/common/RTHeapInfo.m3:22: error: type mismatch in binary expression int_32 int_32 word_32 D.385 = M3_AcxOUs_i.26 * 4 ../src/runtime/common/RTHeapInfo.m3:22: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTHeapMap.i3 new source -> compiling RTIO.i3 new source -> compiling RTTypeMap.i3 new source -> compiling RTMapOp.i3 new source -> compiling RTModule.i3 new source -> compiling RTHeapMap.m3 ../src/runtime/common/RTHeapMap.m3: In function 'RTHeapMap__WalkGlobals': ../src/runtime/common/RTHeapMap.m3:73: error: type mismatch in binary expression int_32 int_32 word_32 D.450 = M3_AcxOUs_i.43 * 4 ../src/runtime/common/RTHeapMap.m3:73: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTHeapRep.m3 new source -> compiling RTHeapStats.i3 new source -> compiling FloatMode.i3 new source -> compiling ThreadF.i3 new source -> compiling RTTypeSRC.i3 new source -> compiling RTCollector.i3 new source -> compiling RTHeapStats.m3 ../src/runtime/common/RTHeapStats.m3: In function 'RTHeapStats__ReportReachable': ../src/runtime/common/RTHeapStats.m3:75: error: type mismatch in shift expression int_32 word_32 int_32 D.624 = D.623 >> 20 ../src/runtime/common/RTHeapStats.m3:75: error: type mismatch in shift expression int_32 word_32 int_32 D.634 = D.633 >> 20 ../src/runtime/common/RTHeapStats.m3:75: error: type mismatch in binary expression int_32 int_32 word_32 D.666 = D.665 * 24 ../src/runtime/common/RTHeapStats.m3:75: error: type mismatch in binary expression int_32 int_32 word_32 D.679 = D.678 * 24 ../src/runtime/common/RTHeapStats.m3:75: error: type mismatch in binary expression int_32 int_32 word_32 D.692 = D.691 * 24 ../src/runtime/common/RTHeapStats.m3:75: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Time.i3 new source -> compiling RTLinker.i3 new source -> compiling RTProcess.i3 new source -> compiling RTHeapEvent.i3 new source -> compiling RTWeakRef.i3 new source -> compiling RTCollectorSRC.i3 new source -> compiling RTCollector.m3 ../src/runtime/common/RTCollector.m3: In function 'RTCollector__Disable': ../src/runtime/common/RTCollector.m3:42: internal compiler error: in verify_gimple_expr, at tree-cfg.c:3957 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTIO.m3 new source -> compiling RTLinkerX.i3 new source -> compiling RTSignal.i3 new source -> compiling RTDebug.i3 new source -> compiling RTLinker.m3 ../src/runtime/common/RTLinker.m3: In function 'RTModule__Get': ../src/runtime/common/RTLinker.m3:439: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTDebug.m3 ../src/runtime/common/RTDebug.m3: In function 'RTDebug__DefaultMsg': ../src/runtime/common/RTDebug.m3:36: error: type mismatch in binary expression int_32 int_32 word_32 D.349 = M3_AcxOUs_i.22 * 4 ../src/runtime/common/RTDebug.m3:36: error: type mismatch in binary expression int_32 int_32 word_32 D.377 = M3_AcxOUs_i.29 * 4 ../src/runtime/common/RTDebug.m3:36: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTError.i3 new source -> compiling RTError.m3 new source -> compiling M3toC.i3 new source -> compiling RTException.m3 new source -> compiling RTMapOp.m3 ../src/runtime/common/RTMapOp.m3: In function 'RTMapOp__GetInt': ../src/runtime/common/RTMapOp.m3:11: error: type mismatch in binary expression word_32 word_32 int_32 D.234 = iftmp.12 | M3_AcxOUs_n.15 ../src/runtime/common/RTMapOp.m3:11: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTMisc.m3 new source -> compiling RTPacking.i3 new source -> compiling RTPacking.m3 ../src/runtime/common/RTPacking.m3: In function 'RTPacking__SizeOf': ../src/runtime/common/RTPacking.m3:63: error: type mismatch in binary expression int_32 int_32 word_32 D.311 = M3_AcxOUs_i.10 * 4 ../src/runtime/common/RTPacking.m3:63: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTArgs.i3 new source -> compiling RTParams.m3 ../src/runtime/common/RTParams.m3: In function 'RTParams__Init': ../src/runtime/common/RTParams.m3:78: error: type mismatch in shift expression int_32 word_32 int_32 D.618 = D.617 >> 1 ../src/runtime/common/RTParams.m3:78: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTProcedure.m3 ../src/runtime/common/RTProcedure.m3: In function 'RTProcedureSRC__FromPC': ../src/runtime/common/RTProcedure.m3:57: error: type mismatch in binary expression int_32 int_32 word_32 D.377 = M3_AcxOUs_i.14 * 4 ../src/runtime/common/RTProcedure.m3:57: error: type mismatch in binary expression int_32 int_32 word_32 D.413 = M3_AcxOUs_best.34 * 4 ../src/runtime/common/RTProcedure.m3:57: error: type mismatch in binary expression int_32 int_32 word_32 D.443 = M3_AcxOUs_best.48 * 4 ../src/runtime/common/RTProcedure.m3:57: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTProcess.m3 new source -> compiling RTTipe.i3 new source -> compiling RTTipe.m3 ../src/runtime/common/RTTipe.m3: In function 'RTTipe__ReadOp': ../src/runtime/common/RTTipe.m3:106: error: type mismatch in binary expression int_32 int_32 word_32 D.792 = D.791 * 4 ../src/runtime/common/RTTipe.m3:106: error: type mismatch in binary expression int_32 int_32 word_32 D.899 = D.898 * 4 ../src/runtime/common/RTTipe.m3:106: error: type mismatch in binary expression int_32 int_32 word_32 D.986 = D.985 * 4 ../src/runtime/common/RTTipe.m3:106: error: type mismatch in binary expression int_32 int_32 word_32 D.1073 = D.1072 * 4 ../src/runtime/common/RTTipe.m3:106: error: type mismatch in binary expression int_32 int_32 word_32 D.1157 = D.1156 * 4 ../src/runtime/common/RTTipe.m3:106: error: type mismatch in binary expression int_32 int_32 word_32 D.1303 = D.1302 * 4 ../src/runtime/common/RTTipe.m3:106: error: type mismatch in binary expression int_32 int_32 word_32 D.1412 = D.1411 * 4 ../src/runtime/common/RTTipe.m3:106: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTType.m3 ../src/runtime/common/RTType.m3: In function 'RTType__Get': ../src/runtime/common/RTType.m3:71: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTTypeFP.i3 new source -> compiling RTTypeFP.m3 ../src/runtime/common/RTTypeFP.m3: In function 'RTTypeFP__FromFingerprint': ../src/runtime/common/RTTypeFP.m3:23: error: type mismatch in binary expression int_32 int_32 word_32 D.285 = M3_AcxOUs_x.17 * 4 ../src/runtime/common/RTTypeFP.m3:23: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTTypeMap.m3 ../src/runtime/common/RTTypeMap.m3: In function 'RTTypeMap__Walk': ../src/runtime/common/RTTypeMap.m3:51: error: type mismatch in binary expression word_32 int_32 word_32 D.657 = M3_DrLXJX_mask.111 & 65536 ../src/runtime/common/RTTypeMap.m3:51: error: type mismatch in binary expression word_32 word_32 int_32 D.695 = iftmp.124 & M3_DrLXJX_mask.128 ../src/runtime/common/RTTypeMap.m3:51: error: type mismatch in binary expression int_32 int_32 word_32 D.715 = D.714 * 4 ../src/runtime/common/RTTypeMap.m3:51: error: type mismatch in binary expression word_32 word_32 int_32 D.736 = iftmp.139 & M3_DrLXJX_mask.143 ../src/runtime/common/RTTypeMap.m3:51: error: type mismatch in binary expression int_32 int_32 word_32 D.790 = D.789 * 4 ../src/runtime/common/RTTypeMap.m3:51: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTutils.i3 new source -> compiling RTutils.m3 ../src/runtime/common/RTutils.m3: In function 'RTutils__Delta': ../src/runtime/common/RTutils.m3:78: error: type mismatch in binary expression int_32 int_32 word_32 D.687 = M3_AcxOUs_i.30 * 12 ../src/runtime/common/RTutils.m3:78: error: type mismatch in binary expression int_32 int_32 word_32 D.718 = M3_AcxOUs_i.36 * 12 ../src/runtime/common/RTutils.m3:78: error: type mismatch in binary expression int_32 int_32 word_32 D.749 = M3_AcxOUs_i.42 * 12 ../src/runtime/common/RTutils.m3:78: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTHeapDebug.i3 new source -> compiling WeakRef.i3 new source -> compiling RTHeapDebug.m3 ../src/runtime/common/RTHeapDebug.m3: In function 'RTHeapDebug__Free': ../src/runtime/common/RTHeapDebug.m3:48: error: type mismatch in binary expression int_32 int_32 word_32 D.348 = D.347 * 8 ../src/runtime/common/RTHeapDebug.m3:48: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTArgs.m3 ../src/runtime/POSIX/RTArgs.m3: In function 'RTArgs__GetArg': ../src/runtime/POSIX/RTArgs.m3:21: error: type mismatch in binary expression int_32 int_32 word_32 D.245 = D.244 * 4 ../src/runtime/POSIX/RTArgs.m3:21: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Uuio.i3 new source -> compiling Unix.i3 new source -> compiling Utime.i3 new source -> compiling RTOS.m3 new source -> compiling Uexec.i3 new source -> compiling RTPerfTool.m3 new source -> compiling Usignal.i3 new source -> compiling RTThread.i3 new source -> compiling RTThreadStk.m3 ../src/runtime/POSIX/RTThreadStk.m3: In function 'RTThread__GetStack': ../src/runtime/POSIX/RTThreadStk.m3:15: error: type mismatch in binary expression int_32 int_32 word_32 D.238 = D.237 * 12 ../src/runtime/POSIX/RTThreadStk.m3:15: error: type mismatch in binary expression int_32 int_32 word_32 D.271 = D.270 * 12 ../src/runtime/POSIX/RTThreadStk.m3:15: error: type mismatch in binary expression int_32 int_32 word_32 D.279 = D.278 * 12 ../src/runtime/POSIX/RTThreadStk.m3:15: error: type mismatch in binary expression int_32 int_32 word_32 D.307 = D.306 * 12 ../src/runtime/POSIX/RTThreadStk.m3:15: error: type mismatch in binary expression int_32 int_32 word_32 D.320 = D.319 * 12 ../src/runtime/POSIX/RTThreadStk.m3:15: error: type mismatch in binary expression int_32 int_32 word_32 D.326 = D.325 * 12 ../src/runtime/POSIX/RTThreadStk.m3:15: error: type mismatch in binary expression int_32 int_32 word_32 D.334 = D.333 * 12 ../src/runtime/POSIX/RTThreadStk.m3:15: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTSignalPrivate.i3 new source -> compiling RTSignalC.i3 new source -> compiling RTSignal.m3 new source -> compiling Umman.i3 new source -> compiling RTThread.m3 ../src/runtime/PPC_DARWIN/RTThread.m3: In function 'RTThread__NewStack': ../src/runtime/PPC_DARWIN/RTThread.m3:26: error: type mismatch in shift expression int_32 word_32 int_32 D.261 = D.260 >> 2 ../src/runtime/PPC_DARWIN/RTThread.m3:26: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTExFrame.i3 new source -> compiling RTExFrame.m3 ../src/runtime/ex_frame/RTExFrame.m3: In function 'RTExFrame_M3': ../src/runtime/ex_frame/RTExFrame.m3:279: internal compiler error: tree check: did not expect class 'type', have 'type' (pointer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling SchedulerPosix.i3 new source -> compiling MutexRep.i3 new source -> compiling ThreadEvent.i3 new source -> compiling ThreadPThread.i3 new source -> compiling Uerror.i3 new source -> compiling Usched.i3 new source -> compiling Cerrno.i3 new source -> compiling ThreadPThread.m3 ../src/thread/PTHREAD/ThreadPThread.m3: In function 'ThreadPThread__SetState': ../src/thread/PTHREAD/ThreadPThread.m3:98: error: type mismatch in binary expression int_32 int_32 word_32 D.954 = D.953 * 4 ../src/thread/PTHREAD/ThreadPThread.m3:98: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling WinBaseTypes.i3 new source -> compiling WinDef.i3 new source -> compiling WinDef.m3 ../src/win32/WinDef.m3: In function 'WinDef__MAKEWORD': ../src/win32/WinDef.m3:78: error: type mismatch in binary expression word_32 word_32 int_32 D.365 = iftmp.1 | D.364 ../src/win32/WinDef.m3:78: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling WinNT.i3 new source -> compiling WinNT.m3 ../src/win32/WinNT.m3: In function 'WinNT__BTYPE': ../src/win32/WinNT.m3:19: error: type mismatch in binary expression word_32 int_32 int_32 D.212 = D.211 & 15 ../src/win32/WinNT.m3:19: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Unetdb.i3 new source -> compiling Uutmp.i3 new source -> compiling Ugrp.i3 new source -> compiling Upwd.i3 new source -> compiling Uugid.i3 new source -> compiling Uprocess.i3 new source -> compiling Unix.m3 new source -> compiling Usocket.i3 new source -> compiling Uin.i3 new source -> compiling Ustat.i3 new source -> compiling Udir.i3 new source -> compiling Usignal.m3 new source -> compiling Uin.m3 new source -> compiling Text8CString.i3 new source -> compiling Text8.i3 new source -> compiling M3toC.m3 new source -> compiling Csignal.i3 new source -> compiling Cstdio.i3 new source -> compiling Cstdio.m3 ../src/C/PPC_DARWIN/Cstdio.m3: In function 'Cstdio_M3': ../src/C/PPC_DARWIN/Cstdio.m3:6: error: type mismatch in binary expression int_32 int_32 word_32 D.212 = M3_AcxOUs_i.2 * 4 ../src/C/PPC_DARWIN/Cstdio.m3:6: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Real.i3 new source -> compiling RealFloat.i3 new source -> compiling LongReal.i3 new source -> compiling LongFloat.i3 new source -> compiling Extended.i3 new source -> compiling ExtendedFloat.i3 new source -> compiling IEEESpecial.i3 new source -> compiling LongRealRep.i3 new source -> compiling RealRep.i3 new source -> compiling IEEESpecial.m3 new source -> compiling Real.m3 new source -> compiling LongReal.m3 new source -> compiling Extended.m3 new source -> compiling DragonInt.i3 new source -> compiling DragonInt.m3 ../src/float/Common/DragonInt.m3: In function 'DragonInt__New': ../src/float/Common/DragonInt.m3:126: error: type mismatch in binary expression word_32 int_32 int_32 D.722 = M3_AcxOUs_a.24 & 16777215 ../src/float/Common/DragonInt.m3:126: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling DragonT.i3 new source -> compiling DragonT.m3 new source -> compiling FPU.i3 new source -> compiling RealFloat.m3 ../src/float/IEEE/RealFloat.m3: In function 'RealFloat__ILogb': ../src/float/IEEE/RealFloat.m3:40: error: type mismatch in binary expression word_32 int_32 int_32 D.409 = M3_AcxOUs_v.14 & M3_AcxOUs_w.15 ../src/float/IEEE/RealFloat.m3:40: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling LongFloat.m3 ../src/float/IEEE/LongFloat.m3: In function 'LongFloat__ILogb': ../src/float/IEEE/LongFloat.m3:44: error: type mismatch in binary expression word_32 int_32 int_32 D.410 = M3_AcxOUs_v.18 & M3_AcxOUs_w.19 ../src/float/IEEE/LongFloat.m3:44: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling ExtendedFloat.m3 new source -> compiling FPU.m3 new source -> compiling FloatMode.m3 new source -> compiling Tick.i3 new source -> compiling Date.i3 new source -> compiling FmtTime.i3 new source -> compiling FmtTime.m3 ../src/time/Common/FmtTime.m3: In function 'FmtTime__DateLong': ../src/time/Common/FmtTime.m3:38: error: type mismatch in binary expression int_32 int_32 word_32 D.300 = D.299 * 4 ../src/time/Common/FmtTime.m3:38: error: type mismatch in binary expression int_32 int_32 word_32 D.326 = D.325 * 4 ../src/time/Common/FmtTime.m3:38: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling TickPortable.m3 new source -> compiling TimePosix.i3 new source -> compiling DateBsd.m3 new source -> compiling TimePosix.m3 new source -> compiling CConvert.i3 new source -> compiling CConvert.m3 ../src/convert/CConvert.m3: In function 'CConvert__Acquire': ../src/convert/CConvert.m3:15: internal compiler error: in verify_gimple_expr, at tree-cfg.c:3957 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Convert.m3 ../src/convert/Convert.m3: In function 'Convert__InternalFromLongFloat': ../src/convert/Convert.m3:337: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling String8.i3 new source -> compiling String8.m3 ../src/text/String8.m3: In function 'String8__Hash': ../src/text/String8.m3:30: error: type mismatch in binary expression word_32 word_32 int_32 D.299 = D.294 ^ D.298 ../src/text/String8.m3:30: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling String16.i3 new source -> compiling String16.m3 ../src/text/String16.m3: In function 'String16__Hash': ../src/text/String16.m3:45: error: type mismatch in binary expression word_32 word_32 int_32 D.374 = D.369 ^ D.373 ../src/text/String16.m3:45: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Text16.i3 new source -> compiling Text.m3 ../src/text/Text.m3: In function 'Text__EqualBuf': ../src/text/Text.m3:47: error: type mismatch in binary expression int_32 int_32 word_32 D.611 = D.610 * 2 ../src/text/Text.m3:47: error: type mismatch in binary expression int_32 int_32 word_32 D.618 = D.617 * 2 ../src/text/Text.m3:47: error: type mismatch in binary expression int_32 int_32 word_32 D.685 = D.684 * 2 ../src/text/Text.m3:47: error: type mismatch in binary expression int_32 int_32 word_32 D.690 = D.689 * 2 ../src/text/Text.m3:47: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling TextClass.m3 ../src/text/TextClass.m3: In function 'TextClass__GetChar': ../src/text/TextClass.m3:8: error: type mismatch in binary expression word_32 int_32 int_32 D.234 = D.233 & 255 ../src/text/TextClass.m3:8: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling TextLiteral.m3 ../src/text/TextLiteral.m3: In function 'RTHooks__TextLitGetChar': ../src/text/TextLiteral.m3:19: error: type mismatch in binary expression word_32 int_32 int_32 D.307 = D.306 & 255 ../src/text/TextLiteral.m3:19: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Text8Short.i3 new source -> compiling Text8.m3 ../src/text/Text8.m3: In function 'Text8__New': ../src/text/Text8.m3:20: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Text8Short.m3 ../src/text/Text8Short.m3: In function 'Text8Short__GetChars': ../src/text/Text8Short.m3:41: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Text8CString.m3 new source -> compiling Text16Short.i3 new source -> compiling Text16.m3 ../src/text/Text16.m3: In function 'Text16__New': ../src/text/Text16.m3:20: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Text16Short.m3 ../src/text/Text16Short.m3: In function 'Text16Short__New': ../src/text/Text16Short.m3:15: error: type mismatch in binary expression int_32 int_32 word_32 D.276 = D.275 * 2 ../src/text/Text16Short.m3:15: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling TextSub.i3 new source -> compiling TextCat.i3 new source -> compiling TextSub.m3 ../src/text/TextSub.m3: In function 'Text__Sub': ../src/text/TextSub.m3:65: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling TextCat.m3 ../src/text/TextCat.m3: In function 'RTHooks__MultiCat': ../src/text/TextCat.m3:39: error: type mismatch in binary expression int_32 int_32 word_32 D.488 = M3_AcxOUs_i.42 * 4 ../src/text/TextCat.m3:39: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling TextConv.i3 new source -> compiling TextConv.m3 ../src/text/TextConv.m3: In function 'TextConv__EncodeChar': ../src/text/TextConv.m3:46: error: type mismatch in shift expression int_32 word_32 int_32 D.497 = D.496 >> 6 ../src/text/TextConv.m3:46: error: type mismatch in binary expression word_32 int_32 int_32 D.510 = D.509 & 63 ../src/text/TextConv.m3:46: error: type mismatch in shift expression int_32 word_32 int_32 D.511 = D.510 >> 3 ../src/text/TextConv.m3:46: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Poly.i3 new source -> compiling Fingerprint.m3 ../src/fingerprint/Fingerprint.m3: In function 'Fingerprint__Fix32': ../src/fingerprint/Fingerprint.m3:93: error: type mismatch in binary expression word_32 word_32 int_32 D.407 = M3_AcxOUs_x.61 | -2147483648 ../src/fingerprint/Fingerprint.m3:93: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Poly.m3 ../src/fingerprint/Poly.m3: In function 'Poly__Sum': ../src/fingerprint/Poly.m3:45: error: type mismatch in binary expression word_32 int_32 int_32 D.381 = D.377 ^ D.380 ../src/fingerprint/Poly.m3:45: error: type mismatch in binary expression word_32 int_32 int_32 D.391 = D.386 ^ D.390 ../src/fingerprint/Poly.m3:45: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling PolyBasis.i3 new source -> compiling PolyBasis.m3 new source -> compiling Main.i3 new source -> compiling WeakRef.m3 new source -> compiling Word.m3 ../src/word/Word.m3 => ../src/word/GenWord.mg: In function 'Word__And': ../src/word/Word.m3 => ../src/word/GenWord.mg:19: error: type mismatch in binary expression word_32 int_32 int_32 D.381 = M3_AcxOUs_x.36 & M3_AcxOUs_y.37 ../src/word/Word.m3 => ../src/word/GenWord.mg:19: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Long.m3 ../src/word/Long.m3 => ../src/word/GenWord.mg: In function 'Long__And': ../src/word/Long.m3 => ../src/word/GenWord.mg:19: error: type mismatch in binary expression word_64 int_64 int_64 D.382 = M3_AGDpCO_x.36 & M3_AGDpCO_y.37 ../src/word/Long.m3 => ../src/word/GenWord.mg:19: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTLinkerC.c new source -> compiling RTOSmmap.c new source -> compiling RTSignalC.c new source -> compiling RTThreadC.c new source -> compiling RTMachineC.c new source -> compiling RTStackC.c new source -> compiling ThreadPThreadC.c new source -> compiling WinNTc.c new source -> compiling UtimeC.c new source -> compiling UnixC.c new source -> compiling Uexec.c new source -> compiling Unetdb.c new source -> compiling Umman.c new source -> compiling Ugrp.c new source -> compiling Uconstants.c new source -> compiling UstatC.c new source -> compiling Usocket.c new source -> compiling UdirC.c new source -> compiling CerrnoC.c new exporters -> recompiling RTHooks.i3 new exporters -> recompiling RTAllocCnts.i3 new exporters -> recompiling RTHeapRep.i3 new exporters -> recompiling RTCollectorSRC.i3 new exporters -> recompiling RTWeakRef.i3 new exporters -> recompiling RTException.i3 new exporters -> recompiling RTModule.i3 new exporters -> recompiling RTProcedureSRC.i3 new exporters -> recompiling RTTypeSRC.i3 new exporters -> recompiling RTOS.i3 new exporters -> recompiling RTThread.i3 new exporters -> recompiling RTSignalPrivate.i3 new exporters -> recompiling Thread.i3 new exporters -> recompiling Scheduler.i3 new exporters -> recompiling SchedulerPosix.i3 new exporters -> recompiling ThreadF.i3 new exporters -> recompiling Time.i3 new exporters -> recompiling Tick.i3 new exporters -> recompiling Date.i3 new exporters -> recompiling Text.i3 compilation failed => not building library "libm3core.a" Fatal Error: package build failed *** execution of cm3 -build -override -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' failed *** From wagner at elegosoft.com Sat Apr 11 11:26:11 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 11 Apr 2009 11:26:11 +0200 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <49DE5A8A.5070307@bellsouth.net> References: <49DE5A8A.5070307@bellsouth.net> Message-ID: <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> Quoting Martin Bishop : > A few days ago there was more talk of a proper "release" for CM3. I > think this is very important. I second that. I'll try to start the release engineering now, as nobody else seems to volunteer ;-) We have two options here though: we can either (a) agree on a code freeze (beginning at some date we need to agree upon) (b) create a release branch immediately Code freeze would mean that nobody commits any major new functionality any more, but all commits concentrate on fixing bugs in some set of release candiates. I'd rather avoid creating a branch too early, as that means more work by selecting and merging fixes from trunk to branch. So here my questions: o Do we all agree on a temporary code freeze? o When should we start? I.e. wha changes would you like to complete before we start the release process? Please let me know your opinions, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 11 13:44:18 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 11 Apr 2009 13:44:18 +0200 Subject: [M3devel] (D)DCVSup in DCCS/DCVS for download Message-ID: <20090411134418.cqc2yem2g44ogkkg@mail.elegosoft.com> Hi, I've put most of the source code of our more or less abandoned DCCS project into http://www.opencm3.net/uploaded-archives/dccs-public.tar.gz for download. It contains a complete and extended version of CVSup along with much other potentially useful M3 code. I was able to compile everything with a recent CM3 for target FreeBSD4. To build everything, cd to dccs-public/prod and type make all. Please note that the resulting executables for CVSup are named dcvsup and dcvsupd, but they should work without DCVS configuration, too. At least you should be able to use the source to get get standard CVSup to compile. Hope this helps, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Sat Apr 11 13:44:41 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 11 Apr 2009 07:44:41 -0400 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> Message-ID: <20090411114441.GA22262@topoi.pooq.com> On Sat, Apr 11, 2009 at 11:26:11AM +0200, Olaf Wagner wrote: > o When should we start? I.e. wha changes would you like to complete > before we start the release process? The change to the ButtonVBT I brought up earlier. But if I continue not having time to get to it, you'd better release rather than watining indefinitely. I'd also like to make some progress in creating the monotone archive. But that's probably not relevant to the release process. It had perhaps better be thought of as (conceptually, at least) something for after the release. -- hendrik From jay.krell at cornell.edu Sat Apr 11 14:03:39 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 11 Apr 2009 12:03:39 +0000 Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN In-Reply-To: <20090411105512.92784fp7cc0o448k@mail.elegosoft.com> References: <20090411105512.92784fp7cc0o448k@mail.elegosoft.com> Message-ID: I do test on 10.4 fairly often, at least do-cm3-std buildship and/or make-dist, I even lately don't always skip gcc, I can report recent results soon. I've got a few PPC iBooks/PowerBooks and might yet try 10.2 or 3 or 5. It sounds like 7.9.0 is 10.3? Do my archives work for you, but then a locally build cm3cg doesn't? What does config.guess say? Can you try removing all the stuff I put in? cd somewhere configure -disable-bootstrap -disable-multilibs make If desperate I can send you a 10.4 machine and you can send me your 10.3, but it's not likely worth the shipping. - Jay > Date: Sat, 11 Apr 2009 10:55:12 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN > > After trying to upgrade cm3 on my notebook to the latest version, > I get lots of internal compiler errors.This is on > > % uname -a > Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 > 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power > Macintosh powerpc > > ... > new source -> compiling RuntimeError.m3 > ../src/runtime/common/RuntimeError.m3: In function 'RuntimeError__Tag': > ../src/runtime/common/RuntimeError.m3:56: error: type mismatch in > binary expression > int_32 > > int_32 > > word_32 > > D.252 = D.251 * 4 > ../src/runtime/common/RuntimeError.m3:56: internal compiler error: > verify_gimple failed > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > ... > > Full log attached. > > Before you ask, it won't be easy to upgrade Darwin on this notebook, > and I surely cannot do this within the next two weeks :-/ > > Any ideas? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Apr 11 14:19:37 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 11 Apr 2009 12:19:37 +0000 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <20090411114441.GA22262@topoi.pooq.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> Message-ID: > > o When should we start? I.e. wha changes would you like to complete > > before we start the release process? I'd like to see the formsvbt crash debugged and fixed, unless I'm the only one seeing it. I only see it on Solaris and PPC_DARWIN but haven't tried "everything". I'll try to get this. I'd also like to see: FreeBSD/x86 switched to the new Unix/*.i3 files. I'll do this. Maybe also I386_DARWIN, AMD64_DARWIN, but I don't have the hardware. $ORIGIN/LD_LIBRARY_PATH resolved a bit further, probably very little work (I'll do this). Basically just 1) put buildlocal back how it was 2) push it across more platforms e.g. I think FreeBSD/x86 is the main one missing, but I'll get to it. cvsup building and in "std" (I'll do this, probably very little left here really. -- beyond this, not required for release -- Maybe more AMD64 releases, e.g. NetBSD and Solaris. (If I get to it). (could be "mingw64" is good enough to try AMD64_NT now). Maybe update gmp/mpfr to fix the "maintainer" problem. (not likely by me) Maybe more new/resuscitated platforms..HPPA64_HPUX, IA64_*, *_VMS, ALPHA_*, ARM_*, *_IRIX, *_AIX, MIPS64_*.... but these take back seat to important fixes in existing platforms. Fix NT386 to use setjmp3 instead of setjmp so exceptions don't skip C __finally blocks. I've just been very lazy here, should demonstrate the behavior with a test case, then fix it.. Maybe fix cm3cg so other -g options besides -gstabs works, like plain -g, -ggdb, on at least one platform -gstabs isn't supported, leaving nothing, because others cause internal compiler errors, like on HPPA64_HPUX. Oh, and NT386GNU probably switched back to Win32 threads. Otherwise one of the test cases hangs and it doesn't look easy to figure out. I'll do this shortly if I remember. But I also wouldn't mind if this platform isn't officially released either (unless someone else wants to support it). Debug why many NT386MINGNU gui apps crash..but also probably just don't release this platform and ok asis. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Apr 11 14:21:38 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 11 Apr 2009 14:21:38 +0200 Subject: [M3devel] (D)DCVSup in DCCS/DCVS for download In-Reply-To: <20090411134418.cqc2yem2g44ogkkg@mail.elegosoft.com> References: <20090411134418.cqc2yem2g44ogkkg@mail.elegosoft.com> Message-ID: <20090411142138.mvnqsfqdus8wk8ko@mail.elegosoft.com> That still does not work on AMD64_LINUX yet. Even after changing dcvs/cvsup/quake/cvsup.quake to recognize Jay's new config files with if defined("INITIAL_REACTOR_EDITOR") or defined("CM3SetInstallRoot") M3_VARIANT = "CM3" I get several errors in FileAttr.m3 and dev_t_linux/DevT.m3. It seems there are some 64 bit issues. I've got to stop M3 work for today, though; perhaps Jay will look further into compiling CVSup for Linux today... Olaf Quoting Olaf Wagner : > Hi, > > I've put most of the source code of our more or less abandoned > DCCS project into > > http://www.opencm3.net/uploaded-archives/dccs-public.tar.gz > > for download. > > It contains a complete and extended version of CVSup along with > much other potentially useful M3 code. > > I was able to compile everything with a recent CM3 for target > FreeBSD4. > > To build everything, cd to dccs-public/prod and type make all. > Please note that the resulting executables for CVSup are named > dcvsup and dcvsupd, but they should work without DCVS configuration, > too. At least you should be able to use the source to get get standard > CVSup to compile. > > Hope this helps, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Sat Apr 11 16:27:02 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 11 Apr 2009 10:27:02 -0400 Subject: [M3devel] m3 CVS? In-Reply-To: References: <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> <20090325144505.GA16526@topoi.pooq.com> <20090325225421.GB17118@topoi.pooq.com> <20090330131918.GA6921@topoi.pooq.com> <20090331133910.flci659jockgo04c@mail.elegosoft.com> <20090331135610.GA9539@topoi.pooq.com> <20090331161908.3pferzf9c08oso40@mail.elegosoft.com> Message-ID: <20090411142702.GA22586@topoi.pooq.com> On Tue, Mar 31, 2009 at 10:41:42PM +0000, Jay wrote: > > Also, presumably you can copy the entire CVS repository with little CPU use and then do the monotone work locally. I doubt it is all that large, can tell you later.. (ssh in and du /usr/cvs) > > > > - Jay OK. What's the recommended way of copying the CVS repository? Downloading a .tgz file? Or figuring out how to get cvsup up first? (the more tools I have to build before I can test feasibility, the less likely I am to get there. cvsup doesn't seem to be available in Debian; perhaps that's because Modula 3 isn't either) I seem to have two ways to try to build the monotone repository. (1) use monotone's rcs_imnport command (2) use the cvs_sync branch, generate a new monotone from that branch, and see what it does. I'd have to try both so see what's feasible. Each seems to have limitations. rcs_import seems to want to have access to the cvs files instead of network access to CVS. -- hendrik > > > > Date: Tue, 31 Mar 2009 16:19:08 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > CC: manderson at elego.de > > Subject: Re: [M3devel] m3 CVS? > > > > Quoting hendrik at topoi.pooq.com: > > > > > On Tue, Mar 31, 2009 at 01:39:10PM +0200, Olaf Wagner wrote: > > >> Quoting hendrik at topoi.pooq.com: > > >> > > >> >Is CVS back up yet? Completely? I've been delaying trying the > > >> >monotone conversion because it would be nice to have only one set > > >> >of problems to look into. > > >> > > >> CVS is up and no history should be lost, but tinderbox is still not > > >> working and several archives are missing. Michael is working on it > > >> (but he's got some other tasks, too). > > > > > > So the current source is available, but not the tools to investigate > > > their status on-line. And the other archives? What are they? Are they > > > more source code? Should they be subject to revision control too? Are > > > they ancient prehistory that should be grafted into the revision tree > > > except that it may not be technically feasible? > > > > Mostly all the old installation archives and snapshots are still missing. > > I'm not sure what's the status of the re-installation of tinderbox. > > > > > Ah. I have too many questions. > > > > > > By the way, rumours are that monotone's cvs pull command is quite > > > demanding on the cvs server, but that sync operation isn't bad at all > > > after that. Getting really old versions of files requires CVS to chain > > > back through a lot of reverse differences. And I don't know if it > > > caches any of that in case it is asked to cough up another really old > > > version. > > > > > > If there are any scheduling considerations I'd like to hear them. I > > > don't know if I'll flatten your system, but if I do there are probably > > > better and worse times to do it. (I may saturate ny DSL link first, but > > > you never know until you try it.) > > > > > > By the way, what's the total size of Modula 3's CVS archive? > > > > I've got no access from here (can only check later tonight); please > > ask Michael Anderson directly for administrative topics. > > > > Olaf > > > > PS: I don't think you can bring the server down a one external CVS > > client; the syncing will just take a long time. Unless lots of parallel > > requests are started... > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > From neels at elego.de Sat Apr 11 23:20:24 2009 From: neels at elego.de (Neels J Hofmeyr) Date: Sat, 11 Apr 2009 23:20:24 +0200 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> Message-ID: <49E10998.5010205@elego.de> I have no opinion since I'm not active in the code. ~Neels Olaf Wagner wrote: > Quoting Martin Bishop : > >> A few days ago there was more talk of a proper "release" for CM3. I >> think this is very important. > > I second that. > > I'll try to start the release engineering now, as nobody else seems > to volunteer ;-) > > We have two options here though: we can either > > (a) agree on a code freeze (beginning at some date we need to agree upon) > (b) create a release branch immediately > > Code freeze would mean that nobody commits any major new functionality > any more, but all commits concentrate on fixing bugs in some set of > release candiates. > > I'd rather avoid creating a branch too early, as that means more work > by selecting and merging fixes from trunk to branch. So here my questions: > > o Do we all agree on a temporary code freeze? > o When should we start? I.e. wha changes would you like to complete > before we start the release process? > > Please let me know your opinions, > > Olaf -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From jay.krell at cornell.edu Sun Apr 12 05:00:39 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 12 Apr 2009 03:00:39 +0000 Subject: [M3devel] readdir/malloc Message-ID: cvsup source says: (*****************************************************************************) (* FIXME - The following procedures work around a bug in SRC Modula-3 thru version 3.6, at least. The FS.Iterator operations call the Unix opendir, readdir, and closedir functions, which in turn usually call malloc. This is done without any mutual exclusion, and malloc is normally not thread-safe. I have observed memory corruption and have traced it to this cause. As a work-around, these wrappers disable thread switching while the offending functions are executing. *) (*****************************************************************************) This is already fixed wrt opendir/closedir in cm3. But readdir? True? I guess I'll be pessimistic and assume it is true. - Jay From jay.krell at cornell.edu Sun Apr 12 13:32:07 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 12 Apr 2009 11:32:07 +0000 Subject: [M3devel] cvsup Message-ID: cvsup builds and starts up on a few platforms now, including Cygwin/x86, Linux/x86, Linux/AMD64 (birch), Macosx/PowerPC, FreeBSD/x86. I can verify more later.. I expect there might be problems on Macosx/x86 and AMD64. And FreeBSD/x86 might not work until I commit the change to use Unix/common. That is -- these are the only platforms not using Unix/common. Some platforms store extra "flags" with files -- Darwin and *BSD. Historically cvsup only get/sets those on FreeBSD. I extended that to the others, though didn't build NetBSD/OpenBSD. (nor have I tested any of the functionality at all..) The source should be refactored some in this regard, the "FreeBSD" directory split into "FreeBSD" and "flags" or something. But I don't like moving files since history might not track well. (I also chose "m3-tools" arbitrarily..) It might not even have to be refactored -- instead of the static platform checks, the code can check of the #defines in Ustat are zero or not, and UstatC.c can provide empty chflags/fchflags functions instead of none at all. It's a tricky area though in terms of what is best, providing no functions, vs. providing functions that do nothing and succeed, vs. providing functions that do nothing and fail, vs. providing a more explicit way to query if the functionality is provided, as well as deciding between build-time vs. run-time checks (we don't have anything like autoconf in our system, for better and worse). Now hopefully we can switch to svn or monotone and cvsup won't matter to us. :) (Well, I never use it in any case. I know it is big in FreeBSD-land.) - Jay From jay.krell at cornell.edu Sun Apr 12 13:34:49 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 12 Apr 2009 11:34:49 +0000 Subject: [M3devel] FW: cvsup Message-ID: [truncated again..] cvsup builds and starts up on a few platforms now, including Cygwin/x86, Linux/x86, Linux/AMD64 (birch), Macosx/PowerPC, FreeBSD/x86. I can verify more later.. I expect there might be problems on Macosx/x86 and AMD64. And FreeBSD/x86 might not work until I commit the change to use Unix/common. That is -- these are the only platforms not using Unix/common. Some platforms store extra "flags" with files -- Darwin and *BSD. see man chflags and man 2 chflags. Historically cvsup only get/sets those on FreeBSD. I extended that to the others, though didn't build NetBSD/OpenBSD. (nor have I tested any of the functionality at all..) The source should be refactored some in this regard, the "FreeBSD" directory split into "FreeBSD" and "flags" or something. But I don't like moving files since history might not track well. (I also chose "m3-tools" arbitrarily..) It might not even have to be refactored -- instead of the static platform checks, the code can check of the #defines in Ustat are zero or not, and UstatC.c can provide empty chflags/fchflags functions instead of none at all. It's a tricky area though in terms of what is best, providing no functions, vs. providing functions that do nothing and succeed, vs. providing functions that do nothing and fail, vs. providing a more explicit way to query if the functionality is provided, as well as deciding between build-time vs. run-time checks (we don't have anything like autoconf in our system, for better and worse). Now hopefully we can switch to svn or monotone and cvsup won't matter to us. :) (Well, I never use it in any case. I know it is big in FreeBSD-land.) - Jay From jay.krell at cornell.edu Sun Apr 12 13:40:45 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 12 Apr 2009 11:40:45 +0000 Subject: [M3devel] (D)DCVSup in DCCS/DCVS for download In-Reply-To: <20090411134418.cqc2yem2g44ogkkg@mail.elegosoft.com> References: <20090411134418.cqc2yem2g44ogkkg@mail.elegosoft.com> Message-ID: Yes, this helped, thank you. FreeBSD4 is unusual in that it has more complete and compatible (and platform specific) m3core/unix. - Jay ---------------------------------------- > Date: Sat, 11 Apr 2009 13:44:18 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] (D)DCVSup in DCCS/DCVS for download > > Hi, > > I've put most of the source code of our more or less abandoned > DCCS project into > > http://www.opencm3.net/uploaded-archives/dccs-public.tar.gz > > for download. > > It contains a complete and extended version of CVSup along with > much other potentially useful M3 code. > > I was able to compile everything with a recent CM3 for target > FreeBSD4. > > To build everything, cd to dccs-public/prod and type make all. > Please note that the resulting executables for CVSup are named > dcvsup and dcvsupd, but they should work without DCVS configuration, > too. At least you should be able to use the source to get get standard > CVSup to compile. > > Hope this helps, > > Olaf > -- From jay.krell at cornell.edu Sun Apr 12 14:07:44 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 12 Apr 2009 12:07:44 +0000 Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN In-Reply-To: <20090411105512.92784fp7cc0o448k@mail.elegosoft.com> References: <20090411105512.92784fp7cc0o448k@mail.elegosoft.com> Message-ID: My machine calls itself: jbook15:~ jay$ uname -a Darwin jbook15.local 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc That is 10.4.something. It works ok. cm3cg built as recently as 4/10.. - Jay ________________________________ > From: jay > To: wagner; m3devel > Subject: RE: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN > Date: Sat, 11 Apr 2009 12:03:39 +0000> > > I do test on 10.4 fairly often... > It sounds like 7.9.0 is 10.3? > > > - Jay > >> Date: Sat, 11 Apr 2009 10:55:12 +0200 >> From: wagner@ >> To: m3devel@ >> Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN >> >> After trying to upgrade cm3 on my notebook to the latest version, >> I get lots of internal compiler errors.This is on >> >> % uname -a >> Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 >> 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power >> Macintosh powerpc >> >> ... From jay.krell at cornell.edu Sun Apr 12 21:45:44 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 12 Apr 2009 19:45:44 +0000 Subject: [M3devel] cvsup and "flags" Message-ID: Um, these "flags" that cvsup is willing to traffic: 1) They are the same between machines that support them? Maybe, maybe not, I can check. 2) They are actually interesting? Given that many operating systems (e.g. Linux, Solaris) don't support them? They seem a little dubious. I suppose most cvsup users have both client and server on FreeBSD and if the FreeBSD source itself needs these flags on source controled files, it is useful. Even storing an executable bit in cvs seems not portable..but that is a different set of flags. (NTFS ACL should be reasonable superset, but then, FAT?) - Jay From mika at async.caltech.edu Sun Apr 12 22:05:49 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 12 Apr 2009 13:05:49 -0700 Subject: [M3devel] quick question for the Modula-3 ether... LONGFLOAT?? Message-ID: <200904122005.n3CK5omN035622@camembert.async.caltech.edu> Does anyone out there have any idea why a lot of bits of Modula-3 refer to something called "LONGFLOAT" or "LongFloat". I just checked Wirth, and Modula-2 used "REAL" as well so it doesn't seem like LONGREAL would ever have been called "LONGFLOAT". Is LONGFLOAT/LongFloat of any significance or is it OK to search-and-replace it away with LONGREAL/LongReal everywhere? (I'm talking about things like the emacs macro package as well as all over m3tk...) Mika From jay.krell at cornell.edu Mon Apr 13 00:01:35 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 12 Apr 2009 22:01:35 +0000 Subject: [M3devel] quick question for the Modula-3 ether... LONGFLOAT?? In-Reply-To: <200904122005.n3CK5omN035622@camembert.async.caltech.edu> References: <200904122005.n3CK5omN035622@camembert.async.caltech.edu> Message-ID: 1) I'm sure it is a natural term to all the other programmers, easy mistake to make. 2) There in fact this natural need to come up with alternate names. You know, if you read the compiler and runtime source, you see things called Type and/or Tipe, not just Type, because Type (or at least TYPE) is already a reserved word if you write "metacode" dealing with types, you can't use that name. In that vein there are some public m3core modules for dealing with floats/reals/whatever and they might use names like this. - Jay > To: m3devel at elegosoft.com > Date: Sun, 12 Apr 2009 13:05:49 -0700 > From: mika at async.caltech.edu > Subject: [M3devel] quick question for the Modula-3 ether... LONGFLOAT?? > > > Does anyone out there have any idea why a lot of bits of Modula-3 > refer to something called "LONGFLOAT" or "LongFloat". I just checked > Wirth, and Modula-2 used "REAL" as well so it doesn't seem like > LONGREAL would ever have been called "LONGFLOAT". > > Is LONGFLOAT/LongFloat of any significance or is it OK to > search-and-replace it away with LONGREAL/LongReal everywhere? > > (I'm talking about things like the emacs macro package as well as > all over m3tk...) > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Apr 13 00:22:23 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 12 Apr 2009 15:22:23 -0700 Subject: [M3devel] quick question for the Modula-3 ether... LONGFLOAT?? In-Reply-To: Your message of "Sun, 12 Apr 2009 22:01:35 -0000." Message-ID: <200904122222.n3CMMNTc041696@camembert.async.caltech.edu> It seems a bit more common a term than I would have thought from someone's making a mistake. I am talking about things like this. In the stubgen sources, there are two interfaces: Value.i3 and Type.i3. Not the only place I've seen it in Modula-3. Value.i3 has: TYPE T <: ROOT; (* Ordinal | Float | LongFloat | Extended | ArrayOrRecord | Set | Text | Null *) Ordinal = T OBJECT ord: INTEGER END; (* ORD(the value) *) Float = T OBJECT val: REAL END; (* XXX *) LongFloat = T OBJECT val: LONGREAL END; (* XXX *) Extended = T OBJECT val: EXTENDED END; ... Type.i3 has: TYPE T <: OBJECT name: Qid; visited := FALSE; brandsOK := TRUE END; (* Ordinal | Real | LongReal | Extended | Reference | Array | Packed | Record | Set | Procedure *) Ordinal = T BRANDED OBJECT END; (* Enumeration | Subrange *) (* ... *) Real = T BRANDED OBJECT END; (* YYY *) LongReal = T BRANDED OBJECT END; (* YYY *) Extended = T BRANDED OBJECT END; ... Is there a reason or is this just inconsistent crud from before the glaciers came thru? Mika Jay writes: >--_eaf98d33-2bbc-4e5b-8afc-bc1f32079c51_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >1) I'm sure it is a natural term to all the other programmers=2C easy mista= >ke to make. > >=20 > >2) There in fact this natural need to come up with alternate names. > >You know=2C if you read the compiler and runtime source=2C you see things c= >alled Type and/or Tipe=2C not just Type=2C because Type (or at least TYPE) = >is already a reserved word if you write "metacode" dealing with types=2C yo= >u can't use that name. > >=20 > >In that vein there are some public m3core modules for dealing with floats/r= >eals/whatever and they might use names like this. > >=20 > > - Jay > > >=20 >> To: m3devel at elegosoft.com >> Date: Sun=2C 12 Apr 2009 13:05:49 -0700 >> From: mika at async.caltech.edu >> Subject: [M3devel] quick question for the Modula-3 ether... LONGFLOAT?? >>=20 >>=20 >> Does anyone out there have any idea why a lot of bits of Modula-3 >> refer to something called "LONGFLOAT" or "LongFloat". I just checked >> Wirth=2C and Modula-2 used "REAL" as well so it doesn't seem like >> LONGREAL would ever have been called "LONGFLOAT". >>=20 >> Is LONGFLOAT/LongFloat of any significance or is it OK to >> search-and-replace it away with LONGREAL/LongReal everywhere? >>=20 >> (I'm talking about things like the emacs macro package as well as >> all over m3tk...) >>=20 >> Mika > >--_eaf98d33-2bbc-4e5b-8afc-bc1f32079c51_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >1) I'm sure it is a natural term to all the =3Bother programmers=2C eas= >y mistake to make.
> =3B
>2) There in fact this =3Bnatural need to come up with alternate names.<= >BR> >You know=2C if you read the compiler =3Band runtime source=2C you see t= >hings called Type and/or Tipe=2C not just Type=2C because Type (or at least= > TYPE) is already a reserved word if you write =3B"metacode" dealing wi= >th types=2C you can't use that name.
> =3B
>In that =3Bvein there are some =3Bpublic m3core modules for dealing= > with floats/reals/whatever and they =3Bmight use names like this.
> =3B
> =3B- Jay


 =3B
>=3B To: m3devel at elegosoft.com
&g= >t=3B Date: Sun=2C 12 Apr 2009 13:05:49 -0700
>=3B From: mika at async.cal= >tech.edu
>=3B Subject: [M3devel] quick question for the Modula-3 ether= >... LONGFLOAT??
>=3B
>=3B
>=3B Does anyone out there have = >any idea why a lot of bits of Modula-3
>=3B refer to something called = >"LONGFLOAT" or "LongFloat". I just checked
>=3B Wirth=2C and Modula-2 = >used "REAL" as well so it doesn't seem like
>=3B LONGREAL would ever h= >ave been called "LONGFLOAT".
>=3B
>=3B Is LONGFLOAT/LongFloat of= > any significance or is it OK to
>=3B search-and-replace it away with = >LONGREAL/LongReal everywhere?
>=3B
>=3B (I'm talking about thing= >s like the emacs macro package as well as
>=3B all over m3tk...)
&g= >t=3B
>=3B Mika
>= > >--_eaf98d33-2bbc-4e5b-8afc-bc1f32079c51_-- From jay.krell at cornell.edu Mon Apr 13 02:00:40 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 13 Apr 2009 00:00:40 +0000 Subject: [M3devel] quick question for the Modula-3 ether... LONGFLOAT?? In-Reply-To: <200904122222.n3CMMNTc041696@camembert.async.caltech.edu> References: Your message of "Sun, 12 Apr 2009 22:01:35 -0000." <200904122222.n3CMMNTc041696@camembert.async.caltech.edu> Message-ID: Here is the stuff I was talking about: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/float/Common/ This stuff is "standard" and in the green book. Surprising that both names occur here, float and real. You can see your example sort of proves my point. Imagine if there was no case sensitivity. Or if you aren't keen on identifiers varying only in case. The below needs to setup a parallel set of names for "wrapper types", or WrapperModule.T. Changing "Float" to "Real" or vice versa can help. Though, now that I'm saying it, it feels a bit sleazy. Maybe better to invent a prefix or suffix. IntegerValue, RealValue, etc. (That reminds me, I've seen "reel" used in a similar fashion.) You know, using homonyms -- ea vs. ee, y for long i, etc. tipe, type runtime, runtyme - Jay > To: jay.krell at cornell.edu > Date: Sun, 12 Apr 2009 15:22:23 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] quick question for the Modula-3 ether... LONGFLOAT?? > > > It seems a bit more common a term than I would have thought from > someone's making a mistake. > > I am talking about things like this. In the stubgen sources, there are > two interfaces: Value.i3 and Type.i3. > > Not the only place I've seen it in Modula-3. > > Value.i3 has: > > TYPE > T <: ROOT; > (* Ordinal | Float | LongFloat | Extended | ArrayOrRecord | Set | > Text | Null *) > > Ordinal = T OBJECT ord: INTEGER END; > (* ORD(the value) *) > > Float = T OBJECT val: REAL END; (* XXX *) > > LongFloat = T OBJECT val: LONGREAL END; (* XXX *) > > Extended = T OBJECT val: EXTENDED END; > > ... > > Type.i3 has: > > TYPE > T <: OBJECT name: Qid; visited := FALSE; brandsOK := TRUE END; > > (* Ordinal | Real | LongReal | Extended | Reference | Array > | Packed | Record | Set | Procedure *) > > Ordinal = T BRANDED OBJECT END; (* Enumeration | Subrange *) > > (* ... *) > > Real = T BRANDED OBJECT END; (* YYY *) > > LongReal = T BRANDED OBJECT END; (* YYY *) > > Extended = T BRANDED OBJECT END; > > ... > > Is there a reason or is this just inconsistent crud from before the > glaciers came thru? > > Mika > > > Jay writes: > >--_eaf98d33-2bbc-4e5b-8afc-bc1f32079c51_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >1) I'm sure it is a natural term to all the other programmers=2C easy mista= > >ke to make. > > > >=20 > > > >2) There in fact this natural need to come up with alternate names. > > > >You know=2C if you read the compiler and runtime source=2C you see things c= > >alled Type and/or Tipe=2C not just Type=2C because Type (or at least TYPE) = > >is already a reserved word if you write "metacode" dealing with types=2C yo= > >u can't use that name. > > > >=20 > > > >In that vein there are some public m3core modules for dealing with floats/r= > >eals/whatever and they might use names like this. > > > >=20 > > > > - Jay > > > > > >=20 > >> To: m3devel at elegosoft.com > >> Date: Sun=2C 12 Apr 2009 13:05:49 -0700 > >> From: mika at async.caltech.edu > >> Subject: [M3devel] quick question for the Modula-3 ether... LONGFLOAT?? > >>=20 > >>=20 > >> Does anyone out there have any idea why a lot of bits of Modula-3 > >> refer to something called "LONGFLOAT" or "LongFloat". I just checked > >> Wirth=2C and Modula-2 used "REAL" as well so it doesn't seem like > >> LONGREAL would ever have been called "LONGFLOAT". > >>=20 > >> Is LONGFLOAT/LongFloat of any significance or is it OK to > >> search-and-replace it away with LONGREAL/LongReal everywhere? > >>=20 > >> (I'm talking about things like the emacs macro package as well as > >> all over m3tk...) > >>=20 > >> Mika > > > >--_eaf98d33-2bbc-4e5b-8afc-bc1f32079c51_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >1) I'm sure it is a natural term to all the =3Bother programmers=2C eas= > >y mistake to make.
> > =3B
> >2) There in fact this =3Bnatural need to come up with alternate names.<= > >BR> > >You know=2C if you read the compiler =3Band runtime source=2C you see t= > >hings called Type and/or Tipe=2C not just Type=2C because Type (or at least= > > TYPE) is already a reserved word if you write =3B"metacode" dealing wi= > >th types=2C you can't use that name.
> > =3B
> >In that =3Bvein there are some =3Bpublic m3core modules for dealing= > > with floats/reals/whatever and they =3Bmight use names like this.
> > =3B
> > =3B- Jay


 =3B
>=3B To: m3devel at elegosoft.com
&g= > >t=3B Date: Sun=2C 12 Apr 2009 13:05:49 -0700
>=3B From: mika at async.cal= > >tech.edu
>=3B Subject: [M3devel] quick question for the Modula-3 ether= > >... LONGFLOAT??
>=3B
>=3B
>=3B Does anyone out there have = > >any idea why a lot of bits of Modula-3
>=3B refer to something called = > >"LONGFLOAT" or "LongFloat". I just checked
>=3B Wirth=2C and Modula-2 = > >used "REAL" as well so it doesn't seem like
>=3B LONGREAL would ever h= > >ave been called "LONGFLOAT".
>=3B
>=3B Is LONGFLOAT/LongFloat of= > > any significance or is it OK to
>=3B search-and-replace it away with = > >LONGREAL/LongReal everywhere?
>=3B
>=3B (I'm talking about thing= > >s like the emacs macro package as well as
>=3B all over m3tk...)
&g= > >t=3B
>=3B Mika
> >= > > > >--_eaf98d33-2bbc-4e5b-8afc-bc1f32079c51_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.m.bates at cox.net Mon Apr 13 04:12:34 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Sun, 12 Apr 2009 21:12:34 -0500 Subject: [M3devel] small objects In-Reply-To: <200904101918.n3AJIcLj003231@camembert.async.caltech.edu> References: <200904101918.n3AJIcLj003231@camembert.async.caltech.edu> Message-ID: <49E29F92.7000808@cox.net> Mika Nystrom wrote: > Sigh, I hate sending so many emails to a mailing list. Sorry about > the inboxes I'm clogging of people with no interest in this. > > But I just realized something important, which I think may be > decisive in deciding the fate of the name "REFANY" in the addition > of new types. > > Rodney proposes > > TAGGED T <: TAGGED REFANY > No. I am specifically proposing that TAGGED T and TAGGED U have _no_ subtype relation, when T #U. Putting the tagged types into their own hierarchy creates a big complicated subtype mess, with both two hierarchies on the one hand and subtype cross-links between them on the other hand. I also really calls for a new, complex structural type equality rule that is very out of sync with the existing type equality rule. > T <: REFANY <: TAGGED REFANY > > I propose > > TAGGED T <: REFANY > T <: UNTAGGEDREFANY <: REFANY > > Both proposals are identical in the power of the language that > results, because they differ merely in naming. > > Both proposals are also backward-compatible: all existing Modula-3 > programs are unchanged by them. > > However, UNTAGGEDREFANY (mine), is *forward*-compatible as well > as backward-compatible. > > Think about it. The TAGGED REFANY proposal will have the following > effect: people will go through all the M3 libraries and replace > every or almost every occurrence of REFANY with TAGGED REFANY. The > resulting code will not compile with an older compiler! > > In my proposal, it is the user of the TAGGED types who is responsible > for---in new code only!---deciding whether he wants his code to > compile both on older and newer M3 systems. If he does, then he > can add appropriate implementations for compilers that don't support > the TAGGED types (which will be trivial since he has to have those > anyway!) The burden of handling change is on the programmer of the > special new feature rather than on everyone who has a container > module. > Well, I do see how this certain class of uses of REFANY could have their meaning changed in this way, with no required editing of source code. But it reminds me of the joke that real programmers don't fix their code, they just patch the compiler. Despite my strong belief in the ability to have portable code, I think it is a terrible thing to have the same code have fundamentally different semantics when compiled by different compilers, even if you can cite a large class of uses for which this semantic change happens to be handy. For portable container data structures between pre/post tagged Modula-3, declare a type in one place and change it in that one place: TYPE MostGeneralContainerElement = REFANY. or TYPE MostGeneralContainerElement = TAGGED REFANY. Then have all the containter ADTs equate their element type to this. It is also a glaring inconsistency to have all reference types other than REFANY to be untagged by default and made tagged by an explicit TAGGED, while REFANY defaults the other way around. > I'll try to refrain from posting any more messages on this topic now. > > Mika > > "Rodney M. Bates" writes: > >> Mika Nystrom wrote: >> >>> Sorry to splice together two emails from you, but I feel I've already >>> used up my m3devel quota this week: >>> >>> "Rodney M. Bates" writes: >>> >>> >>>>> Are you sure? I want a type---some type---that can hold "any >>>>> reference, even a tagged one", and I would rewrite most library >>>>> code that today takes REFANY to take that instead. Why not? Why >>>>> would I want to limit it to REFANY when it performs no operations >>>>> that couldn't legally be performed on TAGGED REFANY. >>>>> >>>>> >>>>> >>>> I believe my "safe" proposal would make this very simple, if I am >>>> thinking of the kind of library code you are. >>>> >>>> I envision a container data structure that takes in things and returns >>>> them without performing operations on them other than moving them around >>>> and storing them, e.g. the ever belabored stack. The values going in >>>> and out are declared REFANY, and the client passes in values of >>>> some proper subtype of REFANY, which get assigned to the REFANY >>>> parameters. When it gets them back, it narrows them to this type. >>>> >>>> In this pattern, just changing the declared type of the container values >>>> >>>> >>> >from REFANY to TAGGED REFANY would do it. The library code's storage >>> ... >>> >>> >> There are two very different kinds of uses of reference and >> tagged types. The one I speak of above is for the type of the >> elements inside a container data structure. In this case, it >> is the client that knows what type the value really is, and will >> declare it as such. The library ADT module should know as little >> as possible about it, so it will declare it as REFANY or >> TAGGED REFANY. Here, you want the most general type >> possible, just to make the abstraction more versatile. >> And TAGGED REFANY generalizes it from REFANY. >> >> But... >> >>> >>> >> >>>>> you'd like to store these in a REFANY and dynamically test for the >>>>> appropriate tagged type: >>>>> >>>>> >>>> No, I do not want to store these in a variable of type REFANY or any >>>> other existing type. >>>> In fact, I want to forbid it. >>>> >>>> >>> I think you are thinking of exactly the same kind of library code. >>> TextRefTbl.T, RefList.T, etc. >>> >>> After the introduction of TAGGED REFANY, what use is there for >>> REFANY? What piece of code can you think of where the cost of the >>> 1-LSB check of TAGGED REFANY outweighs the convenience of being >>> able to process objects of type TAGGED T (for all ref types T) as >>> well as objects of type T? >>> >>> >> The other use is for the abstract type itself. Forgetting tagged >> types for a moment, I have never seen an interface/module that >> uses REFANY for this. Instead, the modules declare their abstract >> type as some proper subtype of REFANY, usually an opaque type. >> >> It would be possible to use just REFANY here of course, but that would >> require an otherwise unnecessary RT check on the allocated type, >> every time an operation of the module is called. This is a much >> more expensive check than a tag check, as has been pointed out >> in this discussion. >> >> But worse, it would sacrifice the static checking that we now have >> that prevents, at compile time, clients from passing, say a Text.T >> to some procedure in Atom that expects an Atom.T. If these modules >> ever wanted to use a tagged type, but the only tagged type were >> REFANY, we would lose this static checking, because Text.T would >> have to become equal to Atom.T. >> >> In cases where your algorithms don't specifically need dynamic >> typing, static typing is always much better, because one run of >> the compiler on the source code will do it. Bugs checked >> only at runtime require a massive test suit to be coded and then >> regularly rerun to get even close to the same confidence they've >> been found. >> >> So when using tagged types as the ADT itself,, we need to be able >> to have a tagged version of whatever proper subtype of REFANY >> the abstraction needs, including an opaque subtype of REFANY >> or an opaque subtype of some Public subtype of REFANY. This is >> why I am adamant that we need to be able to build a tagged type >> > >from any traced or object type. > >> And once you do this, keeping REFANY itself unchanged and allowing >> TAGGED REFANY as one case of a tagged type falls out of the system >> for free _and_ saves a lot of cases that would otherwise need a new RT >> check that can never fail, but the language can't know that, because >> the type system has lost the distinction. >> >> I really feel that the fad of all dynamic typing in languages is a huge >> mistake and that it will someday be recognized as such. In the >> meantime, we have a language that provides a very extensive set >> of statically-typed alternatives, while also allowing dynamic typing >> when you really need it. This is one of Modula-3's best principles. >> Let's don't erode the static alternatives unnecessarily. >> >> >>> Mika >>> >>> >>> > > From rodney.m.bates at cox.net Mon Apr 13 04:12:29 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Sun, 12 Apr 2009 21:12:29 -0500 Subject: [M3devel] small objects In-Reply-To: <200904101902.n3AJ27UI002559@camembert.async.caltech.edu> References: <200904101902.n3AJ27UI002559@camembert.async.caltech.edu> Message-ID: <49E29F8D.9040103@cox.net> Mika Nystrom wrote: > Specific proposal. > > What Rodney said, *except* make REFANY the root of everything. > Insert an untagged root with a new name. > > Rodney himself has said that the uses of REFANY he knows about would > be changed to accept the TAGGED type, No, not all of them. Just those that are the element type of general-purpose container data types. > so I simply propose allowing > REFANY to handle the TAGGED type by default, and insert a new root > for the untagged types. The structure of the type hierarchy is > exactly the same as in Rodney's proposal, but the different naming > makes it more backward-compatible. > > ROOT <: UNTAGGEDREFANY > T <: UNTAGGEDREFANY > > UNTAGGEDREFANY <: REFANY > > and finally. > > TAGGED T <: REFANY (* for all T *) > > The advantages with this proposal are that it does precisely what > Rodney is asking for (typesafe ADTs), but it's compatible with > Tony's runtime changes in the *current* M3 implementation and it > won't require anyone to do a massive search and replace, replacing > REFANY with "TAGGED REFANY" in every existing Modula-3 program. > > Supposed disadvantage: every TYPECASE, NARROW, etc., of REFANY will > cost an extra LSB check. Those who feel strongly about that and > for some reason *know* that they don't want to process TAGGED types > (which may be the empty set), can modify their code to use > UNTAGGEDREFANY instead of REFANY. > I am still not sure we are communicating. I am proposing that _only_ the tagged types, i.e., those constructed by TAGGED T, for T a traced or object type, can have a LSB nonzero. So TYPECASE and friends will not have an LSB check when applied to T, only when applied to TAGGED T. > Mika > > "Rodney M. Bates" writes: > >> Mika Nystrom wrote: >> >>> Sorry to splice together two emails from you, but I feel I've already >>> used up my m3devel quota this week: >>> >>> "Rodney M. Bates" writes: >>> >>> >>>>> Are you sure? I want a type---some type---that can hold "any >>>>> reference, even a tagged one", and I would rewrite most library >>>>> code that today takes REFANY to take that instead. Why not? Why >>>>> would I want to limit it to REFANY when it performs no operations >>>>> that couldn't legally be performed on TAGGED REFANY. >>>>> >>>>> >>>>> >>>> I believe my "safe" proposal would make this very simple, if I am >>>> thinking of the kind of library code you are. >>>> >>>> I envision a container data structure that takes in things and returns >>>> them without performing operations on them other than moving them around >>>> and storing them, e.g. the ever belabored stack. The values going in >>>> and out are declared REFANY, and the client passes in values of >>>> some proper subtype of REFANY, which get assigned to the REFANY >>>> parameters. When it gets them back, it narrows them to this type. >>>> >>>> In this pattern, just changing the declared type of the container values >>>> >>>> >>> >from REFANY to TAGGED REFANY would do it. The library code's storage >>> ... >>> >>> >> There are two very different kinds of uses of reference and >> tagged types. The one I speak of above is for the type of the >> elements inside a container data structure. In this case, it >> is the client that knows what type the value really is, and will >> declare it as such. The library ADT module should know as little >> as possible about it, so it will declare it as REFANY or >> TAGGED REFANY. Here, you want the most general type >> possible, just to make the abstraction more versatile. >> And TAGGED REFANY generalizes it from REFANY. >> >> But... >> >>> >>> >> >>>>> you'd like to store these in a REFANY and dynamically test for the >>>>> appropriate tagged type: >>>>> >>>>> >>>> No, I do not want to store these in a variable of type REFANY or any >>>> other existing type. >>>> In fact, I want to forbid it. >>>> >>>> >>> I think you are thinking of exactly the same kind of library code. >>> TextRefTbl.T, RefList.T, etc. >>> >>> After the introduction of TAGGED REFANY, what use is there for >>> REFANY? What piece of code can you think of where the cost of the >>> 1-LSB check of TAGGED REFANY outweighs the convenience of being >>> able to process objects of type TAGGED T (for all ref types T) as >>> well as objects of type T? >>> >>> >> The other use is for the abstract type itself. Forgetting tagged >> types for a moment, I have never seen an interface/module that >> uses REFANY for this. Instead, the modules declare their abstract >> type as some proper subtype of REFANY, usually an opaque type. >> >> It would be possible to use just REFANY here of course, but that would >> require an otherwise unnecessary RT check on the allocated type, >> every time an operation of the module is called. This is a much >> more expensive check than a tag check, as has been pointed out >> in this discussion. >> >> But worse, it would sacrifice the static checking that we now have >> that prevents, at compile time, clients from passing, say a Text.T >> to some procedure in Atom that expects an Atom.T. If these modules >> ever wanted to use a tagged type, but the only tagged type were >> REFANY, we would lose this static checking, because Text.T would >> have to become equal to Atom.T. >> >> In cases where your algorithms don't specifically need dynamic >> typing, static typing is always much better, because one run of >> the compiler on the source code will do it. Bugs checked >> only at runtime require a massive test suit to be coded and then >> regularly rerun to get even close to the same confidence they've >> been found. >> >> So when using tagged types as the ADT itself,, we need to be able >> to have a tagged version of whatever proper subtype of REFANY >> the abstraction needs, including an opaque subtype of REFANY >> or an opaque subtype of some Public subtype of REFANY. This is >> why I am adamant that we need to be able to build a tagged type >> > >from any traced or object type. > >> And once you do this, keeping REFANY itself unchanged and allowing >> TAGGED REFANY as one case of a tagged type falls out of the system >> for free _and_ saves a lot of cases that would otherwise need a new RT >> check that can never fail, but the language can't know that, because >> the type system has lost the distinction. >> >> I really feel that the fad of all dynamic typing in languages is a huge >> mistake and that it will someday be recognized as such. In the >> meantime, we have a language that provides a very extensive set >> of statically-typed alternatives, while also allowing dynamic typing >> when you really need it. This is one of Modula-3's best principles. >> Let's don't erode the static alternatives unnecessarily. >> >> >>> Mika >>> >>> >>> > > From jay.krell at cornell.edu Mon Apr 13 11:46:22 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 13 Apr 2009 09:46:22 +0000 Subject: [M3devel] pieces of TARGET? Message-ID: We have: TARGET= NT386, LINUXLIBC6, AMD64_DARWIN, etc. OS_TYPE= Win32 or POSIX I added HOST, HOST_OS_TYPE, etc. We should also have TARGET_ARCHITECTURE=X86,AMD64,SPARC32,SPARC64,PPC32,PPC64,MIP32,MIP64,etc. probably defined be whatever preceded the first underscore in new consistently named targets (X86 or I386?) Because already have WORD_SIZE, can probably refine this to just: X86,AMD64,SPARC,PPC,MIPS, no general need for "32" and "64" variants. (I hesitate to point out that neither ALPHA nor IA64 imply WORD_SIZE=64. NT on Alpha had 32bit and 64bit variants, HP-UX on IA64 ditto for usermode). Maybe even can drop AMD64 from this list. TARGET_OS or TARGET_KERNEL or somesuch=NT,LINUX,SOLARIS,DARWIN,CYGWIN, etc. probably defined to be whatever follows the lone underscore in new consistently named targets, with a single underscore Leaving unspecified what to do about ARM and its competing calling conventions and C runtimes Then we can check, for example, if TARGET_OS == "FREEBSD" and get all architectures at once. There isn't a huge need for this, but some. Besides, TARGET_ENDIAN= BIG or LITTLE should probably be exposed. You know, if you look at the lists of platforms, both in Target.m3 and the various m3makefiles, sometimes they can be shortened. Sometimes all that is needed is the "OS" (e.g. the time/date stuff) or the endian or architecture(the float stuff). I realize there aren't tons of these lists, so it's not a huge deal. Let me know if any objections are strong opinions on nailing some of the details. My biggest objection is there is always a lag from the time compiler changes are in, until you can/should depend on them. Building newer code with older compiler and such. It makes it such that it seems sometimes not worth changing anything. Thanks, - Jay From wagner at elegosoft.com Mon Apr 13 12:51:48 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 13 Apr 2009 12:51:48 +0200 Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN In-Reply-To: References: <20090411105512.92784fp7cc0o448k@mail.elegosoft.com> Message-ID: <20090413125148.vxbxs7ftessckwko@mail.elegosoft.com> Quoting Jay : > > My machine calls itself: > > jbook15:~ jay$ uname -a > Darwin jbook15.local 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 > 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh > powerpc > > That is 10.4.something. It works ok. cm3cg built as recently as 4/10.. So it seems OK for newer MacOS X releases. I worked around it here by continuning to use an older backend, which seems OK for now. Doing a realclean and a complete rebuild, I got syntax errors with some pattern substitution in a Makefile, and the build stopped. I'll try a newer backend compiled on another machine, too. Olaf > - Jay > > > ________________________________ >> From: jay >> To: wagner; m3devel >> Subject: RE: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN >> Date: Sat, 11 Apr 2009 12:03:39 +0000> >> >> I do test on 10.4 fairly often... > >> It sounds like 7.9.0 is 10.3? >> >> >> - Jay >> >>> Date: Sat, 11 Apr 2009 10:55:12 +0200 >>> From: wagner@ >>> To: m3devel@ >>> Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN >>> >>> After trying to upgrade cm3 on my notebook to the latest version, >>> I get lots of internal compiler errors.This is on >>> >>> % uname -a >>> Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 >>> 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power >>> Macintosh powerpc >>> >>> ... -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 13 12:56:40 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 13 Apr 2009 12:56:40 +0200 Subject: [M3devel] cvsup and "flags" In-Reply-To: References: Message-ID: <20090413125640.58q2uf7spw0w844o@mail.elegosoft.com> Quoting Jay : > > Um, these "flags" that cvsup is willing to traffic: > > 1) They are the same between machines that support them? > Maybe, maybe not, I can check. > > 2) They are actually interesting? Given that many operating > systems (e.g. Linux, Solaris) don't support them? Yes, they are interesting and important, since they are in use at many sites. They're not portable as far as I know though. The system immutable flag is used by many FreeBSD installations to further protect from accidental and unauthorized changes. > They seem a little dubious. > I suppose most cvsup users have both client and server on FreeBSD > and if the FreeBSD source itself needs these flags on source > controled files, it is useful. > > Even storing an executable bit in cvs seems not portable..but that > is a different set of flags. (NTFS ACL should be reasonable > superset, but then, FAT?) POSIX file access control lists should be portable to a certain degree. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 13 12:58:30 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 13 Apr 2009 10:58:30 +0000 Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN In-Reply-To: <20090413125148.vxbxs7ftessckwko@mail.elegosoft.com> References: <20090411105512.92784fp7cc0o448k@mail.elegosoft.com> <20090413125148.vxbxs7ftessckwko@mail.elegosoft.com> Message-ID: > I got syntax errors with > some pattern substitution in a Makefile, and the build stopped. make vs. gmake? - Jay ---------------------------------------- > Date: Mon, 13 Apr 2009 12:51:48 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN > > Quoting Jay : > >> >> My machine calls itself: >> >> jbook15:~ jay$ uname -a >> Darwin jbook15.local 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 >> 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh >> powerpc >> >> That is 10.4.something. It works ok. cm3cg built as recently as 4/10.. > > So it seems OK for newer MacOS X releases. I worked around it here by > continuning to use an older backend, which seems OK for now. > Doing a realclean and a complete rebuild, I got syntax errors with > some pattern substitution in a Makefile, and the build stopped. > > I'll try a newer backend compiled on another machine, too. > > Olaf > >> - Jay >> >> >> ________________________________ >>> From: jay >>> To: wagner; m3devel >>> Subject: RE: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN >>> Date: Sat, 11 Apr 2009 12:03:39 +0000> >>> >>> I do test on 10.4 fairly often... >> >>> It sounds like 7.9.0 is 10.3? >>> >>> >>> - Jay >>> >>>> Date: Sat, 11 Apr 2009 10:55:12 +0200 >>>> From: wagner@ >>>> To: m3devel@ >>>> Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN >>>> >>>> After trying to upgrade cm3 on my notebook to the latest version, >>>> I get lots of internal compiler errors.This is on >>>> >>>> % uname -a >>>> Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 >>>> 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power >>>> Macintosh powerpc >>>> >>>> ... > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 13 13:04:58 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 13 Apr 2009 11:04:58 +0000 Subject: [M3devel] cvsup and "flags" In-Reply-To: <20090413125640.58q2uf7spw0w844o@mail.elegosoft.com> References: <20090413125640.58q2uf7spw0w844o@mail.elegosoft.com> Message-ID: It's a little different to say "these flags are useful" vs. "I should be able to store these flags in source control". Not entirely different, but somewhat. If you need them in source control, then you need your source control system to bother with system-dependent possibly esoteric features. On the other hand, if nobody every catered to good system-dependent aspects, a lot of things would be a lot worse. I only skimmed the cvsup source a little, but I think it traffics in plain integers. It would be smarter to traffic in the "name" of the flag, and the "OS name" it originated from..and maybe allow some "required" vs. "optional" bit. That way, if Darwin and FreeBSD both had the flag "FOO", it hopefully/probably means the same on each, but could be "translated" into the proper integer. And if user deemed flag "FOO" important than cvsup could error for updates to a system that doesn't support it. Maybe it already does do these things though. Some people use "source control" for keep track of and backup their "system configuration" or perhaps their entire "system install". Whereas most people just store a bunch of text files. There can be quite a difference -- e.g. support for hardlinks, symlinks, owner user, owner group, etc.. Folks just storing textual source files tend to have lighter requirements. (which reminds me -- can you clear the executable bit on the vast majority of non-directories in the tree, like outside of scripts/*.sh and scripts/*.py) - Jay ---------------------------------------- > Date: Mon, 13 Apr 2009 12:56:40 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] cvsup and "flags" > > Quoting Jay : > >> >> Um, these "flags" that cvsup is willing to traffic: >> >> 1) They are the same between machines that support them? >> Maybe, maybe not, I can check. >> >> 2) They are actually interesting? Given that many operating >> systems (e.g. Linux, Solaris) don't support them? > > Yes, they are interesting and important, since they are in use > at many sites. They're not portable as far as I know though. > > The system immutable flag is used by many FreeBSD installations to > further protect from accidental and unauthorized changes. > >> They seem a little dubious. >> I suppose most cvsup users have both client and server on FreeBSD >> and if the FreeBSD source itself needs these flags on source >> controled files, it is useful. >> >> Even storing an executable bit in cvs seems not portable..but that >> is a different set of flags. (NTFS ACL should be reasonable >> superset, but then, FAT?) > > POSIX file access control lists should be portable to a certain degree. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 13 13:07:20 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 13 Apr 2009 13:07:20 +0200 Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN In-Reply-To: References: <20090411105512.92784fp7cc0o448k@mail.elegosoft.com> <20090413125148.vxbxs7ftessckwko@mail.elegosoft.com> Message-ID: <20090413130720.aziv5e0fggwgccw0@mail.elegosoft.com> Quoting Jay : > >> I got syntax errors with >> some pattern substitution in a Makefile, and the build stopped. > > make vs. gmake? Maybe (log attached). But shouldn't configure be able to figure this out by itself? GNU make is /usr/bin/gnumake on this system (Fink packages). Olaf > - Jay > > > > ---------------------------------------- >> Date: Mon, 13 Apr 2009 12:51:48 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN >> >> Quoting Jay : >> >>> >>> My machine calls itself: >>> >>> jbook15:~ jay$ uname -a >>> Darwin jbook15.local 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 >>> 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh >>> powerpc >>> >>> That is 10.4.something. It works ok. cm3cg built as recently as 4/10.. >> >> So it seems OK for newer MacOS X releases. I worked around it here by >> continuning to use an older backend, which seems OK for now. >> Doing a realclean and a complete rebuild, I got syntax errors with >> some pattern substitution in a Makefile, and the build stopped. >> >> I'll try a newer backend compiled on another machine, too. >> >> Olaf >> >>> - Jay >>> >>> >>> ________________________________ >>>> From: jay >>>> To: wagner; m3devel >>>> Subject: RE: [M3devel] Internal compiler errors after upgrade on >>>> PPC_DARWIN >>>> Date: Sat, 11 Apr 2009 12:03:39 +0000> >>>> >>>> I do test on 10.4 fairly often... >>> >>>> It sounds like 7.9.0 is 10.3? >>>> >>>> >>>> - Jay >>>> >>>>> Date: Sat, 11 Apr 2009 10:55:12 +0200 >>>>> From: wagner@ >>>>> To: m3devel@ >>>>> Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN >>>>> >>>>> After trying to upgrade cm3 on my notebook to the latest version, >>>>> I get lots of internal compiler errors.This is on >>>>> >>>>> % uname -a >>>>> Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 >>>>> 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power >>>>> Macintosh powerpc >>>>> >>>>> ... >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 -------------- --- building in PPC_DARWIN --- ignoring ../src/m3overrides cd . && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: configure-host | tee -a _m3.log cd . && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: configure-host | tee -a _m3.log make all-recursive Making all in tests Making all in . make[4]: Nothing to be done for `all-am'. Making all in devel make[4]: Nothing to be done for `all'. Making all in mpn make[4]: Nothing to be done for `all'. Making all in mpz make[4]: Nothing to be done for `all'. Making all in mpq make[4]: Nothing to be done for `all'. Making all in mpf make[4]: Nothing to be done for `all'. Making all in rand make[4]: Nothing to be done for `all'. Making all in misc make[4]: Nothing to be done for `all'. Making all in cxx make[4]: Nothing to be done for `all'. Making all in mpbsd make[4]: Nothing to be done for `all'. Making all in mpn make[3]: Nothing to be done for `all'. Making all in mpz make[3]: Nothing to be done for `all'. Making all in mpq make[3]: Nothing to be done for `all'. Making all in mpf make[3]: Nothing to be done for `all'. Making all in printf make[3]: Nothing to be done for `all'. Making all in scanf make[3]: Nothing to be done for `all'. Making all in cxx make[3]: Nothing to be done for `all'. Making all in mpbsd make[3]: Nothing to be done for `all'. Making all in demos Making all in calc make all-am make[5]: Nothing to be done for `all-am'. Making all in expr make[4]: Nothing to be done for `all'. make[4]: Nothing to be done for `all-am'. Making all in tune make[3]: Nothing to be done for `all'. Making all in doc make[3]: Nothing to be done for `all'. make[3]: Nothing to be done for `all-am'. sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./gcc/Makefile > ./gcc/Makefile.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./gcc/Makefile > ./gcc/Makefile.1 ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./gcc/Makefile > ./gcc/Makefile.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./gcc/Makefile > ./gcc/Makefile.1 ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile sed -e 's/^#define HAVE_ICONV 1$//' < ./gcc/Makefile > ./gcc/Makefile.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./gcc/Makefile > ./gcc/Makefile.1 ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile sed -e 's/^#define HAVE_ICONV_H 1$//' < ./gcc/Makefile > ./gcc/Makefile.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./gcc/Makefile > ./gcc/Makefile.1 ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h sed -e 's/^#define HAVE_ICONV 1$//' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h sed -e 's/^#define HAVE_ICONV_H 1$//' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./libcpp/Makefile > ./libcpp/Makefile.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./libcpp/Makefile > ./libcpp/Makefile.1 ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./libcpp/Makefile > ./libcpp/Makefile.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./libcpp/Makefile > ./libcpp/Makefile.1 ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile sed -e 's/^#define HAVE_ICONV 1$//' < ./libcpp/Makefile > ./libcpp/Makefile.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./libcpp/Makefile > ./libcpp/Makefile.1 ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile sed -e 's/^#define HAVE_ICONV_H 1$//' < ./libcpp/Makefile > ./libcpp/Makefile.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./libcpp/Makefile > ./libcpp/Makefile.1 ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./libcpp/config.h > ./libcpp/config.h.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./libcpp/config.h > ./libcpp/config.h.1 ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./libcpp/config.h > ./libcpp/config.h.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./libcpp/config.h > ./libcpp/config.h.1 ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h sed -e 's/^#define HAVE_ICONV 1$//' < ./libcpp/config.h > ./libcpp/config.h.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./libcpp/config.h > ./libcpp/config.h.1 ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h sed -e 's/^#define HAVE_ICONV_H 1$//' < ./libcpp/config.h > ./libcpp/config.h.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./libcpp/config.h > ./libcpp/config.h.1 ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./mpfr/Makefile > ./mpfr/Makefile.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./mpfr/Makefile > ./mpfr/Makefile.1 ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./mpfr/Makefile > ./mpfr/Makefile.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./mpfr/Makefile > ./mpfr/Makefile.1 ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile sed -e 's/^#define HAVE_ICONV 1$//' < ./mpfr/Makefile > ./mpfr/Makefile.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./mpfr/Makefile > ./mpfr/Makefile.1 ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile sed -e 's/^#define HAVE_ICONV_H 1$//' < ./mpfr/Makefile > ./mpfr/Makefile.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./mpfr/Makefile > ./mpfr/Makefile.1 ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile sed -e 's/^#define HAVE_ICONV 1$//' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile sed -e 's/^#define HAVE_ICONV_H 1$//' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile cd . && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: all-gmp all-mpfr all-build-libiberty all-libiberty all-libdecnumber | tee -a _m3.log cd . && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: all-gmp all-mpfr all-build-libiberty all-libiberty all-libdecnumber | tee -a _m3.log make all-recursive Making all in tests Making all in . make[4]: Nothing to be done for `all-am'. Making all in devel make[4]: Nothing to be done for `all'. Making all in mpn make[4]: Nothing to be done for `all'. Making all in mpz make[4]: Nothing to be done for `all'. Making all in mpq make[4]: Nothing to be done for `all'. Making all in mpf make[4]: Nothing to be done for `all'. Making all in rand make[4]: Nothing to be done for `all'. Making all in misc make[4]: Nothing to be done for `all'. Making all in cxx make[4]: Nothing to be done for `all'. Making all in mpbsd make[4]: Nothing to be done for `all'. Making all in mpn make[3]: Nothing to be done for `all'. Making all in mpz make[3]: Nothing to be done for `all'. Making all in mpq make[3]: Nothing to be done for `all'. Making all in mpf make[3]: Nothing to be done for `all'. Making all in printf make[3]: Nothing to be done for `all'. Making all in scanf make[3]: Nothing to be done for `all'. Making all in cxx make[3]: Nothing to be done for `all'. Making all in mpbsd make[3]: Nothing to be done for `all'. Making all in demos Making all in calc make all-am make[5]: Nothing to be done for `all-am'. Making all in expr make[4]: Nothing to be done for `all'. make[4]: Nothing to be done for `all-am'. Making all in tune make[3]: Nothing to be done for `all'. Making all in doc make[3]: Nothing to be done for `all'. make[3]: Nothing to be done for `all-am'. Making all in tests make[2]: Nothing to be done for `all'. make[2]: Nothing to be done for `all-am'. make[2]: Nothing to be done for `all'. make[2]: Nothing to be done for `all'. make[1]: Nothing to be done for `all'. cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a _m3.log cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a _m3.log Makefile:191: *** Insufficient number of arguments (2) to function `patsubst'. Stop. cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a _m3.log cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a _m3.log Makefile:4437: *** Insufficient number of arguments (2) to function `patsubst'. Stop. "/Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile", line 463: quake runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2 --procedure-- -line- -file--- cp_if -- postcp 463 /Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile include_dir 529 /Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile 4 /Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args Fatal Error: package build failed From wagner at elegosoft.com Mon Apr 13 13:12:00 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 13 Apr 2009 13:12:00 +0200 Subject: [M3devel] cvsup and "flags" In-Reply-To: References: <20090413125640.58q2uf7spw0w844o@mail.elegosoft.com> Message-ID: <20090413131200.aai00p9vk44cgc00@mail.elegosoft.com> Well, yes, that's all correct, but CVSup is not only a CVS mirroring tool, as its name suggest, but also a general efficient file replication tool (which can be used to replicate whole systems). We should try to keep all of its functionality (improvements possible, of course). Olaf Quoting Jay : > > It's a little different to say "these flags are useful" vs. > "I should be able to store these flags in source control". > Not entirely different, but somewhat. > > > If you need them in source control, then you need your source control > system to bother with system-dependent possibly esoteric features. > On the other hand, if nobody every catered to good system-dependent > aspects, a lot of things would be a lot worse. > > > I only skimmed the cvsup source a little, but I think it traffics > in plain integers. It would be smarter to traffic in the "name" > of the flag, and the "OS name" it originated from..and maybe allow > some "required" vs. "optional" bit. That way, if Darwin and FreeBSD > both had the flag "FOO", it hopefully/probably means the same on each, > but could be "translated" into the proper integer. And if user deemed > flag "FOO" important than cvsup could error for updates to a system > that doesn't support it. Maybe it already does do these things though. > > > Some people use "source control" for keep track of and backup > their "system configuration" or perhaps their entire "system install". > Whereas most people just store a bunch of text files. > There can be quite a difference -- e.g. support for hardlinks, symlinks, > owner user, owner group, etc.. > > > Folks just storing textual source files tend to have lighter requirements. > (which reminds me -- can you clear the executable bit on the vast > majority of non-directories in the tree, like outside of > scripts/*.sh and scripts/*.py) > > > - Jay > > > ---------------------------------------- >> Date: Mon, 13 Apr 2009 12:56:40 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] cvsup and "flags" >> >> Quoting Jay : >> >>> >>> Um, these "flags" that cvsup is willing to traffic: >>> >>> 1) They are the same between machines that support them? >>> Maybe, maybe not, I can check. >>> >>> 2) They are actually interesting? Given that many operating >>> systems (e.g. Linux, Solaris) don't support them? >> >> Yes, they are interesting and important, since they are in use >> at many sites. They're not portable as far as I know though. >> >> The system immutable flag is used by many FreeBSD installations to >> further protect from accidental and unauthorized changes. >> >>> They seem a little dubious. >>> I suppose most cvsup users have both client and server on FreeBSD >>> and if the FreeBSD source itself needs these flags on source >>> controled files, it is useful. >>> >>> Even storing an executable bit in cvs seems not portable..but that >>> is a different set of flags. (NTFS ACL should be reasonable >>> superset, but then, FAT?) >> >> POSIX file access control lists should be portable to a certain degree. >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Mon Apr 13 13:34:13 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 13 Apr 2009 13:34:13 +0200 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> Message-ID: <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> Well, that's a quite long list; but many things are bug fixes anyway, and wouldn't be affected by a code freeze, while others are already finished (as integrating CVSup, as I understand). The only thing we should not do is introduce new platforms while trying to get the system stable. We should concentrate on installation support and bug fixing. I'd suggest to start the release process in about two weeks at the start of May. That should give everybody enough time to either finish their ongoing work that shall make it into the release or decide to postpone it ;-) Any objections? Olaf Quoting Jay : > > > > o When should we start? I.e. wha changes would you like to complete > > > before we start the release process? > > > > > I'd like to see the formsvbt crash debugged and fixed, unless I'm > the only one seeing it. > > I only see it on Solaris and PPC_DARWIN but haven't tried "everything". > > I'll try to get this. > > > > > > I'd also like to see: > > > > > > FreeBSD/x86 switched to the new Unix/*.i3 files. I'll do this. > > Maybe also I386_DARWIN, AMD64_DARWIN, but I don't have the hardware. > > > > > > $ORIGIN/LD_LIBRARY_PATH resolved a bit further, probably very > little work (I'll do this). > > Basically just 1) put buildlocal back how it was 2) push it across > more platforms e.g. I think FreeBSD/x86 is the main one missing, > but I'll get to it. > > > > > > cvsup building and in "std" (I'll do this, probably very little > left here really. > > > > > > -- beyond this, not required for release -- > > > > > > Maybe more AMD64 releases, e.g. NetBSD and Solaris. (If I get to it). > > (could be "mingw64" is good enough to try AMD64_NT now). > > > > > > Maybe update gmp/mpfr to fix the "maintainer" problem. (not likely by me) > > > > > > Maybe more new/resuscitated platforms..HPPA64_HPUX, IA64_*, *_VMS, > ALPHA_*, ARM_*, *_IRIX, *_AIX, MIPS64_*.... but these take back > seat to important fixes in existing platforms. > > > > > > Fix NT386 to use setjmp3 instead of setjmp so exceptions don't > skip C __finally blocks. I've just been very lazy here, should > demonstrate the behavior with a test case, then fix it.. > > > > > > Maybe fix cm3cg so other -g options besides -gstabs works, like > plain -g, -ggdb, on at least one platform -gstabs isn't supported, > leaving nothing, because others cause internal compiler errors, like > on HPPA64_HPUX. > > > > > > Oh, and NT386GNU probably switched back to Win32 threads. > Otherwise one of the test cases hangs and it doesn't look easy to > figure out. I'll do this shortly if I remember. > > But I also wouldn't mind if this platform isn't officially released > either (unless someone else wants to support it). > > > > > > Debug why many NT386MINGNU gui apps crash..but also probably just > don't release this platform and ok asis. > > > > > > - 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 hendrik at topoi.pooq.com Mon Apr 13 17:08:54 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 13 Apr 2009 11:08:54 -0400 Subject: [M3devel] FW: cvsup In-Reply-To: References: Message-ID: <20090413150854.GA32577@topoi.pooq.com> On Sun, Apr 12, 2009 at 11:34:49AM +0000, Jay wrote: > > [truncated again..] > > cvsup builds and starts up on a few platforms now, > including Cygwin/x86, Linux/x86, Linux/AMD64 (birch), > Macosx/PowerPC, FreeBSD/x86. I can verify more later.. > > > I expect there might be problems on Macosx/x86 and AMD64. > And FreeBSD/x86 might not work until I commit the change to use Unix/common. > That is -- these are the only platforms not using Unix/common. > > > Some platforms store extra "flags" with files -- Darwin and *BSD. > see man chflags and man 2 chflags. > Historically cvsup only get/sets those on FreeBSD. > I extended that to the others, though didn't build NetBSD/OpenBSD. > (nor have I tested any of the functionality at all..) > The source should be refactored some in this regard, the "FreeBSD" > directory split into "FreeBSD" and "flags" or something. But > I don't like moving files since history might not track well. > (I also chose "m3-tools" arbitrarily..) > > > It might not even have to be refactored -- instead of the static platform checks, the code can check of the #defines in Ustat are zero or not, and UstatC.c can provide empty chflags/fchflags functions instead of none at all. It's a tricky area though in terms of what is best, providing no functions, vs. providing functions that do nothing and succeed, vs. providing functions that do nothing and fail, vs. providing a more explicit way to query if the functionality is provided, as well as deciding between build-time vs. run-time checks (we don't have anything like autoconf in our system, for better and worse). > > > Now hopefully we can switch to svn or monotone and cvsup won't matter to us. :) > (Well, I never use it in any case. I know it is big in FreeBSD-land.) Yes, monotone... I'm trying to organise putting together the monotone repository, and it seems that the first thing to do is to get a local copy of the existing modula 3 CVS repository to experiment on. There are at least two ways to go about putting the monotone repository together, on of them seems to requre me to have a local copy of the repository. I suspect I need to get cvsup running to make this local copy of the CVS. Where should I get cvsup? (It doesn't seem to be distributed as a Debian package; perhaps that's because Modula 3 ins't either?) Did you make changes to cvsup to get it to work on current versions of Modula 3? If so I should probably get the changed version. Or else maybe someone could make a .tgz file out of the entire cm3 CVS and I could download and work with that? -- hendrik From hendrik at topoi.pooq.com Mon Apr 13 21:20:06 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 13 Apr 2009 15:20:06 -0400 Subject: [M3devel] FW: cvsup In-Reply-To: <20090413150854.GA32577@topoi.pooq.com> References: <20090413150854.GA32577@topoi.pooq.com> Message-ID: <20090413192006.GA660@topoi.pooq.com> On Mon, Apr 13, 2009 at 11:08:54AM -0400, hendrik at topoi.pooq.com wrote: > On Sun, Apr 12, 2009 at 11:34:49AM +0000, Jay wrote: > > > > Now hopefully we can switch to svn or monotone and cvsup won't matter to us. :) > > (Well, I never use it in any case. I know it is big in FreeBSD-land.) > > Yes, monotone... I'm trying to organise putting together the monotone > repository, and it seems that the first thing to do is to get a local > copy of the existing modula 3 CVS repository to experiment on. There > are at least two ways to go about putting the monotone repository > together, on of them seems to requre me to have a local copy of the > repository. > > I suspect I need to get cvsup running to make this local copy of the > CVS. Where should I get cvsup? (It doesn't seem to be distributed as a > Debian package; perhaps that's because Modula 3 ins't either?) Did you > make changes to cvsup to get it to work on current versions of Modula 3? > If so I should probably get the changed version. I should definitely get the changed version, to avoid wasting time. I just tried downloading and installing cvsup-snap-16.1h.tar.gz on an x86 Debian system. It seems to run into trouble because it duplicates code in cm3 itself: hendrik at lovesong:~/dv/cvsup/cvsup-snap-16.1h$ make make[1]: Entering directory `/farhome/hendrik/dv/cvsup/cvsup-snap-16.1h' --- building in LINUXLIBC6 --- ===> suptcp make[2]: Entering directory `/farhome/hendrik/dv/cvsup/cvsup-snap-16.1h/suptcp' cm3 --- building in LINUXLIBC6 --- Fatal Error: duplicate unit: /usr/local/cm3/pkg/tcp/src/POSIX/SockOpt.i3 ../src/POSIX/SockOpt.i3 -- hendrik > > Or else maybe someone could make a .tgz file out of the entire cm3 CVS > and I could download and work with that? > > -- hendrik From wagner at elegosoft.com Mon Apr 13 21:58:44 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 13 Apr 2009 21:58:44 +0200 Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN In-Reply-To: <20090413130720.aziv5e0fggwgccw0@mail.elegosoft.com> References: <20090411105512.92784fp7cc0o448k@mail.elegosoft.com> <20090413125148.vxbxs7ftessckwko@mail.elegosoft.com> <20090413130720.aziv5e0fggwgccw0@mail.elegosoft.com> Message-ID: <20090413215844.i3cr5vkecks48004@mail.elegosoft.com> FYI: installing the latest version of GNU make and autoconf manually fixed the problem. m3cc builds after realclean and works perfectly. Olaf Quoting Olaf Wagner : > Quoting Jay : > >> >>> I got syntax errors with >>> some pattern substitution in a Makefile, and the build stopped. >> >> make vs. gmake? > > Maybe (log attached). But shouldn't configure be able to figure this > out by itself? GNU make is /usr/bin/gnumake on this system (Fink > packages). > > Olaf > >> - Jay >> >> >> >> ---------------------------------------- >>> Date: Mon, 13 Apr 2009 12:51:48 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN >>> >>> Quoting Jay : >>> >>>> >>>> My machine calls itself: >>>> >>>> jbook15:~ jay$ uname -a >>>> Darwin jbook15.local 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 >>>> 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh >>>> powerpc >>>> >>>> That is 10.4.something. It works ok. cm3cg built as recently as 4/10.. >>> >>> So it seems OK for newer MacOS X releases. I worked around it here by >>> continuning to use an older backend, which seems OK for now. >>> Doing a realclean and a complete rebuild, I got syntax errors with >>> some pattern substitution in a Makefile, and the build stopped. >>> >>> I'll try a newer backend compiled on another machine, too. >>> >>> Olaf >>> >>>> - Jay >>>> >>>> >>>> ________________________________ >>>>> From: jay >>>>> To: wagner; m3devel >>>>> Subject: RE: [M3devel] Internal compiler errors after upgrade on >>>>> PPC_DARWIN >>>>> Date: Sat, 11 Apr 2009 12:03:39 +0000> >>>>> >>>>> I do test on 10.4 fairly often... >>>> >>>>> It sounds like 7.9.0 is 10.3? >>>>> >>>>> >>>>> - Jay >>>>> >>>>>> Date: Sat, 11 Apr 2009 10:55:12 +0200 >>>>>> From: wagner@ >>>>>> To: m3devel@ >>>>>> Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN >>>>>> >>>>>> After trying to upgrade cm3 on my notebook to the latest version, >>>>>> I get lots of internal compiler errors.This is on >>>>>> >>>>>> % uname -a >>>>>> Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 >>>>>> 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power >>>>>> Macintosh powerpc >>>>>> >>>>>> ... >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 rodney.m.bates at cox.net Mon Apr 13 23:24:06 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 13 Apr 2009 16:24:06 -0500 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> Message-ID: <49E3AD76.1080108@cox.net> Any opinions about the TEXT branch? Anybody tried it? To summarize: - I have tested it extensively on LINUXLIBC6, with a large random test program and two successive rebuilds of CM3. - It makes no changes in data structure, neither to static declarations nor to invariants. Thus it creates no compatibility problems with existing pickles, etc. - It slows down concatenation, but more than makes it up in other string accessing operations, if the numbers of concatenations and accessing operations are equal. - It cuts down on tree depth and even more or recursion depth (which implies needed stack space.) - This effect is dramatic when strings are built by "linear" concatenations, i.e., strictly left-to-right, or vice versa. Gains are moderate when concatenations are random. - It allocates a lot more storage, but abandons a lot more garbage, retaining somewhat more space when lots of old strings are retained along with newly-built ones. It probably retains less when operand strings of concatenations are not kept, but I haven't measured that. - Strategies are partial rebalancing of concatenation trees, flattening of short concatenations, elimination of a lot of tail-recursion, and recursing on the shorter side. Olaf Wagner wrote: > Well, that's a quite long list; but many things are bug fixes anyway, > and wouldn't be affected by a code freeze, while others are already > finished (as integrating CVSup, as I understand). > > The only thing we should not do is introduce new platforms while > trying to get the system stable. We should concentrate on installation > support and bug fixing. > > I'd suggest to start the release process in about two weeks at the > start of May. That should give everybody enough time to either finish > their ongoing work that shall make it into the release or decide to > postpone it ;-) > > Any objections? > > Olaf > > Quoting Jay : > >> >> > > o When should we start? I.e. wha changes would you like to complete >> > > before we start the release process? >> >> >> >> >> I'd like to see the formsvbt crash debugged and fixed, unless I'm >> the only one seeing it. >> >> I only see it on Solaris and PPC_DARWIN but haven't tried "everything". >> >> I'll try to get this. >> >> >> >> >> >> I'd also like to see: >> >> >> >> >> >> FreeBSD/x86 switched to the new Unix/*.i3 files. I'll do this. >> >> Maybe also I386_DARWIN, AMD64_DARWIN, but I don't have the hardware. >> >> >> >> >> >> $ORIGIN/LD_LIBRARY_PATH resolved a bit further, probably very >> little work (I'll do this). >> >> Basically just 1) put buildlocal back how it was 2) push it across >> more platforms e.g. I think FreeBSD/x86 is the main one missing, >> but I'll get to it. >> >> >> >> >> >> cvsup building and in "std" (I'll do this, probably very little >> left here really. >> >> >> >> >> >> -- beyond this, not required for release -- >> >> >> >> >> >> Maybe more AMD64 releases, e.g. NetBSD and Solaris. (If I get to it). >> >> (could be "mingw64" is good enough to try AMD64_NT now). >> >> >> >> >> >> Maybe update gmp/mpfr to fix the "maintainer" problem. (not likely >> by me) >> >> >> >> >> >> Maybe more new/resuscitated platforms..HPPA64_HPUX, IA64_*, *_VMS, >> ALPHA_*, ARM_*, *_IRIX, *_AIX, MIPS64_*.... but these take back >> seat to important fixes in existing platforms. >> >> >> >> >> >> Fix NT386 to use setjmp3 instead of setjmp so exceptions don't >> skip C __finally blocks. I've just been very lazy here, should >> demonstrate the behavior with a test case, then fix it.. >> >> >> >> >> >> Maybe fix cm3cg so other -g options besides -gstabs works, like >> plain -g, -ggdb, on at least one platform -gstabs isn't supported, >> leaving nothing, because others cause internal compiler errors, like >> on HPPA64_HPUX. >> >> >> >> >> >> Oh, and NT386GNU probably switched back to Win32 threads. >> Otherwise one of the test cases hangs and it doesn't look easy to >> figure out. I'll do this shortly if I remember. >> >> But I also wouldn't mind if this platform isn't officially released >> either (unless someone else wants to support it). >> >> >> >> >> >> Debug why many NT386MINGNU gui apps crash..but also probably just >> don't release this platform and ok asis. >> >> >> >> >> >> - Jay >> > > > From rcoleburn at scires.com Mon Apr 13 23:51:21 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 13 Apr 2009 17:51:21 -0400 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <49E3AD76.1080108@cox.net> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> Message-ID: <49E37ADC.1E75.00D7.1@scires.com> Rodney, sorry but I haven't tried your changes. If your test program is available, I would be glad to compile and run it on Windows to obtain results for that platform. Just let me know how to obtain/install your TEXT changes and the test program. I am ok with Olaf's suggestion of starting the release process in May. Again, I will be glad to help on Windows platforms. If necessary, I can also test cygwin on Windows. If we need to test/build/release on HPUX, I have an old v10 system I can pull out of storage (note that v10 is an older version of HPUX and not current). Regards, Randy Coleburn >>> "Rodney M. Bates" 4/13/2009 5:24 PM >>> Any opinions about the TEXT branch? Anybody tried it? To summarize: - I have tested it extensively on LINUXLIBC6, with a large random test program and two successive rebuilds of CM3. - It makes no changes in data structure, neither to static declarations nor to invariants. Thus it creates no compatibility problems with existing pickles, etc. - It slows down concatenation, but more than makes it up in other string accessing operations, if the numbers of concatenations and accessing operations are equal. - It cuts down on tree depth and even more or recursion depth (which implies needed stack space.) - This effect is dramatic when strings are built by "linear" concatenations, i.e., strictly left-to-right, or vice versa. Gains are moderate when concatenations are random. - It allocates a lot more storage, but abandons a lot more garbage, retaining somewhat more space when lots of old strings are retained along with newly-built ones. It probably retains less when operand strings of concatenations are not kept, but I haven't measured that. - Strategies are partial rebalancing of concatenation trees, flattening of short concatenations, elimination of a lot of tail-recursion, and recursing on the shorter side. Olaf Wagner wrote: > Well, that's a quite long list; but many things are bug fixes anyway, > and wouldn't be affected by a code freeze, while others are already > finished (as integrating CVSup, as I understand). > > The only thing we should not do is introduce new platforms while > trying to get the system stable. We should concentrate on installation > support and bug fixing. > > I'd suggest to start the release process in about two weeks at the > start of May. That should give everybody enough time to either finish > their ongoing work that shall make it into the release or decide to > postpone it ;-) > > Any objections? > > Olaf > > Quoting Jay : > >> >> > > o When should we start? I.e. wha changes would you like to complete >> > > before we start the release process? >> >> >> >> >> I'd like to see the formsvbt crash debugged and fixed, unless I'm >> the only one seeing it. >> >> I only see it on Solaris and PPC_DARWIN but haven't tried "everything". >> >> I'll try to get this. >> >> >> >> >> >> I'd also like to see: >> >> >> >> >> >> FreeBSD/x86 switched to the new Unix/*.i3 files. I'll do this. >> >> Maybe also I386_DARWIN, AMD64_DARWIN, but I don't have the hardware. >> >> >> >> >> >> $ORIGIN/LD_LIBRARY_PATH resolved a bit further, probably very >> little work (I'll do this). >> >> Basically just 1) put buildlocal back how it was 2) push it across >> more platforms e.g. I think FreeBSD/x86 is the main one missing, >> but I'll get to it. >> >> >> >> >> >> cvsup building and in "std" (I'll do this, probably very little >> left here really. >> >> >> >> >> >> -- beyond this, not required for release -- >> >> >> >> >> >> Maybe more AMD64 releases, e.g. NetBSD and Solaris. (If I get to it). >> >> (could be "mingw64" is good enough to try AMD64_NT now). >> >> >> >> >> >> Maybe update gmp/mpfr to fix the "maintainer" problem. (not likely >> by me) >> >> >> >> >> >> Maybe more new/resuscitated platforms..HPPA64_HPUX, IA64_*, *_VMS, >> ALPHA_*, ARM_*, *_IRIX, *_AIX, MIPS64_*.... but these take back >> seat to important fixes in existing platforms. >> >> >> >> >> >> Fix NT386 to use setjmp3 instead of setjmp so exceptions don't >> skip C __finally blocks. I've just been very lazy here, should >> demonstrate the behavior with a test case, then fix it.. >> >> >> >> >> >> Maybe fix cm3cg so other -g options besides -gstabs works, like >> plain -g, -ggdb, on at least one platform -gstabs isn't supported, >> leaving nothing, because others cause internal compiler errors, like >> on HPPA64_HPUX. >> >> >> >> >> >> Oh, and NT386GNU probably switched back to Win32 threads. >> Otherwise one of the test cases hangs and it doesn't look easy to >> figure out. I'll do this shortly if I remember. >> >> But I also wouldn't mind if this platform isn't officially released >> either (unless someone else wants to support it). >> >> >> >> >> >> Debug why many NT386MINGNU gui apps crash..but also probably just >> don't release this platform and ok asis. >> >> >> >> >> >> - 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 wagner at elegosoft.com Mon Apr 13 23:49:13 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 13 Apr 2009 23:49:13 +0200 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <49E3AD76.1080108@cox.net> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> Message-ID: <20090413234913.28trgcepwk488sc8@mail.elegosoft.com> Quoting "Rodney M. Bates" : > Any opinions about the TEXT branch? Anybody tried it? To summarize: > > - I have tested it extensively on LINUXLIBC6, with a large random > test program and two successive rebuilds of CM3. > > - It makes no changes in data structure, neither to static declarations > nor to invariants. Thus it creates no compatibility problems with existing > pickles, etc. > > - It slows down concatenation, but more than makes it up in other > string accessing operations, if the numbers of concatenations and > accessing operations are equal. > > - It cuts down on tree depth and even more or recursion depth > (which implies needed stack space.) > > - This effect is dramatic when strings are built by "linear" concatenations, > i.e., strictly left-to-right, or vice versa. Gains are moderate when > concatenations are random. > > - It allocates a lot more storage, but abandons a lot more garbage, > retaining somewhat more space when lots of old strings are retained > along with newly-built ones. It probably retains less when operand > strings of concatenations are not kept, but I haven't measured that. > > - Strategies are partial rebalancing of concatenation trees, flattening > of short concatenations, elimination of a lot of tail-recursion, and > recursing on the shorter side. I would tend to give it a try, i.e. include it in the release candiates, but I'd like to have some data about the impacts on real applications, let's say the cm3 compiler itself, the caltech parser generator, and cvsup. How do these perform for a small set of sample data? I won't have the time to do these tests though, so I'll trust the opinion of others regarding the inclusion in the next release. Olaf > Olaf Wagner wrote: >> Well, that's a quite long list; but many things are bug fixes anyway, >> and wouldn't be affected by a code freeze, while others are already >> finished (as integrating CVSup, as I understand). >> >> The only thing we should not do is introduce new platforms while >> trying to get the system stable. We should concentrate on installation >> support and bug fixing. >> >> I'd suggest to start the release process in about two weeks at the >> start of May. That should give everybody enough time to either finish >> their ongoing work that shall make it into the release or decide to >> postpone it ;-) >> >> Any objections? >> >> Olaf >> >> Quoting Jay : >> >>> >>> > > o When should we start? I.e. wha changes would you like to complete >>> > > before we start the release process? >>> >>> >>> >>> >>> I'd like to see the formsvbt crash debugged and fixed, unless I'm >>> the only one seeing it. >>> >>> I only see it on Solaris and PPC_DARWIN but haven't tried "everything". >>> >>> I'll try to get this. >>> >>> >>> >>> >>> >>> I'd also like to see: >>> >>> >>> >>> >>> >>> FreeBSD/x86 switched to the new Unix/*.i3 files. I'll do this. >>> >>> Maybe also I386_DARWIN, AMD64_DARWIN, but I don't have the hardware. >>> >>> >>> >>> >>> >>> $ORIGIN/LD_LIBRARY_PATH resolved a bit further, probably very >>> little work (I'll do this). >>> >>> Basically just 1) put buildlocal back how it was 2) push it >>> across more platforms e.g. I think FreeBSD/x86 is the main one >>> missing, but I'll get to it. >>> >>> >>> >>> >>> >>> cvsup building and in "std" (I'll do this, probably very little >>> left here really. >>> >>> >>> >>> >>> >>> -- beyond this, not required for release -- >>> >>> >>> >>> >>> >>> Maybe more AMD64 releases, e.g. NetBSD and Solaris. (If I get to it). >>> >>> (could be "mingw64" is good enough to try AMD64_NT now). >>> >>> >>> >>> >>> >>> Maybe update gmp/mpfr to fix the "maintainer" problem. (not likely by me) >>> >>> >>> >>> >>> >>> Maybe more new/resuscitated platforms..HPPA64_HPUX, IA64_*, >>> *_VMS, ALPHA_*, ARM_*, *_IRIX, *_AIX, MIPS64_*.... but these take >>> back seat to important fixes in existing platforms. >>> >>> >>> >>> >>> >>> Fix NT386 to use setjmp3 instead of setjmp so exceptions don't >>> skip C __finally blocks. I've just been very lazy here, should >>> demonstrate the behavior with a test case, then fix it.. >>> >>> >>> >>> >>> >>> Maybe fix cm3cg so other -g options besides -gstabs works, like >>> plain -g, -ggdb, on at least one platform -gstabs isn't supported, >>> leaving nothing, because others cause internal compiler errors, >>> like on HPPA64_HPUX. >>> >>> >>> >>> >>> >>> Oh, and NT386GNU probably switched back to Win32 threads. >>> Otherwise one of the test cases hangs and it doesn't look easy to >>> figure out. I'll do this shortly if I remember. >>> >>> But I also wouldn't mind if this platform isn't officially >>> released either (unless someone else wants to support it). >>> >>> >>> >>> >>> >>> Debug why many NT386MINGNU gui apps crash..but also probably just >>> don't release this platform and ok asis. >>> >>> >>> >>> >>> >>> - 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 Mon Apr 13 23:51:31 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 13 Apr 2009 16:51:31 -0500 Subject: [M3devel] small objects] Message-ID: <49E3B3E3.8090400@cox.net> Mika Nystrom wrote: > Ahhhh!!!!! Now I get it, Rodney! > > You're talking about using tagged types "within" Modula-3. > > I've just been asking for tagged types to do something "that's not > Modula-3". I'm completely aware that passing REFANY around is not > the "Modula-3 way", and had no intention of making it so. (That's > why I keep saying that only lazy people do it, so it doesn't matter.) > > My desire for storing integers and pointers in the same machine word > is not something I thought would ever be useful in Modula-3 itself. > But now what you say makes sense to me... you want to build your > ADTs with this. Then you do need the full M3 type system "above" > your tagged reference. > > I agree with you on MOST of the following: > > >> I really feel that the fad of all dynamic typing in languages is a huge >> mistake and that it will someday be recognized as such. In the >> meantime, we have a language that provides a very extensive set >> of statically-typed alternatives, while also allowing dynamic typing >> when you really need it. This is one of Modula-3's best principles. >> Let's don't erode the static alternatives unnecessarily. >> > > I program, currently, mostly in Scheme and in Modula-3, (mostly M3) > and I am constantly amazed by: > > 1. The way that Modula-3 programs often are correct the first time > they are compiled, even if they haven't been carefully designed. > Using the M3 type system can really make your code obviously correct. > > 2. The way that Scheme programs can sometimes abstract away all sorts > of type irrelevancies. In M3 you'd have to have many versions of the > same code, or at least many generic instances. This is especially > true for "higher-higher order" types, where one type is made from > another and that was made from another, etc. (Interpret "type" > liberally, please. It's probably just some sort of lambda expression.) > > Now I agree that untyped languages are probably a fad, and they have > set computing back by years or decades(?). Too easy to make mistakes. > But there is something of value there, and my feeling is that the best > way to take advantage of it is to *combine* the two worlds, rather than > trying to come up with some sort of "super language" that incorporates > the best of both worlds and somehow manages to step on no one's toes. > I'm presenting this as an alternative to type inferencing schemes in > environments such as ML. > > So my idea, my "vision" if you like, is that we embed untyped > languages in Modula-3. The parts of the system that need performance > or are more convenient to program in the "bondage and discipline" > world of Algol get written in Modula-3, and the parts of the system > that it is more convenient (all things considered) to program in a > typeless environment can be programmed in Scheme (currently, other > interpreted languages can be added later if this turns out to be a > good idea). But it is clear that the typeless approach of REFANY > (REALLYREFANY, including the tagged types) is necessary to implement > this layer of the system---if you want to be able to pass data > structures seamlessly between the two layers. > > Maybe that explains better where I'm coming from. I have no intention > of using these types for Modula-3 programming :-) > > However, I do see your point. A facility provided is a facility > used, so if there's a very compact way of storing data in pointers, > other applications than the ones I have in mind will use them, too, > and perhaps lead to an abuse of Modula-3. But I'm not sure if this > isn't over the line of legislating programming *style*---if we go > down that route, we can do it the Java way and ban UNSAFE as well, > so people won't be tempted to program C in Modula-3. In any case, > the particular feature that one can hide 31 bits of information in > a REFANY (and only a REFANY) can't hurt you if you don't choose to > avail yourself of it---in fact it's transparent to people who don't > care about it. Ok, an added 2 instructions out of 1,000 on an > ISTYPE or TYPECASE of r : REFANY, but come on, that's not really > an argument! > > So I am supportive of making a new type hierarchy TAGGED T for any > No, not a tagged hierarchy. That was an earlier idea I toyed with that I considered a tar pit. The reference types remain in the existing hierarchy, but the tagged types have no subtype relation to each other. > T. And yes I understand that now---once you have TAGGED T---it is > trivial to add a TAGGED REFANY, which you can distinguish from > REFANY. I think your arguments for the TAGGED hierarchy are very > good. > > However, I still don't think you have made a good argument *against* > being able to hide 31 bits of information in a REFANY. You don't > have to use the facility if it doesn't meet your requirements! > > Please remember that what I've been proposing is not a language > change at all but a request that the runtime system and compiler > respect a couple of not-difficult-to-ensure properties, so that we > may do some new tricks in UNSAFE code. Nothing more than that. > > Mika > > P.S. You didn't actually give any examples of code where you > would, after *your* proposed change, still use REFANY instead of > switching the code to TAGGED REFANY. I brought up container data structures as one important group, but they are not the universe of uses of REFANY. As an example, I have a good sized module that builds a tree--not a general tree determined by input, but exactly one, hard-coded specific tree. It's needed to boostrap the general tree-building code. The tree is rather large, and hard coding all the node constructor calls was very tedious and boring. I wrote some node constructor procedures with the intent of minimizing the keystrokes in the calls on them. One way I did this was to make the child parameters have type REFANY, with meaningful values being either TEXT or previously-built tree nodes of a few possible different types. The constructors then TYPECASE on them. REFANY is the narrowest possible type that can take this set of options. This has nothing to do with any abstract data type and is not intended for any general-purpose use by various other code. In fact, it has a very specific and limited purpose. > You said that: > > >> And TAGGED REFANY generalizes it from REFANY. >> > > i.e., container code would switch to TAGGED REFANY > > >> The other use is for the abstract type itself. Forgetting tagged >> types for a moment, I have never seen an interface/module that >> uses REFANY for this. Instead, the modules declare their abstract >> type as some proper subtype of REFANY, usually an opaque type. >> > > i.e., other code doesn't actually use REFANY! > > (For what it's worth, your experience here matches mine. Container > types (may) use REFANY and ADTs (almost) never do.) > > So back to my question: where would you use REFANY???? If never, > then why bother having the two roots? > > What you're saying is that after *my* proposed runtime change, *you* > will be tempted to abuse REFANY for ADTs. I don't think this is a > very good argument against my proposal (but it is a good argument > for yours, which is not incompatible with mine but instead expands it). > The only thing that makes your proposal slightly incompatible with > mine is that you're insisting on having a new distinction between > REFANY and TAGGED REFANY, which I am saying will never be used in > practice. And both your experience with Modula-3 and mine seem to > back up this assertion. > > > "Rodney M. Bates" writes: > >> Mika Nystrom wrote: >> >>> Sorry to splice together two emails from you, but I feel I've already >>> used up my m3devel quota this week: >>> >>> "Rodney M. Bates" writes: >>> >>> >>>>> Are you sure? I want a type---some type---that can hold "any >>>>> reference, even a tagged one", and I would rewrite most library >>>>> code that today takes REFANY to take that instead. Why not? Why >>>>> would I want to limit it to REFANY when it performs no operations >>>>> that couldn't legally be performed on TAGGED REFANY. >>>>> >>>>> >>>>> >>>> I believe my "safe" proposal would make this very simple, if I am >>>> thinking of the kind of library code you are. >>>> >>>> I envision a container data structure that takes in things and returns >>>> them without performing operations on them other than moving them around >>>> and storing them, e.g. the ever belabored stack. The values going in >>>> and out are declared REFANY, and the client passes in values of >>>> some proper subtype of REFANY, which get assigned to the REFANY >>>> parameters. When it gets them back, it narrows them to this type. >>>> >>>> In this pattern, just changing the declared type of the container values >>>> >>>> >>> >from REFANY to TAGGED REFANY would do it. The library code's storage >>> ... >>> >>> >> There are two very different kinds of uses of reference and >> tagged types. The one I speak of above is for the type of the >> elements inside a container data structure. In this case, it >> is the client that knows what type the value really is, and will >> declare it as such. The library ADT module should know as little >> as possible about it, so it will declare it as REFANY or >> TAGGED REFANY. Here, you want the most general type >> possible, just to make the abstraction more versatile. >> And TAGGED REFANY generalizes it from REFANY. >> >> But... >> >>> >>> >> >>>>> you'd like to store these in a REFANY and dynamically test for the >>>>> appropriate tagged type: >>>>> >>>>> >>>> No, I do not want to store these in a variable of type REFANY or any >>>> other existing type. >>>> In fact, I want to forbid it. >>>> >>>> >>> I think you are thinking of exactly the same kind of library code. >>> TextRefTbl.T, RefList.T, etc. >>> >>> After the introduction of TAGGED REFANY, what use is there for >>> REFANY? What piece of code can you think of where the cost of the >>> 1-LSB check of TAGGED REFANY outweighs the convenience of being >>> able to process objects of type TAGGED T (for all ref types T) as >>> well as objects of type T? >>> >>> >> The other use is for the abstract type itself. Forgetting tagged >> types for a moment, I have never seen an interface/module that >> uses REFANY for this. Instead, the modules declare their abstract >> type as some proper subtype of REFANY, usually an opaque type. >> >> It would be possible to use just REFANY here of course, but that would >> require an otherwise unnecessary RT check on the allocated type, >> every time an operation of the module is called. This is a much >> more expensive check than a tag check, as has been pointed out >> in this discussion. >> >> But worse, it would sacrifice the static checking that we now have >> that prevents, at compile time, clients from passing, say a Text.T >> to some procedure in Atom that expects an Atom.T. If these modules >> ever wanted to use a tagged type, but the only tagged type were >> REFANY, we would lose this static checking, because Text.T would >> have to become equal to Atom.T. >> >> In cases where your algorithms don't specifically need dynamic >> typing, static typing is always much better, because one run of >> the compiler on the source code will do it. Bugs checked >> only at runtime require a massive test suit to be coded and then >> regularly rerun to get even close to the same confidence they've >> been found. >> >> So when using tagged types as the ADT itself,, we need to be able >> to have a tagged version of whatever proper subtype of REFANY >> the abstraction needs, including an opaque subtype of REFANY >> or an opaque subtype of some Public subtype of REFANY. This is >> why I am adamant that we need to be able to build a tagged type >> > >from any traced or object type. > >> And once you do this, keeping REFANY itself unchanged and allowing >> TAGGED REFANY as one case of a tagged type falls out of the system >> for free _and_ saves a lot of cases that would otherwise need a new RT >> check that can never fail, but the language can't know that, because >> the type system has lost the distinction. >> >> I really feel that the fad of all dynamic typing in languages is a huge >> mistake and that it will someday be recognized as such. In the >> meantime, we have a language that provides a very extensive set >> of statically-typed alternatives, while also allowing dynamic typing >> when you really need it. This is one of Modula-3's best principles. >> Let's don't erode the static alternatives unnecessarily. >> >> >>> Mika >>> >>> >>> > > From jay.krell at cornell.edu Tue Apr 14 02:37:42 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 14 Apr 2009 00:37:42 +0000 Subject: [M3devel] FW: cvsup In-Reply-To: <20090413192006.GA660@topoi.pooq.com> References: <20090413150854.GA32577@topoi.pooq.com> <20090413192006.GA660@topoi.pooq.com> Message-ID: I think you can ssh into birch and tar cfz /usr/cvs/cm3 or such. If you want/need cvsup, yes please try current cm3 source. It at least builds and the changes weren't really significant. Yes they had their own copy of TCP. Olaf's does too, but his used "override" to avoid the duplicate. I just don't use the duplicate. It looks like the mainline and cvsup were mostly in sync, though mainline has 64bit big endian bug fixes ("one is int not INTEGER"). I should double check that though. I think there is a bit of a language problem in Modula3. I can have: INTERFACE A; PROCEDURE F; INTERFACE B; PROCEDURE F; and IMPORT both A and B from a third module, since I can refer to A.F and B.F, but I cannot IMPORT A from B's implementation or vice versa. The implementation of F is ambiguous. A possible solution is to let the implementation put the interface name ahead of the function. MODULE B IMPORTS A; PROCEDURE B.F() = BEGIN END B.F; and all uses of F within B must say B.F or A.F. - Jay ---------------------------------------- > Date: Mon, 13 Apr 2009 15:20:06 -0400 > From: hendrik > To: m3devel > Subject: Re: [M3devel] FW: cvsup > From rodney.m.bates at cox.net Tue Apr 14 04:33:48 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 13 Apr 2009 21:33:48 -0500 Subject: [M3devel] FW: cvsup In-Reply-To: References: <20090413150854.GA32577@topoi.pooq.com> <20090413192006.GA660@topoi.pooq.com> Message-ID: <49E3F60C.3070808@cox.net> Jay wrote: > I think you can ssh into birch and tar cfz /usr/cvs/cm3 or such. > > > If you want/need cvsup, yes please try current cm3 source. > It at least builds and the changes weren't really significant. > Yes they had their own copy of TCP. > Olaf's does too, but his used "override" to avoid the duplicate. > I just don't use the duplicate. > It looks like the mainline and cvsup were mostly in sync, > though mainline has 64bit big endian bug fixes ("one is int not INTEGER"). > I should double check that though. > > > I think there is a bit of a language problem in Modula3. > I can have: > > > INTERFACE A; > PROCEDURE F; > > > INTERFACE B; > PROCEDURE F; > > > and IMPORT both A and B from a third module, since I can refer to A.F and B.F, > > but I cannot IMPORT A from B's implementation or vice versa. > The implementation of F is ambiguous. > Sure you can. > > > A possible solution is to let the implementation put the > interface name ahead of the function. > > MODULE B IMPORTS A; > In module B, you can refer to A.F. If you want the F in B, its name is just unqualified F. MODULE B is short for MODULE B EXPORTS B (see 2.5.3, 1st paragraph), and one consequence of exporting B is that everything declared in interface B is available without qualification in the module that does the export . See 2.5.3, 2nd paragraph. What you can't do is have the same module export both A and B. That would make F an illegal redeclaration. See 2.5.3, 4th paragraph. > > PROCEDURE B.F() = BEGIN END B.F; > > > and all uses of F within B must say B.F or A.F. > > > - Jay > > > ---------------------------------------- > >> Date: Mon, 13 Apr 2009 15:20:06 -0400 >> From: hendrik >> To: m3devel >> Subject: Re: [M3devel] FW: cvsup >> >> From hosking at cs.purdue.edu Tue Apr 14 05:43:45 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 14 Apr 2009 13:43:45 +1000 Subject: [M3devel] FW: cvsup In-Reply-To: References: <20090413150854.GA32577@topoi.pooq.com> <20090413192006.GA660@topoi.pooq.com> Message-ID: <7F0E7523-EC64-44C5-932B-48EA3F3B05A6@cs.purdue.edu> ssh + rsync! On 14 Apr 2009, at 10:37, Jay wrote: > > I think you can ssh into birch and tar cfz /usr/cvs/cm3 or such. > > > If you want/need cvsup, yes please try current cm3 source. > It at least builds and the changes weren't really significant. > Yes they had their own copy of TCP. > Olaf's does too, but his used "override" to avoid the duplicate. > I just don't use the duplicate. > It looks like the mainline and cvsup were mostly in sync, > though mainline has 64bit big endian bug fixes ("one is int not > INTEGER"). > I should double check that though. > > > I think there is a bit of a language problem in Modula3. > I can have: > > > INTERFACE A; > PROCEDURE F; > > > INTERFACE B; > PROCEDURE F; > > > and IMPORT both A and B from a third module, since I can refer to > A.F and B.F, > > but I cannot IMPORT A from B's implementation or vice versa. > The implementation of F is ambiguous. > > > A possible solution is to let the implementation put the > interface name ahead of the function. > > MODULE B IMPORTS A; > > PROCEDURE B.F() = BEGIN END B.F; > > > and all uses of F within B must say B.F or A.F. > > > - Jay > > > ---------------------------------------- >> Date: Mon, 13 Apr 2009 15:20:06 -0400 >> From: hendrik >> To: m3devel >> Subject: Re: [M3devel] FW: cvsup >> From wagner at elegosoft.com Tue Apr 14 12:02:17 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 14 Apr 2009 12:02:17 +0200 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <49E37ADC.1E75.00D7.1@scires.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> <49E37ADC.1E75.00D7.1@scires.com> Message-ID: <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> If anybody could test Rodney's TEXT changes and provide some information on the impacts on our applications, that would help a lot. I also wasn't able to read and understand all the mails about small objects. (Guessing, I'd say I'd need another day for that :-) Can anybody summarize? Has a conclusion been reached and what will be done/implemented? Is this relevant for the next release, or will it take longer? Olaf Quoting Randy Coleburn : > Rodney, sorry but I haven't tried your changes. If your test > program is available, I would be glad to compile and run it on > Windows to obtain results for that platform. Just let me know how > to obtain/install your TEXT changes and the test program. > > I am ok with Olaf's suggestion of starting the release process in May. > > Again, I will be glad to help on Windows platforms. If necessary, I > can also test cygwin on Windows. > > If we need to test/build/release on HPUX, I have an old v10 system I > can pull out of storage (note that v10 is an older version of HPUX > and not current). > > Regards, > Randy Coleburn > >>>> "Rodney M. Bates" 4/13/2009 5:24 PM >>> > Any opinions about the TEXT branch? Anybody tried it? To summarize: > > - I have tested it extensively on LINUXLIBC6, with a large random > test program and two successive rebuilds of CM3. > > - It makes no changes in data structure, neither to static declarations > nor to invariants. Thus it creates no compatibility problems with > existing > pickles, etc. > > - It slows down concatenation, but more than makes it up in other > string accessing operations, if the numbers of concatenations and > accessing operations are equal. > > - It cuts down on tree depth and even more or recursion depth > (which implies needed stack space.) > > - This effect is dramatic when strings are built by "linear" concatenations, > i.e., strictly left-to-right, or vice versa. Gains are moderate when > concatenations are random. > > - It allocates a lot more storage, but abandons a lot more garbage, > retaining somewhat more space when lots of old strings are retained > along with newly-built ones. It probably retains less when operand > strings of concatenations are not kept, but I haven't measured that. > > - Strategies are partial rebalancing of concatenation trees, flattening > of short concatenations, elimination of a lot of tail-recursion, and > recursing on the shorter side. > > > > Olaf Wagner wrote: >> Well, that's a quite long list; but many things are bug fixes anyway, >> and wouldn't be affected by a code freeze, while others are already >> finished (as integrating CVSup, as I understand). >> >> The only thing we should not do is introduce new platforms while >> trying to get the system stable. We should concentrate on installation >> support and bug fixing. >> >> I'd suggest to start the release process in about two weeks at the >> start of May. That should give everybody enough time to either finish >> their ongoing work that shall make it into the release or decide to >> postpone it ;-) >> >> Any objections? >> >> Olaf >> >> Quoting Jay : >> >>> >>> > > o When should we start? I.e. wha changes would you like to complete >>> > > before we start the release process? >>> >>> >>> >>> >>> I'd like to see the formsvbt crash debugged and fixed, unless I'm >>> the only one seeing it. >>> >>> I only see it on Solaris and PPC_DARWIN but haven't tried "everything". >>> >>> I'll try to get this. >>> >>> >>> >>> >>> >>> I'd also like to see: >>> >>> >>> >>> >>> >>> FreeBSD/x86 switched to the new Unix/*.i3 files. I'll do this. >>> >>> Maybe also I386_DARWIN, AMD64_DARWIN, but I don't have the hardware. >>> >>> >>> >>> >>> >>> $ORIGIN/LD_LIBRARY_PATH resolved a bit further, probably very >>> little work (I'll do this). >>> >>> Basically just 1) put buildlocal back how it was 2) push it across >>> more platforms e.g. I think FreeBSD/x86 is the main one missing, >>> but I'll get to it. >>> >>> >>> >>> >>> >>> cvsup building and in "std" (I'll do this, probably very little >>> left here really. >>> >>> >>> >>> >>> >>> -- beyond this, not required for release -- >>> >>> >>> >>> >>> >>> Maybe more AMD64 releases, e.g. NetBSD and Solaris. (If I get to it). >>> >>> (could be "mingw64" is good enough to try AMD64_NT now). >>> >>> >>> >>> >>> >>> Maybe update gmp/mpfr to fix the "maintainer" problem. (not likely >>> by me) >>> >>> >>> >>> >>> >>> Maybe more new/resuscitated platforms..HPPA64_HPUX, IA64_*, *_VMS, >>> ALPHA_*, ARM_*, *_IRIX, *_AIX, MIPS64_*.... but these take back >>> seat to important fixes in existing platforms. >>> >>> >>> >>> >>> >>> Fix NT386 to use setjmp3 instead of setjmp so exceptions don't >>> skip C __finally blocks. I've just been very lazy here, should >>> demonstrate the behavior with a test case, then fix it.. >>> >>> >>> >>> >>> >>> Maybe fix cm3cg so other -g options besides -gstabs works, like >>> plain -g, -ggdb, on at least one platform -gstabs isn't supported, >>> leaving nothing, because others cause internal compiler errors, like >>> on HPPA64_HPUX. >>> >>> >>> >>> >>> >>> Oh, and NT386GNU probably switched back to Win32 threads. >>> Otherwise one of the test cases hangs and it doesn't look easy to >>> figure out. I'll do this shortly if I remember. >>> >>> But I also wouldn't mind if this platform isn't officially released >>> either (unless someone else wants to support it). >>> >>> >>> >>> >>> >>> Debug why many NT386MINGNU gui apps crash..but also probably just >>> don't release this platform and ok asis. >>> >>> >>> >>> >>> >>> - 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. > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Tue Apr 14 15:04:33 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 14 Apr 2009 09:04:33 -0400 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> <49E37ADC.1E75.00D7.1@scires.com> <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> Message-ID: <20090414130433.GA2968@topoi.pooq.com> On Tue, Apr 14, 2009 at 12:02:17PM +0200, Olaf Wagner wrote: > If anybody could test Rodney's TEXT changes and provide some > information on the impacts on our applications, that would help a lot. > > I also wasn't able to read and understand all the mails about small objects. > (Guessing, I'd say I'd need another day for that :-) > Can anybody summarize? > Has a conclusion been reached and what will be done/implemented? > Is this relevant for the next release, or will it take longer? Deciding that the garbage collector should test for the low-order bit of pointers and leave them alone if the bit is set could probably dop done immediately, and would make it possible for users to build unsafe code to do the small-objects stuff. This could go in the next release if the garbage-collector change wom't upset anything. There's still some discussion about just what form the final language feature should take. I don't know if that will be finished in time for the release. -- hendrik From rodney.m.bates at cox.net Tue Apr 14 14:21:07 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Tue, 14 Apr 2009 07:21:07 -0500 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <49E37ADC.1E75.00D7.1@scires.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> <49E37ADC.1E75.00D7.1@scires.com> Message-ID: <49E47FB3.2070102@cox.net> Randy Coleburn wrote: > Rodney, sorry but I haven't tried your changes. If your test program > is available, I would be glad to compile and run it on Windows to > obtain results for that platform. Just let me know how to > obtain/install your TEXT changes and the test program. It's in a branch named: devel_m3core_text_newtext_branch It's all part of m3core, which you have to rebuild and ship. The test program source code is in m3-libs/m3core/tests/newtext/src of the branch, along with a README file. > > I am ok with Olaf's suggestion of starting the release process in May. > > Again, I will be glad to help on Windows platforms. If necessary, I > can also test cygwin on Windows. > > If we need to test/build/release on HPUX, I have an old v10 system I > can pull out of storage (note that v10 is an older version of HPUX and > not current). > > Regards, > Randy Coleburn > > >>> "Rodney M. Bates" 4/13/2009 5:24 PM >>> > Any opinions about the TEXT branch? Anybody tried it? To summarize: > > - I have tested it extensively on LINUXLIBC6, with a large random > test program and two successive rebuilds of CM3. > > - It makes no changes in data structure, neither to static declarations > nor to invariants. Thus it creates no compatibility problems with > existing > pickles, etc. > > - It slows down concatenation, but more than makes it up in other > string accessing operations, if the numbers of concatenations and > accessing operations are equal. > > - It cuts down on tree depth and even more or recursion depth > (which implies needed stack space.) > > - This effect is dramatic when strings are built by "linear" > concatenations, > i.e., strictly left-to-right, or vice versa. Gains are moderate when > concatenations are random. > > - It allocates a lot more storage, but abandons a lot more garbage, > retaining somewhat more space when lots of old strings are retained > along with newly-built ones. It probably retains less when operand > strings of concatenations are not kept, but I haven't measured that. > > - Strategies are partial rebalancing of concatenation trees, flattening > of short concatenations, elimination of a lot of tail-recursion, and > recursing on the shorter side. > > > > Olaf Wagner wrote: > > Well, that's a quite long list; but many things are bug fixes anyway, > > and wouldn't be affected by a code freeze, while others are already > > finished (as integrating CVSup, as I understand). > > > > The only thing we should not do is introduce new platforms while > > trying to get the system stable. We should concentrate on installation > > support and bug fixing. > > > > I'd suggest to start the release process in about two weeks at the > > start of May. That should give everybody enough time to either finish > > their ongoing work that shall make it into the release or decide to > > postpone it ;-) > > > > Any objections? > > > > Olaf > > > > Quoting Jay : > > > >> > >> > > o When should we start? I.e. wha changes would you like to > complete > >> > > before we start the release process? > >> > >> > >> > >> > >> I'd like to see the formsvbt crash debugged and fixed, unless I'm > >> the only one seeing it. > >> > >> I only see it on Solaris and PPC_DARWIN but haven't tried > "everything". > >> > >> I'll try to get this. > >> > >> > >> > >> > >> > >> I'd also like to see: > >> > >> > >> > >> > >> > >> FreeBSD/x86 switched to the new Unix/*.i3 files. I'll do this. > >> > >> Maybe also I386_DARWIN, AMD64_DARWIN, but I don't have the > hardware. > >> > >> > >> > >> > >> > >> $ORIGIN/LD_LIBRARY_PATH resolved a bit further, probably very > >> little work (I'll do this). > >> > >> Basically just 1) put buildlocal back how it was 2) push it across > >> more platforms e.g. I think FreeBSD/x86 is the main one missing, > >> but I'll get to it. > >> > >> > >> > >> > >> > >> cvsup building and in "std" (I'll do this, probably very little > >> left here really. > >> > >> > >> > >> > >> > >> -- beyond this, not required for release -- > >> > >> > >> > >> > >> > >> Maybe more AMD64 releases, e.g. NetBSD and Solaris. (If I get to it). > >> > >> (could be "mingw64" is good enough to try AMD64_NT now). > >> > >> > >> > >> > >> > >> Maybe update gmp/mpfr to fix the "maintainer" problem. (not likely > >> by me) > >> > >> > >> > >> > >> > >> Maybe more new/resuscitated platforms..HPPA64_HPUX, IA64_*, *_VMS, > >> ALPHA_*, ARM_*, *_IRIX, *_AIX, MIPS64_*.... but these take back > >> seat to important fixes in existing platforms. > >> > >> > >> > >> > >> > >> Fix NT386 to use setjmp3 instead of setjmp so exceptions don't > >> skip C __finally blocks. I've just been very lazy here, should > >> demonstrate the behavior with a test case, then fix it.. > >> > >> > >> > >> > >> > >> Maybe fix cm3cg so other -g options besides -gstabs works, like > >> plain -g, -ggdb, on at least one platform -gstabs isn't supported, > >> leaving nothing, because others cause internal compiler errors, like > >> on HPPA64_HPUX. > >> > >> > >> > >> > >> > >> Oh, and NT386GNU probably switched back to Win32 threads. > >> Otherwise one of the test cases hangs and it doesn't look easy to > >> figure out. I'll do this shortly if I remember. > >> > >> But I also wouldn't mind if this platform isn't officially released > >> either (unless someone else wants to support it). > >> > >> > >> > >> > >> > >> Debug why many NT386MINGNU gui apps crash..but also probably just > >> don't release this platform and ok asis. > >> > >> > >> > >> > >> > >> - Jay > >> > > > > > > > > From jay.krell at cornell.edu Tue Apr 14 17:29:11 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 14 Apr 2009 15:29:11 +0000 Subject: [M3devel] $ORIGIN/../lib vs. $ORIGIN/../../../lib? Message-ID: $ORIGIN/../lib vs. $ORIGIN/../../../lib? It doesn't appear simple to know which of these runpaths to use. It depends on if the file is exported to bin or just "regular". It would be nice to just use one of these and not concatenate them. Usually "libraries" are in pkg and "executables" are not. But cm3 is an exception, can be ignored in general anything "standalone" can be ignored vorun is an exception. cmpfp is an exception. Also standalone. Is that it? Ignore cm3, change the others to go to bin, and use that rule then? cvsup and cvsupd where also exceptions but I went ahead and changed them. m3back is an exception, but isn't really ever used. uniq is an exception. But it is build static. There, is you know, the notion of an executable that is only meant to be run by code, not humans directly (e.g. cm3cg, cc1, etc.). These can be located outside of $PATH. I guess I can do this with "non local" information or parameter passing? I assume it is too painful right now to add a parameter to the quake link function. or maybe not -- go ahead and add a parameter to m3_link and make_lib, giving the installed path of the file? proc make_lib(lib, options, objects, imported_libs, shared, installed_path) is proc m3_link(prog, options, objects, imported_libs, shared, installed_path) is ? This would affect all configuration files. Several alternatives..that might be too large: Stop shippping any shared libraries or executables to pkg, just bin and lib? Or, reverse the sense of the file vs. symlink? Or make them hardlinks -- not great, since runpath would be wrong for one of them. Relink-upon-install still seems reasonable -- it knows the destination path. Is "../../../lib" moving too far around? How about the notion of confirming the layout, using: $ORIGIN/../pkg/m3core/target/../../.. $ORIGIN/../../../pkg/m3core/target/../../.. Does that feel safer? And not too inefficient? This way generally the ../../../ doesn't hold, unless "pkg/m3core/target" exists. - Jay From mika at async.caltech.edu Tue Apr 14 18:56:34 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 14 Apr 2009 09:56:34 -0700 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: Your message of "Tue, 14 Apr 2009 09:04:33 EDT." <20090414130433.GA2968@topoi.pooq.com> Message-ID: <200904141656.n3EGuYuZ061174@camembert.async.caltech.edu> I agree with what Hendrik says, but what about TYPECASE, ISTYPE, NARROW? Those are necessary to make it possible to pass "pointers" with the low-order bit set outside of unsafe code. My feeling is that if Tony can make the necessary changes, it could be done immediately, and the language issues can be pushed to the future. But admittedly I'm biased because of the application I'm working on. I need to get a recent CM3 up to test the TEXTs.... are they the default now? Mika hendrik at topoi.pooq.com writes: >On Tue, Apr 14, 2009 at 12:02:17PM +0200, Olaf Wagner wrote: >> If anybody could test Rodney's TEXT changes and provide some >> information on the impacts on our applications, that would help a lot. >> >> I also wasn't able to read and understand all the mails about small objects. >> (Guessing, I'd say I'd need another day for that :-) >> Can anybody summarize? >> Has a conclusion been reached and what will be done/implemented? >> Is this relevant for the next release, or will it take longer? > >Deciding that the garbage collector should test for the low-order bit of >pointers and leave them alone if the bit is set could probably dop done >immediately, and would make it possible for users to build unsafe code >to do the small-objects stuff. This could go in the next release if >the garbage-collector change wom't upset anything. > >There's still some discussion about just what form the final language >feature should take. I don't know if that will be finished in time for >the release. > >-- hendrik > From hendrik at topoi.pooq.com Tue Apr 14 18:59:57 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 14 Apr 2009 12:59:57 -0400 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <200904141656.n3EGuYuZ061174@camembert.async.caltech.edu> References: <20090414130433.GA2968@topoi.pooq.com> <200904141656.n3EGuYuZ061174@camembert.async.caltech.edu> Message-ID: <20090414165957.GA3460@topoi.pooq.com> On Tue, Apr 14, 2009 at 09:56:34AM -0700, Mika Nystrom wrote: > > I agree with what Hendrik says, but what about TYPECASE, ISTYPE, > NARROW? Those are necessary to make it possible to pass "pointers" > with the low-order bit set outside of unsafe code. Actually, it's possible to hack this inside unsafe code. So the language chenges are not absolutely essential. But if we have the right langauge changes, agreed, it would be pleasant not to have teo rewrite our code when the language changes finally freeze. -- hendrik From hendrik at topoi.pooq.com Tue Apr 14 19:11:33 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 14 Apr 2009 13:11:33 -0400 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> Message-ID: <20090414171133.GB3460@topoi.pooq.com> On Sat, Apr 11, 2009 at 11:26:11AM +0200, Olaf Wagner wrote: > > I'd rather avoid creating a branch too early, as that means more work > by selecting and merging fixes from trunk to branch. So here my questions: > > o Do we all agree on a temporary code freeze? > o When should we start? I.e. wha changes would you like to complete > before we start the release process? One thing that's essential is to debug the documentation -- specifically, the installation instructions, the various README files, and so forth. A naive user. competent in the ways of computers, but not yet in the ways of Modula 3, should be able to follow the instructions and succeed. Now I've done Modula 3 installations from snapshots before. So I'm no longer the naive user you want from this. If we can find a few colunteers who have never done such installations before, it would be useful to have them try to install, log the results, and come up with a list of obscuritues in the docs. (right down to difficulties in finding the docs!) But I have never compiled and installed the entire system from CVS. I've just downloaded the source from CVS, using the helpful instructions on http://modula3.elegosoft.com/cm3/, so I can report on how this goes, and there there are problems. First problem: the instructions don't say that cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 create a new dubdirectory of the current directory called cm3, and put everything in there. In particular, if there's already a directory called cm3, the downloaded source code will be plunked right on top of whatever was there. This may be obvious to experienced cvs users, but cvs is no longer the standard version control system, and we shouln't expect familiarity. -- hendrik From hendrik at topoi.pooq.com Wed Apr 15 04:54:32 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 14 Apr 2009 22:54:32 -0400 Subject: [M3devel] cvsup and TEXT In-Reply-To: References: <20090413150854.GA32577@topoi.pooq.com> <20090413192006.GA660@topoi.pooq.com> <20090414021311.GB1549@topoi.pooq.com> Message-ID: <20090415025432.GA3881@topoi.pooq.com> On Tue, Apr 14, 2009 at 03:00:48AM +0000, Jay wrote: > > > birch's full domain name > > > > .elegosoft.com > > aka m3.elegosoft.com > > aka modula3.elegosoft.com > > > > > Maybe it's time to change all this. > > > Could be. > > > > > So I should just remove the duplicate from the m3makefile, and maybe > > from the src directory? > > > Just cvs upd -dAP in cm3/m3-tools/cvsup. > > The current commited code should work. > > > > Specifically: remove the suptcp directory, change import(suptcp) to > tcp, any occurences of IMPORT SupFoo AS Foo changed to just IMPORT > Foo, where Foo is roughly in the set TCP, ConnFD, ConnRW, and similer > for SupErrno vs. CErrno, but don't take my word for it, try the > current source. There are more changes than that, such as adapt for > non-const errno values, fixes for big endian 64bit system (a rare > thing, I realize)... Anyway, I checked out cm3 from cvs and spent a while (that's another story) getting a lot of it built and shipped. I'm not quite sure if you're enumerating the things I still have to do, or the things that already have been done on the mainline CVS version. Most of the Sup things seem to be gone already, except suptcp and suplib are still there. Or maybe I haven't looked in the right places yet. I ran ..//scripts/do-pkg.sh buildship cvsup in the source tree as obtained from CVS, without changes, and got no complaints about suptcp (but maybe they were masked by other problems, in which case I'll get around to them soon). Instead I got a complaint that seems to have nothing at all to do with sup: Fatal Error: duplicate unit: ../suplib/src/text_cm3/CText.m3 ../suplib/src/text_pm3/CText.m3 Would this be related to the TEXT changes that are going on? -- hendrik From jay.krell at cornell.edu Wed Apr 15 12:59:59 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 15 Apr 2009 10:59:59 +0000 Subject: [M3devel] cvsup In-Reply-To: <20090415025432.GA3881@topoi.pooq.com> References: <20090413150854.GA32577@topoi.pooq.com> <20090413192006.GA660@topoi.pooq.com> <20090414021311.GB1549@topoi.pooq.com> <20090415025432.GA3881@topoi.pooq.com> Message-ID: Again, the current source builds. The stuff I listed is some of what I did, what you would have to do if you started with the snapshop. I shouldn't have mentioned it. I did not make "do-pkg cvsup" and such work however. Or test it. But it might work, like do-pkg suplib && do-pkg cvsup/server && do-pkg cvsup/client. The error indicates you don't have current source maybe. Or, whatever, the pm3 vs. cm3 check isn't working. I' think I'll just make unconditional. The text changes do not change the interface or even the underlying data structures/pickes (future changes will conceivable change the underlying structures). Only small bugfixes are even in the mainline. suplib is fine and needed. It is specific to cvsup and a bunch of code unique to it. Just suptcp is dead now. cd $CVSROOT/m3-tools cvs -z3 upd cvsup cd cvsup/suplib cm3 cm3 -ship cd ../server cm3 cm3 -ship (optional) cd ../client cm3 cm3 -ship (optional) (client and server can be built in either order; suplib must be built before either) - Jay From hendrik at topoi.pooq.com Wed Apr 15 15:39:53 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 15 Apr 2009 09:39:53 -0400 Subject: [M3devel] cvsup In-Reply-To: References: <20090413150854.GA32577@topoi.pooq.com> <20090413192006.GA660@topoi.pooq.com> <20090414021311.GB1549@topoi.pooq.com> <20090415025432.GA3881@topoi.pooq.com> Message-ID: <20090415133953.GB5233@topoi.pooq.com> On Wed, Apr 15, 2009 at 10:59:59AM +0000, Jay wrote: > > Again, the current source builds. > The stuff I listed is some of what I did, what > you would have to do if you started with the snapshop. > I shouldn't have mentioned it. > > > I did not make "do-pkg cvsup" and such work however. Or test it. > But it might work, like do-pkg suplib && do-pkg cvsup/server && do-pkg cvsup/client. > The error indicates you don't have current source maybe. Well, I just checked the entire cm3 out from cvs yesterday (or was it the evening before? No earlier, anyway.). > Or, whatever, the pm3 vs. cm3 check isn't working. Perhaps this is the problem. What is the pm3 vs cm3 check? > I' think I'll just make unconditional. > The text changes do not change the interface or even the > underlying data structures/pickes (future changes will conceivable > change the underlying structures). Only small bugfixes > are even in the mainline. So I should see where the extraneous interfece comes from and try to get rid of it. > > > suplib is fine and needed. It is specific to cvsup and a bunch > of code unique to it. > Just suptcp is dead now. > > > cd $CVSROOT/m3-tools > cvs -z3 upd cvsup > cd cvsup/suplib > cm3 > cm3 -ship > cd ../server > cm3 > cm3 -ship (optional) > cd ../client > cm3 > cm3 -ship (optional) Will try this first. -- hendrik > > > (client and server can be built in either order; suplib must be built before either) > > > - Jay From jay.krell at cornell.edu Wed Apr 15 16:12:34 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 15 Apr 2009 14:12:34 +0000 Subject: [M3devel] fewer wrappers/more C? (or a wash?) Message-ID: This "rewrites" ThreadPThread.InitMutex and ThreadPThread.InitCondition in C. They are only a few lines either way. Thereby removing all uses of initMu from Modula-3 and enabling removing the "bridging" of it between Modula-3 and C. Better? I'm not sure. No real difference? Maybe. Likewise can be done for CreateT's allocation/initialization of cond_t. And then MemAlloc/MemFree would be moved. Ultimately this is the route toward - writing most/all of ThreadPThread.c in C - removing most/all bridging I'm aware it should handle out of memory. - Jay Index: ThreadPThread.i3 =================================================================== RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThread.i3,v retrieving revision 1.14 diff -u -r1.14 ThreadPThread.i3 --- ThreadPThread.i3 30 Mar 2009 21:52:15 -0000 1.14 +++ ThreadPThread.i3 15 Apr 2009 14:03:58 -0000 @@ -137,20 +137,10 @@ pthread_mutex_t = ADDRESS; pthread_cond_t = ADDRESS; - -(*CONST*) VAR sizeof_pthread_mutex_t:int; - (*CONST*) VAR sizeof_pthread_cond_t:int; -PROCEDURE pthread_mutex_init(mutex: pthread_mutex_t; attr:ADDRESS:=NIL):int; - -(* This wrapper has some OS-specific bug workarounds. *) - -PROCEDURE pthread_mutex_destroy(mutex: pthread_mutex_t):int; - - PROCEDURE pthread_mutex_lock(mutex: pthread_mutex_t):int; @@ -170,4 +160,12 @@ (*---------------------------------------------------------------------------*) + +PROCEDURE InitMutex (MutexRoot: REFANY; VAR pthread_mutex: pthread_mutex_t); + + +PROCEDURE InitCondition (ConditionRoot: REFANY; VAR pthread_mutex: pthread_mutex_t); + +(*---------------------------------------------------------------------------*) + END ThreadPThread. Index: ThreadPThread.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThread.m3,v retrieving revision 1.101 diff -u -r1.101 ThreadPThread.m3 --- ThreadPThread.m3 30 Mar 2009 21:59:31 -0000 1.101 +++ ThreadPThread.m3 15 Apr 2009 14:03:58 -0000 @@ -155,35 +155,13 @@ m.release (); END Release; -PROCEDURE CleanMutex (r: REFANY) = - VAR m := NARROW(r, Mutex); - BEGIN - WITH r = pthread_mutex_destroy (m.mutex) DO END; - MemFree(m.mutex); - END CleanMutex; - -PROCEDURE InitMutex (m: Mutex) = - VAR mutex: pthread_mutex_t; - BEGIN - TRY - WITH r = pthread_mutex_lock_init() DO END; - IF m.mutex # NIL THEN RETURN END; - mutex := MemAlloc(sizeof_pthread_mutex_t); - WITH r = pthread_mutex_init(mutex) DO END; - m.mutex := mutex; - FINALLY - WITH r = pthread_mutex_unlock_init() DO END; - END; - RTHeapRep.RegisterFinalCleanup (m, CleanMutex); - END InitMutex; - PROCEDURE LockMutex (m: Mutex) = VAR self := Self(); BEGIN IF self = NIL THEN Die(ThisLine(), "LockMutex called from a non-Modula-3 thread"); END; - IF m.mutex = NIL THEN InitMutex(m) END; + IF m.mutex = NIL THEN InitMutex(m, m.mutex) END; IF perfOn THEN PerfChanged(self.id, State.locking) END; WITH r = pthread_mutex_lock(m.mutex) DO IF r # 0 THEN @@ -211,34 +189,12 @@ (*---------------------------------------- Condition variables and Alerts ---*) -PROCEDURE CleanCondition (r: REFANY) = - VAR c := NARROW(r, Condition); - BEGIN - WITH r = pthread_mutex_destroy (c.mutex) DO END; - MemFree(c.mutex); - END CleanCondition; - -PROCEDURE InitCondition (c: Condition) = - VAR mutex: pthread_mutex_t; - BEGIN - TRY - WITH r = pthread_mutex_lock_init() DO END; - IF c.mutex # NIL THEN RETURN END; - mutex := MemAlloc(sizeof_pthread_mutex_t); - WITH r = pthread_mutex_init(mutex) DO END; - c.mutex := mutex; - FINALLY - WITH r = pthread_mutex_unlock_init() DO END; - END; - RTHeapRep.RegisterFinalCleanup (c, CleanCondition); - END InitCondition; - PROCEDURE XWait (self: T; m: Mutex; c: Condition; alertable: BOOLEAN) RAISES {Alerted} = (* LL = m *) VAR next, prev: T; BEGIN - IF c.mutex = NIL THEN InitCondition(c) END; + IF c.mutex = NIL THEN InitCondition(c, c.mutex) END; TRY @@ -325,7 +281,7 @@ PROCEDURE Signal (c: Condition) = BEGIN - IF c.mutex = NIL THEN InitCondition(c) END; + IF c.mutex = NIL THEN InitCondition(c, c.mutex) END; WITH r = pthread_mutex_lock(c.mutex) DO END; IF c.waiters # NIL THEN DequeueHead(c) END; WITH r = pthread_mutex_unlock(c.mutex) DO END; @@ -333,7 +289,7 @@ PROCEDURE Broadcast (c: Condition) = BEGIN - IF c.mutex = NIL THEN InitCondition(c) END; + IF c.mutex = NIL THEN InitCondition(c, c.mutex) END; WITH r = pthread_mutex_lock(c.mutex) DO END; WHILE c.waiters # NIL DO DequeueHead(c) END; WITH r = pthread_mutex_unlock(c.mutex) DO END; Index: ThreadPThreadC.c =================================================================== RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThreadC.c,v retrieving revision 1.19 diff -u -r1.19 ThreadPThreadC.c --- ThreadPThreadC.c 30 Mar 2009 21:52:15 -0000 1.19 +++ ThreadPThreadC.c 15 Apr 2009 14:03:58 -0000 @@ -250,16 +250,12 @@ MUTEX(active) /* global lock for list of active threads */ MUTEX(slot) /* global lock for thread slot table */ -MUTEX(init) /* global lock for initializers */ MUTEX(perf) MUTEX(heap) CONDITION_VARIABLE(heap) THREAD_LOCAL(activations) EXTERN_CONST -int ThreadPThread__sizeof_pthread_mutex_t = sizeof(pthread_mutex_t); - -EXTERN_CONST int ThreadPThread__sizeof_pthread_cond_t = sizeof(pthread_cond_t); int @@ -271,17 +267,83 @@ pthread_mutex_destroy() intermittently returns EBUSY even when there are no threads accessing the mutex. */ int e; - do - { - e = pthread_mutex_destroy(mutex); - } - while (e == EBUSY); + while ((e = pthread_mutex_destroy(mutex)) == EBUSY) { } return e; #else return pthread_mutex_destroy(mutex); #endif } +void RTHeapRep__RegisterFinalCleanup (char* Root, void (*clean)(char*)); + +/* This should be known at compile-time, but I don't know the Modula-3 object model. */ +size_t M3MutexToPthreadMutex; +size_t M3ConditionToPthreadMutex; + +#define MemAlloc ThreadPThread__MemAlloc +#define MemFree ThreadPThread__MemFree + +void* MemAlloc (size_t size); +void MemFree (void* a); + +static void Common_CleanMutex(char* Root, size_t Offset) +{ + pthread_mutex_t** inout_Mutex = (pthread_mutex_t**)(Root + Offset); + pthread_mutex_t* Mutex = *inout_Mutex; + *inout_Mutex = NULL; + if (Mutex != NULL) + { + ThreadPThread__pthread_mutex_destroy(Mutex); + MemFree(Mutex); + } +} + +static void CleanCondition(char* Root) +{ + Common_CleanMutex(Root, M3ConditionToPthreadMutex); +} + +static void CleanMutex(char* Root) +{ + Common_CleanMutex(Root, M3MutexToPthreadMutex); +} + +static void Common_InitMutex(char* Root, pthread_mutex_t** inout_Mutex, size_t* inout_Offset, void (*Clean)(char*)) +{ + static pthread_mutex_t initMu = PTHREAD_MUTEX_INITIALIZER; /* global lock for initializers */ + size_t Offset = *inout_Offset; + + if (Offset == 0) + *inout_Offset = (((char*)inout_Mutex) - Root); + else + assert(Offset == (((char*)inout_Mutex) - Root)); + assert((char*)inout_Mutex>= Root); + + pthread_mutex_lock(&initMu); + if (*inout_Mutex == NULL) + { + pthread_mutex_t* Mutex = (pthread_mutex_t*)calloc(1, sizeof(*Mutex)); + if (Mutex) + { + pthread_mutex_init(Mutex, NULL); + *inout_Mutex = Mutex; + } + } + pthread_mutex_unlock(&initMu); + + RTHeapRep__RegisterFinalCleanup (Root, Clean); +} + +void ThreadPThread__InitMutex(char* Root, pthread_mutex_t** Mutex) +{ + Common_InitMutex(Root, Mutex, &M3MutexToPthreadMutex, CleanMutex); +} + +void ThreadPThread__InitCondition (char* Root, pthread_mutex_t** Mutex) +{ + Common_InitMutex(Root, Mutex, &M3ConditionToPthreadMutex, CleanCondition); +} + #ifdef __cplusplus } /* extern "C" */ #endif -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ThreadPThreadC.c URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ThreadPThread.m3 URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt URL: From jay.krell at cornell.edu Wed Apr 15 16:09:33 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 15 Apr 2009 14:09:33 +0000 Subject: [M3devel] cvsup In-Reply-To: <20090415133953.GB5233@topoi.pooq.com> References: <20090413150854.GA32577@topoi.pooq.com> <20090413192006.GA660@topoi.pooq.com> <20090414021311.GB1549@topoi.pooq.com> <20090415025432.GA3881@topoi.pooq.com> <20090415133953.GB5233@topoi.pooq.com> Message-ID: cm3/m3-tools/cvsup/quake/cvsup.quake I made it unconditional after your mail. There is code that is PM3 or CM3 or SRC specific and tries to pick the right one by sniffing the compiler. or Windows, easy to find it: cd \dev2\cm3\m3-tools\cvsup findstr /s PM3 * or dir /s/b/a-d | findstr /i cm3 dir /s/b/a-d | findstr /i pm3 It should all be easy to find. But again, it should just work from current cvs. - Jay From hendrik at topoi.pooq.com Wed Apr 15 19:25:29 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 15 Apr 2009 13:25:29 -0400 Subject: [M3devel] cvsup In-Reply-To: References: <20090413150854.GA32577@topoi.pooq.com> <20090413192006.GA660@topoi.pooq.com> <20090414021311.GB1549@topoi.pooq.com> <20090415025432.GA3881@topoi.pooq.com> <20090415133953.GB5233@topoi.pooq.com> Message-ID: <20090415172529.GA5566@topoi.pooq.com> On Wed, Apr 15, 2009 at 02:09:33PM +0000, Jay wrote: > > cm3/m3-tools/cvsup/quake/cvsup.quake > I made it unconditional after your mail. Maybe that's why it works now. And cvsup runs and I now have over a gigabyte of Modula 3 .v files. Next to figure out what monotone wants me to do with them. -- hendrik From hosking at cs.purdue.edu Fri Apr 17 04:54:13 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 17 Apr 2009 12:54:13 +1000 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <200904141656.n3EGuYuZ061174@camembert.async.caltech.edu> References: <200904141656.n3EGuYuZ061174@camembert.async.caltech.edu> Message-ID: <0DEE58D2-97B2-4BE3-A5F9-4FAFC326EC68@cs.purdue.edu> Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 15 Apr 2009, at 02:56, Mika Nystrom wrote: > > I agree with what Hendrik says, but what about TYPECASE, ISTYPE, > NARROW? Those are necessary to make it possible to pass "pointers" > with the low-order bit set outside of unsafe code. > > My feeling is that if Tony can make the necessary changes, it could > be done immediately, and the language issues can be pushed to the > future. But admittedly I'm biased because of the application I'm > working on. I can take care of this next week. > I need to get a recent CM3 up to test the TEXTs.... are they the > default now? > > Mika > > hendrik at topoi.pooq.com writes: >> On Tue, Apr 14, 2009 at 12:02:17PM +0200, Olaf Wagner wrote: >>> If anybody could test Rodney's TEXT changes and provide some >>> information on the impacts on our applications, that would help a >>> lot. >>> >>> I also wasn't able to read and understand all the mails about >>> small objects. >>> (Guessing, I'd say I'd need another day for that :-) >>> Can anybody summarize? >>> Has a conclusion been reached and what will be done/implemented? >>> Is this relevant for the next release, or will it take longer? >> >> Deciding that the garbage collector should test for the low-order >> bit of >> pointers and leave them alone if the bit is set could probably dop >> done >> immediately, and would make it possible for users to build unsafe >> code >> to do the small-objects stuff. This could go in the next release if >> the garbage-collector change wom't upset anything. >> >> There's still some discussion about just what form the final language >> feature should take. I don't know if that will be finished in time >> for >> the release. >> >> -- hendrik >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 17 14:57:10 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 17 Apr 2009 22:57:10 +1000 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: References: Message-ID: I am a little concerned about passing REFANY directly to C code as there is no guarantee that REFANY and C pointers will always be compatible. ADDRESS can more safely be assumed compatible. On 16 Apr 2009, at 00:12, Jay wrote: > > This "rewrites" ThreadPThread.InitMutex and > ThreadPThread.InitCondition in C. > They are only a few lines either way. > Thereby removing all uses of initMu from Modula-3 and enabling > removing > the "bridging" of it between Modula-3 and C. > > > Better? I'm not sure. > No real difference? Maybe. > > > Likewise can be done for CreateT's allocation/initialization of > cond_t. > And then MemAlloc/MemFree would be moved. > > > Ultimately this is the route toward > - writing most/all of ThreadPThread.c in C > - removing most/all bridging > > > I'm aware it should handle out of memory. > > > - Jay > > > Index: ThreadPThread.i3 > =================================================================== > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ > ThreadPThread.i3,v > retrieving revision 1.14 > diff -u -r1.14 ThreadPThread.i3 > --- ThreadPThread.i3 30 Mar 2009 21:52:15 -0000 1.14 > +++ ThreadPThread.i3 15 Apr 2009 14:03:58 -0000 > @@ -137,20 +137,10 @@ > pthread_mutex_t = ADDRESS; > pthread_cond_t = ADDRESS; > > - > -(*CONST*) VAR sizeof_pthread_mutex_t:int; > - > > (*CONST*) VAR sizeof_pthread_cond_t:int; > > > -PROCEDURE pthread_mutex_init(mutex: pthread_mutex_t; > attr:ADDRESS:=NIL):int; > - > -(* This wrapper has some OS-specific bug workarounds. *) > - > -PROCEDURE pthread_mutex_destroy(mutex: pthread_mutex_t):int; > - > - > PROCEDURE pthread_mutex_lock(mutex: pthread_mutex_t):int; > > > @@ -170,4 +160,12 @@ > > (*---------------------------------------------------------------------------*) > > + > +PROCEDURE InitMutex (MutexRoot: REFANY; VAR pthread_mutex: > pthread_mutex_t); > + > + > +PROCEDURE InitCondition (ConditionRoot: REFANY; VAR pthread_mutex: > pthread_mutex_t); > + > + > (*---------------------------------------------------------------------------*) > + > END ThreadPThread. > Index: ThreadPThread.m3 > =================================================================== > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ > ThreadPThread.m3,v > retrieving revision 1.101 > diff -u -r1.101 ThreadPThread.m3 > --- ThreadPThread.m3 30 Mar 2009 21:59:31 -0000 1.101 > +++ ThreadPThread.m3 15 Apr 2009 14:03:58 -0000 > @@ -155,35 +155,13 @@ > m.release (); > END Release; > > -PROCEDURE CleanMutex (r: REFANY) = > - VAR m := NARROW(r, Mutex); > - BEGIN > - WITH r = pthread_mutex_destroy (m.mutex) DO END; > - MemFree(m.mutex); > - END CleanMutex; > - > -PROCEDURE InitMutex (m: Mutex) = > - VAR mutex: pthread_mutex_t; > - BEGIN > - TRY > - WITH r = pthread_mutex_lock_init() DO END; > - IF m.mutex # NIL THEN RETURN END; > - mutex := MemAlloc(sizeof_pthread_mutex_t); > - WITH r = pthread_mutex_init(mutex) DO END; > - m.mutex := mutex; > - FINALLY > - WITH r = pthread_mutex_unlock_init() DO END; > - END; > - RTHeapRep.RegisterFinalCleanup (m, CleanMutex); > - END InitMutex; > - > PROCEDURE LockMutex (m: Mutex) = > VAR self := Self(); > BEGIN > IF self = NIL THEN > Die(ThisLine(), "LockMutex called from a non-Modula-3 thread"); > END; > - IF m.mutex = NIL THEN InitMutex(m) END; > + IF m.mutex = NIL THEN InitMutex(m, m.mutex) END; > IF perfOn THEN PerfChanged(self.id, State.locking) END; > WITH r = pthread_mutex_lock(m.mutex) DO > IF r # 0 THEN > @@ -211,34 +189,12 @@ > > (*---------------------------------------- Condition variables and > Alerts ---*) > > -PROCEDURE CleanCondition (r: REFANY) = > - VAR c := NARROW(r, Condition); > - BEGIN > - WITH r = pthread_mutex_destroy (c.mutex) DO END; > - MemFree(c.mutex); > - END CleanCondition; > - > -PROCEDURE InitCondition (c: Condition) = > - VAR mutex: pthread_mutex_t; > - BEGIN > - TRY > - WITH r = pthread_mutex_lock_init() DO END; > - IF c.mutex # NIL THEN RETURN END; > - mutex := MemAlloc(sizeof_pthread_mutex_t); > - WITH r = pthread_mutex_init(mutex) DO END; > - c.mutex := mutex; > - FINALLY > - WITH r = pthread_mutex_unlock_init() DO END; > - END; > - RTHeapRep.RegisterFinalCleanup (c, CleanCondition); > - END InitCondition; > - > PROCEDURE XWait (self: T; m: Mutex; c: Condition; alertable: BOOLEAN) > RAISES {Alerted} = > (* LL = m *) > VAR next, prev: T; > BEGIN > - IF c.mutex = NIL THEN InitCondition(c) END; > + IF c.mutex = NIL THEN InitCondition(c, c.mutex) END; > TRY > > > @@ -325,7 +281,7 @@ > > PROCEDURE Signal (c: Condition) = > BEGIN > - IF c.mutex = NIL THEN InitCondition(c) END; > + IF c.mutex = NIL THEN InitCondition(c, c.mutex) END; > WITH r = pthread_mutex_lock(c.mutex) DO END; > IF c.waiters # NIL THEN DequeueHead(c) END; > WITH r = pthread_mutex_unlock(c.mutex) DO END; > @@ -333,7 +289,7 @@ > > PROCEDURE Broadcast (c: Condition) = > BEGIN > - IF c.mutex = NIL THEN InitCondition(c) END; > + IF c.mutex = NIL THEN InitCondition(c, c.mutex) END; > WITH r = pthread_mutex_lock(c.mutex) DO END; > WHILE c.waiters # NIL DO DequeueHead(c) END; > WITH r = pthread_mutex_unlock(c.mutex) DO END; > Index: ThreadPThreadC.c > =================================================================== > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ > ThreadPThreadC.c,v > retrieving revision 1.19 > diff -u -r1.19 ThreadPThreadC.c > --- ThreadPThreadC.c 30 Mar 2009 21:52:15 -0000 1.19 > +++ ThreadPThreadC.c 15 Apr 2009 14:03:58 -0000 > @@ -250,16 +250,12 @@ > > MUTEX(active) /* global lock for list of active threads */ > MUTEX(slot) /* global lock for thread slot table */ > -MUTEX(init) /* global lock for initializers */ > MUTEX(perf) > MUTEX(heap) > CONDITION_VARIABLE(heap) > THREAD_LOCAL(activations) > > EXTERN_CONST > -int ThreadPThread__sizeof_pthread_mutex_t = sizeof(pthread_mutex_t); > - > -EXTERN_CONST > int ThreadPThread__sizeof_pthread_cond_t = sizeof(pthread_cond_t); > > int > @@ -271,17 +267,83 @@ > pthread_mutex_destroy() intermittently returns > EBUSY even when there are no threads accessing the mutex. */ > int e; > - do > - { > - e = pthread_mutex_destroy(mutex); > - } > - while (e == EBUSY); > + while ((e = pthread_mutex_destroy(mutex)) == EBUSY) { } > return e; > #else > return pthread_mutex_destroy(mutex); > #endif > } > > +void RTHeapRep__RegisterFinalCleanup (char* Root, void (*clean) > (char*)); > + > +/* This should be known at compile-time, but I don't know the > Modula-3 object model. */ > +size_t M3MutexToPthreadMutex; > +size_t M3ConditionToPthreadMutex; > + > +#define MemAlloc ThreadPThread__MemAlloc > +#define MemFree ThreadPThread__MemFree > + > +void* MemAlloc (size_t size); > +void MemFree (void* a); > + > +static void Common_CleanMutex(char* Root, size_t Offset) > +{ > + pthread_mutex_t** inout_Mutex = (pthread_mutex_t**)(Root + > Offset); > + pthread_mutex_t* Mutex = *inout_Mutex; > + *inout_Mutex = NULL; > + if (Mutex != NULL) > + { > + ThreadPThread__pthread_mutex_destroy(Mutex); > + MemFree(Mutex); > + } > +} > + > +static void CleanCondition(char* Root) > +{ > + Common_CleanMutex(Root, M3ConditionToPthreadMutex); > +} > + > +static void CleanMutex(char* Root) > +{ > + Common_CleanMutex(Root, M3MutexToPthreadMutex); > +} > + > +static void Common_InitMutex(char* Root, pthread_mutex_t** > inout_Mutex, size_t* inout_Offset, void (*Clean)(char*)) > +{ > + static pthread_mutex_t initMu = PTHREAD_MUTEX_INITIALIZER; /* > global lock for initializers */ > + size_t Offset = *inout_Offset; > + > + if (Offset == 0) > + *inout_Offset = (((char*)inout_Mutex) - Root); > + else > + assert(Offset == (((char*)inout_Mutex) - Root)); > + assert((char*)inout_Mutex>= Root); > + > + pthread_mutex_lock(&initMu); > + if (*inout_Mutex == NULL) > + { > + pthread_mutex_t* Mutex = (pthread_mutex_t*)calloc(1, > sizeof(*Mutex)); > + if (Mutex) > + { > + pthread_mutex_init(Mutex, NULL); > + *inout_Mutex = Mutex; > + } > + } > + pthread_mutex_unlock(&initMu); > + > + RTHeapRep__RegisterFinalCleanup (Root, Clean); > +} > + > +void ThreadPThread__InitMutex(char* Root, pthread_mutex_t** Mutex) > +{ > + Common_InitMutex(Root, Mutex, &M3MutexToPthreadMutex, > CleanMutex); > +} > + > +void ThreadPThread__InitCondition (char* Root, pthread_mutex_t** > Mutex) > +{ > + Common_InitMutex(Root, Mutex, &M3ConditionToPthreadMutex, > CleanCondition); > +} > + > #ifdef __cplusplus > } /* extern "C" */ > #endif > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Apr 17 23:48:44 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 17 Apr 2009 21:48:44 +0000 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: References: Message-ID: Ok. And the rest/overall? Usually I'm very certain my "more C code" changes are for the better. In this case it might be a wash. REFANY might have some tag bits set? ADDRESS really is/must-be a direct pointer that us C programmers are familiar with? UNTRACED REF T would have to be a plain old pointer too right? - Jay ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: fewer wrappers/more C? (or a wash?) > Date: Fri, 17 Apr 2009 22:57:10 +1000 > > I am a little concerned about passing REFANY directly to C code as there is no guarantee that REFANY and C pointers will always be compatible. ADDRESS can more safely be assumed compatible. > > On 16 Apr 2009, at 00:12, Jay wrote: > > > This "rewrites" ThreadPThread.InitMutex and ThreadPThread.InitCondition in C. > They are only a few lines either way. > Thereby removing all uses of initMu from Modula-3 and enabling removing > the "bridging" of it between Modula-3 and C. > > > Better? I'm not sure. > No real difference? Maybe. > > > Likewise can be done for CreateT's allocation/initialization of cond_t. > And then MemAlloc/MemFree would be moved. > > > Ultimately this is the route toward > - writing most/all of ThreadPThread.c in C > - removing most/all bridging > > > I'm aware it should handle out of memory. > > > - Jay > > > Index: ThreadPThread.i3 > =================================================================== > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThread.i3,v > retrieving revision 1.14 > diff -u -r1.14 ThreadPThread.i3 > --- ThreadPThread.i3 30 Mar 2009 21:52:15 -0000 1.14 > +++ ThreadPThread.i3 15 Apr 2009 14:03:58 -0000 > @@ -137,20 +137,10 @@ > pthread_mutex_t = ADDRESS; > pthread_cond_t = ADDRESS; > > - > -(*CONST*) VAR sizeof_pthread_mutex_t:int; > - > > (*CONST*) VAR sizeof_pthread_cond_t:int; > > > -PROCEDURE pthread_mutex_init(mutex: pthread_mutex_t; attr:ADDRESS:=NIL):int; > - > -(* This wrapper has some OS-specific bug workarounds. *) > - > -PROCEDURE pthread_mutex_destroy(mutex: pthread_mutex_t):int; > - > - > PROCEDURE pthread_mutex_lock(mutex: pthread_mutex_t):int; > > > @@ -170,4 +160,12 @@ > > (*---------------------------------------------------------------------------*) > > + > +PROCEDURE InitMutex (MutexRoot: REFANY; VAR pthread_mutex: pthread_mutex_t); > + > + > +PROCEDURE InitCondition (ConditionRoot: REFANY; VAR pthread_mutex: pthread_mutex_t); > + > +(*---------------------------------------------------------------------------*) > + > END ThreadPThread. > Index: ThreadPThread.m3 > =================================================================== > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThread.m3,v > retrieving revision 1.101 > diff -u -r1.101 ThreadPThread.m3 > --- ThreadPThread.m3 30 Mar 2009 21:59:31 -0000 1.101 > +++ ThreadPThread.m3 15 Apr 2009 14:03:58 -0000 > @@ -155,35 +155,13 @@ > m.release (); > END Release; > > -PROCEDURE CleanMutex (r: REFANY) = > - VAR m := NARROW(r, Mutex); > - BEGIN > - WITH r = pthread_mutex_destroy (m.mutex) DO END; > - MemFree(m.mutex); > - END CleanMutex; > - > -PROCEDURE InitMutex (m: Mutex) = > - VAR mutex: pthread_mutex_t; > - BEGIN > - TRY > - WITH r = pthread_mutex_lock_init() DO END; > - IF m.mutex # NIL THEN RETURN END; > - mutex := MemAlloc(sizeof_pthread_mutex_t); > - WITH r = pthread_mutex_init(mutex) DO END; > - m.mutex := mutex; > - FINALLY > - WITH r = pthread_mutex_unlock_init() DO END; > - END; > - RTHeapRep.RegisterFinalCleanup (m, CleanMutex); > - END InitMutex; > - > PROCEDURE LockMutex (m: Mutex) = > VAR self := Self(); > BEGIN > IF self = NIL THEN > Die(ThisLine(), "LockMutex called from a non-Modula-3 thread"); > END; > - IF m.mutex = NIL THEN InitMutex(m) END; > + IF m.mutex = NIL THEN InitMutex(m, m.mutex) END; > IF perfOn THEN PerfChanged(self.id, State.locking) END; > WITH r = pthread_mutex_lock(m.mutex) DO > IF r # 0 THEN > @@ -211,34 +189,12 @@ > > (*---------------------------------------- Condition variables and Alerts ---*) > > -PROCEDURE CleanCondition (r: REFANY) = > - VAR c := NARROW(r, Condition); > - BEGIN > - WITH r = pthread_mutex_destroy (c.mutex) DO END; > - MemFree(c.mutex); > - END CleanCondition; > - > -PROCEDURE InitCondition (c: Condition) = > - VAR mutex: pthread_mutex_t; > - BEGIN > - TRY > - WITH r = pthread_mutex_lock_init() DO END; > - IF c.mutex # NIL THEN RETURN END; > - mutex := MemAlloc(sizeof_pthread_mutex_t); > - WITH r = pthread_mutex_init(mutex) DO END; > - c.mutex := mutex; > - FINALLY > - WITH r = pthread_mutex_unlock_init() DO END; > - END; > - RTHeapRep.RegisterFinalCleanup (c, CleanCondition); > - END InitCondition; > - > PROCEDURE XWait (self: T; m: Mutex; c: Condition; alertable: BOOLEAN) > RAISES {Alerted} = > (* LL = m *) > VAR next, prev: T; > BEGIN > - IF c.mutex = NIL THEN InitCondition(c) END; > + IF c.mutex = NIL THEN InitCondition(c, c.mutex) END; > TRY > > > @@ -325,7 +281,7 @@ > > PROCEDURE Signal (c: Condition) = > BEGIN > - IF c.mutex = NIL THEN InitCondition(c) END; > + IF c.mutex = NIL THEN InitCondition(c, c.mutex) END; > WITH r = pthread_mutex_lock(c.mutex) DO END; > IF c.waiters # NIL THEN DequeueHead(c) END; > WITH r = pthread_mutex_unlock(c.mutex) DO END; > @@ -333,7 +289,7 @@ > > PROCEDURE Broadcast (c: Condition) = > BEGIN > - IF c.mutex = NIL THEN InitCondition(c) END; > + IF c.mutex = NIL THEN InitCondition(c, c.mutex) END; > WITH r = pthread_mutex_lock(c.mutex) DO END; > WHILE c.waiters # NIL DO DequeueHead(c) END; > WITH r = pthread_mutex_unlock(c.mutex) DO END; > Index: ThreadPThreadC.c > =================================================================== > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThreadC.c,v > retrieving revision 1.19 > diff -u -r1.19 ThreadPThreadC.c > --- ThreadPThreadC.c 30 Mar 2009 21:52:15 -0000 1.19 > +++ ThreadPThreadC.c 15 Apr 2009 14:03:58 -0000 > @@ -250,16 +250,12 @@ > > MUTEX(active) /* global lock for list of active threads */ > MUTEX(slot) /* global lock for thread slot table */ > -MUTEX(init) /* global lock for initializers */ > MUTEX(perf) > MUTEX(heap) > CONDITION_VARIABLE(heap) > THREAD_LOCAL(activations) > > EXTERN_CONST > -int ThreadPThread__sizeof_pthread_mutex_t = sizeof(pthread_mutex_t); > - > -EXTERN_CONST > int ThreadPThread__sizeof_pthread_cond_t = sizeof(pthread_cond_t); > > int > @@ -271,17 +267,83 @@ > pthread_mutex_destroy() intermittently returns > EBUSY even when there are no threads accessing the mutex. */ > int e; > - do > - { > - e = pthread_mutex_destroy(mutex); > - } > - while (e == EBUSY); > + while ((e = pthread_mutex_destroy(mutex)) == EBUSY) { } > return e; > #else > return pthread_mutex_destroy(mutex); > #endif > } > > +void RTHeapRep__RegisterFinalCleanup (char* Root, void (*clean)(char*)); > + > +/* This should be known at compile-time, but I don't know the Modula-3 object model. */ > +size_t M3MutexToPthreadMutex; > +size_t M3ConditionToPthreadMutex; > + > +#define MemAlloc ThreadPThread__MemAlloc > +#define MemFree ThreadPThread__MemFree > + > +void* MemAlloc (size_t size); > +void MemFree (void* a); > + > +static void Common_CleanMutex(char* Root, size_t Offset) > +{ > + pthread_mutex_t** inout_Mutex = (pthread_mutex_t**)(Root + Offset); > + pthread_mutex_t* Mutex = *inout_Mutex; > + *inout_Mutex = NULL; > + if (Mutex != NULL) > + { > + ThreadPThread__pthread_mutex_destroy(Mutex); > + MemFree(Mutex); > + } > +} > + > +static void CleanCondition(char* Root) > +{ > + Common_CleanMutex(Root, M3ConditionToPthreadMutex); > +} > + > +static void CleanMutex(char* Root) > +{ > + Common_CleanMutex(Root, M3MutexToPthreadMutex); > +} > + > +static void Common_InitMutex(char* Root, pthread_mutex_t** inout_Mutex, size_t* inout_Offset, void (*Clean)(char*)) > +{ > + static pthread_mutex_t initMu = PTHREAD_MUTEX_INITIALIZER; /* global lock for initializers */ > + size_t Offset = *inout_Offset; > + > + if (Offset == 0) > + *inout_Offset = (((char*)inout_Mutex) - Root); > + else > + assert(Offset == (((char*)inout_Mutex) - Root)); > + assert((char*)inout_Mutex>= Root); > + > + pthread_mutex_lock(&initMu); > + if (*inout_Mutex == NULL) > + { > + pthread_mutex_t* Mutex = (pthread_mutex_t*)calloc(1, sizeof(*Mutex)); > + if (Mutex) > + { > + pthread_mutex_init(Mutex, NULL); > + *inout_Mutex = Mutex; > + } > + } > + pthread_mutex_unlock(&initMu); > + > + RTHeapRep__RegisterFinalCleanup (Root, Clean); > +} > + > +void ThreadPThread__InitMutex(char* Root, pthread_mutex_t** Mutex) > +{ > + Common_InitMutex(Root, Mutex, &M3MutexToPthreadMutex, CleanMutex); > +} > + > +void ThreadPThread__InitCondition (char* Root, pthread_mutex_t** Mutex) > +{ > + Common_InitMutex(Root, Mutex, &M3ConditionToPthreadMutex, CleanCondition); > +} > + > #ifdef __cplusplus > } /* extern "C" */ > #endif > > From hendrik at topoi.pooq.com Sat Apr 18 00:02:58 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 17 Apr 2009 18:02:58 -0400 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <0DEE58D2-97B2-4BE3-A5F9-4FAFC326EC68@cs.purdue.edu> References: <200904141656.n3EGuYuZ061174@camembert.async.caltech.edu> <0DEE58D2-97B2-4BE3-A5F9-4FAFC326EC68@cs.purdue.edu> Message-ID: <20090417220257.GB15700@topoi.pooq.com> On Fri, Apr 17, 2009 at 12:54:13PM +1000, Tony Hosking wrote: > > On 15 Apr 2009, at 02:56, Mika Nystrom wrote: > > > > >I agree with what Hendrik says, but what about TYPECASE, ISTYPE, > >NARROW? Those are necessary to make it possible to pass "pointers" > >with the low-order bit set outside of unsafe code. > > > >My feeling is that if Tony can make the necessary changes, it could should > >be done immediately, and the language issues can be pushed to the > >future. But admittedly I'm biased because of the application I'm > >working on. > > I can take care of this next week. I'm in favour of trying it out before freezing the feature. That means going ahead now with an implementation, and reconsidering it in a few months. Perhaps marking it experimental with an appropriate warning message. A few months is little enough time to use it that it won't be traumatic if code that uses the new features has to be partially rewritten. -- hendrik From rcoleburn at scires.com Sat Apr 18 01:07:02 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 17 Apr 2009 19:07:02 -0400 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <20090417220257.GB15700@topoi.pooq.com> References: <200904141656.n3EGuYuZ061174@camembert.async.caltech.edu> <0DEE58D2-97B2-4BE3-A5F9-4FAFC326EC68@cs.purdue.edu> <20090417220257.GB15700@topoi.pooq.com> Message-ID: <49E8D325.1E75.00D7.1@scires.com> There have been a lot of messages flying back and forth on this idea of adding some sort of tagged ref. I'm afraid I've gotten lost on what exactly is being proposed. Can someone please succinctly state the proposal again along with the reasoning behind why it should be done--what does this change enable us to do that we couldn't do before? Based on the messages, I'm not sure that Mika, Tony, Rodney, et al are all saying the same thing. Also, not sure I clued into the significance of the LSB value. Regards, Randy >>> 4/17/2009 6:02 PM >>> On Fri, Apr 17, 2009 at 12:54:13PM +1000, Tony Hosking wrote: > > On 15 Apr 2009, at 02:56, Mika Nystrom wrote: > > > > >I agree with what Hendrik says, but what about TYPECASE, ISTYPE, > >NARROW? Those are necessary to make it possible to pass "pointers" > >with the low-order bit set outside of unsafe code. > > > >My feeling is that if Tony can make the necessary changes, it could should > >be done immediately, and the language issues can be pushed to the > >future. But admittedly I'm biased because of the application I'm > >working on. > > I can take care of this next week. I'm in favour of trying it out before freezing the feature. That means going ahead now with an implementation, and reconsidering it in a few months. Perhaps marking it experimental with an appropriate warning message. A few months is little enough time to use it that it won't be traumatic if code that uses the new features has to be partially rewritten. -- hendrik CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Apr 19 04:58:37 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 18 Apr 2009 19:58:37 -0700 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: Your message of "Fri, 17 Apr 2009 19:07:02 EDT." <49E8D325.1E75.00D7.1@scires.com> Message-ID: <200904190258.n3J2wcfG066701@camembert.async.caltech.edu> Randy, I think Tony and I are on the same page. I've proposed that the runtime and compiler be modified as necessary to allow values of type REFANY to hold, instead of an actual memory reference, an arbitrary (wordsize-1)-bit integer. The necessary changes would only guarantee that the type safety of Modula-3 could not be subverted within any type of safe code by any manipulations involving these new REFANY values. The necessary modifications are pretty limited: a tag check for uses of ISTYPE, NARROW, TYPECASE, and TYPECODE on values known only to be REFANY. Rodney has proposed adding a type constructor (I think that's the right terminology) to permit tagged values as above to be held in variables of type other than REFANY. And our disagreement at this point I think is only on whether REFANY itself should then be allowed to hold the tagged values, as it wouldn't strictly speaking be necessary, but I contend there are good "software engineering" reasons for permitting it. There are several applications for this idea. Think of it as using all those unused values of a reference. My application is to do small integers (a la Smalltalk); Rodney wants to do efficient data structures that can either be small (max 31 bits) or pointers to something bigger. In the former case they wouldn't involve memory allocation or garbage collection. Mika "Randy Coleburn" writes: >This is a MIME message. If you are reading this text, you may want to >consider changing to a mail reader or gateway that understands how to >properly handle MIME multipart messages. > >--=__Part456DE886.0__= >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: quoted-printable > >There have been a lot of messages flying back and forth on this idea of = >adding some sort of tagged ref. I'm afraid I've gotten lost on what = >exactly is being proposed. >=20 >Can someone please succinctly state the proposal again along with the = >reasoning behind why it should be done--what does this change enable us to = >do that we couldn't do before? Based on the messages, I'm not sure that = >Mika, Tony, Rodney, et al are all saying the same thing. >=20 >Also, not sure I clued into the significance of the LSB value. >=20 >Regards, >Randy > >>>> 4/17/2009 6:02 PM >>> >On Fri, Apr 17, 2009 at 12:54:13PM +1000, Tony Hosking wrote: >>=20 >> On 15 Apr 2009, at 02:56, Mika Nystrom wrote: >>=20 >> > >> >I agree with what Hendrik says, but what about TYPECASE, ISTYPE, >> >NARROW? Those are necessary to make it possible to pass "pointers" >> >with the low-order bit set outside of unsafe code. >> > >> >My feeling is that if Tony can make the necessary changes, it could > should >> >be done immediately, and the language issues can be pushed to the >> >future. But admittedly I'm biased because of the application I'm >> >working on. >>=20 >> I can take care of this next week. > >I'm in favour of trying it out before freezing the feature. That=20 >means going ahead now with an implementation, and reconsidering it=20 >in a few months. Perhaps marking it experimental with an appropriate=20 >warning message. A few months is little enough time to use it that it=20 >won't be traumatic if code that uses the new features has to be=20 >partially rewritten. > >-- hendrik > > >CONFIDENTIALITY NOTICE: This email and any attachments are intended = >solely for the use of the named recipient(s). This e-mail may contain = >confidential and/or proprietary information of Scientific Research = >Corporation. If you are not a named recipient, you are prohibited from = >making any use of the information in the email and attachments. If you = >believe you have received this email in error, please notify the sender = >immediately and permanently delete the email, any attachments, and all = >copies thereof from any drives or storage media and destroy any printouts = >of the email or attachments. > >EXPORT COMPLIANCE NOTICE: This email and any attachments may contain = >technical data subject to U.S export restrictions under the International = >Traffic in Arms Regulations (ITAR) or the Export Administration Regulations= > (EAR). Export or transfer of this technical data and/or related = >information to any foreign person(s) or entity(ies), either within the = >U.S. or outside of the U.S., may require export authorization by the = >appropriate U.S. Government agency prior to export or transfer. In = >addition, technical data may not be exported or transferred to certain = >countries or specified designated nationals identified by U.S. embargo = >controls without prior export authorization. By accepting this email and = >any attachments, all recipients confirm that they understand and will = >comply with all applicable ITAR, EAR and embargo compliance requirements. > > >--=__Part456DE886.0__= >Content-Type: text/html; charset=US-ASCII >Content-Transfer-Encoding: quoted-printable >Content-Description: HTML > > >"> > > >
There have been a lot of messages flying back and forth on this idea = >of adding some sort of tagged ref.  I'm afraid I've gotten lost on = >what exactly is being proposed.
>
 
>
Can someone please succinctly state the proposal again along with the = >reasoning behind why it should be done--what does this change enable us to = >do that we couldn't do before?  Based on the messages, I'm not sure = >that Mika, Tony, Rodney, et al are all saying the same thing.
>
 
>
Also, not sure I clued into the significance of the LSB value.
>
 
>
Regards,
>
Randy

>>> <hendrik at topoi.pooq.com> 4/17/2009 = >6:02 PM >>>
On Fri, Apr 17, 2009 at 12:54:13PM +1000, Tony = >Hosking wrote:
>
> On 15 Apr 2009, at 02:56, Mika Nystrom = >wrote:
>
> >
> >I agree with what Hendrik says, = >but what about TYPECASE, ISTYPE,
> >NARROW?  Those are = >necessary to make it possible to pass "pointers"
> >with the = >low-order bit set outside of unsafe code.
> >
> >My = >feeling is that if Tony can make the necessary changes, it could
 &= >nbsp;           &nbs= >p;            &= >nbsp;           &nbs= >p;            &= >nbsp;            = >should
> >be done immediately, and the language issues can be = >pushed to the
> >future.  But admittedly I'm biased because = >of the application I'm
> >working on.
>
> I can take = >care of this next week.

I'm in favour of trying it out before = >freezing the feature.  That
means going ahead now with an = >implementation, and reconsidering it
in a few months.  Perhaps = >marking it experimental with an appropriate
warning message.  A = >few months is little enough time to use it that it
won't be traumatic = >if code that uses the new features has to be
partially rewritten.
R>-- hendrik

> >--=__Part456DE886.0__=-- From hendrik at topoi.pooq.com Mon Apr 20 03:21:29 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 19 Apr 2009 21:21:29 -0400 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: References: Message-ID: <20090420012129.GA22387@topoi.pooq.com> On Fri, Apr 17, 2009 at 10:57:10PM +1000, Tony Hosking wrote: > I am a little concerned about passing REFANY directly to C code as > there is no guarantee that REFANY and C pointers will always be > compatible. ADDRESS can more safely be assumed compatible. Indeed, I once read the X toolkit specs, and it was rife with small integers being packed into pointers. Apparently the toolkit resolved it not by a tag bit, but by its magnitude. There was some constant somewhere that identified which numbers were small enough to be considered not-pointers. This was a discrimination without a tag bit. Similar concept to what we're planning for the future of REFANY, but different implementation. I don't know how they figured out which pointer values were safe to treat as integers. -- hendrik From rodney.m.bates at cox.net Mon Apr 20 04:37:37 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Sun, 19 Apr 2009 21:37:37 -0500 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <49E8D325.1E75.00D7.1@scires.com> References: <200904141656.n3EGuYuZ061174@camembert.async.caltech.edu> <0DEE58D2-97B2-4BE3-A5F9-4FAFC326EC68@cs.purdue.edu> <20090417220257.GB15700@topoi.pooq.com> <49E8D325.1E75.00D7.1@scires.com> Message-ID: <49EBDFF1.2070902@cox.net> Randy Coleburn wrote: > There have been a lot of messages flying back and forth on this idea > of adding some sort of tagged ref. I'm afraid I've gotten lost on > what exactly is being proposed. > > Can someone please succinctly state the proposal again along with the > reasoning behind why it should be done--what does this change enable > us to do that we couldn't do before? The idea is to be able to have a "pointer", but certain values of the pointer actually have the desired data right in the "pointer" itself instead of located in a separate object in the heap. If the actual value is relatively small but common, this can save a _lot_ of overhead. I have an abstract data type module that implements sets of integers that are bounded only by the range of INTEGER, in which, for small sets that actually can fit in one word minus one bit, this technique would save memory words 11-to-one. On a 64-bit machine, the savings measured in bytes would be even bigger, and the likelihood the savings would happen would also be greater. Smalltalk implementations have used this idea. In Smalltalk, there is no static typing at all, so all variables have the same universal type, which, at runtime, can hold any value of any type and be changed with every assignment. For some common values such as false, true, and relatively small integers, the value is stored right in the variable. Otherwise, the variable is a pointer to a heap object. The heap object tells what class it belongs to and has other information about the value. Since heap objects are always aligned at least modulo 2, it follows that a heap pointer always has a zero in the lsb. So a one in the lsb can be used as a flag that says the value is right in the variable. Of course, it will have been shifted left by at least a bit in that case. How Smalltalk makes this look abstractly in the language is another story and a bit tricky. Even with a static typing system in Modula-3, the reference types still have at least 2 lsb's that are always zero in a 32-bit system, where heap objects will always be aligned modulo 4. So the idea is to arrange things so that at least the lsb can be used as a tag to indicate that a value is actually stored in the variable rather than in the heap. We seem to be calling these "tagged" values, and also "small objects". With unsafe code, such values can be created and accessed by bit-twiddling. However, the garbage collector as it stands would undoubtedly be confused by improperly aligned reference type values, when they occur in fields/elements inside heap objects. The GC can presumably be easily fixed to tolerate them. But then, other operations in the language would also be broken. The code for NARROW, ISTYPE, TYPECASE, and assignments that implicitly narrow a value would undoubtedly crash if they got a misaligned value of a supposedly reference type. So such values would have to never be given to these four operations. That undermines the language's principle that the writers of unsafe code can, if they coded everything correctly, ensure that all other (safe) code can't suffer events that are not explainable by the rules of the language. So we really should do a language fix, if we are to do this. > Based on the messages, I'm not sure that Mika, Tony, Rodney, et al are > all saying the same thing. > > Also, not sure I clued into the significance of the LSB value. See above. > > Regards, > Randy > > >>> 4/17/2009 6:02 PM >>> > On Fri, Apr 17, 2009 at 12:54:13PM +1000, Tony Hosking wrote: > > > > On 15 Apr 2009, at 02:56, Mika Nystrom wrote: > > > > > > > >I agree with what Hendrik says, but what about TYPECASE, ISTYPE, > > >NARROW? Those are necessary to make it possible to pass "pointers" > > >with the low-order bit set outside of unsafe code. > > > > > >My feeling is that if Tony can make the necessary changes, it could > should > > >be done immediately, and the language issues can be pushed to the > > >future. But admittedly I'm biased because of the application I'm > > >working on. > > > > I can take care of this next week. > > I'm in favour of trying it out before freezing the feature. That > means going ahead now with an implementation, and reconsidering it > in a few months. Perhaps marking it experimental with an appropriate > warning message. A few months is little enough time to use it that it > won't be traumatic if code that uses the new features has to be > partially rewritten. > > -- hendrik > From rodney.m.bates at cox.net Mon Apr 20 04:45:49 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Sun, 19 Apr 2009 21:45:49 -0500 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: <20090420012129.GA22387@topoi.pooq.com> References: <20090420012129.GA22387@topoi.pooq.com> Message-ID: <49EBE1DD.6080809@cox.net> hendrik at topoi.pooq.com wrote: > On Fri, Apr 17, 2009 at 10:57:10PM +1000, Tony Hosking wrote: > >> I am a little concerned about passing REFANY directly to C code as >> there is no guarantee that REFANY and C pointers will always be >> compatible. ADDRESS can more safely be assumed compatible. >> > > Indeed, I once read the X toolkit specs, and it was rife with small > integers being packed into pointers. Apparently the toolkit resolved > it not by a tag bit, but by its magnitude. There was some constant > somewhere that identified which numbers were small enough to be > considered not-pointers. > > This was a discrimination without a tag bit. Similar concept to what > we're planning for the future of REFANY, but different implementation. > > I don't know how they figured out which pointer values were safe to > treat as integers. > In my more elaborate "safe" proposal, at least, the language itself does not specify anything about what the bit-encodings of tagged types are. It's an implementors' option, and the language can support whatever the implementors choose. This could be used to match the X toolkit's encoding. However, using the lsb takes advantage of the fact that heap objects must always be aligned and thus the lsb is already always zero, when it's really a heap pointer. That seems like by far the most efficient encoding. > -- hendrik > > > From jay.krell at cornell.edu Mon Apr 20 05:31:27 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 20 Apr 2009 03:31:27 +0000 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: <49EBE1DD.6080809@cox.net> References: <20090420012129.GA22387@topoi.pooq.com> <49EBE1DD.6080809@cox.net> Message-ID: Um..you know..if you just use ADDRESS instead of REFANY, doesn't that get you what you need, with no language/compiler/runtime changes? Can't you check the low bit of the address and only if it is zero, assign it to a REFANY, and that party (NARROW/ISTYPE/etc.) on the REFANY? Otherwise LOOPHOLE the ADDRESS to an INTEGER and shift it right by one? There is danger here no matter what. Who says heap pointers need any alignment? On most machines they are aligned, but on most machines (x86, AMD64) they don't need to be. x86/AMD64 may have an option for triggering "alignment exceptions" in the hardware, but I don't think any OS ever enables it. And I doubt that any application can. On Windows when dealing with "resources" (strings, bitmaps, etc., same notion as Apple), anything under 64K is considered a small integer. This gives you a system where resources can be efficiently identified by small integers, and you need to coordinate with all contributors of resources to a particular file, or less efficiently but more flexibily use strings and less/no coordination is needed. It's a nice compromise. Very little code relies on the alignment of pointers. It is a "special purpose" kind of thing. Very little code makes these "policy" decisions either. On most machines, the pointer NULL is made invalid at the hardware level by making the first page inaccessible. On most machines, a page is at least 4K. On many machines it is larger, or even variably sized. Going further and always reserving the first 64K of address space is not a big waste. It's not physical memory, it's "just" address space. (It does cost something, but not much; it costs you some reduced capacity) There is danger here no matter what but also a lot of efficiency to be gained in some scenarios. On most machines you can probably take more than 1 bit. On NT the heap allocator aligns to "two pointers", so that gives you 3 (32bit) or 4 (64bit) bits. But that's just for typical code. Modula-3 usually allocates with mmap/sbrk/VirtualAlloc, giving it at least 4K alignment, probably in reality something larger like 64K. It is the under its control to subdivide that as it sees fit. So you could arbitrarily decree that all Modula-3 objects are aligned at say 32 bytes and have 5 tag bits. It's just that at some point you start wasting space. Allocating a bunch of 10 byte objects with 32 byte alignment wastes a lot of space. But allocating a bunch of 32 or 64 or 96 etc., byte objects with 32 byte alignment wastes nothing.. On NT as well, historically, the address space was split in two. (It still is split, but details vary). The upper bit was zero for usermode, one for kernelmode. Therefore, historically, another avenue this proposal could take is to use the high bit for a tag bit. Assuming nobody is writing drivers in kernel mode. However, this 2gig/2gig split can be constraining on usermode (and kernelmode..). So there is an option at boot-time to make it 3gig/1gig -- 3gig user mode, 1 gig usermode. However that breaks any code that uses the high bit as a tag bit. Therefore executables (.exes, not .dlls) have a flag in them to indicate if they are "large address aware". If they are not, even if you boot /3gig, you still, I guess, won't ever see addresses over 2gig. If you are using tag bits, it then becomes that the upper two bits are: 00: definitely usermode 01: ambiguous 10: definitely kernelmode (can be used as a 30 bit integer) 11: definitely kernelmode (can be used as a 30 bit integer) However if you run a "large address aware" 32bit executable on a 64bit system, you get all 4gig as usermode. The kernelmode addresses are even higher than 4gig and you can't even encode them in a 32bit usermode address, which is fine. It becomes that all addresses are usermode. (This is a little mind-bending at first). Using a small struct with a type tag (possibly an entire pointer) and a separate data word also seems very viable. Very portable, very safe. Just that it grows the representation. - Jay ---------------------------------------- > Date: Sun, 19 Apr 2009 21:45:49 -0500 > From: rodney.m.bates at cox.net > To: m3devel at elegosoft.com > Subject: Re: [M3devel] fewer wrappers/more C? (or a wash?) > > hendrik at topoi.pooq.com wrote: >> On Fri, Apr 17, 2009 at 10:57:10PM +1000, Tony Hosking wrote: >> >>> I am a little concerned about passing REFANY directly to C code as >>> there is no guarantee that REFANY and C pointers will always be >>> compatible. ADDRESS can more safely be assumed compatible. >>> >> >> Indeed, I once read the X toolkit specs, and it was rife with small >> integers being packed into pointers. Apparently the toolkit resolved >> it not by a tag bit, but by its magnitude. There was some constant >> somewhere that identified which numbers were small enough to be >> considered not-pointers. >> >> This was a discrimination without a tag bit. Similar concept to what >> we're planning for the future of REFANY, but different implementation. >> >> I don't know how they figured out which pointer values were safe to >> treat as integers. >> > In my more elaborate "safe" proposal, at least, the language itself > does not specify anything about what the bit-encodings of tagged > types are. It's an implementors' option, and the language > can support whatever the implementors choose. > > This could be used to match the X toolkit's encoding. However, > using the lsb takes advantage of the fact that heap objects must > always be aligned and thus the lsb is already always zero, when > it's really a heap pointer. That seems like by far the most efficient > encoding. >> -- hendrik >> >> >> > From hosking at cs.purdue.edu Mon Apr 20 05:34:15 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 20 Apr 2009 13:34:15 +1000 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: References: <20090420012129.GA22387@topoi.pooq.com> <49EBE1DD.6080809@cox.net> Message-ID: <3130252C-D715-4C35-8F20-5D6BAB71B523@cs.purdue.edu> The proposal that Mika and I have converged on doesn't require language changes. And it works with ISTYPE, etc. Confusing REFANY with ADDRESS is a swamp. On 20 Apr 2009, at 13:31, Jay wrote: > > > Um..you know..if you just use ADDRESS instead of REFANY, doesn't > that get you what you need, with no language/compiler/runtime changes? > > Can't you check the low bit of the address and only if it is zero, > assign it to a REFANY, and that party (NARROW/ISTYPE/etc.) on the > REFANY? Otherwise LOOPHOLE the ADDRESS to an INTEGER and shift it > right by one? > > > > > There is danger here no matter what. > > > Who says heap pointers need any alignment? > > > On most machines they are aligned, but on most machines (x86, AMD64) > they don't need to be. x86/AMD64 may have an option for triggering > "alignment exceptions" in the hardware, but I don't think any OS > ever enables it. And I doubt that any application can. > > > On Windows when dealing with "resources" (strings, bitmaps, etc., > same notion as Apple), anything under 64K is considered a small > integer. > This gives you a system where resources can be efficiently > identified by small integers, and you need to coordinate with all > contributors of resources to a particular file, or less efficiently > but more flexibily use strings and less/no coordination is needed. > It's a nice compromise. > > > Very little code relies on the alignment of pointers. > It is a "special purpose" kind of thing. > > > Very little code makes these "policy" decisions either. > > > On most machines, the pointer NULL is made invalid at the hardware > level by making the first page inaccessible. On most machines, a > page is at least 4K. On many machines it is larger, or even variably > sized. > Going further and always reserving the first 64K of address space is > not a big waste. > It's not physical memory, it's "just" address space. (It does cost > something, but not much; it costs you some reduced capacity) > > > There is danger here no matter what but also a lot of efficiency to > be gained in some scenarios. > > > On most machines you can probably take more than 1 bit. > > > On NT the heap allocator aligns to "two pointers", so that gives you > 3 (32bit) or 4 (64bit) bits. But that's just for typical code. > Modula-3 usually allocates with mmap/sbrk/VirtualAlloc, giving it at > least 4K alignment, probably in reality something larger like 64K. > It is the under its control to subdivide that as it sees fit. > So you could arbitrarily decree that all Modula-3 objects are > aligned at say 32 bytes and have 5 tag bits. It's just that at some > point you start wasting space. Allocating a bunch of 10 byte objects > with 32 byte alignment wastes a lot of space. But allocating a bunch > of 32 or 64 or 96 etc., byte objects with 32 byte alignment wastes > nothing.. > > > On NT as well, historically, the address space was split in two. > (It still is split, but details vary). > The upper bit was zero for usermode, one for kernelmode. > Therefore, historically, another avenue this proposal could take is > to use the high bit for a tag bit. Assuming nobody is writing > drivers in kernel mode. > > > However, this 2gig/2gig split can be constraining on usermode (and > kernelmode..). > So there is an option at boot-time to make it 3gig/1gig -- 3gig user > mode, 1 gig usermode. > However that breaks any code that uses the high bit as a tag bit. > Therefore executables (.exes, not .dlls) have a flag in them to > indicate if they are "large address aware". If they are not, even if > you boot /3gig, you still, I guess, won't ever see addresses over > 2gig. > If you are using tag bits, it then becomes that the upper two bits > are: > 00: definitely usermode > 01: ambiguous > 10: definitely kernelmode (can be used as a 30 bit integer) > 11: definitely kernelmode (can be used as a 30 bit integer) > > > However if you run a "large address aware" 32bit executable on a > 64bit system, you get all 4gig as usermode. The kernelmode addresses > are even higher than 4gig and you can't even encode them in a 32bit > usermode address, which is fine. It becomes that all addresses are > usermode. (This is a little mind-bending at first). > > > Using a small struct with a type tag (possibly an entire pointer) > and a separate data word also seems very viable. Very portable, very > safe. Just that it grows the representation. > > > - Jay > > > > ---------------------------------------- >> Date: Sun, 19 Apr 2009 21:45:49 -0500 >> From: rodney.m.bates at cox.net >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] fewer wrappers/more C? (or a wash?) >> >> hendrik at topoi.pooq.com wrote: >>> On Fri, Apr 17, 2009 at 10:57:10PM +1000, Tony Hosking wrote: >>> >>>> I am a little concerned about passing REFANY directly to C code as >>>> there is no guarantee that REFANY and C pointers will always be >>>> compatible. ADDRESS can more safely be assumed compatible. >>>> >>> >>> Indeed, I once read the X toolkit specs, and it was rife with small >>> integers being packed into pointers. Apparently the toolkit resolved >>> it not by a tag bit, but by its magnitude. There was some constant >>> somewhere that identified which numbers were small enough to be >>> considered not-pointers. >>> >>> This was a discrimination without a tag bit. Similar concept to what >>> we're planning for the future of REFANY, but different >>> implementation. >>> >>> I don't know how they figured out which pointer values were safe to >>> treat as integers. >>> >> In my more elaborate "safe" proposal, at least, the language itself >> does not specify anything about what the bit-encodings of tagged >> types are. It's an implementors' option, and the language >> can support whatever the implementors choose. >> >> This could be used to match the X toolkit's encoding. However, >> using the lsb takes advantage of the fact that heap objects must >> always be aligned and thus the lsb is already always zero, when >> it's really a heap pointer. That seems like by far the most efficient >> encoding. >>> -- hendrik >>> >>> >>> >> From jay.krell at cornell.edu Mon Apr 20 05:36:38 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 20 Apr 2009 03:36:38 +0000 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: References: <20090420012129.GA22387@topoi.pooq.com> <49EBE1DD.6080809@cox.net> Message-ID: > Assuming nobody is writing drivers in kernel mode. I meant, "in Modula-3". Even so, the runtime could discover the tag bits at initialization time. Or more efficiently, the runtime could be built twice. But the variations available make the high bit or bits as a tag not really viable. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: rodney.m.bates at cox.net; m3devel at elegosoft.com > Date: Mon, 20 Apr 2009 03:31:27 +0000 > Subject: Re: [M3devel] fewer wrappers/more C? (or a wash?) > > > > Um..you know..if you just use ADDRESS instead of REFANY, doesn't that get you what you need, with no language/compiler/runtime changes? > > Can't you check the low bit of the address and only if it is zero, assign it to a REFANY, and that party (NARROW/ISTYPE/etc.) on the REFANY? Otherwise LOOPHOLE the ADDRESS to an INTEGER and shift it right by one? > > > > > There is danger here no matter what. > > > Who says heap pointers need any alignment? > > > On most machines they are aligned, but on most machines (x86, AMD64) they don't need to be. x86/AMD64 may have an option for triggering "alignment exceptions" in the hardware, but I don't think any OS ever enables it. And I doubt that any application can. > > > On Windows when dealing with "resources" (strings, bitmaps, etc., same notion as Apple), anything under 64K is considered a small integer. > This gives you a system where resources can be efficiently identified by small integers, and you need to coordinate with all contributors of resources to a particular file, or less efficiently but more flexibily use strings and less/no coordination is needed. It's a nice compromise. > > > Very little code relies on the alignment of pointers. > It is a "special purpose" kind of thing. > > > Very little code makes these "policy" decisions either. > > > On most machines, the pointer NULL is made invalid at the hardware level by making the first page inaccessible. On most machines, a page is at least 4K. On many machines it is larger, or even variably sized. > Going further and always reserving the first 64K of address space is not a big waste. > It's not physical memory, it's "just" address space. (It does cost something, but not much; it costs you some reduced capacity) > > > There is danger here no matter what but also a lot of efficiency to be gained in some scenarios. > > > On most machines you can probably take more than 1 bit. > > > On NT the heap allocator aligns to "two pointers", so that gives you 3 (32bit) or 4 (64bit) bits. But that's just for typical code. Modula-3 usually allocates with mmap/sbrk/VirtualAlloc, giving it at least 4K alignment, probably in reality something larger like 64K. It is the under its control to subdivide that as it sees fit. > So you could arbitrarily decree that all Modula-3 objects are aligned at say 32 bytes and have 5 tag bits. It's just that at some point you start wasting space. Allocating a bunch of 10 byte objects with 32 byte alignment wastes a lot of space. But allocating a bunch of 32 or 64 or 96 etc., byte objects with 32 byte alignment wastes nothing.. > > > On NT as well, historically, the address space was split in two. > (It still is split, but details vary). > The upper bit was zero for usermode, one for kernelmode. > Therefore, historically, another avenue this proposal could take is to use the high bit for a tag bit. Assuming nobody is writing drivers in kernel mode. > > > However, this 2gig/2gig split can be constraining on usermode (and kernelmode..). > So there is an option at boot-time to make it 3gig/1gig -- 3gig user mode, 1 gig usermode. > However that breaks any code that uses the high bit as a tag bit. > Therefore executables (.exes, not .dlls) have a flag in them to indicate if they are "large address aware". If they are not, even if you boot /3gig, you still, I guess, won't ever see addresses over 2gig. > If you are using tag bits, it then becomes that the upper two bits are: > 00: definitely usermode > 01: ambiguous > 10: definitely kernelmode (can be used as a 30 bit integer) > 11: definitely kernelmode (can be used as a 30 bit integer) > > > However if you run a "large address aware" 32bit executable on a 64bit system, you get all 4gig as usermode. The kernelmode addresses are even higher than 4gig and you can't even encode them in a 32bit usermode address, which is fine. It becomes that all addresses are usermode. (This is a little mind-bending at first). > > > Using a small struct with a type tag (possibly an entire pointer) and a separate data word also seems very viable. Very portable, very safe. Just that it grows the representation. > > > - Jay > > > > ---------------------------------------- >> Date: Sun, 19 Apr 2009 21:45:49 -0500 >> From: rodney.m.bates at cox.net >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] fewer wrappers/more C? (or a wash?) >> >> hendrik at topoi.pooq.com wrote: >>> On Fri, Apr 17, 2009 at 10:57:10PM +1000, Tony Hosking wrote: >>> >>>> I am a little concerned about passing REFANY directly to C code as >>>> there is no guarantee that REFANY and C pointers will always be >>>> compatible. ADDRESS can more safely be assumed compatible. >>>> >>> >>> Indeed, I once read the X toolkit specs, and it was rife with small >>> integers being packed into pointers. Apparently the toolkit resolved >>> it not by a tag bit, but by its magnitude. There was some constant >>> somewhere that identified which numbers were small enough to be >>> considered not-pointers. >>> >>> This was a discrimination without a tag bit. Similar concept to what >>> we're planning for the future of REFANY, but different implementation. >>> >>> I don't know how they figured out which pointer values were safe to >>> treat as integers. >>> >> In my more elaborate "safe" proposal, at least, the language itself >> does not specify anything about what the bit-encodings of tagged >> types are. It's an implementors' option, and the language >> can support whatever the implementors choose. >> >> This could be used to match the X toolkit's encoding. However, >> using the lsb takes advantage of the fact that heap objects must >> always be aligned and thus the lsb is already always zero, when >> it's really a heap pointer. That seems like by far the most efficient >> encoding. >>> -- hendrik >>> >>> >>> >> From jay.krell at cornell.edu Mon Apr 20 05:46:30 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 20 Apr 2009 03:46:30 +0000 Subject: [M3devel] explanation of CheckLoadTracedRef? Message-ID: - What does CheckLoadTracedRef and co. do? - Can the compiler be smarter? Easily/effectively? I'm just reading code to understand the object model.. and I see like this: b.F1(1); (* line 60 *) b.F2(2); .stabn 68,0,60,LM17-LFBB2 (",60," means line 60) LM17: movl _MM_Main+584, %esi testl %esi, %esi je L13 testb $64, -2(%esi) je L13 movl %esi, (%esp) call _RTHooks__CheckLoadTracedRef L13: movl (%esi), %eax movl (%eax), %ebx movl $1, 4(%esp) movl %esi, (%esp) call *%ebx .stabn 68,0,61,LM18-LFBB2 (",61," means line 61) LM18: movl _MM_Main+584, %ebx testl %ebx, %ebx je L14 testb $64, -2(%ebx) je L14 movl %ebx, (%esp) call _RTHooks__CheckLoadTracedRef L14: movl (%ebx), %eax movl 4(%eax), %esi movl $2, 4(%esp) movl %ebx, (%esp) call *%esi Does one really need to "check" pointers so often? You know, like twice in a row? Granted, there is a call in between. I understand, that one call could have done "anything". Ok, here is another case cm3 -O, cm3cg -O3, no intervening function call, still two checks: T3 = OBJECT a: INTEGER; END; c := NEW(T3); RTIO.PutInt(c.a + c.a); .stabn 68,0,63,LM20-LFBB2 LM20: movl _MM_Main+588, %esi testl %esi, %esi je L15 testb $64, -2(%esi) je L15 movl %esi, (%esp) call _RTHooks__CheckLoadTracedRef L15: movl _MM_Main+588, %ebx testl %ebx, %ebx je L16 testb $64, -2(%ebx) je L16 movl %ebx, (%esp) call _RTHooks__CheckLoadTracedRef L16: movl $0, 4(%esp) movl 4(%ebx), %eax addl 4(%esi), %eax movl %eax, (%esp) call _RTIO__PutInt I'm of two minds on optimizing though. Do it. Don't it. I don't like debugging optimize code. Nor do I want to waste time having the compiler make the code less debuggable. But when I look at the code and how bad the code quality is, and that it could be substantially better without sacrificing debuging... This example is somewhat contrived, but the code seems like 33% waste. Eventually that much bloat is going to cost in terms of I/O in the assembly, linker, paging it in at runtime, and even a little extra to run it. "Now that I understand things somewhat better.." How bad/unportable was it the previous way, the VM-synchronized way? Can the checks only be generated for calls to extern functions? When I write C wrappers, am I missing checks? (I can check, maybe the checks are generated). Are they missing sometimes with regard to X Windows? I think I understand just barely some of what is going on. That writes through pointers need to be checked. Because objects can move around. But moving objects doesn't update the references, but instead marks pages as different? (In the VM-synchronized world, moving an object would mark its original page invalid, triggering a page fault upon subsequent access, which is handled by referencing the new location and maybe updating the old pointer). ??? Something like that ??? - Jay From jay.krell at cornell.edu Mon Apr 20 05:48:00 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 20 Apr 2009 03:48:00 +0000 Subject: [M3devel] explanation of CheckLoadTracedRef? Message-ID: - What does CheckLoadTracedRef and co. do? - Can the compiler be smarter? Easily/effectively? I'm just reading code to understand the object model.. and I see like this: b.F1(1); (* line 60 *) b.F2(2); .stabn 68,0,60,LM17-LFBB2 (",60," means line 60) LM17: movl _MM_Main+584, %esi testl %esi, %esi je L13 testb $64, -2(%esi) je L13 movl %esi, (%esp) call _RTHooks__CheckLoadTracedRef L13: movl (%esi), %eax movl (%eax), %ebx movl $1, 4(%esp) movl %esi, (%esp) call *%ebx .stabn 68,0,61,LM18-LFBB2 (",61," means line 61) LM18: movl _MM_Main+584, %ebx testl %ebx, %ebx je L14 testb $64, -2(%ebx) je L14 movl %ebx, (%esp) call _RTHooks__CheckLoadTracedRef L14: movl (%ebx), %eax movl 4(%eax), %esi movl $2, 4(%esp) movl %ebx, (%esp) call *%esi Does one really need to "check" pointers so often? You know, like twice in a row? Granted, there is a call in between. I understand, that one call could have done "anything". Ok, here is another case cm3 -O, cm3cg -O3, no intervening function call, still two checks: T3 = OBJECT a: INTEGER; END; c := NEW(T3); RTIO.PutInt(c.a + c.a); .stabn 68,0,63,LM20-LFBB2 LM20: movl _MM_Main+588, %esi testl %esi, %esi je L15 testb $64, -2(%esi) je L15 movl %esi, (%esp) call _RTHooks__CheckLoadTracedRef L15: movl _MM_Main+588, %ebx testl %ebx, %ebx je L16 testb $64, -2(%ebx) je L16 movl %ebx, (%esp) call _RTHooks__CheckLoadTracedRef L16: movl $0, 4(%esp) movl 4(%ebx), %eax addl 4(%esi), %eax movl %eax, (%esp) call _RTIO__PutInt I'm of two minds on optimizing though. Do it. Don't it. I don't like debugging optimize code. Nor do I want to waste time having the compiler make the code less debuggable. But when I look at the code and how bad the code quality is, and that it could be substantially better without sacrificing debuging... This example is somewhat contrived, but the code seems like 33% waste. Eventually that much bloat is going to cost in terms of I/O in the assembly, linker, paging it in at runtime, and even a little extra to run it. "Now that I understand things somewhat better.." How bad/unportable was it the previous way, the VM-synchronized way? Can the checks only be generated for calls to extern functions? When I write C wrappers, am I missing checks? (I can check, maybe the checks are generated). Are they missing sometimes with regard to X Windows? I think I understand just barely some of what is going on. That writes through pointers need to be checked. Because objects can move around. But moving objects doesn't update the references, but instead marks pages as different? (In the VM-synchronized world, moving an object would mark its original page invalid, triggering a page fault upon subsequent access, which is handled by referencing the new location and maybe updating the old pointer). ??? Something like that ??? - Jay From jay.krell at cornell.edu Mon Apr 20 05:47:09 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 20 Apr 2009 03:47:09 +0000 Subject: [M3devel] explanation of CheckLoadTracedRef? Message-ID: - What does CheckLoadTracedRef and co. do? - Can the compiler be smarter? Easily/effectively? I'm just reading code to understand the object model.. and I see like this: b.F1(1); (* line 60 *) b.F2(2); .stabn 68,0,60,LM17-LFBB2 (",60," means line 60) LM17: movl _MM_Main+584, %esi testl %esi, %esi je L13 testb $64, -2(%esi) je L13 movl %esi, (%esp) call _RTHooks__CheckLoadTracedRef L13: movl (%esi), %eax movl (%eax), %ebx movl $1, 4(%esp) movl %esi, (%esp) call *%ebx .stabn 68,0,61,LM18-LFBB2 (",61," means line 61) LM18: movl _MM_Main+584, %ebx testl %ebx, %ebx je L14 testb $64, -2(%ebx) je L14 movl %ebx, (%esp) call _RTHooks__CheckLoadTracedRef L14: movl (%ebx), %eax movl 4(%eax), %esi movl $2, 4(%esp) movl %ebx, (%esp) call *%esi Does one really need to "check" pointers so often? You know, like twice in a row? Granted, there is a call in between. I understand, that one call could have done "anything". Ok, here is another case cm3 -O, cm3cg -O3, no intervening function call, still two checks: T3 = OBJECT a: INTEGER; END; c := NEW(T3); RTIO.PutInt(c.a + c.a); .stabn 68,0,63,LM20-LFBB2 LM20: movl _MM_Main+588, %esi testl %esi, %esi je L15 testb $64, -2(%esi) je L15 movl %esi, (%esp) call _RTHooks__CheckLoadTracedRef L15: movl _MM_Main+588, %ebx testl %ebx, %ebx je L16 testb $64, -2(%ebx) je L16 movl %ebx, (%esp) call _RTHooks__CheckLoadTracedRef L16: movl $0, 4(%esp) movl 4(%ebx), %eax addl 4(%esi), %eax movl %eax, (%esp) call _RTIO__PutInt I'm of two minds on optimizing though. Do it. Don't it. I don't like debugging optimize code. Nor do I want to waste time having the compiler make the code less debuggable. But when I look at the code and how bad the code quality is, and that it could be substantially better without sacrificing debuging... This example is somewhat contrived, but the code seems like 33% waste. Eventually that much bloat is going to cost in terms of I/O in the assembly, linker, paging it in at runtime, and even a little extra to run it. "Now that I understand things somewhat better.." How bad/unportable was it the previous way, the VM-synchronized way? Can the checks only be generated for calls to extern functions? When I write C wrappers, am I missing checks? (I can check, maybe the checks are generated). Are they missing sometimes with regard to X Windows? I think I understand just barely some of what is going on. That writes through pointers need to be checked. Because objects can move around. But moving objects doesn't update the references, but instead marks pages as different? (In the VM-synchronized world, moving an object would mark its original page invalid, triggering a page fault upon subsequent access, which is handled by referencing the new location and maybe updating the old pointer). ??? Something like that ??? - Jay From hosking at cs.purdue.edu Mon Apr 20 06:55:13 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 20 Apr 2009 14:55:13 +1000 Subject: [M3devel] explanation of CheckLoadTracedRef? In-Reply-To: References: Message-ID: On 20 Apr 2009, at 13:47, Jay wrote: > > > - What does CheckLoadTracedRef and co. do? It makes sure that when loading a reference from the heap we make sure that reference is black (i.e., not gray). The invariant is that mutator threads should never be exposed to pointers to old space while the incrememtal collector is executing. > - Can the compiler be smarter? It's tricky. We'd like to eliminate two checks on the same field. So long as we can ensure that no GC flip occurs between the first check and the second then yes. If not then we must keep both checks. > Easily/effectively? > I'm just reading code to understand the object model.. > and I see like this: > b.F1(1); (* line 60 *) > b.F2(2); > > > > .stabn 68,0,60,LM17-LFBB2 (",60," means line 60) > LM17: > movl _MM_Main+584, %esi > testl %esi, %esi > je L13 > testb $64, -2(%esi) > je L13 > movl %esi, (%esp) > call _RTHooks__CheckLoadTracedRef > L13: > movl (%esi), %eax > movl (%eax), %ebx > movl $1, 4(%esp) > movl %esi, (%esp) > call *%ebx > .stabn 68,0,61,LM18-LFBB2 (",61," means line 61) > LM18: > movl _MM_Main+584, %ebx > testl %ebx, %ebx > je L14 > testb $64, -2(%ebx) > je L14 > movl %ebx, (%esp) > call _RTHooks__CheckLoadTracedRef > L14: > movl (%ebx), %eax > movl 4(%eax), %esi > movl $2, 4(%esp) > movl %ebx, (%esp) > call *%esi > > > Does one really need to "check" pointers so often? > You know, like twice in a row? > Granted, there is a call in between. > I understand, that one call could have done "anything". > > > Ok, here is another case cm3 -O, cm3cg -O3, no intervening function > call, still two checks: > > > T3 = OBJECT > a: INTEGER; > END; > > > c := NEW(T3); > > > RTIO.PutInt(c.a + c.a); > > > .stabn 68,0,63,LM20-LFBB2 > LM20: > movl _MM_Main+588, %esi > testl %esi, %esi > je L15 > testb $64, -2(%esi) > je L15 > movl %esi, (%esp) > call _RTHooks__CheckLoadTracedRef > L15: > movl _MM_Main+588, %ebx > testl %ebx, %ebx > je L16 > testb $64, -2(%ebx) > je L16 > movl %ebx, (%esp) > call _RTHooks__CheckLoadTracedRef > L16: > movl $0, 4(%esp) > movl 4(%ebx), %eax > addl 4(%esi), %eax > movl %eax, (%esp) > call _RTIO__PutInt > > > I'm of two minds on optimizing though. > Do it. Don't it. > > I don't like debugging optimize code. > Nor do I want to waste time having the compiler make the code less > debuggable. > But when I look at the code and how bad the code quality is, and > that it could be substantially > better without sacrificing debuging... > > > This example is somewhat contrived, but the code seems like 33% waste. > Eventually that much bloat is going to cost in terms of I/O in the > assembly, linker, > paging it in at runtime, and even a little extra to run it. It would be useful to see what the overhead actually is. You can do this by changing Host.doIncGC to FALSE instead of TRUE in m3front. There is a flag that will do this: -NoIncGC. I forget how we actually pass those flags to the front-end from m3build. I think something like: M3Option("-NoIncGC") > "Now that I understand things somewhat better.." > How bad/unportable was it the previous way, the VM-synchronized way? Not compatible with system threading. > Can the checks only be generated for calls to extern functions? Huh? Not pertinent. > When I write C wrappers, am I missing checks? > (I can check, maybe the checks are generated). > Are they missing sometimes with regard to X Windows? You should *never* access a field in the heap in C code! All accesses to traced fields in the heap must take place in Modula-3. Otherwise things will break! C wrappers should not do anything other than forward calls to C library calls. They should not perform heap accesses. > I think I understand just barely some of what is going on. > That writes through pointers need to be checked. Yes, writes of references to traced fields in the heap need the checks too for generational GC. > Because objects can move around. > But moving objects doesn't update the references, but instead > marks pages as different? (In the VM-synchronized world, > moving an object would mark its original page invalid, triggering > a page fault upon subsequent access, which is handled by referencing > the new location and maybe updating the old pointer). I think you are confusing incremental and incremental GC. > > > > ??? Something like that ??? > > > - Jay From jay.krell at cornell.edu Mon Apr 20 10:47:21 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 20 Apr 2009 08:47:21 +0000 Subject: [M3devel] crummy ThreadWin32.m3 implementation? Message-ID: Um, ThreadWin32.m3 looks pretty crummy -- all LockMutex calls bottleneck on one giant lock. .v0 and .v1 aren't bad this way. - Jay From jay.krell at cornell.edu Mon Apr 20 11:11:17 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 20 Apr 2009 09:11:17 +0000 Subject: [M3devel] crummy ThreadWin32.m3 implementation? In-Reply-To: References: Message-ID: Searching the web...finds this which seems very relevant: http://birrell.org/andrew/papers/ImplementingCVs.pdf - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 20 Apr 2009 08:47:21 +0000 > Subject: [M3devel] crummy ThreadWin32.m3 implementation? > > > Um, ThreadWin32.m3 looks pretty crummy -- all LockMutex calls bottleneck on one giant lock. .v0 and .v1 aren't bad this way. > > > - Jay From rodney.m.bates at cox.net Mon Apr 20 15:35:02 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 20 Apr 2009 08:35:02 -0500 Subject: [M3devel] Resummary of tagged reference proposals Message-ID: <49EC7A06.5040403@cox.net> I am going to try to resummarize the various proposals, as their description has now gotten rather scattered around in all the discussion. --------------------------------------------------------------------- Mika's proposal (I'll call it the "minimalist" propsal): Mika, please correct me if I misrepresent what you are proposing. There are no language changes at all, only changes in implementation. The implementation of the existing type REFANY, and no other type, allows it to have values whose lsb is nonzero. ISTYPE, NARROW, TYPECASE, and narrowing assignments, when and only when applied to REFANY, have their generated code fixed so it checks the lsb, and, if it is nonzero, consider the runtime type check to have failed, in whichever way such a failure is already handled. The only effect is to liberalize the rules unsafe code must follow to avoid undermining the safety of safe code. Only unsafe code can create or detect these misaligned values. Today, it must never return them in a variable of any reference type, lest the four narrowing operations unexpectedly crash. In the proposal, unsafe code would be able to return such values in variables of type REFANY, but not any other type. Already, the only things safe code can do with values of REFANY are copy them around (which would happily work on misaligned values) and narrow them. With the implementation of the narrowing operations changed, misaligned values can never escape from REFANY variables. In safe code, there is no way to detect whether a value of type REFANY is misaligned. Doing it by elimination, trying to narrow to any proper subtype of REFANY, is impractical, as there are an unbounded number of REF types to eliminate. If there is more than one abstract data type that uses this mechanism, client code can not be prevented from mixing up values from the different abstractions. (Perhaps this could be fixed by a language change allowing BRANDED REFANY?) --------------------------------------------------------------------- My (Rodney's) "safe" proposal: There is a new type named TAGABLE. It is a subrange of INTEGER, whose bounds are implementation-defined. These can be queried by the existing FIRST and LAST functions. Similar to CARDINAL, it has all the properties of a subrange type but is not the same type as the corresponding subrange. There is a new type constructor TAGGED. If T is any traced or object type, including branded and opaque types, then TAGGED T is a new type whose value set is the union of the value sets of T and TAGABLE. Moreover, TAGABLE <: TAGGED T T <: TAGGED T. IF T # U, then TAGGED T and TAGGED U are not the same type and have no subtype or assignability relation to each other. The semantics of ISTYPE, NARROW, TYPECASE, and assignability of a type to a type are generalized so that their to-be-narrowed operand can have a tagged type, and if it does, their to-be-narrowed-to type can be TAGABLE. Comments: Making TAGGED T have no relation to TAGGED U avoids a lot of really complicated type equality and subtype rules. The former would be a drastic departure from the current state of Modula-3. It is up to the implementation to decide the bit representation of tagged types, including how values of TAGABLE will be distinguished from reference values. Though the language would not require it, most likely a word the same size as a pointer will be used. Using the lsb as the tag bit is an efficient encoding, because in any currently conceivable machine, it will be zero for all pointers to heap objects. There is no reason pickles would have to use the same representation as compiler-generated code. The implementation should define the bounds of TAGABLE to be whatever it can fit in its representation, after removing the values that are true pointers. If the lsb is used as a tag, this will no doubt be a 31-bit integer on a 32-bit machine and 63-bit integer on a 64-bit machine. The language wouldn't even specify whether it is signed, although somehow unsigned seems nice to me. If it is unsigned and the suggested encodings are used, TAGABLE would have the same bounds as CARDINAL, but it really should be a separate type, so as not to overconstrain the implementation. If T is branded, then the effects of branding will propagate to TAGGED T, thus allowing independent abstract data types to ensure each one's values can't be mixed up with the other's. This will statically detect misuses by client code. However, TAGGED T is not a branded type. If T is an opaque type, then TAGGED T can be used to combine the space efficiency of tagging with the ability of an opaque type to reveal some but not all of its properties. To use this, client code will have to narrow a value first, since access to methods/fields could not have a definable meaning for a value in TAGABLE. On the other hand, T could be an opaque subtype of REFANY, thus revealing almost nothing about TAGGED T to clients. This would give tagged types the existing ability of ensuring statically, that the code in a revealed context will never get TAGGED REFANY, thus avoiding extra runtime type checks. From rodney.m.bates at cox.net Mon Apr 20 16:06:12 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 20 Apr 2009 09:06:12 -0500 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: References: <20090420012129.GA22387@topoi.pooq.com> <49EBE1DD.6080809@cox.net> Message-ID: <49EC8154.20909@cox.net> Jay wrote: > > Um..you know..if you just use ADDRESS instead of REFANY, doesn't that get you what you need, with no language/compiler/runtime changes? > > Can't you check the low bit of the address and only if it is zero, assign it to a REFANY, and that party (NARROW/ISTYPE/etc.) on the REFANY? Otherwise LOOPHOLE the ADDRESS to an INTEGER and shift it right by one? > > > > > There is danger here no matter what. > > > Who says heap pointers need any alignment? > They need alignment for the conjunction of the following two reasons: 1. Some heap objects have to be aligned because they contain a field or element that must be aligned. Examples are an open array of INTEGER and a linked-list node that contains a pointer. And, 2. It is impractically overcomplicated to build a heap allocator/garbage collector that handles a mix of aligned and unaligned heap objects. Even if one did so, there would probably be no benefit, or maybe memory use might even get worse, on account of increased fragmentation. So heap managers give all objects the strictest alignment any object could require. > > > On most machines they are aligned, but on most machines (x86, AMD64) they don't need to be. x86/AMD64 may have an option for triggering "alignment exceptions" in the hardware, but I don't think any OS ever enables it. And I doubt that any application can. > > > On Windows when dealing with "resources" (strings, bitmaps, etc., same notion as Apple), anything under 64K is considered a small integer. > This gives you a system where resources can be efficiently identified by small integers, and you need to coordinate with all contributors of resources to a particular file, or less efficiently but more flexibily use strings and less/no coordination is needed. It's a nice compromise. > > > Very little code relies on the alignment of pointers. > It is a "special purpose" kind of thing. > > > Very little code makes these "policy" decisions either. > > > On most machines, the pointer NULL is made invalid at the hardware level by making the first page inaccessible. On most machines, a page is at least 4K. On many machines it is larger, or even variably sized. > Going further and always reserving the first 64K of address space is not a big waste. > It's not physical memory, it's "just" address space. (It does cost something, but not much; it costs you some reduced capacity) > > > There is danger here no matter what but also a lot of efficiency to be gained in some scenarios. > > > On most machines you can probably take more than 1 bit. > > > On NT the heap allocator aligns to "two pointers", so that gives you 3 (32bit) or 4 (64bit) bits. But that's just for typical code. Modula-3 usually allocates with mmap/sbrk/VirtualAlloc, giving it at least 4K alignment, probably in reality something larger like 64K. It is the under its control to subdivide that as it sees fit. > So you could arbitrarily decree that all Modula-3 objects are aligned at say 32 bytes and have 5 tag bits. It's just that at some point you start wasting space. Allocating a bunch of 10 byte objects with 32 byte alignment wastes a lot of space. But allocating a bunch of 32 or 64 or 96 etc., byte objects with 32 byte alignment wastes nothing.. > > > On NT as well, historically, the address space was split in two. > (It still is split, but details vary). > The upper bit was zero for usermode, one for kernelmode. > Therefore, historically, another avenue this proposal could take is to use the high bit for a tag bit. Assuming nobody is writing drivers in kernel mode. > > > However, this 2gig/2gig split can be constraining on usermode (and kernelmode..). > So there is an option at boot-time to make it 3gig/1gig -- 3gig user mode, 1 gig usermode. > However that breaks any code that uses the high bit as a tag bit. > Therefore executables (.exes, not .dlls) have a flag in them to indicate if they are "large address aware". If they are not, even if you boot /3gig, you still, I guess, won't ever see addresses over 2gig. > If you are using tag bits, it then becomes that the upper two bits are: > 00: definitely usermode > 01: ambiguous > 10: definitely kernelmode (can be used as a 30 bit integer) > 11: definitely kernelmode (can be used as a 30 bit integer) > > > However if you run a "large address aware" 32bit executable on a 64bit system, you get all 4gig as usermode. The kernelmode addresses are even higher than 4gig and you can't even encode them in a 32bit usermode address, which is fine. It becomes that all addresses are usermode. (This is a little mind-bending at first). > > > Using a small struct with a type tag (possibly an entire pointer) and a separate data word also seems very viable. Very portable, very safe. Just that it grows the representation. > > > - Jay > > > > ---------------------------------------- > >> Date: Sun, 19 Apr 2009 21:45:49 -0500 >> From: rodney.m.bates at cox.net >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] fewer wrappers/more C? (or a wash?) >> >> hendrik at topoi.pooq.com wrote: >> >>> On Fri, Apr 17, 2009 at 10:57:10PM +1000, Tony Hosking wrote: >>> >>> >>>> I am a little concerned about passing REFANY directly to C code as >>>> there is no guarantee that REFANY and C pointers will always be >>>> compatible. ADDRESS can more safely be assumed compatible. >>>> >>>> >>> Indeed, I once read the X toolkit specs, and it was rife with small >>> integers being packed into pointers. Apparently the toolkit resolved >>> it not by a tag bit, but by its magnitude. There was some constant >>> somewhere that identified which numbers were small enough to be >>> considered not-pointers. >>> >>> This was a discrimination without a tag bit. Similar concept to what >>> we're planning for the future of REFANY, but different implementation. >>> >>> I don't know how they figured out which pointer values were safe to >>> treat as integers. >>> >>> >> In my more elaborate "safe" proposal, at least, the language itself >> does not specify anything about what the bit-encodings of tagged >> types are. It's an implementors' option, and the language >> can support whatever the implementors choose. >> >> This could be used to match the X toolkit's encoding. However, >> using the lsb takes advantage of the fact that heap objects must >> always be aligned and thus the lsb is already always zero, when >> it's really a heap pointer. That seems like by far the most efficient >> encoding. >> >>> -- hendrik >>> >>> >>> >>> From hendrik at topoi.pooq.com Mon Apr 20 16:53:20 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 20 Apr 2009 10:53:20 -0400 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: <49EBE1DD.6080809@cox.net> References: <20090420012129.GA22387@topoi.pooq.com> <49EBE1DD.6080809@cox.net> Message-ID: <20090420145320.GA23397@topoi.pooq.com> On Sun, Apr 19, 2009 at 09:45:49PM -0500, Rodney M. Bates wrote: > hendrik at topoi.pooq.com wrote: > >On Fri, Apr 17, 2009 at 10:57:10PM +1000, Tony Hosking wrote: > > > >>I am a little concerned about passing REFANY directly to C code as > >>there is no guarantee that REFANY and C pointers will always be > >>compatible. ADDRESS can more safely be assumed compatible. > >> > > > >Indeed, I once read the X toolkit specs, and it was rife with small > >integers being packed into pointers. Apparently the toolkit resolved > >it not by a tag bit, but by its magnitude. There was some constant > >somewhere that identified which numbers were small enough to be > >considered not-pointers. > > > >This was a discrimination without a tag bit. Similar concept to what > >we're planning for the future of REFANY, but different implementation. > > > >I don't know how they figured out which pointer values were safe to > >treat as integers. > > > In my more elaborate "safe" proposal, at least, the language itself > does not specify anything about what the bit-encodings of tagged > types are. It's an implementors' option, and the language > can support whatever the implementors choose. > > This could be used to match the X toolkit's encoding. However, > using the lsb takes advantage of the fact that heap objects must > always be aligned and thus the lsb is already always zero, when > it's really a heap pointer. That seems like by far the most efficient > encoding. The X toolkit was set up to be called from C, and the small integers were just parameters to a C function, or else pointers, whatever was more convenient. They had a specific range of small integers (which was machine-dependent as far as I can tell), and the whole convention seems to have been set up for coding convenience. I don't know how the limit on "small" inetgers was decided. The LSB trick is what I would recommend for us. I was just reinforcing the hopelessless of assuming we can make REFANY match C conventions. I suspect there are too many different ones. -- hendrik From jay.krell at cornell.edu Mon Apr 20 16:51:52 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 20 Apr 2009 14:51:52 +0000 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: <49EC8154.20909@cox.net> References: <20090420012129.GA22387@topoi.pooq.com> <49EBE1DD.6080809@cox.net> <49EC8154.20909@cox.net> Message-ID: > 1. Some heap objects have to be aligned because they contain a field or > element > that must be aligned. Examples are an open array of INTEGER and a > linked-list node that contains a pointer. And, And on every system there exist fields/elements that really require alignment? The following works fine for me..x86 tends to be very lax on requiring any alignment. #include int main() { unsigned char a[20]; unsigned i; for (i = 0 ; i < 20 ; ++i) a[i] = (unsigned char)i; for (i = 0 ; i < 8 ; ++i) printf("%x\n", *(unsigned*)&a[i]); for (i = 0 ; i < 8 ; ++i) printf("%f\n", *(double*)&a[i]); return 0; } I think we only care about Modula-3 heap allocated pointers, so what folks do in their C code doesn't matter. We can even introduce and depend upon higher alignment than the hardware requires or the underlying allocator provides. I realize that SPARC, MIPS, maybe Alpha, ARM?, IA64, and probably others, do have hardware-enforced alignment requirements. (Having debugged some of them.) I'm mostly just causing trouble. The proposals are all somewhat dangerous, but in reality they are ok, and can buy significant efficiencies in certain applications. Alignment is normal, even on x86. Btw, presumably on a 64 bit system, you can get a 32bit float in one of these things. - Jay From hendrik at topoi.pooq.com Mon Apr 20 16:57:48 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 20 Apr 2009 10:57:48 -0400 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: References: <20090420012129.GA22387@topoi.pooq.com> <49EBE1DD.6080809@cox.net> Message-ID: <20090420145748.GB23397@topoi.pooq.com> On Mon, Apr 20, 2009 at 03:36:38AM +0000, Jay wrote: > > > Assuming nobody is writing drivers in kernel mode. > > I meant, "in Modula-3". Hasn't an operating system been written in Modula 3? But not NT, I guess. -- hendrik From jay.krell at cornell.edu Mon Apr 20 17:06:41 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 20 Apr 2009 15:06:41 +0000 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: <20090420145748.GB23397@topoi.pooq.com> References: <20090420012129.GA22387@topoi.pooq.com> <49EBE1DD.6080809@cox.net> <20090420145748.GB23397@topoi.pooq.com> Message-ID: Yes, SPIN. - Jay ---------------------------------------- > Date: Mon, 20 Apr 2009 10:57:48 -0400 > From: hendrik@ >>> Assuming nobody is writing drivers in kernel mode. >> >> I meant, "in Modula-3". > > Hasn't an operating system been written in Modula 3? > But not NT, I guess. > > -- hendrik From mika at async.caltech.edu Mon Apr 20 17:31:32 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 20 Apr 2009 08:31:32 -0700 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: Your message of "Mon, 20 Apr 2009 14:51:52 -0000." Message-ID: <200904201531.n3KFVWLl065496@camembert.async.caltech.edu> I just wanted to point out that the discussion about X pointers is introducing a large red herring into the discussion about tagged REFANYs. The tagged REFANY idea just depends on Modula-3's own heap allocator's returning aligned addresses. If they're not aligned, you can't tag the REFANY. If they are, you can, because the only thing ever held by a REFANY is a Modula-3-heap-allocated address, NIL, or a tagged value. X pointers should clearly be passed as ADDRESS, not as REFANY. Completely different issue. Mika Jay writes: > >> 1. Some heap objects have to be aligned because they contain a field or >> element >> that must be aligned. Examples are an open array of INTEGER and a >> linked-list node that contains a pointer. And, > > >And on every system there exist fields/elements that really require alignment? > > >The following works fine for me..x86 tends to be very lax on requiring any alignment. > > >#include > > >int main() >{ >unsigned char a[20]; >unsigned i; > > >for (i = 0 ; i < 20 ; ++i) > a[i] = (unsigned char)i; > > >for (i = 0 ; i < 8 ; ++i) > printf("%x\n", *(unsigned*)&a[i]); > >for (i = 0 ; i < 8 ; ++i) > printf("%f\n", *(double*)&a[i]); > >return 0; >} > > >I think we only care about Modula-3 heap allocated pointers, so what >folks do in their C code doesn't matter. >We can even introduce and depend upon higher alignment than the hardware requires >or the underlying allocator provides. > > >I realize that SPARC, MIPS, maybe Alpha, ARM?, IA64, and probably others, >do have hardware-enforced alignment requirements. >(Having debugged some of them.) > > >I'm mostly just causing trouble. >The proposals are all somewhat dangerous, but in reality they are ok, >and can buy significant efficiencies in certain applications. >Alignment is normal, even on x86. > > >Btw, presumably on a 64 bit system, you can get a 32bit float in one of these things. > > > > - Jay From hosking at cs.purdue.edu Mon Apr 20 23:53:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Apr 2009 07:53:57 +1000 Subject: [M3devel] crummy ThreadWin32.m3 implementation? In-Reply-To: References: Message-ID: <14FDB4AD-26AA-43B0-BD25-925C596452EF@cs.purdue.edu> Also, note that win32 now supports CVs directly! No need for semaphores. On 20 Apr 2009, at 19:11, Jay wrote: > > Searching the web...finds this which seems very relevant: > > http://birrell.org/andrew/papers/ImplementingCVs.pdf > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Mon, 20 Apr 2009 08:47:21 +0000 >> Subject: [M3devel] crummy ThreadWin32.m3 implementation? >> >> >> Um, ThreadWin32.m3 looks pretty crummy -- all LockMutex calls >> bottleneck on one giant lock. .v0 and .v1 aren't bad this way. >> >> >> - Jay From hosking at cs.purdue.edu Tue Apr 21 03:53:05 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Apr 2009 11:53:05 +1000 Subject: [M3devel] Latest ThreadPThread Message-ID: <8510055B-CBC6-4A02-BAFA-B26AF9A827EC@cs.purdue.edu> Jay, I have some questions about why you have moved the Activation declaration to C code. I'm not sure what this gains, and I have strong reasons for wanting to keep it in Modula-3. I'd like to revert these most recent changes if possible, unless you can say why you want to retain them. Perhaps you have a good reason, but I remain to be convinced. -- Tony Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Apr 21 03:58:31 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Apr 2009 11:58:31 +1000 Subject: [M3devel] Latest ThreadPThread In-Reply-To: <8510055B-CBC6-4A02-BAFA-B26AF9A827EC@cs.purdue.edu> References: <8510055B-CBC6-4A02-BAFA-B26AF9A827EC@cs.purdue.edu> Message-ID: Jay, I am curious why you are using atomic operations for INC and DEC of inCritical (on WIN32/WIN64). In general, they are protected by an appropriate lock, so I don't know what the need is. Are you trying to move towards lock-free implementations of some of the thread primitives? 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 21 Apr 2009, at 11:53, Tony Hosking wrote: > Jay, > > I have some questions about why you have moved the Activation > declaration to C code. I'm not sure what this gains, and I have > strong reasons for wanting to keep it in Modula-3. I'd like to > revert these most recent changes if possible, unless you can say why > you want to retain them. Perhaps you have a good reason, but I > remain to be convinced. > > -- Tony > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Apr 21 04:51:18 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Apr 2009 12:51:18 +1000 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <49EC7A06.5040403@cox.net> References: <49EC7A06.5040403@cox.net> Message-ID: I note that Mika's proposal is no less safe than Rodney's. On 20 Apr 2009, at 23:35, Rodney M. Bates wrote: > I am going to try to resummarize the various proposals, as their > description has now gotten rather scattered around in all the > discussion. > --------------------------------------------------------------------- > Mika's proposal (I'll call it the "minimalist" propsal): > > Mika, please correct me if I misrepresent what you are proposing. > > There are no language changes at all, only changes in implementation. > The implementation of the existing type REFANY, and no other type, > allows it to have values whose lsb is nonzero. ISTYPE, NARROW, > TYPECASE, and narrowing assignments, when and only when applied to > REFANY, have their generated code fixed so it checks the lsb, and, if > it is nonzero, consider the runtime type check to have failed, in > whichever way such a failure is already handled. > > The only effect is to liberalize the rules unsafe code must follow to > avoid undermining the safety of safe code. Only unsafe code can > create or detect these misaligned values. Today, it must never return > them in a variable of any reference type, lest the four narrowing > operations unexpectedly crash. In the proposal, unsafe code would be > able to return such values in variables of type REFANY, but not any > other type. > > Already, the only things safe code can do with values of REFANY are > copy them around (which would happily work on misaligned values) and > narrow them. With the implementation of the narrowing operations > changed, misaligned values can never escape from REFANY variables. > > In safe code, there is no way to detect whether a value of type REFANY > is misaligned. Doing it by elimination, trying to narrow to any > proper subtype of REFANY, is impractical, as there are an unbounded > number of REF types to eliminate. > > If there is more than one abstract data type that uses this mechanism, > client code can not be prevented from mixing up values from the > different abstractions. (Perhaps this could be fixed by a language > change allowing BRANDED REFANY?) > > --------------------------------------------------------------------- > My (Rodney's) "safe" proposal: > > There is a new type named TAGABLE. It is a subrange of INTEGER, whose > bounds are implementation-defined. These can be queried by the > existing FIRST and LAST functions. Similar to CARDINAL, it has all > the properties of a subrange type but is not the same type as the > corresponding subrange. > > There is a new type constructor TAGGED. If T is any traced or object > type, including branded and opaque types, then TAGGED T is a new type > whose value set is the union of the value sets of T and TAGABLE. > Moreover, > > TAGABLE <: TAGGED T > T <: TAGGED T. > > IF T # U, then TAGGED T and TAGGED U are not the same type and have no > subtype or assignability relation to each other. > > The semantics of ISTYPE, NARROW, TYPECASE, and assignability of a type > to a type are generalized so that their to-be-narrowed operand can > have a tagged type, and if it does, their to-be-narrowed-to type can > be TAGABLE. > > Comments: > > Making TAGGED T have no relation to TAGGED U avoids a lot of really > complicated type equality and subtype rules. The former would be a > drastic departure from the current state of Modula-3. > > It is up to the implementation to decide the bit representation of > tagged types, including how values of TAGABLE will be distinguished > from reference values. Though the language would not require it, most > likely a word the same size as a pointer will be used. Using the lsb > as the tag bit is an efficient encoding, because in any currently > conceivable machine, it will be zero for all pointers to heap objects. > There is no reason pickles would have to use the same representation > as compiler-generated code. > > The implementation should define the bounds of TAGABLE to be whatever > it can fit in its representation, after removing the values that are > true pointers. If the lsb is used as a tag, this will no doubt be a > 31-bit integer on a 32-bit machine and 63-bit integer on a 64-bit > machine. The language wouldn't even specify whether it is signed, > although somehow unsigned seems nice to me. If it is unsigned and the > suggested encodings are used, TAGABLE would have the same bounds as > CARDINAL, but it really should be a separate type, so as not to > overconstrain the implementation. > > If T is branded, then the effects of branding will propagate to TAGGED > T, thus allowing independent abstract data types to ensure each one's > values can't be mixed up with the other's. This will statically > detect misuses by client code. However, TAGGED T is not a branded > type. > > If T is an opaque type, then TAGGED T can be used to combine the space > efficiency of tagging with the ability of an opaque type to reveal > some but not all of its properties. To use this, client code will > have to narrow a value first, since access to methods/fields could not > have a definable meaning for a value in TAGABLE. > > On the other hand, T could be an opaque subtype of REFANY, thus > revealing almost nothing about TAGGED T to clients. This would give > tagged types the existing ability of ensuring statically, that the > code in a revealed context will never get TAGGED REFANY, thus avoiding > extra runtime type checks. From hosking at cs.purdue.edu Tue Apr 21 05:59:35 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Apr 2009 13:59:35 +1000 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <49EC7A06.5040403@cox.net> References: <49EC7A06.5040403@cox.net> Message-ID: On 20 Apr 2009, at 23:35, Rodney M. Bates wrote: > I am going to try to resummarize the various proposals, as their > description has now gotten rather scattered around in all the > discussion. > --------------------------------------------------------------------- > Mika's proposal (I'll call it the "minimalist" propsal): > > Mika, please correct me if I misrepresent what you are proposing. > > There are no language changes at all, only changes in implementation. > The implementation of the existing type REFANY, and no other type, > allows it to have values whose lsb is nonzero. ISTYPE, NARROW, > TYPECASE, and narrowing assignments, when and only when applied to > REFANY, have their generated code fixed so it checks the lsb, and, if > it is nonzero, consider the runtime type check to have failed, in > whichever way such a failure is already handled. > > The only effect is to liberalize the rules unsafe code must follow to > avoid undermining the safety of safe code. Only unsafe code can > create or detect these misaligned values. Today, it must never return > them in a variable of any reference type, lest the four narrowing > operations unexpectedly crash. In the proposal, unsafe code would be > able to return such values in variables of type REFANY, but not any > other type. I don't see why we can't have safe creation of the misaligned values as per Mika's interface. > Already, the only things safe code can do with values of REFANY are > copy them around (which would happily work on misaligned values) and > narrow them. With the implementation of the narrowing operations > changed, misaligned values can never escape from REFANY variables. > > In safe code, there is no way to detect whether a value of type REFANY > is misaligned. Doing it by elimination, trying to narrow to any > proper subtype of REFANY, is impractical, as there are an unbounded > number of REF types to eliminate. An alternative would be to loosen the language spec to allow TYPECODE(REFANY) and use this typecode for tagged references. Then one can explicitly test for it without elimination of alternatives. > If there is more than one abstract data type that uses this mechanism, > client code can not be prevented from mixing up values from the > different abstractions. (Perhaps this could be fixed by a language > change allowing BRANDED REFANY?) Indeed. > --------------------------------------------------------------------- > My (Rodney's) "safe" proposal: > > There is a new type named TAGABLE. It is a subrange of INTEGER, whose > bounds are implementation-defined. These can be queried by the > existing FIRST and LAST functions. Similar to CARDINAL, it has all > the properties of a subrange type but is not the same type as the > corresponding subrange. > > There is a new type constructor TAGGED. If T is any traced or object > type, including branded and opaque types, then TAGGED T is a new type > whose value set is the union of the value sets of T and TAGABLE. > Moreover, > > TAGABLE <: TAGGED T > T <: TAGGED T. > > IF T # U, then TAGGED T and TAGGED U are not the same type and have no > subtype or assignability relation to each other. > > The semantics of ISTYPE, NARROW, TYPECASE, and assignability of a type > to a type are generalized so that their to-be-narrowed operand can > have a tagged type, and if it does, their to-be-narrowed-to type can > be TAGABLE. Hmm. It seems there is a nasty loophole in your spec. Consider: TYPE T = BRANDED OBJECT END TYPE U = BRANDED OBJECT END These are unrelated types. Now, the rules let me take: t: TAGGED T and obtain: i: TAGABLE := NARROW(t, TAGABLE); But TAGABLE <: TAGGED U so I can do: u: TAGGED U := t; Is that your intention? > > > Comments: > > Making TAGGED T have no relation to TAGGED U avoids a lot of really > complicated type equality and subtype rules. The former would be a > drastic departure from the current state of Modula-3. > > It is up to the implementation to decide the bit representation of > tagged types, including how values of TAGABLE will be distinguished > from reference values. Though the language would not require it, most > likely a word the same size as a pointer will be used. Using the lsb > as the tag bit is an efficient encoding, because in any currently > conceivable machine, it will be zero for all pointers to heap objects. > There is no reason pickles would have to use the same representation > as compiler-generated code. > > The implementation should define the bounds of TAGABLE to be whatever > it can fit in its representation, after removing the values that are > true pointers. If the lsb is used as a tag, this will no doubt be a > 31-bit integer on a 32-bit machine and 63-bit integer on a 64-bit > machine. The language wouldn't even specify whether it is signed, > although somehow unsigned seems nice to me. If it is unsigned and the > suggested encodings are used, TAGABLE would have the same bounds as > CARDINAL, but it really should be a separate type, so as not to > overconstrain the implementation. > > If T is branded, then the effects of branding will propagate to TAGGED > T, thus allowing independent abstract data types to ensure each one's > values can't be mixed up with the other's. This will statically > detect misuses by client code. However, TAGGED T is not a branded > type. > > If T is an opaque type, then TAGGED T can be used to combine the space > efficiency of tagging with the ability of an opaque type to reveal > some but not all of its properties. To use this, client code will > have to narrow a value first, since access to methods/fields could not > have a definable meaning for a value in TAGABLE. > > On the other hand, T could be an opaque subtype of REFANY, thus > revealing almost nothing about TAGGED T to clients. This would give > tagged types the existing ability of ensuring statically, that the > code in a revealed context will never get TAGGED REFANY, thus avoiding > extra runtime type checks. From jay.krell at cornell.edu Tue Apr 21 06:14:43 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 21 Apr 2009 04:14:43 +0000 Subject: [M3devel] crummy ThreadWin32.m3 implementation? In-Reply-To: <14FDB4AD-26AA-43B0-BD25-925C596452EF@cs.purdue.edu> References: <14FDB4AD-26AA-43B0-BD25-925C596452EF@cs.purdue.edu> Message-ID: Only if you drop support for pre-Vista versions. - Jay > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 21 Apr 2009 07:53:57 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? > > Also, note that win32 now supports CVs directly! No need for > semaphores. > > On 20 Apr 2009, at 19:11, Jay wrote: > > > > > Searching the web...finds this which seems very relevant: > > > > http://birrell.org/andrew/papers/ImplementingCVs.pdf > > > > - Jay > > > > > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: m3devel at elegosoft.com > >> Date: Mon, 20 Apr 2009 08:47:21 +0000 > >> Subject: [M3devel] crummy ThreadWin32.m3 implementation? > >> > >> > >> Um, ThreadWin32.m3 looks pretty crummy -- all LockMutex calls > >> bottleneck on one giant lock. .v0 and .v1 aren't bad this way. > >> > >> > >> - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 21 06:13:23 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 21 Apr 2009 04:13:23 +0000 Subject: [M3devel] Latest ThreadPThread In-Reply-To: <8510055B-CBC6-4A02-BAFA-B26AF9A827EC@cs.purdue.edu> References: <8510055B-CBC6-4A02-BAFA-B26AF9A827EC@cs.purdue.edu> Message-ID: Question is whether or not it is interesting to have fewer of those very thin pthread wrappers or not. This has fewer of them. Not clearly worthwhile. I can it put back later. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 21 Apr 2009 11:53:05 +1000 CC: m3devel at elegosoft.com Subject: [M3devel] Latest ThreadPThread Jay, I have some questions about why you have moved the Activation declaration to C code. I'm not sure what this gains, and I have strong reasons for wanting to keep it in Modula-3. I'd like to revert these most recent changes if possible, unless you can say why you want to retain them. Perhaps you have a good reason, but I remain to be convinced. -- Tony Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Apr 21 06:33:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Apr 2009 14:33:29 +1000 Subject: [M3devel] crummy ThreadWin32.m3 implementation? In-Reply-To: References: <14FDB4AD-26AA-43B0-BD25-925C596452EF@cs.purdue.edu> Message-ID: <3577783C-1892-435E-95E3-5E967C9BA638@cs.purdue.edu> Might not be such a bad thing ;-) On 21 Apr 2009, at 14:14, Jay wrote: > Only if you drop support for pre-Vista versions. > > - Jay > > > > > From: hosking at cs.purdue.edu > > To: jay.krell at cornell.edu > > Date: Tue, 21 Apr 2009 07:53:57 +1000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? > > > > Also, note that win32 now supports CVs directly! No need for > > semaphores. > > > > On 20 Apr 2009, at 19:11, Jay wrote: > > > > > > > > Searching the web...finds this which seems very relevant: > > > > > > http://birrell.org/andrew/papers/ImplementingCVs.pdf > > > > > > - Jay > > > > > > > > > > > > ---------------------------------------- > > >> From: jay.krell at cornell.edu > > >> To: m3devel at elegosoft.com > > >> Date: Mon, 20 Apr 2009 08:47:21 +0000 > > >> Subject: [M3devel] crummy ThreadWin32.m3 implementation? > > >> > > >> > > >> Um, ThreadWin32.m3 looks pretty crummy -- all LockMutex calls > > >> bottleneck on one giant lock. .v0 and .v1 aren't bad this way. > > >> > > >> > > >> - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 21 06:41:55 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 21 Apr 2009 04:41:55 +0000 Subject: [M3devel] crummy ThreadWin32.m3 implementation? In-Reply-To: <3577783C-1892-435E-95E3-5E967C9BA638@cs.purdue.edu> References: <14FDB4AD-26AA-43B0-BD25-925C596452EF@cs.purdue.edu> <3577783C-1892-435E-95E3-5E967C9BA638@cs.purdue.edu> Message-ID: I'm not keen on it. Checking the version and having two implementation switched between at initialization would be ok though -- actually using function pointers like so: void DoSomething_v2(void) { } void DoSomething_v1(void) { } void DoSomething_init(void) { if (... ) DoSomething = DoSomething_v1; else DoSomething = DoSomething_v2; DoSomething(); } void (*DoSomething)(void) = DoSomething_init; Something more if switching multiple pointers though -- switching a pointer to a struct of function pointers. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 21 Apr 2009 14:33:29 +1000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? Might not be such a bad thing ;-) On 21 Apr 2009, at 14:14, Jay wrote: Only if you drop support for pre-Vista versions. - Jay > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 21 Apr 2009 07:53:57 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? > > Also, note that win32 now supports CVs directly! No need for > semaphores. > > On 20 Apr 2009, at 19:11, Jay wrote: > > > > > Searching the web...finds this which seems very relevant: > > > > http://birrell.org/andrew/papers/ImplementingCVs.pdf > > > > - Jay > > > > > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: m3devel at elegosoft.com > >> Date: Mon, 20 Apr 2009 08:47:21 +0000 > >> Subject: [M3devel] crummy ThreadWin32.m3 implementation? > >> > >> > >> Um, ThreadWin32.m3 looks pretty crummy -- all LockMutex calls > >> bottleneck on one giant lock. .v0 and .v1 aren't bad this way. > >> > >> > >> - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 21 06:44:33 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 21 Apr 2009 04:44:33 +0000 Subject: [M3devel] Latest ThreadPThread In-Reply-To: References: <8510055B-CBC6-4A02-BAFA-B26AF9A827EC@cs.purdue.edu> Message-ID: The Interlocked doesn't have a strong reason. It's fairly cheap at least. There are places in the Modula-3 code with comments about inc/dec taking one instruction, which these would but otherwise I'm skeptical.. - Jay From: hosking at cs.purdue.edu To: hosking at cs.purdue.edu Date: Tue, 21 Apr 2009 11:58:31 +1000 CC: m3devel at elegosoft.com; jay.krell at cornell.edu Subject: Re: [M3devel] Latest ThreadPThread Jay, I am curious why you are using atomic operations for INC and DEC of inCritical (on WIN32/WIN64). In general, they are protected by an appropriate lock, so I don't know what the need is. Are you trying to move towards lock-free implementations of some of the thread primitives? 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 21 Apr 2009, at 11:53, Tony Hosking wrote: Jay, I have some questions about why you have moved the Activation declaration to C code. I'm not sure what this gains, and I have strong reasons for wanting to keep it in Modula-3. I'd like to revert these most recent changes if possible, unless you can say why you want to retain them. Perhaps you have a good reason, but I remain to be convinced. -- Tony Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Apr 21 07:05:48 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Apr 2009 15:05:48 +1000 Subject: [M3devel] Latest ThreadPThread In-Reply-To: References: <8510055B-CBC6-4A02-BAFA-B26AF9A827EC@cs.purdue.edu> Message-ID: On 21 Apr 2009, at 14:44, Jay wrote: > The Interlocked doesn't have a strong reason. > It's fairly cheap at least. It's many cycles (~50x depending on hardware) more expensive than an unlocked INC/DEC. > There are places in the Modula-3 code with comments about inc/dec > taking one instruction, > which these would but otherwise I'm skeptical.. I'm pretty sure that is only in the user-level threading model, where thread switches only occur on delivery of a signal to the process. I am unaware of any OS/hardware that will deliver a thread switch signal in the middle of INC/DEC. So, effectively, for user level threads INC/ DEC can be assumed atomic. That's what the comments are meant to imply. Outside ThreadPosix, all other uses of INC/DEC manipulate state that is already protected appropriately by a lock so should be thread safe. > > > > - Jay > > > > From: hosking at cs.purdue.edu > To: hosking at cs.purdue.edu > Date: Tue, 21 Apr 2009 11:58:31 +1000 > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] Latest ThreadPThread > > Jay, I am curious why you are using atomic operations for INC and > DEC of inCritical (on WIN32/WIN64). In general, they are protected > by an appropriate lock, so I don't know what the need is. Are you > trying to move towards lock-free implementations of some of the > thread primitives? > > 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 21 Apr 2009, at 11:53, Tony Hosking wrote: > > Jay, > > I have some questions about why you have moved the Activation > declaration to C code. I'm not sure what this gains, and I have > strong reasons for wanting to keep it in Modula-3. I'd like to > revert these most recent changes if possible, unless you can say why > you want to retain them. Perhaps you have a good reason, but I > remain to be convinced. > > -- Tony > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 21 11:37:21 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 21 Apr 2009 09:37:21 +0000 Subject: [M3devel] explanation of CheckLoadTracedRef? In-Reply-To: References: Message-ID: > > How bad/unportable was it the previous way, the VM-synchronized way? > > Not compatible with system threading. Really? NT386 wasn't VM-synchronized back in 3.6, 4.1, etc.? Or only with great cost? I have to admit, those old import .libs, kernel32.lib, etc. I didn't realize what was in them when I deleted them. I thought they were just regular import .libs. I think I got luckly in that the overlap between me deleting them and you removing VM-synchronized GC was small or zero. > You should *never* access a field in the heap in C code! All > accesses to traced fields in the heap must take place in Modula-3. > Otherwise things will break! C wrappers should not do anything other > than forward calls to C library calls. They should not perform heap > accesses. Ok, that makes sense. Important "out" is the accessing stack is always ok. But this is a requirement I didn't keep in mind. Now, luckily, the C wrappers are all relatively thin and not difficult to re-review in their entirety. But, take for example "open". The first parameter to it is bound to be in the heap. But probably it is untraced or somehow ok, since it does come from a module used primarily for C interop. And, the line between C wrappers and the "C library" that they forward to does not exist. If I, say, pass a VAR to a VAR..no check is made? Important to declare extern/C functions as taking UNTRACED REF and not VAR? > I think you are confusing incremental and incremental GC. You assume I understand more than I do (I assume you have a typo. :)) "generational" -- the concept that most objects die young. (aka most objects could have been allocated on the stack...) But does that imply detailed implementation choices, or is just like a "guiding principle"? I guess it implies the heap is split into at least two generations, old and young. Though I guess in reality there is a range of young, less young, lesser young, least young, etc. And that has objects age, they should be moved from young to old heaps, and references to them either updated right away, or "caught" upon use and updated then...something like that. "incremental" -- don't pause the world.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Apr 21 14:18:00 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 21 Apr 2009 08:18:00 -0400 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: <200904201531.n3KFVWLl065496@camembert.async.caltech.edu> References: <200904201531.n3KFVWLl065496@camembert.async.caltech.edu> Message-ID: <20090421121800.GA25465@topoi.pooq.com> On Mon, Apr 20, 2009 at 08:31:32AM -0700, Mika Nystrom wrote: > > I just wanted to point out that the discussion about X pointers > is introducing a large red herring into the discussion about tagged REFANYs. > > The tagged REFANY idea just depends on Modula-3's own heap allocator's > returning aligned addresses. If they're not aligned, you can't tag > the REFANY. If they are, you can, because the only thing ever held by > a REFANY is a Modula-3-heap-allocated address, NIL, or a tagged value. > > X pointers should clearly be passed as ADDRESS, not as REFANY. Completely > different issue. Because Modula 3's reference data structures are subject to the Modula 3 garbage collector, and C's are not. And further, C's addresses don't have to be aligned; neither do ADDRESSes. -- hendrik From hendrik at topoi.pooq.com Tue Apr 21 14:26:48 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 21 Apr 2009 08:26:48 -0400 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <49EC7A06.5040403@cox.net> References: <49EC7A06.5040403@cox.net> Message-ID: <20090421122648.GB25465@topoi.pooq.com> On Mon, Apr 20, 2009 at 08:35:02AM -0500, Rodney M. Bates wrote: > > --------------------------------------------------------------------- > My (Rodney's) "safe" proposal: > > There is a new type named TAGABLE. It is a subrange of INTEGER, whose Please spell it TAGGABLE. TAG doubles its last consonant when adding suffixes: TAGGED, TAGGING. -- hendrik From jay.krell at cornell.edu Tue Apr 21 14:46:22 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 21 Apr 2009 12:46:22 +0000 Subject: [M3devel] crummy ThreadWin32.m3 implementation? In-Reply-To: References: <14FDB4AD-26AA-43B0-BD25-925C596452EF@cs.purdue.edu> <3577783C-1892-435E-95E3-5E967C9BA638@cs.purdue.edu> Message-ID: did more "research" (search the web..) It sounds like: if fairness not critical, and pre NT 4.0 compat is needed, there are options where mutex/lock=criticalsection If fairness is important, and NT 4.0 can be used, and perf can be degraded, then mutex/lock=kernel mutex, and use the SignalAndWait function They never seem to use a global lock like ours. Should we maybe adopt Boost's code? e.g.: http://svn.boost.org/trac/boost/browser/trunk/boost/thread/win32/mutex.hpp http://svn.boost.org/trac/boost/browser/trunk/boost/thread/win32/condition_variable.hpp I don't know, it all seems kind of unforunate. Perhaps there should be two types of locks, one that can be associated with a conditionvariable (kernel mutex), one that cannot (criticalsection)? I guess our implementation is quite simple and solves "all the problems" by throwing scalability right out -- lots of independent threads acquiring lots of independent locks will all interfere somewhat with each other, but not a ton. The "giant" lock protects too much data, but not for long durations. It might be interesting to see what cygwin does..but I notice..pthread is a superset, e.g. timedwait, trylock, etc. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 21 Apr 2009 04:41:55 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? I'm not keen on it. Checking the version and having two implementation switched between at initialization would be ok though -- actually using function pointers like so: void DoSomething_v2(void) { } void DoSomething_v1(void) { } void DoSomething_init(void) { if (... ) DoSomething = DoSomething_v1; else DoSomething = DoSomething_v2; DoSomething(); } void (*DoSomething)(void) = DoSomething_init; Something more if switching multiple pointers though -- switching a pointer to a struct of function pointers. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 21 Apr 2009 14:33:29 +1000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? Might not be such a bad thing ;-) On 21 Apr 2009, at 14:14, Jay wrote: Only if you drop support for pre-Vista versions. - Jay > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 21 Apr 2009 07:53:57 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? > > Also, note that win32 now supports CVs directly! No need for > semaphores. > > On 20 Apr 2009, at 19:11, Jay wrote: > > > > > Searching the web...finds this which seems very relevant: > > > > http://birrell.org/andrew/papers/ImplementingCVs.pdf > > > > - Jay > > > > > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: m3devel at elegosoft.com > >> Date: Mon, 20 Apr 2009 08:47:21 +0000 > >> Subject: [M3devel] crummy ThreadWin32.m3 implementation? > >> > >> > >> Um, ThreadWin32.m3 looks pretty crummy -- all LockMutex calls > >> bottleneck on one giant lock. .v0 and .v1 aren't bad this way. > >> > >> > >> - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 21 14:47:16 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 21 Apr 2009 12:47:16 +0000 Subject: [M3devel] crummy ThreadWin32.m3 implementation? In-Reply-To: References: <14FDB4AD-26AA-43B0-BD25-925C596452EF@cs.purdue.edu> <3577783C-1892-435E-95E3-5E967C9BA638@cs.purdue.edu> Message-ID: did more "research" (search the web..) It sounds like: if fairness not critical, and pre NT 4.0 compat is needed, there are options where mutex/lock=criticalsection If fairness is important, and NT 4.0 can be used, and perf can be degraded, then mutex/lock=kernel mutex, and use the SignalAndWait function They never seem to use a global lock like ours. Should we maybe adopt Boost's code? e.g.: http://svn.boost.org/trac/boost/browser/trunk/boost/thread/win32/mutex.hpp http://svn.boost.org/trac/boost/browser/trunk/boost/thread/win32/condition_variable.hpp I don't know, it all seems kind of unforunate. Perhaps there should be two types of locks, one that can be associated with a conditionvariable (kernel mutex), one that cannot (criticalsection)? I guess our implementation is quite simple and solves "all the problems" by throwing scalability right out -- lots of independent threads acquiring lots of independent locks will all interfere somewhat with each other, but not a ton. The "giant" lock protects too much data, but not for long durations. It might be interesting to see what cygwin does..but I notice..pthread is a superset, e.g. timedwait, trylock, etc. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 21 Apr 2009 04:41:55 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? I'm not keen on it. Checking the version and having two implementation switched between at initialization would be ok though -- actually using function pointers like so: void DoSomething_v2(void) { } void DoSomething_v1(void) { } void DoSomething_init(void) { if (... ) DoSomething = DoSomething_v1; else DoSomething = DoSomething_v2; DoSomething(); } void (*DoSomething)(void) = DoSomething_init; Something more if switching multiple pointers though -- switching a pointer to a struct of function pointers. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 21 Apr 2009 14:33:29 +1000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? Might not be such a bad thing ;-) On 21 Apr 2009, at 14:14, Jay wrote: Only if you drop support for pre-Vista versions. - Jay > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 21 Apr 2009 07:53:57 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? > > Also, note that win32 now supports CVs directly! No need for > semaphores. > > On 20 Apr 2009, at 19:11, Jay wrote: > > > > > Searching the web...finds this which seems very relevant: > > > > http://birrell.org/andrew/papers/ImplementingCVs.pdf > > > > - Jay > > > > > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: m3devel at elegosoft.com > >> Date: Mon, 20 Apr 2009 08:47:21 +0000 > >> Subject: [M3devel] crummy ThreadWin32.m3 implementation? > >> > >> > >> Um, ThreadWin32.m3 looks pretty crummy -- all LockMutex calls > >> bottleneck on one giant lock. .v0 and .v1 aren't bad this way. > >> > >> > >> - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carson at taltos.org Tue Apr 21 20:29:28 2009 From: carson at taltos.org (Carson Gaspar) Date: Tue, 21 Apr 2009 11:29:28 -0700 Subject: [M3devel] Latest ThreadPThread In-Reply-To: References: <8510055B-CBC6-4A02-BAFA-B26AF9A827EC@cs.purdue.edu> Message-ID: <49EE1088.6030006@taltos.org> Tony Hosking wrote: > I'm pretty sure that is only in the user-level threading model, where > thread switches only occur on delivery of a signal to the process. I am > unaware of any OS/hardware that will deliver a thread switch signal in > the middle of INC/DEC. So, effectively, for user level threads INC/DEC > can be assumed atomic. That's what the comments are meant to imply. > Outside ThreadPosix, all other uses of INC/DEC manipulate state that is > already protected appropriately by a lock so should be thread safe. I'm not sure what you mean by INC/DEC... but if it involves changing a value in memory (as opposed to a register), then it is _not_ atomic and _must_ use a lock. The most common mistake I've seen is a variable modified in a signal handler and in the main code, especially SIGCHLD. "nchildren++" is _not_ signal or thread safe. If you're talking about purely register instructions, please ignore me ;-) -- Carson From mika at async.caltech.edu Tue Apr 21 23:41:49 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 21 Apr 2009 14:41:49 -0700 Subject: [M3devel] an old, recurring issue: mapping runtime errors to exceptions? Message-ID: <200904212141.n3LLfnZ4030631@camembert.async.caltech.edu> Hello Modula-3ers, I know this is a question that comes up from time to time, and I am aware of Greg Nelson's short article in "Threads" about why Modula-3 doesn't map runtime errors to exceptions, but the Green Book does allude to mapping runtime errors to exceptions, and I know that the SPIN OS did that. How hard would this be to support in CM3? Attached is a transcript of an interactive session with my current Scheme environment. I think it ought to be obvious why I ask about exceptions. In Modula-3, from safe code, only checked runtime errors can occur. Checked runtime errors cannot violate invariants of the runtime system, so it ought to be safe to convert them to exceptions that can be caught, and then permit the program to continue. I realize this isn't *always* what you want to do, but in an interactive environment, making the system dump core on runtime errors sort of spoils the whole experience. In this application, there are many places where you may want to raise an exception that hasn't been declared. In a non-interactive environment, it is probably best to go for the core dump, but in an interactive environment, it seems to me it ought to just return control to the read-eval-print loop.... Mika LITHP ITH LITHENING. > (define wr (scheme-procedure-stubs-call '(TextWr . New) '())) wr > wr > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) "hello!" > (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) "" > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) "hello!hello!hello!hello!hello!" > (scheme-procedure-stubs-call '(TextWr . ToText) (list '()) '()) *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x80c69c8 = LockMutex + 0x28 in /usr/ports/lang/ezm3/work/ezm3-1.0/libs/m3core/src/thread/POSIX/ThreadPosix.m3 *** use option @M3stackdump to get a stack trace Abort From rcoleburn at scires.com Wed Apr 22 00:22:28 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 21 Apr 2009 18:22:28 -0400 Subject: [M3devel] an old, recurring issue: mapping runtime errors to exceptions? In-Reply-To: <200904212141.n3LLfnZ4030631@camembert.async.caltech.edu> References: <200904212141.n3LLfnZ4030631@camembert.async.caltech.edu> Message-ID: <49EE0E7B.1E75.00D7.1@scires.com> Mika: You state that "Checked runtime errors cannot violate invariants of the runtime system, so it ought to be safe to ..." Are you sure this statement is true for all implementations? I would tend to think that SPIN was able to do this mapping for itself, but in general, it would be difficult to be able to do this for any arbitrary OS environment, esp with differences in underlying libraries and implementations, which is part of what Greg alluded to in the Threads article you reference. Note also on pg 47 of the green book under "2.5.7 Safety" the notes about intrinsic safety and when the compiler makes the guarantee vs. the programmer. I also note from the path in your example (ezm3) that you may not be using the current cm3. Is it possible that the NIL dereference problem in your example has been solved in a later implementation? Regards, Randy >>> Mika Nystrom 4/21/2009 5:41 PM >>> Hello Modula-3ers, I know this is a question that comes up from time to time, and I am aware of Greg Nelson's short article in "Threads" about why Modula-3 doesn't map runtime errors to exceptions, but the Green Book does allude to mapping runtime errors to exceptions, and I know that the SPIN OS did that. How hard would this be to support in CM3? Attached is a transcript of an interactive session with my current Scheme environment. I think it ought to be obvious why I ask about exceptions. In Modula-3, from safe code, only checked runtime errors can occur. Checked runtime errors cannot violate invariants of the runtime system, so it ought to be safe to convert them to exceptions that can be caught, and then permit the program to continue. I realize this isn't *always* what you want to do, but in an interactive environment, making the system dump core on runtime errors sort of spoils the whole experience. In this application, there are many places where you may want to raise an exception that hasn't been declared. In a non-interactive environment, it is probably best to go for the core dump, but in an interactive environment, it seems to me it ought to just return control to the read-eval-print loop.... Mika LITHP ITH LITHENING. > (define wr (scheme-procedure-stubs-call '(TextWr . New) '())) wr > wr > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) "hello!" > (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) "" > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) "hello!hello!hello!hello!hello!" > (scheme-procedure-stubs-call '(TextWr . ToText) (list '()) '()) *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x80c69c8 = LockMutex + 0x28 in /usr/ports/lang/ezm3/work/ezm3-1.0/libs/m3core/src/thread/POSIX/ThreadPosix.m3 *** use option @M3stackdump to get a stack trace Abort 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 mika at async.caltech.edu Wed Apr 22 00:41:19 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 21 Apr 2009 15:41:19 -0700 Subject: [M3devel] an old, recurring issue: mapping runtime errors to exceptions? In-Reply-To: Your message of "Tue, 21 Apr 2009 18:22:28 EDT." <49EE0E7B.1E75.00D7.1@scires.com> Message-ID: <200904212241.n3LMfJB7032643@camembert.async.caltech.edu> Well the point of "safety" is that the system can guarantee that the runtime environment hasn't been damaged by a misbehaving program, no? In fact, in Threads 3 there are not one but *two* reports of implementations that "reflect" runtime errors as exceptions. On of them is SPIN, the other is the commercial CM3 with JVM. See http://www.modula3.org/threads/3/ Nelson's article in Threads 2 doesn't give the possibility of having had the runtime invariants violated as a reason to abort. His arguments are more practical, having to do with debugging. I agree, and I think that the default method of dealing with runtime errors should be to abort the program. But it just is very unfriendly in an interactive environment, and I would love some kind of (possibly very implementation-dependent) way of catching the runtime error. The way Java does it would be ideal, I think..... Nelson's article is here http://www.modula3.org/threads/2/ [Tony, the link in your M3 bibliography is broken!] I'm running this example in a PM3/EZM3 environment right now but that's not relevant. The code I showed you *should* crash. In plain M3 it was: TextWr.ToText(NIL) But in an interactive environment, the user can do this sort of thing. It should give you a nasty error message, not crash your whole environment. Mika "Randy Coleburn" writes: >This is a MIME message. If you are reading this text, you may want to >consider changing to a mail reader or gateway that understands how to >properly handle MIME multipart messages. > >--=__PartBC941634.0__= >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: quoted-printable > >Mika: >=20 >You state that "Checked runtime errors cannot violate invariants of the = >runtime system, so it ought to be safe to ..." >=20 >Are you sure this statement is true for all implementations? >=20 >I would tend to think that SPIN was able to do this mapping for itself, = >but in general, it would be difficult to be able to do this for any = >arbitrary OS environment, esp with differences in underlying libraries and = >implementations, which is part of what Greg alluded to in the Threads = >article you reference. >=20 >Note also on pg 47 of the green book under "2.5.7 Safety" the notes about = >intrinsic safety and when the compiler makes the guarantee vs. the = >programmer. >=20 >I also note from the path in your example (ezm3) that you may not be using = >the current cm3. Is it possible that the NIL dereference problem in your = >example has been solved in a later implementation? >=20 >Regards, >Randy > >>>> Mika Nystrom 4/21/2009 5:41 PM >>> > >Hello Modula-3ers, > >I know this is a question that comes up from time to time, and I >am aware of Greg Nelson's short article in "Threads" about why=20 >Modula-3 doesn't map runtime errors to exceptions, but the Green Book >does allude to mapping runtime errors to exceptions, and I know that >the SPIN OS did that. > >How hard would this be to support in CM3? > >Attached is a transcript of an interactive session with my current >Scheme environment. I think it ought to be obvious why I ask about >exceptions. In Modula-3, from safe code, only checked runtime errors >can occur. Checked runtime errors cannot violate invariants of the >runtime system, so it ought to be safe to convert them to exceptions >that can be caught, and then permit the program to continue. =20 > >I realize this isn't *always* what you want to do, but in an interactive >environment, making the system dump core on runtime errors sort of >spoils the whole experience. > >In this application, there are many places where you may want to >raise an exception that hasn't been declared. In a non-interactive >environment, it is probably best to go for the core dump, but in >an interactive environment, it seems to me it ought to just return >control to the read-eval-print loop.... > Mika > >LITHP ITH LITHENING. >> (define wr (scheme-procedure-stubs-call '(TextWr . New) '())) >wr >> wr > >> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >#t >> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >"hello!" >> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >"" >> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >#t >> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >#t >> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >#t >> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >#t >> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >#t >> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >"hello!hello!hello!hello!hello!" >> (scheme-procedure-stubs-call '(TextWr . ToText) (list '()) '()) > > >*** >*** runtime error: >*** Segmentation violation - possible attempt to dereference NIL >*** pc =3D 0x80c69c8 =3D LockMutex + 0x28 in /usr/ports/lang/ezm3/work/e= >zm3-1.0/libs/m3core/src/thread/POSIX/ThreadPosix.m3 >*** > > use option @M3stackdump to get a stack trace >Abort > > > > > > > >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. > > >--=__PartBC941634.0__= >Content-Type: text/html; charset=US-ASCII >Content-Transfer-Encoding: quoted-printable >Content-Description: HTML > > >"> > > >
Mika:
>
 
>
You state that "Checked runtime errors cannot violate invariants of = >the runtime system, so it ought to be safe to ..."
>
 
>
Are you sure this statement is true for all implementations?> >
 
>
I would tend to think that SPIN was able to do this mapping for = >itself, but in general, it would be difficult to be able to do this for = >any arbitrary OS environment, esp with differences in underlying libraries = >and implementations, which is part of what Greg alluded to in the Threads = >article you reference.
>
 
>
Note also on pg 47 of the green book under "2.5.7 Safety" the notes = >about intrinsic safety and when the compiler makes the guarantee vs. the = >programmer.
>
 
>
I also note from the path in your example (ezm3) that you may not be = >using the current cm3.  Is it possible that the NIL dereference = >problem in your example has been solved in a later implementation?
>
 
>
Regards,
>
Randy

>>> Mika Nystrom <mika at async.caltech.edu> = >4/21/2009 5:41 PM >>>

Hello Modula-3ers,

I know = >this is a question that comes up from time to time, and I
am aware of = >Greg Nelson's short article in "Threads" about why
Modula-3 doesn't = >map runtime errors to exceptions, but the Green Book
does allude to = >mapping runtime errors to exceptions, and I know that
the SPIN OS did = >that.

How hard would this be to support in CM3?

Attached is = >a transcript of an interactive session with my current
Scheme environmen= >t.  I think it ought to be obvious why I ask about
exceptions. = >; In Modula-3, from safe code, only checked runtime errors
can = >occur.  Checked runtime errors cannot violate invariants of the
run= >time system, so it ought to be safe to convert them to exceptions
that = >can be caught, and then permit the program to continue. 

I = >realize this isn't *always* what you want to do, but in an interactive
e= >nvironment, making the system dump core on runtime errors sort of
spoils= > the whole experience.

In this application, there are many places = >where you may want to
raise an exception that hasn't been declared. = >; In a non-interactive
environment, it is probably best to go for the = >core dump, but in
an interactive environment, it seems to me it ought = >to just return
control to the read-eval-print loop....

 &nbs= >p;   Mika

LITHP ITH LITHENING.
> (define wr = >(scheme-procedure-stubs-call '(TextWr . New) '()))
wr
> wr
<= >Modula-3 object : TextWr.T, BRANDED TextWr_^%#%^__0001M>
> = >(scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '())
#t<= >BR>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) = >'())
"hello!"
> (scheme-procedure-stubs-call '(TextWr . ToText) = >(list wr) '())
""
> (scheme-procedure-stubs-call '(Wr . PutText) = >(list wr "hello!") '())
#t
> (scheme-procedure-stubs-call '(Wr . = >PutText) (list wr "hello!") '())
#t
> (scheme-procedure-stubs-call= > '(Wr . PutText) (list wr "hello!") '())
#t
> (scheme-procedure-st= >ubs-call '(Wr . PutText) (list wr "hello!") '())
#t
> (scheme-proc= >edure-stubs-call '(Wr . PutText) (list wr "hello!") '())
#t
> = >(scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '())
"hello!he= >llo!hello!hello!hello!"
> (scheme-procedure-stubs-call '(TextWr . = >ToText) (list '()) '())


***
*** runtime error:
*** &n= >bsp;  Segmentation violation - possible attempt to dereference = >NIL
***    pc =3D 0x80c69c8 =3D LockMutex + 0x28 in = >/usr/ports/lang/ezm3/work/ezm3-1.0/libs/m3core/src/thread/POSIX/ThreadPosix= >.m3
***

  use option @M3stackdump to get a stack trace
Ab= >ort






> >--=__PartBC941634.0__=-- From hosking at cs.purdue.edu Wed Apr 22 02:02:52 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Apr 2009 10:02:52 +1000 Subject: [M3devel] explanation of CheckLoadTracedRef? In-Reply-To: References: Message-ID: <19C20763-18A0-413A-9440-3D7ED0C918B1@cs.purdue.edu> On 21 Apr 2009, at 19:37, Jay wrote: > > > How bad/unportable was it the previous way, the VM-synchronized > way? > > > > Not compatible with system threading. > > > Really? NT386 wasn't VM-synchronized back in 3.6, 4.1, etc.? It was, but every system call had to be wrapped with a call to acquire the global heap lock! > Or only with great cost? Yes, taking the lock was expensive and prevented scaling on multi-cores. > I have to admit, those old import .libs, kernel32.lib, etc. I didn't > realize what was in them when I deleted them. I thought they were > just regular import .libs. There was also the work to wrap all dll symbols to acquire the lock. > I think I got luckly in that the overlap between me deleting them > and you removing VM-synchronized GC was small or zero. You should have seen the mess it was before... ;-) > > You should *never* access a field in the heap in C code! All > > accesses to traced fields in the heap must take place in Modula-3. > > Otherwise things will break! C wrappers should not do anything other > > than forward calls to C library calls. They should not perform heap > > accesses. > > > Ok, that makes sense. > Important "out" is the accessing stack is always ok. Yes, so long as a references to an object is held on the stack then it is safe to pass an address within it to external calls. Thus, many C functions can take VAR arguments that may end being references to the fields of objects. The compiler injects the necessary CheckLoad/ CheckStore operations when passing VAR parameters, etc., and the GC maintains the invariant that all stack-referenced objects don't move, stay black (for incremental GC), and remain dirty (for generational GC). > But this is a requirement I didn't keep in mind. > Now, luckily, the C wrappers are all relatively thin and not difficult > to re-review in their entirety. Right. I think I did see you compute and pass an offset to C code, but that may have only been in code you e-mailed me for perusal rather than code that got checked in. Might be worth reviewing... > But, take for example "open". > The first parameter to it is bound to be in the heap. The ambiguous roots garbage collector we use maintains the invariant that pointers to the interior of heap objects from the stack *pin* that object in the heap: it will not move while the pointer from the stack exists, and invariants will be maintained so that its contenst can be manipulated safely even in the face of incremental and generational GC. > But probably it is untraced or somehow ok, since it does > come from a module used primarily for C interop. Certainly, C code should never be manipulating the *traced* fields of traced heap objects. It is fine for it to manipulate the untraced fields of traced heap objects. > And, the line between C wrappers and the "C library" that they > forward to > does not exist. > If I, say, pass a VAR to a VAR..no check is made? Not sure what you mean by this. Any call that passes traced VAR params will generate a check as necessary before the call. > Important to declare extern/C functions as taking UNTRACED REF and > not VAR? No, VAR is fine. So long as the VAR value being passed is not traced. > > I think you are confusing incremental and incremental GC. > You assume I understand more than I do (I assume you have a typo. :)) ;-) > "generational" -- the concept that most objects die young. > (aka most objects could have been allocated on the stack...) Not quite. The idea is that the likelihood of an object dying is a function of its age. There is a *weak* generational hypothesis that "most objects die young", and a *strong* generational hypothesis that "the older an object is the less likely it is to die". Many (but not all) programs support these hypotheses, which permits generational GC to focus effort where it is likely to be profitable (i.e., to free up a lot of space). > But does that imply detailed implementation choices, or is just like > a "guiding principle"? > I guess it implies the heap is split into at least two generations, > old and young. > Though I guess in reality there is a range of young, less young, > lesser young, least young, etc. Right, many different collectors have exploited age in this way. For the M3 collector we have just two generations: old and young. > And that has objects age, they should be moved from young to old > heaps, and references to them either updated right away, or "caught" > upon use and updated then...something like that. Old-space objects are "clean" if they contain no references to young- space objects. The Modula-3 compiler injects checks to make sure that whenever we store a reference into a clean old-space object it is marked "dirty". When a young-space collection occurs we must process the references in dirty old-space objects as roots into the young-space. > "incremental" -- don't pause the world.. Not quite. The opposite of stop-the-world (stopping all the mutator threads to process their stacks) is on-the-fly. Incremental refers to the ability to interleave GC work with mutator work. If the GC work can be interleaved with mutator threads without stopping the mutator threads at each increment then the collector is said to be concurrent (GC work proceeds concurrently with mutator work). The current M3 collector has a stop-the-world non-moving phase, followed by an concurrent copying phase. I have some incomplete work that will also make the M3 collector on-the-fly (no STW phase) and parallel (multiple GC threads can operate concurrently). Hope all this helps! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Apr 22 02:10:09 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Apr 2009 10:10:09 +1000 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <20090421122648.GB25465@topoi.pooq.com> References: <49EC7A06.5040403@cox.net> <20090421122648.GB25465@topoi.pooq.com> Message-ID: I'd prefer something like TAGGEDINT or some such. But I am still not convinced that the minimalist proposal and this proposal differ in any significant way. On 21 Apr 2009, at 22:26, hendrik at topoi.pooq.com wrote: > On Mon, Apr 20, 2009 at 08:35:02AM -0500, Rodney M. Bates wrote: >> >> --------------------------------------------------------------------- >> My (Rodney's) "safe" proposal: >> >> There is a new type named TAGABLE. It is a subrange of INTEGER, >> whose > > Please spell it TAGGABLE. TAG doubles its last consonant when adding > suffixes: TAGGED, TAGGING. > > -- hendrik From hosking at cs.purdue.edu Wed Apr 22 02:11:53 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Apr 2009 10:11:53 +1000 Subject: [M3devel] crummy ThreadWin32.m3 implementation? In-Reply-To: References: <14FDB4AD-26AA-43B0-BD25-925C596452EF@cs.purdue.edu> <3577783C-1892-435E-95E3-5E967C9BA638@cs.purdue.edu> Message-ID: <591C91AF-5362-43FE-8564-7FB9F4D32ECB@cs.purdue.edu> I'd be curious what OpenJDK does on Windows... On 21 Apr 2009, at 22:46, Jay wrote: > did more "research" (search the web..) > > It sounds like: > if fairness not critical, and pre NT 4.0 compat is needed, there > are options where mutex/lock=criticalsection > > If fairness is important, and NT 4.0 can be used, and perf can be > degraded, then mutex/lock=kernel mutex, and use the SignalAndWait > function > > They never seem to use a global lock like ours. > > Should we maybe adopt Boost's code? > e.g.: > > http://svn.boost.org/trac/boost/browser/trunk/boost/thread/win32/mutex.hpp > http://svn.boost.org/trac/boost/browser/trunk/boost/thread/win32/condition_variable.hpp > > I don't know, it all seems kind of unforunate. > > Perhaps there should be two types of locks, one that can be > associated with a conditionvariable (kernel mutex), one that cannot > (criticalsection)? > > I guess our implementation is quite simple and solves "all the > problems" by throwing scalability right out -- lots of independent > threads acquiring lots of independent locks will all interfere > somewhat with each other, but not a ton. The "giant" lock protects > too much data, but not for long durations. > > It might be interesting to see what cygwin does..but I > notice..pthread is a superset, e.g. timedwait, trylock, etc. > > - Jay > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Tue, 21 Apr 2009 04:41:55 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? > > I'm not keen on it. > Checking the version and having two implementation switched between > at initialization would be ok though -- actually using function > pointers like so: > > void DoSomething_v2(void) { } > void DoSomething_v1(void) { } > void DoSomething_init(void) > { > if (... ) > DoSomething = DoSomething_v1; > else > DoSomething = DoSomething_v2; > DoSomething(); > } > > void (*DoSomething)(void) = DoSomething_init; > > Something more if switching multiple pointers though -- switching a > pointer to a struct of function pointers. > > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 21 Apr 2009 14:33:29 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? > > Might not be such a bad thing ;-) > > On 21 Apr 2009, at 14:14, Jay wrote: > > Only if you drop support for pre-Vista versions. > > - Jay > > > > > From: hosking at cs.purdue.edu > > To: jay.krell at cornell.edu > > Date: Tue, 21 Apr 2009 07:53:57 +1000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? > > > > Also, note that win32 now supports CVs directly! No need for > > semaphores. > > > > On 20 Apr 2009, at 19:11, Jay wrote: > > > > > > > > Searching the web...finds this which seems very relevant: > > > > > > http://birrell.org/andrew/papers/ImplementingCVs.pdf > > > > > > - Jay > > > > > > > > > > > > ---------------------------------------- > > >> From: jay.krell at cornell.edu > > >> To: m3devel at elegosoft.com > > >> Date: Mon, 20 Apr 2009 08:47:21 +0000 > > >> Subject: [M3devel] crummy ThreadWin32.m3 implementation? > > >> > > >> > > >> Um, ThreadWin32.m3 looks pretty crummy -- all LockMutex calls > > >> bottleneck on one giant lock. .v0 and .v1 aren't bad this way. > > >> > > >> > > >> - Jay > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 22 02:54:00 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 22 Apr 2009 00:54:00 +0000 Subject: [M3devel] explanation of CheckLoadTracedRef? In-Reply-To: <19C20763-18A0-413A-9440-3D7ED0C918B1@cs.purdue.edu> References: <19C20763-18A0-413A-9440-3D7ED0C918B1@cs.purdue.edu> Message-ID: Yes this helps, thank you. Maybe checkin under doc? One thing you didn't understand my wording about and you seemed to contradict is "VAR to VAR". PROCEDURE F1() = VAR i; BEGIN F2(i); END F1; PROCEDURE F2(VAR a:INTEGER)= BEGIN F3(i); END F2; PROCEDURE F3(VAR a:INTEGER)= BEGIN a := 1; END F3; Where are the calls to CheckLoad/StoreTracedRef? (Duh, I can try it out..) It seems redundant to put them "everywhere". Esp. it seems that F2 shouldn't have do anything. But throw in that F3 might extern and that is unclear. So I just made up a suggestion that VAR is not good to pass to C code. That checks are inserted when 1) a pointer is dereferenced -- loaded or stored in Modula-3 or 2) a pointer becomes untraced (var becomes untraced ref, among others). > Right. I think I did see you compute and pass an offset to C code I had something like that very recently but think I didn't set it or commit it. I had something like: size_t offset; Init(Mutex* root, int* interior) { offset = (size_t)interior - (size_t)root; } DoSomething(Mutex* anotherRoot) { int* interior = (int*)(offset + (size_t)anotherRoot); printf("%d\n", *interior); } but I came up with a way to avoid that I think, and then rolled it all back or something anyway. - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] explanation of CheckLoadTracedRef? Date: Wed, 22 Apr 2009 10:02:52 +1000 On 21 Apr 2009, at 19:37, Jay wrote: > > How bad/unportable was it the previous way, the VM-synchronized way? > > Not compatible with system threading. Really? NT386 wasn't VM-synchronized back in 3.6, 4.1, etc.? It was, but every system call had to be wrapped with a call to acquire the global heap lock! Or only with great cost? Yes, taking the lock was expensive and prevented scaling on multi-cores. I have to admit, those old import .libs, kernel32.lib, etc. I didn't realize what was in them when I deleted them. I thought they were just regular import .libs. There was also the work to wrap all dll symbols to acquire the lock. I think I got luckly in that the overlap between me deleting them and you removing VM-synchronized GC was small or zero. You should have seen the mess it was before... ;-) > You should *never* access a field in the heap in C code! All > accesses to traced fields in the heap must take place in Modula-3. > Otherwise things will break! C wrappers should not do anything other > than forward calls to C library calls. They should not perform heap > accesses. Ok, that makes sense. Important "out" is the accessing stack is always ok. Yes, so long as a references to an object is held on the stack then it is safe to pass an address within it to external calls. Thus, many C functions can take VAR arguments that may end being references to the fields of objects. The compiler injects the necessary CheckLoad/CheckStore operations when passing VAR parameters, etc., and the GC maintains the invariant that all stack-referenced objects don't move, stay black (for incremental GC), and remain dirty (for generational GC). But this is a requirement I didn't keep in mind. Now, luckily, the C wrappers are all relatively thin and not difficult to re-review in their entirety. Right. I think I did see you compute and pass an offset to C code, but that may have only been in code you e-mailed me for perusal rather than code that got checked in. Might be worth reviewing... But, take for example "open". The first parameter to it is bound to be in the heap. The ambiguous roots garbage collector we use maintains the invariant that pointers to the interior of heap objects from the stack *pin* that object in the heap: it will not move while the pointer from the stack exists, and invariants will be maintained so that its contenst can be manipulated safely even in the face of incremental and generational GC. But probably it is untraced or somehow ok, since it does come from a module used primarily for C interop. Certainly, C code should never be manipulating the *traced* fields of traced heap objects. It is fine for it to manipulate the untraced fields of traced heap objects. And, the line between C wrappers and the "C library" that they forward to does not exist. If I, say, pass a VAR to a VAR..no check is made? Not sure what you mean by this. Any call that passes traced VAR params will generate a check as necessary before the call. Important to declare extern/C functions as taking UNTRACED REF and not VAR? No, VAR is fine. So long as the VAR value being passed is not traced. > I think you are confusing incremental and incremental GC. You assume I understand more than I do (I assume you have a typo. :)) ;-) "generational" -- the concept that most objects die young. (aka most objects could have been allocated on the stack...) Not quite. The idea is that the likelihood of an object dying is a function of its age. There is a *weak* generational hypothesis that "most objects die young", and a *strong* generational hypothesis that "the older an object is the less likely it is to die". Many (but not all) programs support these hypotheses, which permits generational GC to focus effort where it is likely to be profitable (i.e., to free up a lot of space). But does that imply detailed implementation choices, or is just like a "guiding principle"? I guess it implies the heap is split into at least two generations, old and young. Though I guess in reality there is a range of young, less young, lesser young, least young, etc. Right, many different collectors have exploited age in this way. For the M3 collector we have just two generations: old and young. And that has objects age, they should be moved from young to old heaps, and references to them either updated right away, or "caught" upon use and updated then...something like that. Old-space objects are "clean" if they contain no references to young-space objects. The Modula-3 compiler injects checks to make sure that whenever we store a reference into a clean old-space object it is marked "dirty". When a young-space collection occurs we must process the references in dirty old-space objects as roots into the young-space. "incremental" -- don't pause the world.. Not quite. The opposite of stop-the-world (stopping all the mutator threads to process their stacks) is on-the-fly. Incremental refers to the ability to interleave GC work with mutator work. If the GC work can be interleaved with mutator threads without stopping the mutator threads at each increment then the collector is said to be concurrent (GC work proceeds concurrently with mutator work). The current M3 collector has a stop-the-world non-moving phase, followed by an concurrent copying phase. I have some incomplete work that will also make the M3 collector on-the-fly (no STW phase) and parallel (multiple GC threads can operate concurrently). Hope all this helps! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Apr 22 04:14:13 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Apr 2009 12:14:13 +1000 Subject: [M3devel] Latest ThreadPThread In-Reply-To: <49EE1088.6030006@taltos.org> References: <8510055B-CBC6-4A02-BAFA-B26AF9A827EC@cs.purdue.edu> <49EE1088.6030006@taltos.org> Message-ID: <16FF28FE-78F3-4C16-A756-72C8D55437D5@cs.purdue.edu> On 22 Apr 2009, at 04:29, Carson Gaspar wrote: > Tony Hosking wrote: > >> I'm pretty sure that is only in the user-level threading model, >> where thread switches only occur on delivery of a signal to the >> process. I am unaware of any OS/hardware that will deliver a thread >> switch signal in the middle of INC/DEC. So, effectively, for user >> level threads INC/DEC can be assumed atomic. That's what the >> comments are meant to imply. Outside ThreadPosix, all other uses >> of INC/DEC manipulate state that is already protected appropriately >> by a lock so should be thread safe. > > I'm not sure what you mean by INC/DEC... but if it involves changing > a value in memory (as opposed to a register), then it is _not_ > atomic and _must_ use a lock. The most common mistake I've seen is a > variable modified in a signal handler and in the main code, > especially SIGCHLD. "nchildren++" is _not_ signal or thread safe. Indeed, on a multi-processor with system-scheduled threads that is the case. My comments pertain only to the rather narrow implementation of single-processor user-level threads using signal-handling that the Modula-3 user-level threads implementation uses/used. That implementation is pretty much unused on modern platforms where we support proper hardware-level parallelism. There, all memory operations must be protected by proper synchronization. From hosking at cs.purdue.edu Wed Apr 22 04:26:01 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Apr 2009 12:26:01 +1000 Subject: [M3devel] an old, recurring issue: mapping runtime errors to exceptions? In-Reply-To: <200904212241.n3LMfJB7032643@camembert.async.caltech.edu> References: <200904212241.n3LMfJB7032643@camembert.async.caltech.edu> Message-ID: CM3 does map some (I'm not sure if all) run-time errors to exceptions. See RuntimeError.i3 for details of what exceptions might occur. On 22 Apr 2009, at 08:41, Mika Nystrom wrote: > > Well the point of "safety" is that the system can guarantee that the > runtime environment hasn't been damaged by a misbehaving program, no? > > In fact, in Threads 3 there are not one but *two* reports of > implementations that "reflect" runtime errors as exceptions. On > of them is SPIN, the other is the commercial CM3 with JVM. > > See > > http://www.modula3.org/threads/3/ > > Nelson's article in Threads 2 doesn't give the possibility of having > had the runtime invariants violated as a reason to abort. His > arguments are more practical, having to do with debugging. I agree, > and I think that the default method of dealing with runtime errors > should be to abort the program. But it just is very unfriendly in > an interactive environment, and I would love some kind of (possibly > very implementation-dependent) way of catching the runtime error. > The way Java does it would be ideal, I think..... > > Nelson's article is here > > http://www.modula3.org/threads/2/ > > [Tony, the link in your M3 bibliography is broken!] > > I'm running this example in a PM3/EZM3 environment right now but > that's not relevant. The code I showed you *should* crash. In > plain M3 it was: > > TextWr.ToText(NIL) > > But in an interactive environment, the user can do this sort of > thing. It should give you a nasty error message, not crash your > whole environment. > > Mika > > > > "Randy Coleburn" writes: >> This is a MIME message. If you are reading this text, you may want to >> consider changing to a mail reader or gateway that understands how to >> properly handle MIME multipart messages. >> >> --=__PartBC941634.0__= >> Content-Type: text/plain; charset=US-ASCII >> Content-Transfer-Encoding: quoted-printable >> >> Mika: >> =20 >> You state that "Checked runtime errors cannot violate invariants of >> the = >> runtime system, so it ought to be safe to ..." >> =20 >> Are you sure this statement is true for all implementations? >> =20 >> I would tend to think that SPIN was able to do this mapping for >> itself, = >> but in general, it would be difficult to be able to do this for any = >> arbitrary OS environment, esp with differences in underlying >> libraries and = >> implementations, which is part of what Greg alluded to in the >> Threads = >> article you reference. >> =20 >> Note also on pg 47 of the green book under "2.5.7 Safety" the notes >> about = >> intrinsic safety and when the compiler makes the guarantee vs. the = >> programmer. >> =20 >> I also note from the path in your example (ezm3) that you may not >> be using = >> the current cm3. Is it possible that the NIL dereference problem >> in your = >> example has been solved in a later implementation? >> =20 >> Regards, >> Randy >> >>>>> Mika Nystrom 4/21/2009 5:41 PM >>> >> >> Hello Modula-3ers, >> >> I know this is a question that comes up from time to time, and I >> am aware of Greg Nelson's short article in "Threads" about why=20 >> Modula-3 doesn't map runtime errors to exceptions, but the Green Book >> does allude to mapping runtime errors to exceptions, and I know that >> the SPIN OS did that. >> >> How hard would this be to support in CM3? >> >> Attached is a transcript of an interactive session with my current >> Scheme environment. I think it ought to be obvious why I ask about >> exceptions. In Modula-3, from safe code, only checked runtime errors >> can occur. Checked runtime errors cannot violate invariants of the >> runtime system, so it ought to be safe to convert them to exceptions >> that can be caught, and then permit the program to continue. =20 >> >> I realize this isn't *always* what you want to do, but in an >> interactive >> environment, making the system dump core on runtime errors sort of >> spoils the whole experience. >> >> In this application, there are many places where you may want to >> raise an exception that hasn't been declared. In a non-interactive >> environment, it is probably best to go for the core dump, but in >> an interactive environment, it seems to me it ought to just return >> control to the read-eval-print loop.... > >> Mika >> >> LITHP ITH LITHENING. >>> (define wr (scheme-procedure-stubs-call '(TextWr . New) '())) >> wr >>> wr >> >>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >> #t >>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >> "hello!" >>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >> "" >>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >> #t >>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >> #t >>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >> #t >>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >> #t >>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >> #t >>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >> "hello!hello!hello!hello!hello!" >>> (scheme-procedure-stubs-call '(TextWr . ToText) (list '()) '()) >> >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL >> *** pc =3D 0x80c69c8 =3D LockMutex + 0x28 in /usr/ports/lang/ >> ezm3/work/e= >> zm3-1.0/libs/m3core/src/thread/POSIX/ThreadPosix.m3 >> *** >> >> use option @M3stackdump to get a stack trace >> Abort >> >> >> >> >> >> >> >> 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. >> >> >> --=__PartBC941634.0__= >> Content-Type: text/html; charset=US-ASCII >> Content-Transfer-Encoding: quoted-printable >> Content-Description: HTML >> >> >> > charset=3Diso-8859-15= >> "> >> >> >>
Mika:
>>
 
>>
You state that "Checked runtime errors cannot violate >> invariants of = >> the runtime system, so it ought to be safe to ..."
>>
 
>>
Are you sure this statement is true for all >> implementations?>> >>
 
>>
I would tend to think that SPIN was able to do this mapping >> for = >> itself, but in general, it would be difficult to be able to do this >> for = >> any arbitrary OS environment, esp with differences in underlying >> libraries = >> and implementations, which is part of what Greg alluded to in the >> Threads = >> article you reference.
>>
 
>>
Note also on pg 47 of the green book under "2.5.7 Safety" the >> notes = >> about intrinsic safety and when the compiler makes the guarantee >> vs. the = >> programmer.
>>
 
>>
I also note from the path in your example (ezm3) that you may >> not be = >> using the current cm3.  Is it possible that the NIL >> dereference = >> problem in your example has been solved in a later implementation?> DIV> >>
 
>>
Regards,
>>
Randy

>>> Mika Nystrom <mika at async.caltech.edu >> > = >> 4/21/2009 5:41 PM >>>

Hello Modula-3ers,

I >> know = >> this is a question that comes up from time to time, and I
am >> aware of = >> Greg Nelson's short article in "Threads" about why
Modula-3 >> doesn't = >> map runtime errors to exceptions, but the Green Book
does allude >> to = >> mapping runtime errors to exceptions, and I know that
the SPIN >> OS did = >> that.

How hard would this be to support in CM3? >>

Attached is = >> a transcript of an interactive session with my current
Scheme >> environmen= >> t.  I think it ought to be obvious why I ask >> about
exceptions. = >> ; In Modula-3, from safe code, only checked runtime errors
can = >> occur.  Checked runtime errors cannot violate invariants of >> the
run= >> time system, so it ought to be safe to convert them to >> exceptions
that = >> can be caught, and then permit the program to continue.  >>

I = >> realize this isn't *always* what you want to do, but in an >> interactive
e= >> nvironment, making the system dump core on runtime errors sort >> of
spoils= >> the whole experience.

In this application, there are many >> places = >> where you may want to
raise an exception that hasn't been >> declared. = >> ; In a non-interactive
environment, it is probably best to go >> for the = >> core dump, but in
an interactive environment, it seems to me it >> ought = >> to just return
control to the read-eval-print >> loop....

 &nbs= >> p;   Mika

LITHP ITH LITHENING.
> (define wr = >> (scheme-procedure-stubs-call '(TextWr . New) '()))
wr
> >> wr
<= >> Modula-3 object : TextWr.T, BRANDED TextWr_^%#%^__0001M>
> = >> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") >> '())
#t<= >> BR>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) = >> '())
"hello!"
> (scheme-procedure-stubs-call '(TextWr . >> ToText) = >> (list wr) '())
""
> (scheme-procedure-stubs-call '(Wr . >> PutText) = >> (list wr "hello!") '())
#t
> (scheme-procedure-stubs-call >> '(Wr . = >> PutText) (list wr "hello!") '())
#t
> (scheme-procedure- >> stubs-call= >> '(Wr . PutText) (list wr "hello!") '())
#t
> (scheme- >> procedure-st= >> ubs-call '(Wr . PutText) (list wr "hello!") '())
#t
> >> (scheme-proc= >> edure-stubs-call '(Wr . PutText) (list wr "hello!") >> '())
#t
> = >> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) >> '())
"hello!he= >> llo!hello!hello!hello!"
> (scheme-procedure-stubs-call >> '(TextWr . = >> ToText) (list '()) '())


***
*** runtime >> error:
*** &n= >> bsp;  Segmentation violation - possible attempt to dereference = >> NIL
***    pc =3D 0x80c69c8 =3D LockMutex + 0x28 >> in = >> /usr/ports/lang/ezm3/work/ezm3-1.0/libs/m3core/src/thread/POSIX/ >> ThreadPosix= >> .m3
***

  use option @M3stackdump to get a stack >> trace
Ab= >> ort






>> >> --=__PartBC941634.0__=-- From mika at async.caltech.edu Wed Apr 22 04:38:18 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 21 Apr 2009 19:38:18 -0700 Subject: [M3devel] an old, recurring issue: mapping runtime errors to exceptions? In-Reply-To: Your message of "Wed, 22 Apr 2009 12:26:01 +1000." Message-ID: <200904220238.n3M2cIWk040392@camembert.async.caltech.edu> It's as simple as that!? Wow! Tony Hosking writes: >CM3 does map some (I'm not sure if all) run-time errors to >exceptions. See RuntimeError.i3 for details of what exceptions might >occur. > >On 22 Apr 2009, at 08:41, Mika Nystrom wrote: > >> > Well the point of "safety" is that the system can guarantee that the >> runtime environment hasn't been damaged by a misbehaving program, no? >> >> In fact, in Threads 3 there are not one but *two* reports of >> implementations that "reflect" runtime errors as exceptions. On >> of them is SPIN, the other is the commercial CM3 with JVM. >> >> See >> >> http://www.modula3.org/threads/3/ >> >> Nelson's article in Threads 2 doesn't give the possibility of having >> had the runtime invariants violated as a reason to abort. His >> arguments are more practical, having to do with debugging. I agree, >> and I think that the default method of dealing with runtime errors >> should be to abort the program. But it just is very unfriendly in >> an interactive environment, and I would love some kind of (possibly >> very implementation-dependent) way of catching the runtime error. >> The way Java does it would be ideal, I think..... >> >> Nelson's article is here >> >> http://www.modula3.org/threads/2/ >> >> [Tony, the link in your M3 bibliography is broken!] >> >> I'm running this example in a PM3/EZM3 environment right now but >> that's not relevant. The code I showed you *should* crash. In >> plain M3 it was: >> >> TextWr.ToText(NIL) >> >> But in an interactive environment, the user can do this sort of >> thing. It should give you a nasty error message, not crash your >> whole environment. >> >> Mika >> >> >> >> "Randy Coleburn" writes: >>> This is a MIME message. If you are reading this text, you may want to >>> consider changing to a mail reader or gateway that understands how to >>> properly handle MIME multipart messages. >>> >>> --=__PartBC941634.0__= >>> Content-Type: text/plain; charset=US-ASCII >>> Content-Transfer-Encoding: quoted-printable >>> >>> Mika: >>> =20 >>> You state that "Checked runtime errors cannot violate invariants of >>> the = >>> runtime system, so it ought to be safe to ..." >>> =20 >>> Are you sure this statement is true for all implementations? >>> =20 >>> I would tend to think that SPIN was able to do this mapping for >>> itself, = >>> but in general, it would be difficult to be able to do this for any = >>> arbitrary OS environment, esp with differences in underlying >>> libraries and = >>> implementations, which is part of what Greg alluded to in the >>> Threads = >>> article you reference. >>> =20 >>> Note also on pg 47 of the green book under "2.5.7 Safety" the notes >>> about = >>> intrinsic safety and when the compiler makes the guarantee vs. the = >>> programmer. >>> =20 >>> I also note from the path in your example (ezm3) that you may not >>> be using = >>> the current cm3. Is it possible that the NIL dereference problem >>> in your = >>> example has been solved in a later implementation? >>> =20 >>> Regards, >>> Randy >>> >>>>>> Mika Nystrom 4/21/2009 5:41 PM >>> >>> >>> Hello Modula-3ers, >>> >>> I know this is a question that comes up from time to time, and I >>> am aware of Greg Nelson's short article in "Threads" about why=20 >>> Modula-3 doesn't map runtime errors to exceptions, but the Green Book >>> does allude to mapping runtime errors to exceptions, and I know that >>> the SPIN OS did that. >>> >>> How hard would this be to support in CM3? >>> >>> Attached is a transcript of an interactive session with my current >>> Scheme environment. I think it ought to be obvious why I ask about >>> exceptions. In Modula-3, from safe code, only checked runtime errors >>> can occur. Checked runtime errors cannot violate invariants of the >>> runtime system, so it ought to be safe to convert them to exceptions >>> that can be caught, and then permit the program to continue. =20 >>> >>> I realize this isn't *always* what you want to do, but in an >>> interactive >>> environment, making the system dump core on runtime errors sort of >>> spoils the whole experience. >>> >>> In this application, there are many places where you may want to >>> raise an exception that hasn't been declared. In a non-interactive >>> environment, it is probably best to go for the core dump, but in >>> an interactive environment, it seems to me it ought to just return >>> control to the read-eval-print loop.... >> >>> Mika >>> >>> LITHP ITH LITHENING. >>>> (define wr (scheme-procedure-stubs-call '(TextWr . New) '())) >>> wr >>>> wr >>> >>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>> #t >>>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >>> "hello!" >>>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >>> "" >>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>> #t >>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>> #t >>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>> #t >>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>> #t >>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>> #t >>>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >>> "hello!hello!hello!hello!hello!" >>>> (scheme-procedure-stubs-call '(TextWr . ToText) (list '()) '()) >>> >>> >>> *** >>> *** runtime error: >>> *** Segmentation violation - possible attempt to dereference NIL >>> *** pc =3D 0x80c69c8 =3D LockMutex + 0x28 in /usr/ports/lang/ >>> ezm3/work/e= >>> zm3-1.0/libs/m3core/src/thread/POSIX/ThreadPosix.m3 >>> *** >>> >>> use option @M3stackdump to get a stack trace >>> Abort >>> >>> >>> >>> >>> >>> >>> >>> 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. >>> >>> >>> --=__PartBC941634.0__= >>> Content-Type: text/html; charset=US-ASCII >>> Content-Transfer-Encoding: quoted-printable >>> Content-Description: HTML >>> >>> >>> >> charset=3Diso-8859-15= >>> "> >>> >>> >>>
Mika:
>>>
 
>>>
You state that "Checked runtime errors cannot violate >>> invariants of = >>> the runtime system, so it ought to be safe to ..."
>>>
 
>>>
Are you sure this statement is true for all >>> implementations?>>> >>>
 
>>>
I would tend to think that SPIN was able to do this mapping >>> for = >>> itself, but in general, it would be difficult to be able to do this >>> for = >>> any arbitrary OS environment, esp with differences in underlying >>> libraries = >>> and implementations, which is part of what Greg alluded to in the >>> Threads = >>> article you reference.
>>>
 
>>>
Note also on pg 47 of the green book under "2.5.7 Safety" the >>> notes = >>> about intrinsic safety and when the compiler makes the guarantee >>> vs. the = >>> programmer.
>>>
 
>>>
I also note from the path in your example (ezm3) that you may >>> not be = >>> using the current cm3.  Is it possible that the NIL >>> dereference = >>> problem in your example has been solved in a later implementation?>> DIV> >>>
 
>>>
Regards,
>>>
Randy

>>> Mika Nystrom <mika at async.caltech.edu >>> > = >>> 4/21/2009 5:41 PM >>>

Hello Modula-3ers,

I >>> know = >>> this is a question that comes up from time to time, and I
am >>> aware of = >>> Greg Nelson's short article in "Threads" about why
Modula-3 >>> doesn't = >>> map runtime errors to exceptions, but the Green Book
does allude >>> to = >>> mapping runtime errors to exceptions, and I know that
the SPIN >>> OS did = >>> that.

How hard would this be to support in CM3? >>>

Attached is = >>> a transcript of an interactive session with my current
Scheme >>> environmen= >>> t.  I think it ought to be obvious why I ask >>> about
exceptions. = >>> ; In Modula-3, from safe code, only checked runtime errors
can = >>> occur.  Checked runtime errors cannot violate invariants of >>> the
run= >>> time system, so it ought to be safe to convert them to >>> exceptions
that = >>> can be caught, and then permit the program to continue.  >>>

I = >>> realize this isn't *always* what you want to do, but in an >>> interactive
e= >>> nvironment, making the system dump core on runtime errors sort >>> of
spoils= >>> the whole experience.

In this application, there are many >>> places = >>> where you may want to
raise an exception that hasn't been >>> declared. = >>> ; In a non-interactive
environment, it is probably best to go >>> for the = >>> core dump, but in
an interactive environment, it seems to me it >>> ought = >>> to just return
control to the read-eval-print >>> loop....

 &nbs= >>> p;   Mika

LITHP ITH LITHENING.
> (define wr = >>> (scheme-procedure-stubs-call '(TextWr . New) '()))
wr
> >>> wr
<= >>> Modula-3 object : TextWr.T, BRANDED TextWr_^%#%^__0001M>
> = >>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") >>> '())
#t<= >>> BR>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) = >>> '())
"hello!"
> (scheme-procedure-stubs-call '(TextWr . >>> ToText) = >>> (list wr) '())
""
> (scheme-procedure-stubs-call '(Wr . >>> PutText) = >>> (list wr "hello!") '())
#t
> (scheme-procedure-stubs-call >>> '(Wr . = >>> PutText) (list wr "hello!") '())
#t
> (scheme-procedure- >>> stubs-call= >>> '(Wr . PutText) (list wr "hello!") '())
#t
> (scheme- >>> procedure-st= >>> ubs-call '(Wr . PutText) (list wr "hello!") '())
#t
> >>> (scheme-proc= >>> edure-stubs-call '(Wr . PutText) (list wr "hello!") >>> '())
#t
> = >>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) >>> '())
"hello!he= >>> llo!hello!hello!hello!"
> (scheme-procedure-stubs-call >>> '(TextWr . = >>> ToText) (list '()) '())


***
*** runtime >>> error:
*** &n= >>> bsp;  Segmentation violation - possible attempt to dereference = >>> NIL
***    pc =3D 0x80c69c8 =3D LockMutex + 0x28 >>> in = >>> /usr/ports/lang/ezm3/work/ezm3-1.0/libs/m3core/src/thread/POSIX/ >>> ThreadPosix= >>> .m3
***

  use option @M3stackdump to get a stack >>> trace
Ab= >>> ort






>>> >>> --=__PartBC941634.0__=-- From hosking at cs.purdue.edu Wed Apr 22 04:37:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Apr 2009 12:37:36 +1000 Subject: [M3devel] explanation of CheckLoadTracedRef? In-Reply-To: References: <19C20763-18A0-413A-9440-3D7ED0C918B1@cs.purdue.edu> Message-ID: I believe there is just one check when the parameter is first passed. On 22 Apr 2009, at 10:54, Jay wrote: > Yes this helps, thank you. Maybe checkin under doc? One thing you > didn't understand my wording about and you seemed to contradict is > "VAR to VAR". > > > PROCEDURE F1() = > VAR i; > BEGIN > F2(i); > END F1; > > > PROCEDURE F2(VAR a:INTEGER)= > BEGIN > F3(i); > END F2; > > > PROCEDURE F3(VAR a:INTEGER)= > BEGIN > a := 1; > END F3; > > > Where are the calls to CheckLoad/StoreTracedRef? > (Duh, I can try it out..) > It seems redundant to put them "everywhere". > Esp. it seems that F2 shouldn't have do anything. > > > But throw in that F3 might extern and that is unclear. > So I just made up a suggestion that VAR is not good to pass to C code. > That checks are inserted when 1) a pointer is dereferenced -- loaded > or stored in Modula-3 or 2) a > pointer becomes untraced (var becomes untraced ref, among others). > > > > Right. I think I did see you compute and pass an offset to C code > > > I had something like that very recently but think I didn't set it or > commit it. > I had something like: > > > size_t offset; > > > Init(Mutex* root, int* interior) > { > offset = (size_t)interior - (size_t)root; > } > > > DoSomething(Mutex* anotherRoot) > { > int* interior = (int*)(offset + (size_t)anotherRoot); > printf("%d\n", *interior); > } > > > but I came up with a way to avoid that I think, and then rolled it > all back or something anyway. > > > > - Jay > > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] explanation of CheckLoadTracedRef? > Date: Wed, 22 Apr 2009 10:02:52 +1000 > > On 21 Apr 2009, at 19:37, Jay wrote: > > > > How bad/unportable was it the previous way, the VM-synchronized > way? > > > > Not compatible with system threading. > > > Really? NT386 wasn't VM-synchronized back in 3.6, 4.1, etc.? > > It was, but every system call had to be wrapped with a call to > acquire the global heap lock! > > Or only with great cost? > > Yes, taking the lock was expensive and prevented scaling on multi- > cores. > > I have to admit, those old import .libs, kernel32.lib, etc. I didn't > realize what was in them when I deleted them. I thought they were > just regular import .libs. > > There was also the work to wrap all dll symbols to acquire the lock. > > I think I got luckly in that the overlap between me deleting them > and you removing VM-synchronized GC was small or zero. > > You should have seen the mess it was before... ;-) > > > You should *never* access a field in the heap in C code! All > > accesses to traced fields in the heap must take place in Modula-3. > > Otherwise things will break! C wrappers should not do anything other > > than forward calls to C library calls. They should not perform heap > > accesses. > > > Ok, that makes sense. > Important "out" is the accessing stack is always ok. > > Yes, so long as a references to an object is held on the stack then > it is safe to pass an address within it to external calls. Thus, > many C functions can take VAR arguments that may end being > references to the fields of objects. The compiler injects the > necessary CheckLoad/CheckStore operations when passing VAR > parameters, etc., and the GC maintains the invariant that all stack- > referenced objects don't move, stay black (for incremental GC), and > remain dirty (for generational GC). > > But this is a requirement I didn't keep in mind. > Now, luckily, the C wrappers are all relatively thin and not difficult > to re-review in their entirety. > > Right. I think I did see you compute and pass an offset to C code, > but that may have only been in code you e-mailed me for perusal > rather than code that got checked in. Might be worth reviewing... > > But, take for example "open". > The first parameter to it is bound to be in the heap. > > The ambiguous roots garbage collector we use maintains the invariant > that pointers to the interior of heap objects from the stack *pin* > that object in the heap: it will not move while the pointer from the > stack exists, and invariants will be maintained so that its contenst > can be manipulated safely even in the face of incremental and > generational GC. > > But probably it is untraced or somehow ok, since it does > come from a module used primarily for C interop. > > Certainly, C code should never be manipulating the *traced* fields > of traced heap objects. It is fine for it to manipulate the > untraced fields of traced heap objects. > > And, the line between C wrappers and the "C library" that they > forward to > does not exist. > If I, say, pass a VAR to a VAR..no check is made? > > Not sure what you mean by this. Any call that passes traced VAR > params will generate a check as necessary before the call. > > Important to declare extern/C functions as taking UNTRACED REF and > not VAR? > > No, VAR is fine. So long as the VAR value being passed is not traced. > > > I think you are confusing incremental and incremental GC. > You assume I understand more than I do (I assume you have a typo. :)) > > ;-) > > "generational" -- the concept that most objects die young. > (aka most objects could have been allocated on the stack...) > > Not quite. The idea is that the likelihood of an object dying is a > function of its age. There is a *weak* generational hypothesis that > "most objects die young", and a *strong* generational hypothesis > that "the older an object is the less likely it is to die". Many > (but not all) programs support these hypotheses, which permits > generational GC to focus effort where it is likely to be profitable > (i.e., to free up a lot of space). > > But does that imply detailed implementation choices, or is just like > a "guiding principle"? > I guess it implies the heap is split into at least two generations, > old and young. > Though I guess in reality there is a range of young, less young, > lesser young, least young, etc. > > Right, many different collectors have exploited age in this way. > For the M3 collector we have just two generations: old and young. > > And that has objects age, they should be moved from young to old > heaps, and references to them either updated right away, or "caught" > upon use and updated then...something like that. > > Old-space objects are "clean" if they contain no references to young- > space objects. The Modula-3 compiler injects checks to make sure > that whenever we store a reference into a clean old-space object it > is marked "dirty". When a young-space collection occurs we must > process the references in dirty old-space objects as roots into the > young-space. > > "incremental" -- don't pause the world.. > > Not quite. The opposite of stop-the-world (stopping all the mutator > threads to process their stacks) is on-the-fly. Incremental refers > to the ability to interleave GC work with mutator work. If the GC > work can be interleaved with mutator threads without stopping the > mutator threads at each increment then the collector is said to be > concurrent (GC work proceeds concurrently with mutator work). > The current M3 collector has a stop-the-world non-moving phase, > followed by an concurrent copying phase. I have some incomplete > work that will also make the M3 collector on-the-fly (no STW phase) > and parallel (multiple GC threads can operate concurrently). > > Hope all this helps! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Apr 22 08:54:37 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 22 Apr 2009 08:54:37 +0200 Subject: [M3devel] an old, recurring issue: mapping runtime errors to exceptions? In-Reply-To: <200904220238.n3M2cIWk040392@camembert.async.caltech.edu> References: <200904220238.n3M2cIWk040392@camembert.async.caltech.edu> Message-ID: <20090422085437.i0hqnzu6rk0gw80w@mail.elegosoft.com> Quoting Mika Nystrom : > > It's as simple as that!? IMO it should just work. See m3-sys/m3tests/src/p2/p208/Main.m3: % cat m3-sys/m3tests/src/p2/p208/Main.m3 MODULE Main; IMPORT RuntimeError, IO, Process; CONST Tag = RuntimeError.Tag; PROCEDURE CatchAssert() = BEGIN TRY <*ASSERT FALSE*> EXCEPT RuntimeError.E( t ) => IO.Put( "OK: caught RuntimeError.Assert: " & Tag( t ) & "\n" ); END; END CatchAssert; PROCEDURE TestAll() = BEGIN CatchAssert(); END TestAll; BEGIN TRY <*NOWARN*> TestAll(); EXCEPT ELSE IO.Put( "ERROR: caught unexpected exception\n" ); Process.Exit( 1 ); END; END Main. Olaf > > Wow! > > Tony Hosking writes: >> CM3 does map some (I'm not sure if all) run-time errors to >> exceptions. See RuntimeError.i3 for details of what exceptions might >> occur. >> >> On 22 Apr 2009, at 08:41, Mika Nystrom wrote: >> >>> >> Well the point of "safety" is that the system can guarantee that the >>> runtime environment hasn't been damaged by a misbehaving program, no? >>> >>> In fact, in Threads 3 there are not one but *two* reports of >>> implementations that "reflect" runtime errors as exceptions. On >>> of them is SPIN, the other is the commercial CM3 with JVM. >>> >>> See >>> >>> http://www.modula3.org/threads/3/ >>> >>> Nelson's article in Threads 2 doesn't give the possibility of having >>> had the runtime invariants violated as a reason to abort. His >>> arguments are more practical, having to do with debugging. I agree, >>> and I think that the default method of dealing with runtime errors >>> should be to abort the program. But it just is very unfriendly in >>> an interactive environment, and I would love some kind of (possibly >>> very implementation-dependent) way of catching the runtime error. >>> The way Java does it would be ideal, I think..... >>> >>> Nelson's article is here >>> >>> http://www.modula3.org/threads/2/ >>> >>> [Tony, the link in your M3 bibliography is broken!] >>> >>> I'm running this example in a PM3/EZM3 environment right now but >>> that's not relevant. The code I showed you *should* crash. In >>> plain M3 it was: >>> >>> TextWr.ToText(NIL) >>> >>> But in an interactive environment, the user can do this sort of >>> thing. It should give you a nasty error message, not crash your >>> whole environment. >>> >>> Mika >>> >>> >>> >>> "Randy Coleburn" writes: >>>> This is a MIME message. If you are reading this text, you may want to >>>> consider changing to a mail reader or gateway that understands how to >>>> properly handle MIME multipart messages. >>>> >>>> --=__PartBC941634.0__= >>>> Content-Type: text/plain; charset=US-ASCII >>>> Content-Transfer-Encoding: quoted-printable >>>> >>>> Mika: >>>> =20 >>>> You state that "Checked runtime errors cannot violate invariants of >>>> the = >>>> runtime system, so it ought to be safe to ..." >>>> =20 >>>> Are you sure this statement is true for all implementations? >>>> =20 >>>> I would tend to think that SPIN was able to do this mapping for >>>> itself, = >>>> but in general, it would be difficult to be able to do this for any = >>>> arbitrary OS environment, esp with differences in underlying >>>> libraries and = >>>> implementations, which is part of what Greg alluded to in the >>>> Threads = >>>> article you reference. >>>> =20 >>>> Note also on pg 47 of the green book under "2.5.7 Safety" the notes >>>> about = >>>> intrinsic safety and when the compiler makes the guarantee vs. the = >>>> programmer. >>>> =20 >>>> I also note from the path in your example (ezm3) that you may not >>>> be using = >>>> the current cm3. Is it possible that the NIL dereference problem >>>> in your = >>>> example has been solved in a later implementation? >>>> =20 >>>> Regards, >>>> Randy >>>> >>>>>>> Mika Nystrom 4/21/2009 5:41 PM >>> >>>> >>>> Hello Modula-3ers, >>>> >>>> I know this is a question that comes up from time to time, and I >>>> am aware of Greg Nelson's short article in "Threads" about why=20 >>>> Modula-3 doesn't map runtime errors to exceptions, but the Green Book >>>> does allude to mapping runtime errors to exceptions, and I know that >>>> the SPIN OS did that. >>>> >>>> How hard would this be to support in CM3? >>>> >>>> Attached is a transcript of an interactive session with my current >>>> Scheme environment. I think it ought to be obvious why I ask about >>>> exceptions. In Modula-3, from safe code, only checked runtime errors >>>> can occur. Checked runtime errors cannot violate invariants of the >>>> runtime system, so it ought to be safe to convert them to exceptions >>>> that can be caught, and then permit the program to continue. =20 >>>> >>>> I realize this isn't *always* what you want to do, but in an >>>> interactive >>>> environment, making the system dump core on runtime errors sort of >>>> spoils the whole experience. >>>> >>>> In this application, there are many places where you may want to >>>> raise an exception that hasn't been declared. In a non-interactive >>>> environment, it is probably best to go for the core dump, but in >>>> an interactive environment, it seems to me it ought to just return >>>> control to the read-eval-print loop.... >>> >>>> Mika >>>> >>>> LITHP ITH LITHENING. >>>>> (define wr (scheme-procedure-stubs-call '(TextWr . New) '())) >>>> wr >>>>> wr >>>> >>>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>>> #t >>>>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >>>> "hello!" >>>>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >>>> "" >>>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>>> #t >>>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>>> #t >>>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>>> #t >>>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>>> #t >>>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>>> #t >>>>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >>>> "hello!hello!hello!hello!hello!" >>>>> (scheme-procedure-stubs-call '(TextWr . ToText) (list '()) '()) >>>> >>>> >>>> *** >>>> *** runtime error: >>>> *** Segmentation violation - possible attempt to dereference NIL >>>> *** pc =3D 0x80c69c8 =3D LockMutex + 0x28 in /usr/ports/lang/ >>>> ezm3/work/e= >>>> zm3-1.0/libs/m3core/src/thread/POSIX/ThreadPosix.m3 >>>> *** >>>> >>>> use option @M3stackdump to get a stack trace >>>> Abort >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> 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. >>>> >>>> >>>> --=__PartBC941634.0__= >>>> Content-Type: text/html; charset=US-ASCII >>>> Content-Transfer-Encoding: quoted-printable >>>> Content-Description: HTML >>>> >>>> >>>> >>> charset=3Diso-8859-15= >>>> "> >>>> >>>> >>>>
Mika:
>>>>
 
>>>>
You state that "Checked runtime errors cannot violate >>>> invariants of = >>>> the runtime system, so it ought to be safe to ..."
>>>>
 
>>>>
Are you sure this statement is true for all >>>> implementations?>>>> >>>>
 
>>>>
I would tend to think that SPIN was able to do this mapping >>>> for = >>>> itself, but in general, it would be difficult to be able to do this >>>> for = >>>> any arbitrary OS environment, esp with differences in underlying >>>> libraries = >>>> and implementations, which is part of what Greg alluded to in the >>>> Threads = >>>> article you reference.
>>>>
 
>>>>
Note also on pg 47 of the green book under "2.5.7 Safety" the >>>> notes = >>>> about intrinsic safety and when the compiler makes the guarantee >>>> vs. the = >>>> programmer.
>>>>
 
>>>>
I also note from the path in your example (ezm3) that you may >>>> not be = >>>> using the current cm3.  Is it possible that the NIL >>>> dereference = >>>> problem in your example has been solved in a later implementation?>>> DIV> >>>>
 
>>>>
Regards,
>>>>
Randy

>>> Mika Nystrom <mika at async.caltech.edu >>>> > = >>>> 4/21/2009 5:41 PM >>>

Hello Modula-3ers,

I >>>> know = >>>> this is a question that comes up from time to time, and I
am >>>> aware of = >>>> Greg Nelson's short article in "Threads" about why
Modula-3 >>>> doesn't = >>>> map runtime errors to exceptions, but the Green Book
does allude >>>> to = >>>> mapping runtime errors to exceptions, and I know that
the SPIN >>>> OS did = >>>> that.

How hard would this be to support in CM3? >>>>

Attached is = >>>> a transcript of an interactive session with my current
Scheme >>>> environmen= >>>> t.  I think it ought to be obvious why I ask >>>> about
exceptions. = >>>> ; In Modula-3, from safe code, only checked runtime errors
can = >>>> occur.  Checked runtime errors cannot violate invariants of >>>> the
run= >>>> time system, so it ought to be safe to convert them to >>>> exceptions
that = >>>> can be caught, and then permit the program to continue.  >>>>

I = >>>> realize this isn't *always* what you want to do, but in an >>>> interactive
e= >>>> nvironment, making the system dump core on runtime errors sort >>>> of
spoils= >>>> the whole experience.

In this application, there are many >>>> places = >>>> where you may want to
raise an exception that hasn't been >>>> declared. = >>>> ; In a non-interactive
environment, it is probably best to go >>>> for the = >>>> core dump, but in
an interactive environment, it seems to me it >>>> ought = >>>> to just return
control to the read-eval-print >>>> loop....

 &nbs= >>>> p;   Mika

LITHP ITH LITHENING.
> (define wr = >>>> (scheme-procedure-stubs-call '(TextWr . New) '()))
wr
> >>>> wr
<= >>>> Modula-3 object : TextWr.T, BRANDED TextWr_^%#%^__0001M>
> = >>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") >>>> '())
#t<= >>>> BR>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) = >>>> '())
"hello!"
> (scheme-procedure-stubs-call '(TextWr . >>>> ToText) = >>>> (list wr) '())
""
> (scheme-procedure-stubs-call '(Wr . >>>> PutText) = >>>> (list wr "hello!") '())
#t
> (scheme-procedure-stubs-call >>>> '(Wr . = >>>> PutText) (list wr "hello!") '())
#t
> (scheme-procedure- >>>> stubs-call= >>>> '(Wr . PutText) (list wr "hello!") '())
#t
> (scheme- >>>> procedure-st= >>>> ubs-call '(Wr . PutText) (list wr "hello!") '())
#t
> >>>> (scheme-proc= >>>> edure-stubs-call '(Wr . PutText) (list wr "hello!") >>>> '())
#t
> = >>>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) >>>> '())
"hello!he= >>>> llo!hello!hello!hello!"
> (scheme-procedure-stubs-call >>>> '(TextWr . = >>>> ToText) (list '()) '())


***
*** runtime >>>> error:
*** &n= >>>> bsp;  Segmentation violation - possible attempt to dereference = >>>> NIL
***    pc =3D 0x80c69c8 =3D LockMutex + 0x28 >>>> in = >>>> /usr/ports/lang/ezm3/work/ezm3-1.0/libs/m3core/src/thread/POSIX/ >>>> ThreadPosix= >>>> .m3
***

  use option @M3stackdump to get a stack >>>> trace
Ab= >>>> ort






>>>> >>>> --=__PartBC941634.0__=-- > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Wed Apr 22 18:00:03 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 22 Apr 2009 11:00:03 -0500 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: References: <49EC7A06.5040403@cox.net> Message-ID: <49EF3F03.5090104@cox.net> Tony Hosking wrote: > On 20 Apr 2009, at 23:35, Rodney M. Bates wrote: > >> I am going to try to resummarize the various proposals, as their >> description has now gotten rather scattered around in all the >> discussion. >> --------------------------------------------------------------------- >> Mika's proposal (I'll call it the "minimalist" propsal): >> >> Mika, please correct me if I misrepresent what you are proposing. >> >> There are no language changes at all, only changes in implementation. >> The implementation of the existing type REFANY, and no other type, >> allows it to have values whose lsb is nonzero. ISTYPE, NARROW, >> TYPECASE, and narrowing assignments, when and only when applied to >> REFANY, have their generated code fixed so it checks the lsb, and, if >> it is nonzero, consider the runtime type check to have failed, in >> whichever way such a failure is already handled. >> >> The only effect is to liberalize the rules unsafe code must follow to >> avoid undermining the safety of safe code. Only unsafe code can >> create or detect these misaligned values. Today, it must never return >> them in a variable of any reference type, lest the four narrowing >> operations unexpectedly crash. In the proposal, unsafe code would be >> able to return such values in variables of type REFANY, but not any >> other type. > > I don't see why we can't have safe creation of the misaligned values > as per Mika's interface. Well, somebody has to implement that interface, and that module will have to be UNSAFE. You weren't thinking of implementing it in C were you? ;-) > >> Already, the only things safe code can do with values of REFANY are >> copy them around (which would happily work on misaligned values) and >> narrow them. With the implementation of the narrowing operations >> changed, misaligned values can never escape from REFANY variables. >> >> In safe code, there is no way to detect whether a value of type REFANY >> is misaligned. Doing it by elimination, trying to narrow to any >> proper subtype of REFANY, is impractical, as there are an unbounded >> number of REF types to eliminate. > > An alternative would be to loosen the language spec to allow > TYPECODE(REFANY) and use this typecode for tagged references. Then > one can explicitly test for it without elimination of alternatives. > >> If there is more than one abstract data type that uses this mechanism, >> client code can not be prevented from mixing up values from the >> different abstractions. (Perhaps this could be fixed by a language >> change allowing BRANDED REFANY?) > > Indeed. > >> --------------------------------------------------------------------- >> My (Rodney's) "safe" proposal: >> >> There is a new type named TAGABLE. It is a subrange of INTEGER, whose >> bounds are implementation-defined. These can be queried by the >> existing FIRST and LAST functions. Similar to CARDINAL, it has all >> the properties of a subrange type but is not the same type as the >> corresponding subrange. >> >> There is a new type constructor TAGGED. If T is any traced or object >> type, including branded and opaque types, then TAGGED T is a new type >> whose value set is the union of the value sets of T and TAGABLE. >> Moreover, >> >> TAGABLE <: TAGGED T >> T <: TAGGED T. >> >> IF T # U, then TAGGED T and TAGGED U are not the same type and have no >> subtype or assignability relation to each other. >> >> The semantics of ISTYPE, NARROW, TYPECASE, and assignability of a type >> to a type are generalized so that their to-be-narrowed operand can >> have a tagged type, and if it does, their to-be-narrowed-to type can >> be TAGABLE. > > Hmm. It seems there is a nasty loophole in your spec. > Consider: > > TYPE T = BRANDED OBJECT END > TYPE U = BRANDED OBJECT END > > These are unrelated types. > > Now, the rules let me take: > > t: TAGGED T > > and obtain: > > i: TAGABLE := NARROW(t, TAGABLE); > > But TAGABLE <: TAGGED U > > so I can do: > > u: TAGGED U := t; > > Is that your intention? > >> >> >> Comments: >> >> Making TAGGED T have no relation to TAGGED U avoids a lot of really >> complicated type equality and subtype rules. The former would be a >> drastic departure from the current state of Modula-3. >> >> It is up to the implementation to decide the bit representation of >> tagged types, including how values of TAGABLE will be distinguished >> from reference values. Though the language would not require it, most >> likely a word the same size as a pointer will be used. Using the lsb >> as the tag bit is an efficient encoding, because in any currently >> conceivable machine, it will be zero for all pointers to heap objects. >> There is no reason pickles would have to use the same representation >> as compiler-generated code. >> >> The implementation should define the bounds of TAGABLE to be whatever >> it can fit in its representation, after removing the values that are >> true pointers. If the lsb is used as a tag, this will no doubt be a >> 31-bit integer on a 32-bit machine and 63-bit integer on a 64-bit >> machine. The language wouldn't even specify whether it is signed, >> although somehow unsigned seems nice to me. If it is unsigned and the >> suggested encodings are used, TAGABLE would have the same bounds as >> CARDINAL, but it really should be a separate type, so as not to >> overconstrain the implementation. >> >> If T is branded, then the effects of branding will propagate to TAGGED >> T, thus allowing independent abstract data types to ensure each one's >> values can't be mixed up with the other's. This will statically >> detect misuses by client code. However, TAGGED T is not a branded >> type. >> >> If T is an opaque type, then TAGGED T can be used to combine the space >> efficiency of tagging with the ability of an opaque type to reveal >> some but not all of its properties. To use this, client code will >> have to narrow a value first, since access to methods/fields could not >> have a definable meaning for a value in TAGABLE. >> >> On the other hand, T could be an opaque subtype of REFANY, thus >> revealing almost nothing about TAGGED T to clients. This would give >> tagged types the existing ability of ensuring statically, that the >> code in a revealed context will never get TAGGED REFANY, thus avoiding >> extra runtime type checks. > > From rodney.m.bates at cox.net Wed Apr 22 18:33:13 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 22 Apr 2009 11:33:13 -0500 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: References: <49EC7A06.5040403@cox.net> <20090421122648.GB25465@topoi.pooq.com> Message-ID: <49EF46C9.6050503@cox.net> Tony Hosking wrote: > I'd prefer something like TAGGEDINT or some such. But I am still not > convinced that the minimalist proposal and this proposal differ in any > significant way. The minimalist proposal forces you to give up some static safety you have in the current language, that the safe proposal allows. In the minimalist proposal, you cannot both use tagged pointers and have any of the following: 1) An abstract data type T can (and today virtually always is) some proper subtype of REFANY. This statically restricts values to this type. In minimalist, T can only be declared REFANY, allowing a client to provide a value that was neither tagged nor of the type the abstraction expects. Instead, the type constraint will be checked at runtime, on every call into the abstraction. And this is a more expensive check than just a tag bit check. Aside from the overhead, going from static to runtime type checking requires an extensive test suite to get somewhere short of the same level of confidence that a mere compile would guarantee. In the safe proposal, T could be replaced by TAGGED T, and the static rules would guarantee its values are always either integer or T, comparable to the current language. 2) If there is more than one abstraction that uses tagged types, minimalist loses static guarantee that they are not mixed up by client code. Since Abs1.T and Abs2.T must both be REFANY, a client can get a value from Abs1 and pass it to Abs2. Again, this is a demotion of static to runtime type checking. In safe, Abs1.T and Abs2.T could be tagged types built from different opaque types, giving the same separation that we get in the current language. 3) The type declared in an abstraction can currently be an opaque subtype of some proper subtype of REFANY. This allows the abstraction writer to give clients the ability to directly access some fields/methods, while hiding others. Once again, the restriction that only REFANY can be tagged makes this impossible in minimalist. I suppose this could be worked around by providing accessors, mutators, and plain procedures in the abstraction, but then these would have to take REFANY too, just making for more instances of loss of static checking. > > On 21 Apr 2009, at 22:26, hendrik at topoi.pooq.com wrote: > >> On Mon, Apr 20, 2009 at 08:35:02AM -0500, Rodney M. Bates wrote: >>> >>> --------------------------------------------------------------------- >>> My (Rodney's) "safe" proposal: >>> >>> There is a new type named TAGABLE. It is a subrange of INTEGER, whose >> >> Please spell it TAGGABLE. TAG doubles its last consonant when adding >> suffixes: TAGGED, TAGGING. >> >> -- hendrik > > From mika at async.caltech.edu Thu Apr 23 01:41:22 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 22 Apr 2009 16:41:22 -0700 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: Your message of "Wed, 22 Apr 2009 11:00:03 CDT." <49EF3F03.5090104@cox.net> Message-ID: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> "Rodney M. Bates" writes: >Tony Hosking wrote: >> On 20 Apr 2009, at 23:35, Rodney M. Bates wrote: >> >>> I am going to try to resummarize the various proposals, as their >>> description has now gotten rather scattered around in all the >>> discussion. >>> --------------------------------------------------------------------- >>> Mika's proposal (I'll call it the "minimalist" propsal): >>> >>> Mika, please correct me if I misrepresent what you are proposing. >>> >>> There are no language changes at all, only changes in implementation. >>> The implementation of the existing type REFANY, and no other type, >>> allows it to have values whose lsb is nonzero. ISTYPE, NARROW, >>> TYPECASE, and narrowing assignments, when and only when applied to >>> REFANY, have their generated code fixed so it checks the lsb, and, if >>> it is nonzero, consider the runtime type check to have failed, in >>> whichever way such a failure is already handled. >>> >>> The only effect is to liberalize the rules unsafe code must follow to >>> avoid undermining the safety of safe code. Only unsafe code can >>> create or detect these misaligned values. Today, it must never return >>> them in a variable of any reference type, lest the four narrowing >>> operations unexpectedly crash. In the proposal, unsafe code would be >>> able to return such values in variables of type REFANY, but not any >>> other type. This is pretty much exactly what I was proposing, yes. Only one point to add, and that is that you need a TYPECODE value. I think Tony and I discussed having all the ISTYPE etc. behave as if the tagged values were of a specific opaque type that cannot be dereferenced, newed, etc., in safe modules. (I.e., revealed as <: REFANY only) This seems conceptually simpler than introducing a "nonexistent" type, and has the same safety properties. >> >> I don't see why we can't have safe creation of the misaligned values >> as per Mika's interface. > >Well, somebody has to implement that interface, and that module will >have to be UNSAFE. >You weren't thinking of implementing it in C were you? ;-) I don't see how to do it "safely" unless you add it to the compiler itself? (Which means it's no longer minimalist!) >> >>> Already, the only things safe code can do with values of REFANY are >>> copy them around (which would happily work on misaligned values) and >>> narrow them. With the implementation of the narrowing operations >>> changed, misaligned values can never escape from REFANY variables. >>> >>> In safe code, there is no way to detect whether a value of type REFANY >>> is misaligned. Doing it by elimination, trying to narrow to any >>> proper subtype of REFANY, is impractical, as there are an unbounded >>> number of REF types to eliminate. >> >> An alternative would be to loosen the language spec to allow >> TYPECODE(REFANY) and use this typecode for tagged references. Then >> one can explicitly test for it without elimination of alternatives. Yes you could do this or use the specific type idea mentioned above. I don't see what harm there is in letting a safe module know that it's holding a tagged value. Nothing it can do with that information anyhow... it can't extract the value. >> >>> If there is more than one abstract data type that uses this mechanism, >>> client code can not be prevented from mixing up values from the >>> different abstractions. (Perhaps this could be fixed by a language >>> change allowing BRANDED REFANY?) >> >> Indeed. Right. As it stands, the clients would have to sort on what's going on inside. No help from compiler or runtime. You can't do anything about what's checkable at runtime, but adding TAGGED could let you check a lot of things at compile time. I still think, though (referring to what's below), that the advantage of not having to change existing "container" code outweighs the cost of checking the LSB (which is likely to be negligble), and I would therefore recommend that the type called "REFANY" be able to hold "TAGGED" values after such a language change. Mika >> >>> --------------------------------------------------------------------- >>> My (Rodney's) "safe" proposal: >>> >>> There is a new type named TAGABLE. It is a subrange of INTEGER, whose >>> bounds are implementation-defined. These can be queried by the >>> existing FIRST and LAST functions. Similar to CARDINAL, it has all >>> the properties of a subrange type but is not the same type as the >>> corresponding subrange. >>> >>> There is a new type constructor TAGGED. If T is any traced or object >>> type, including branded and opaque types, then TAGGED T is a new type >>> whose value set is the union of the value sets of T and TAGABLE. >>> Moreover, >>> >>> TAGABLE <: TAGGED T >>> T <: TAGGED T. >>> >>> IF T # U, then TAGGED T and TAGGED U are not the same type and have no >>> subtype or assignability relation to each other. >>> >>> The semantics of ISTYPE, NARROW, TYPECASE, and assignability of a type >>> to a type are generalized so that their to-be-narrowed operand can >>> have a tagged type, and if it does, their to-be-narrowed-to type can >>> be TAGABLE. >> >> Hmm. It seems there is a nasty loophole in your spec. >> Consider: >> >> TYPE T = BRANDED OBJECT END >> TYPE U = BRANDED OBJECT END >> >> These are unrelated types. >> >> Now, the rules let me take: >> >> t: TAGGED T >> >> and obtain: >> >> i: TAGABLE := NARROW(t, TAGABLE); >> >> But TAGABLE <: TAGGED U >> >> so I can do: >> >> u: TAGGED U := t; >> >> Is that your intention? >> >>> >>> >>> Comments: >>> >>> Making TAGGED T have no relation to TAGGED U avoids a lot of really >>> complicated type equality and subtype rules. The former would be a >>> drastic departure from the current state of Modula-3. >>> >>> It is up to the implementation to decide the bit representation of >>> tagged types, including how values of TAGABLE will be distinguished >>> from reference values. Though the language would not require it, most >>> likely a word the same size as a pointer will be used. Using the lsb >>> as the tag bit is an efficient encoding, because in any currently >>> conceivable machine, it will be zero for all pointers to heap objects. >>> There is no reason pickles would have to use the same representation >>> as compiler-generated code. >>> >>> The implementation should define the bounds of TAGABLE to be whatever >>> it can fit in its representation, after removing the values that are >>> true pointers. If the lsb is used as a tag, this will no doubt be a >>> 31-bit integer on a 32-bit machine and 63-bit integer on a 64-bit >>> machine. The language wouldn't even specify whether it is signed, >>> although somehow unsigned seems nice to me. If it is unsigned and the >>> suggested encodings are used, TAGABLE would have the same bounds as >>> CARDINAL, but it really should be a separate type, so as not to >>> overconstrain the implementation. >>> >>> If T is branded, then the effects of branding will propagate to TAGGED >>> T, thus allowing independent abstract data types to ensure each one's >>> values can't be mixed up with the other's. This will statically >>> detect misuses by client code. However, TAGGED T is not a branded >>> type. >>> >>> If T is an opaque type, then TAGGED T can be used to combine the space >>> efficiency of tagging with the ability of an opaque type to reveal >>> some but not all of its properties. To use this, client code will >>> have to narrow a value first, since access to methods/fields could not >>> have a definable meaning for a value in TAGABLE. >>> >>> On the other hand, T could be an opaque subtype of REFANY, thus >>> revealing almost nothing about TAGGED T to clients. This would give >>> tagged types the existing ability of ensuring statically, that the >>> code in a revealed context will never get TAGGED REFANY, thus avoiding >>> extra runtime type checks. >> >> From mika at async.caltech.edu Thu Apr 23 01:51:10 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 22 Apr 2009 16:51:10 -0700 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: Your message of "Wed, 22 Apr 2009 11:33:13 CDT." <49EF46C9.6050503@cox.net> Message-ID: <200904222351.n3MNpA3v086629@camembert.async.caltech.edu> Rodney, Yes I agree that minimalist doesn't solve your problems as well as TAGGED does. However, if you allow REFANY to hold tagged values in the future (once you have TAGGED in the language), adding TAGGED will be a backward-compatible step on top of minimalist. In my application anything that might want to be TAGGED is today declared as (exactly) REFANY, so I'm happy either way. But of course I realize I am not the only Modula-3 programmer in the world (even if sometimes it does feel a bit like it). Mika "Rodney M. Bates" writes: >Tony Hosking wrote: >> I'd prefer something like TAGGEDINT or some such. But I am still not >> convinced that the minimalist proposal and this proposal differ in any >> significant way. >The minimalist proposal forces you to give up some static safety you have >in the current language, that the safe proposal allows. In the minimalist >proposal, you cannot both use tagged pointers and have any of the >following: > >1) An abstract data type T can (and today virtually always is) some >proper subtype > of REFANY. This statically restricts values to this type. In >minimalist, T can > only be declared REFANY, allowing a client to provide a value that >was neither > tagged nor of the type the abstraction expects. Instead, the type >constraint will be > checked at runtime, on every call into the abstraction. And this >is a more expensive > check than just a tag bit check. Aside from the overhead, going >from static to runtime type checking requires an extensive test suite to get >somewhere short > of the same level of confidence that a mere compile would >guarantee. In the safe > proposal, T could be replaced by TAGGED T, and the static rules >would guarantee > its values are always either integer or T, comparable to the current >language. > >2) If there is more than one abstraction that uses tagged types, >minimalist loses static > guarantee that they are not mixed up by client code. Since Abs1.T >and Abs2.T must > both be REFANY, a client can get a value from Abs1 and pass it to >Abs2. Again, this > is a demotion of static to runtime type checking. In safe, Abs1.T >and Abs2.T could > be tagged types built from different opaque types, giving the same >separation that > we get in the current language. > >3) The type declared in an abstraction can currently be an opaque >subtype of some > proper subtype of REFANY. This allows the abstraction writer to >give clients the > ability to directly access some fields/methods, while hiding >others. Once again, > the restriction that only REFANY can be tagged makes this impossible >in minimalist. > I suppose this could be worked around by providing accessors, >mutators, and plain > procedures in the abstraction, but then these would have to take >REFANY too, just > making for more instances of loss of static checking. >> >> On 21 Apr 2009, at 22:26, hendrik at topoi.pooq.com wrote: >> >>> On Mon, Apr 20, 2009 at 08:35:02AM -0500, Rodney M. Bates wrote: >>>> >>>> --------------------------------------------------------------------- >>>> My (Rodney's) "safe" proposal: >>>> >>>> There is a new type named TAGABLE. It is a subrange of INTEGER, whose >>> >>> Please spell it TAGGABLE. TAG doubles its last consonant when adding >>> suffixes: TAGGED, TAGGING. >>> >>> -- hendrik >> >> From hosking at cs.purdue.edu Thu Apr 23 03:07:25 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 23 Apr 2009 11:07:25 +1000 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> References: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> Message-ID: <690A324D-3F1A-433F-BFC0-78CFF9D22713@cs.purdue.edu> On 23 Apr 2009, at 09:41, Mika Nystrom wrote: > "Rodney M. Bates" writes: >> Tony Hosking wrote: >>> On 20 Apr 2009, at 23:35, Rodney M. Bates wrote: >>> >>>> I am going to try to resummarize the various proposals, as their >>>> description has now gotten rather scattered around in all the >>>> discussion. >>>> --------------------------------------------------------------------- >>>> Mika's proposal (I'll call it the "minimalist" propsal): >>>> >>>> Mika, please correct me if I misrepresent what you are proposing. >>>> >>>> There are no language changes at all, only changes in >>>> implementation. >>>> The implementation of the existing type REFANY, and no other type, >>>> allows it to have values whose lsb is nonzero. ISTYPE, NARROW, >>>> TYPECASE, and narrowing assignments, when and only when applied to >>>> REFANY, have their generated code fixed so it checks the lsb, >>>> and, if >>>> it is nonzero, consider the runtime type check to have failed, in >>>> whichever way such a failure is already handled. >>>> >>>> The only effect is to liberalize the rules unsafe code must >>>> follow to >>>> avoid undermining the safety of safe code. Only unsafe code can >>>> create or detect these misaligned values. Today, it must never >>>> return >>>> them in a variable of any reference type, lest the four narrowing >>>> operations unexpectedly crash. In the proposal, unsafe code >>>> would be >>>> able to return such values in variables of type REFANY, but not any >>>> other type. > > This is pretty much exactly what I was proposing, yes. > > Only one point to add, and that is that you need a TYPECODE value. Yes. I currently have a full-blown implementation in the compiler and run-time that uses RT0.RefanyTypecode as the typecode. Since the only thing that will respond with the typecode are tagged references, and it is not legal to say TYPECODE(REFANY) we can hide that fact in an implementation of the tagged interface where we use TYPECODE(r) = RT0.RefanyTypecode, or ISTYPE(r, RT0.RefanyTypecode). Currently, no other type in the system will respond with that. > I think Tony and I discussed having all the ISTYPE etc. behave as > if the tagged values were of a specific opaque type that cannot be > dereferenced, newed, etc., in safe modules. (I.e., revealed as <: > REFANY only) Done (modulo what typecode to use as described above). > This seems conceptually simpler than introducing a "nonexistent" > type, and has the same safety properties. > >>> >>> I don't see why we can't have safe creation of the misaligned values >>> as per Mika's interface. >> >> Well, somebody has to implement that interface, and that module will >> have to be UNSAFE. >> You weren't thinking of implementing it in C were you? ;-) > > I don't see how to do it "safely" unless you add it to the compiler > itself? (Which means it's no longer minimalist!) It would be hidden behind a safe interface. >>>> Already, the only things safe code can do with values of REFANY are >>>> copy them around (which would happily work on misaligned values) >>>> and >>>> narrow them. With the implementation of the narrowing operations >>>> changed, misaligned values can never escape from REFANY variables. >>>> >>>> In safe code, there is no way to detect whether a value of type >>>> REFANY >>>> is misaligned. Doing it by elimination, trying to narrow to any >>>> proper subtype of REFANY, is impractical, as there are an unbounded >>>> number of REF types to eliminate. >>> >>> An alternative would be to loosen the language spec to allow >>> TYPECODE(REFANY) and use this typecode for tagged references. Then >>> one can explicitly test for it without elimination of alternatives. > > Yes you could do this or use the specific type idea mentioned above. > > I don't see what harm there is in letting a safe module know that > it's holding a tagged value. Nothing it can do with that information > anyhow... it can't extract the value. > >>> >>>> If there is more than one abstract data type that uses this >>>> mechanism, >>>> client code can not be prevented from mixing up values from the >>>> different abstractions. (Perhaps this could be fixed by a language >>>> change allowing BRANDED REFANY?) >>> >>> Indeed. > > Right. As it stands, the clients would have to sort on what's going > on inside. No help from compiler or runtime. You can't do anything > about what's checkable at runtime, but adding TAGGED could let you > check a lot of things at compile time. > > I still think, though (referring to what's below), that the advantage > of not having to change existing "container" code outweighs the > cost of checking the LSB (which is likely to be negligble), and I > would > therefore recommend that the type called "REFANY" be able to hold > "TAGGED" > values after such a language change. Right. > > > Mika > >>> >>>> --------------------------------------------------------------------- >>>> My (Rodney's) "safe" proposal: >>>> >>>> There is a new type named TAGABLE. It is a subrange of INTEGER, >>>> whose >>>> bounds are implementation-defined. These can be queried by the >>>> existing FIRST and LAST functions. Similar to CARDINAL, it has all >>>> the properties of a subrange type but is not the same type as the >>>> corresponding subrange. >>>> >>>> There is a new type constructor TAGGED. If T is any traced or >>>> object >>>> type, including branded and opaque types, then TAGGED T is a new >>>> type >>>> whose value set is the union of the value sets of T and TAGABLE. >>>> Moreover, >>>> >>>> TAGABLE <: TAGGED T >>>> T <: TAGGED T. >>>> >>>> IF T # U, then TAGGED T and TAGGED U are not the same type and >>>> have no >>>> subtype or assignability relation to each other. >>>> >>>> The semantics of ISTYPE, NARROW, TYPECASE, and assignability of a >>>> type >>>> to a type are generalized so that their to-be-narrowed operand can >>>> have a tagged type, and if it does, their to-be-narrowed-to type >>>> can >>>> be TAGABLE. >>> >>> Hmm. It seems there is a nasty loophole in your spec. >>> Consider: >>> >>> TYPE T = BRANDED OBJECT END >>> TYPE U = BRANDED OBJECT END >>> >>> These are unrelated types. >>> >>> Now, the rules let me take: >>> >>> t: TAGGED T >>> >>> and obtain: >>> >>> i: TAGABLE := NARROW(t, TAGABLE); >>> >>> But TAGABLE <: TAGGED U >>> >>> so I can do: >>> >>> u: TAGGED U := t; >>> >>> Is that your intention? >>> >>>> >>>> >>>> Comments: >>>> >>>> Making TAGGED T have no relation to TAGGED U avoids a lot of really >>>> complicated type equality and subtype rules. The former would be a >>>> drastic departure from the current state of Modula-3. >>>> >>>> It is up to the implementation to decide the bit representation of >>>> tagged types, including how values of TAGABLE will be distinguished >>>> from reference values. Though the language would not require it, >>>> most >>>> likely a word the same size as a pointer will be used. Using the >>>> lsb >>>> as the tag bit is an efficient encoding, because in any currently >>>> conceivable machine, it will be zero for all pointers to heap >>>> objects. >>>> There is no reason pickles would have to use the same >>>> representation >>>> as compiler-generated code. >>>> >>>> The implementation should define the bounds of TAGABLE to be >>>> whatever >>>> it can fit in its representation, after removing the values that >>>> are >>>> true pointers. If the lsb is used as a tag, this will no doubt >>>> be a >>>> 31-bit integer on a 32-bit machine and 63-bit integer on a 64-bit >>>> machine. The language wouldn't even specify whether it is signed, >>>> although somehow unsigned seems nice to me. If it is unsigned >>>> and the >>>> suggested encodings are used, TAGABLE would have the same bounds as >>>> CARDINAL, but it really should be a separate type, so as not to >>>> overconstrain the implementation. >>>> >>>> If T is branded, then the effects of branding will propagate to >>>> TAGGED >>>> T, thus allowing independent abstract data types to ensure each >>>> one's >>>> values can't be mixed up with the other's. This will statically >>>> detect misuses by client code. However, TAGGED T is not a branded >>>> type. >>>> >>>> If T is an opaque type, then TAGGED T can be used to combine the >>>> space >>>> efficiency of tagging with the ability of an opaque type to reveal >>>> some but not all of its properties. To use this, client code will >>>> have to narrow a value first, since access to methods/fields >>>> could not >>>> have a definable meaning for a value in TAGABLE. >>>> >>>> On the other hand, T could be an opaque subtype of REFANY, thus >>>> revealing almost nothing about TAGGED T to clients. This would >>>> give >>>> tagged types the existing ability of ensuring statically, that the >>>> code in a revealed context will never get TAGGED REFANY, thus >>>> avoiding >>>> extra runtime type checks. >>> >>> From mika at async.caltech.edu Fri Apr 24 08:54:46 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 23 Apr 2009 23:54:46 -0700 Subject: [M3devel] bug in Wx.ToText, CM3 TEXTs Message-ID: <200904240654.n3O6skJM072255@camembert.async.caltech.edu> Hello Modula-3ers, These CM3 TEXTs simply won't stop dogging me! There's a bug that I just fixed in Wx.ToText. I seem not to have the repository checked out as me again, so could I bother someone else to commit the change? Synopsis -------- Under SRC and P M3, the way you created a new TEXT of a given size was you imported TextF and allocated a TEXT using NEW(TEXT, n + 1) where n is the length of the TEXT you want. Under CM3, you're supposed to call (e.g.) Text8.New(n) Line 171 of Wx.m3 has: PROCEDURE ToText (t: T): TEXT = VAR txt := Text8.Create(t.nFull * ChunkSize + t.next + 1); (* line 171 *) c := t.head; n := 0; BEGIN (The code t.nFull + ... + 1 is copied exactly from the older implementation, and is wrong.) Fix --- The 1 needs to be removed, to make: PROCEDURE ToText (t: T): TEXT = VAR txt := Text8.Create(t.nFull * ChunkSize + t.next); (* line 171 *) c := t.head; n := 0; BEGIN The path is m3-libs/libbuf/src/Wx.m3 I'm surprised no one has noticed this before. Does no one else use Wx? Mika From mika at async.caltech.edu Fri Apr 24 18:57:32 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 24 Apr 2009 09:57:32 -0700 Subject: [M3devel] Sneaky C++isms in m3cc Message-ID: <200904241657.n3OGvWh4000584@camembert.async.caltech.edu> As usual, my quest to switch to CM3 ends up in my attempting (usually not very well) to bootstrap CM3. This time I am trying to build with cm3 5.3.1 on FreeBSD 4.11. The reason for this is that the "FreeBSD4" snapshot on elego does not appear to be a FreeBSD4 snapshot at all. Anyone know what OS this builds on? (Links to the 5.5.0 -min I contributed from a real FreeBSD 4 system are broken, and I can't find the source myself.) But enough of that. I noticed the following in parse.c (under m3cc): 2395 static void 2396 m3cg_set_source_line (void) 2397 { 2398 INTEGER (i); 2399 2400 if (option_source_line_trace) fprintf(stderr, " source line %4ld\n", i); 2401 #ifdef USE_MAPPED_LOCATION 2402 source_location s = linemap_line_start (line_table, i, 80); 2403 input_location = s; 2404 #else 2405 input_line = i; 2406 #endif 2407 } The code on line 2402 is a C++ism. You cannot declare variables in the middle of code in C. Unless it has changed with the new version of C, but it still won't build with older C compilers. (I'm using gcc 2.95.4) Mika From jay.krell at cornell.edu Sat Apr 25 00:02:23 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 24 Apr 2009 22:02:23 +0000 Subject: [M3devel] Sneaky C++isms in m3cc In-Reply-To: <200904241657.n3OGvWh4000584@camembert.async.caltech.edu> References: <200904241657.n3OGvWh4000584@camembert.async.caltech.edu> Message-ID: It's 7.0 or 7.1. file should tell you this. In time it should be renamed I386_FREEBSD. In time maybe I'll get out regular "boot" archives that are version-independent. The Modula-3 code pretty much only interfaces with our own C code, thus making the assembly for our Modula-3 ABI-independent (the part of ABI that is the signatures of open, etc., not the part that is the function call protocol). I'll fix the C++-ism. Well understood. - Jay ---------------------------------------- > To: m3devel at elegosoft.com > Date: Fri, 24 Apr 2009 09:57:32 -0700 > From: mika at async.caltech.edu > CC: mika at camembert.async.caltech.edu > Subject: [M3devel] Sneaky C++isms in m3cc > > > As usual, my quest to switch to CM3 ends up in my attempting (usually > not very well) to bootstrap CM3. This time I am trying to build with > cm3 5.3.1 on FreeBSD 4.11. > > The reason for this is that the "FreeBSD4" snapshot on elego does > not appear to be a FreeBSD4 snapshot at all. Anyone know what OS > this builds on? (Links to the 5.5.0 -min I contributed from a real > FreeBSD 4 system are broken, and I can't find the source myself.) > > But enough of that. I noticed the following in parse.c (under m3cc): > > 2395 static void > 2396 m3cg_set_source_line (void) > 2397 { > 2398 INTEGER (i); > 2399 > 2400 if (option_source_line_trace) fprintf(stderr, " source line %4ld\n", i); > 2401 #ifdef USE_MAPPED_LOCATION > 2402 source_location s = linemap_line_start (line_table, i, 80); > 2403 input_location = s; > 2404 #else > 2405 input_line = i; > 2406 #endif > 2407 } > > The code on line 2402 is a C++ism. You cannot declare variables > in the middle of code in C. Unless it has changed with the new > version of C, but it still won't build with older C compilers. (I'm > using gcc 2.95.4) > > Mika > From mika at async.caltech.edu Sat Apr 25 00:12:20 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 24 Apr 2009 15:12:20 -0700 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? Message-ID: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> Hi Modula-3ers, I'm trying to boot CM3 on FreeBSD 4.11 right now. Yes, I know it's an old system, but really, the older, the better. Once I have it running on 4.11, I'll have a binary archive that should work on *any* FreeBSD system from 4.x up to 7.x, not just the latest releases. My problems are not with FreeBSD. Well to some extent they are. I had to turn off pthreads: FreeBSD 4 has only a partial implementation, from what I can tell (in libc_r, not libpthreads) No, what's going on is I am trying to boot with CM3 5.3.1, which was the most recent binary I was able to get running on my FreeBSD 4 system. I inserted lots and lots of "LONGINT = INTEGER" in the code, but I'm still running into this one: -> linking cm3 UtilsPosix.mo: In function `UtilsPosix__MakeRelative': /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:23: undefined reference to `ThreadF__handlerStack' /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:23: undefined reference to `ThreadF__handlerStack' /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:33: undefined reference to `ThreadF__handlerStack' /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:50: undefined reference to `ThreadF__handlerStack' /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:60: undefined reference to `ThreadF__handlerStack' Builder.mo:/home/mika/cm3-cvs/cm3/m3-sys/cm3/FreeBSD4/Builder.m3:188: more undefined references to `ThreadF__handlerStack' follow Fatal Error: package build failed No matter what I try... I tried to make ThreadF.handlerStack invariantly equal to ThreadPosix.self.context.handlers... it won't link. Somehow it's not letting me slip in a "handlerStack" in the interface? Anyone have an idea for workarounds? Mika From mika at async.caltech.edu Sat Apr 25 00:20:00 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 24 Apr 2009 15:20:00 -0700 Subject: [M3devel] Suspicious code in Cstdio.i3 for FreeBSD Message-ID: <200904242220.n3OMK0K3016010@camembert.async.caltech.edu> This code looks a bit suspicious: FILE = RECORD p : unsigned_char_star; (* current position in (some) buffer *) r : int; (* read space left for getc() *) w : int; (* write space left for putc() *) flags : short_int; (* flags, below; this FILE is free if 0 *) file : short_int; (* fileno, if Unix descriptor, else -1 *) bf : SBUF; (* the buffer (at least 1 byte, if !NULL) *) lbfsize : int; (* 0 or -_bf._size, for inline putc *) (* operations *) cookie : void_star; (* cookie passed to io functions *) xxclose: void_star; xxread : void_star; xxseek : void_star; xxwrite: void_star; (* separate buffer for long sequences of ungetc() *) ub : SBUF; (* ungetc buffer *) up : unsigned_char_star; (* saved _p when _p is doing ungetc data *) ur : int; (* saved _r when _r is counting ungetc data *) (* tricks to meet minimum requirements even when malloc() fails *) ubuf : ARRAY[0..2] OF unsigned_char; (* guarantee an ungetc() buffer *) nbuf : ARRAY[0..0] OF unsigned_char; (* guarantee a getc() buffer *) (* separate buffer for fgetln() when line crosses buffer boundary *) lb : SBUF; (* buffer for fgetln() *) (* Unix stdio files get aligned to block boundaries on fseek() *) blksize : int; (* stat.st_blksize (may be != _bf._size) *) offset : off_t; (* current lseek offset *) pad1 : int; (* assume high 4 bytes of offset are 0 *) END; Note the "offset" and "pad1". Now... off_t = int64_t; int64_t = BITS 64 FOR Ctypes.long_long; Is this right or is there a bit too much padding here? Is the padding also assuming little-endianness? Hmm... Mika From jay.krell at cornell.edu Sat Apr 25 00:22:53 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 24 Apr 2009 22:22:53 +0000 Subject: [M3devel] Suspicious code in Cstdio.i3 for FreeBSD In-Reply-To: <200904242220.n3OMK0K3016010@camembert.async.caltech.edu> References: <200904242220.n3OMK0K3016010@camembert.async.caltech.edu> Message-ID: I believe this is all dead anyway. - Jay ---------------------------------------- > To: m3devel at elegosoft.com > Date: Fri, 24 Apr 2009 15:20:00 -0700 > From: mika at async.caltech.edu > CC: mika at camembert.async.caltech.edu > Subject: [M3devel] Suspicious code in Cstdio.i3 for FreeBSD > > > This code looks a bit suspicious: > > FILE = RECORD > p : unsigned_char_star; (* current position in (some) buffer *) > r : int; (* read space left for getc() *) > w : int; (* write space left for putc() *) > flags : short_int; (* flags, below; this FILE is free if 0 *) > file : short_int; (* fileno, if Unix descriptor, else -1 *) > bf : SBUF; (* the buffer (at least 1 byte, if !NULL) *) > lbfsize : int; (* 0 or -_bf._size, for inline putc *) > > (* operations *) > cookie : void_star; (* cookie passed to io functions *) > xxclose: void_star; > xxread : void_star; > xxseek : void_star; > xxwrite: void_star; > > (* separate buffer for long sequences of ungetc() *) > ub : SBUF; (* ungetc buffer *) > up : unsigned_char_star; (* saved _p when _p is doing ungetc data *) > ur : int; (* saved _r when _r is counting ungetc data *) > > (* tricks to meet minimum requirements even when malloc() fails *) > ubuf : ARRAY[0..2] OF unsigned_char; (* guarantee an ungetc() buffer *) > nbuf : ARRAY[0..0] OF unsigned_char; (* guarantee a getc() buffer *) > > (* separate buffer for fgetln() when line crosses buffer boundary *) > lb : SBUF; (* buffer for fgetln() *) > > (* Unix stdio files get aligned to block boundaries on fseek() *) > blksize : int; (* stat.st_blksize (may be != _bf._size) *) > offset : off_t; (* current lseek offset *) > pad1 : int; (* assume high 4 bytes of offset are 0 *) > > END; > > > Note the "offset" and "pad1". > > Now... > > off_t = int64_t; > > int64_t = BITS 64 FOR Ctypes.long_long; > > Is this right or is there a bit too much padding here? > > Is the padding also assuming little-endianness? Hmm... > > > Mika From jay.krell at cornell.edu Sat Apr 25 00:23:36 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 24 Apr 2009 22:23:36 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> References: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> Message-ID: ouch, really, no adequate pthreads here? Well, I can still give you an archive to try, but less certain it will work. I never test the user thread stuff.. - Jay ---------------------------------------- > To: m3devel at elegosoft.com > Date: Fri, 24 Apr 2009 15:12:20 -0700 > From: mika at async.caltech.edu > CC: mika at camembert.async.caltech.edu > Subject: [M3devel] help booting CM3 on FreeBSD 4.11? > > Hi Modula-3ers, > > I'm trying to boot CM3 on FreeBSD 4.11 right now. > > Yes, I know it's an old system, but really, the older, the better. > Once I have it running on 4.11, I'll have a binary archive that > should work on *any* FreeBSD system from 4.x up to 7.x, not just > the latest releases. > > My problems are not with FreeBSD. Well to some extent they are. > I had to turn off pthreads: FreeBSD 4 has only a partial implementation, > from what I can tell (in libc_r, not libpthreads) > > No, what's going on is I am trying to boot with CM3 5.3.1, which was the > most recent binary I was able to get running on my FreeBSD 4 system. > > I inserted lots and lots of "LONGINT = INTEGER" in the code, but I'm > still running into this one: > > -> linking cm3 > UtilsPosix.mo: In function `UtilsPosix__MakeRelative': > /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:23: undefined reference to `ThreadF__handlerStack' > /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:23: undefined reference to `ThreadF__handlerStack' > /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:33: undefined reference to `ThreadF__handlerStack' > /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:50: undefined reference to `ThreadF__handlerStack' > /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:60: undefined reference to `ThreadF__handlerStack' > Builder.mo:/home/mika/cm3-cvs/cm3/m3-sys/cm3/FreeBSD4/Builder.m3:188: more undefined references to `ThreadF__handlerStack' follow > Fatal Error: package build failed > > No matter what I try... I tried to make ThreadF.handlerStack > invariantly equal to ThreadPosix.self.context.handlers... it won't > link. Somehow it's not letting me slip in a "handlerStack" in the > interface? > > Anyone have an idea for workarounds? > > Mika From jay.krell at cornell.edu Sat Apr 25 00:26:43 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 24 Apr 2009 22:26:43 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> References: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> Message-ID: You shouldn't have to muck with LONGINT actually. When you bootstrap, you use your existing libm3 and m3core. And you build sysutils, m3front, m3middle, m3quake, cm3, etc. -- none of which should be using LONGINT. upgrade.py and upgrade.sh get this right. If LONGINT has crept into those packages, that would be a problem. But LONGINT in m3core and libm3 can/does exist and is not a problem. I'll fix handlerStack for you in a sec. Would help if you had pthreads though. - Jay ---------------------------------------- > To: m3devel at elegosoft.com > Date: Fri, 24 Apr 2009 15:12:20 -0700 > From: mika at async.caltech.edu > CC: mika at camembert.async.caltech.edu > Subject: [M3devel] help booting CM3 on FreeBSD 4.11? > > Hi Modula-3ers, > > I'm trying to boot CM3 on FreeBSD 4.11 right now. > > Yes, I know it's an old system, but really, the older, the better. > Once I have it running on 4.11, I'll have a binary archive that > should work on *any* FreeBSD system from 4.x up to 7.x, not just > the latest releases. > > My problems are not with FreeBSD. Well to some extent they are. > I had to turn off pthreads: FreeBSD 4 has only a partial implementation, > from what I can tell (in libc_r, not libpthreads) > > No, what's going on is I am trying to boot with CM3 5.3.1, which was the > most recent binary I was able to get running on my FreeBSD 4 system. > > I inserted lots and lots of "LONGINT = INTEGER" in the code, but I'm > still running into this one: > > -> linking cm3 > UtilsPosix.mo: In function `UtilsPosix__MakeRelative': > /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:23: undefined reference to `ThreadF__handlerStack' > /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:23: undefined reference to `ThreadF__handlerStack' > /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:33: undefined reference to `ThreadF__handlerStack' > /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:50: undefined reference to `ThreadF__handlerStack' > /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:60: undefined reference to `ThreadF__handlerStack' > Builder.mo:/home/mika/cm3-cvs/cm3/m3-sys/cm3/FreeBSD4/Builder.m3:188: more undefined references to `ThreadF__handlerStack' follow > Fatal Error: package build failed > > No matter what I try... I tried to make ThreadF.handlerStack > invariantly equal to ThreadPosix.self.context.handlers... it won't > link. Somehow it's not letting me slip in a "handlerStack" in the > interface? > > Anyone have an idea for workarounds? > > Mika From jay.krell at cornell.edu Sat Apr 25 00:34:45 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 24 Apr 2009 22:34:45 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> References: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> Message-ID: > I'll fix handlerStack for you in a sec. No, nevermind that. Just use your installed m3core/libm3 and you don't need it "fixed". You already have it. You aren't bootstrapping in the right order I presume. Try upgrade.sh or upgrade.py. They build the current compiler against the existing runtime. Oh, I guess you'll hit a problem in sysutils. It uses Cerrno which is relatively new. You can just comment that out -- assume there is no error. sysutils should maybe carry its own errno wrapper because of this. Trivial. I've hit it multiple times building on Darwin from older distributions. - Jay From jay.krell at cornell.edu Sat Apr 25 00:40:41 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 24 Apr 2009 22:40:41 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> References: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> Message-ID: > > Would help if you had pthreads though. IF you have a working-enough pthreads, no matter what library they are in, take a look at: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-FreeBSD4-1.tar.gz It's a little gross -- one directory with LOTS of files. And a few subdirectories you don't need. Be sure to look at the start of the Makefile and possibly adjust it. There are some *.sh files, redundant with the Makefile. The output of this is just cm3. You can use that to then build up the system from the bottom of the dependeny tree and on up -- m3cc, m3core, libm3, etc. do-cm3-core.sh/do-cm3-core.py should do that. This is different than "upgrade", which uses an existing m3core/libm3. This is how I do cross builds, both to existing systems and new systems. It has worked several times for me. Most often from a Cygwin host but maybe not always, and it isn't Cygwin specific. If you really don't have a working pthreads, well, I'd just have to rebuild this with one edit...maybe I can do that quickly (it'll be -2 if so..), maybe it'll work...maybe... - Jay From mika at async.caltech.edu Sat Apr 25 01:03:13 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 24 Apr 2009 16:03:13 -0700 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: Your message of "Fri, 24 Apr 2009 22:34:45 -0000." Message-ID: <200904242303.n3ON3DO0018052@camembert.async.caltech.edu> yes it sounds like I'm just using the wrong bootstrapping order. I'm going on an old email from Tony, but there were fewer updates back then to worry about. I'll try your version and report back! Thanks! Mika Jay writes: > >> I'll fix handlerStack for you in a sec. > >No, nevermind that. >Just use your installed m3core/libm3 and you don't need it "fixed". >You already have it. > > >You aren't bootstrapping in the right order I presume. >Try upgrade.sh or upgrade.py. >They build the current compiler against the existing runtime. > > >Oh, I guess you'll hit a problem in sysutils. It uses Cerrno which is relative >ly new. >You can just comment that out -- assume there is no error. >sysutils should maybe carry its own errno wrapper because of this. > Trivial. >I've hit it multiple times building on Darwin from older distributions. > > > - Jay > From mika at async.caltech.edu Sat Apr 25 01:05:06 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 24 Apr 2009 16:05:06 -0700 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: Your message of "Fri, 24 Apr 2009 22:40:41 -0000." Message-ID: <200904242305.n3ON56IS018186@camembert.async.caltech.edu> By the way, I take it booting the compiler "old-fashionedly" with PM3 is out of the question? I have a very well-working PM3... reason it's taken me so long to get around to really pushing on updating to CM3... But let me fiddle around for a bit and see if I need you again. Mika Jay writes: > >> >> Would help if you had pthreads though. > > >IF you have a working-enough pthreads, no matter what library they are in, tak >e a look at: > > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-FreeBSD4-1.tar.gz > > > >It's a little gross -- one directory with LOTS of files. >And a few subdirectories you don't need. > > >Be sure to look at the start of the Makefile and possibly adjust it. >There are some *.sh files, redundant with the Makefile. > > >The output of this is just cm3. >You can use that to then build up the system from the bottom of the dependeny >tree and on up -- m3cc, m3core, libm3, etc. do-cm3-core.sh/do-cm3-core.py shou >ld do that. >This is different than "upgrade", which uses an existing m3core/libm3. > >This is how I do cross builds, both to existing systems and new systems. >It has worked several times for me. Most often from a Cygwin host but maybe no >t always, and it isn't Cygwin specific. > > > >If you really don't have a working pthreads, well, I'd just have to rebuild th >is with one edit...maybe I can do that quickly (it'll be -2 if so..), maybe it >'ll work...maybe... > > > - Jay From jay.krell at cornell.edu Sat Apr 25 01:21:49 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 24 Apr 2009 23:21:49 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <200904242305.n3ON56IS018186@camembert.async.caltech.edu> References: Your message of "Fri, 24 Apr 2009 22:40:41 -0000." <200904242305.n3ON56IS018186@camembert.async.caltech.edu> Message-ID: > By the way, I take it booting the compiler "old-fashionedly" with > PM3 is out of the question? What is the PM3 way? The SRC way is out of the question at least (unless you want to /start/ with it and go through a few releases...). I gather that the PM3 was good and could be resusitated. But it is is some work..maybe too much. I gather that PM3 factored out word size and endianness from the IL? And padding/alignment? And jmpbuf size? And whatever else is target-dependent? There isn't much. Not impossible, but seems a bit onerous. padding/alignment actually don't have to be factored out, kind of. They can be made "worst case", as long as the interactions with C are correct. word size and endianness are in the IL but I think only barely. jmpbuf size is easy to factor out at a small perf cost. or again, make it worst case. These "worst cases" are likely to be pretty bad, such that they are ok for building the first compiler, but then you'd want to immediately rebuild it "ideally". jmpbuf size varies from around 16 bytes to over 200 bytes for example. You could also use extern int jmpbufsize; jmpbuf = alloca(jmpbufsize) thereby not blowing stack, but still being slow. Again, fine for bootstrap purposes but it should end there. "aligned procedures" can be factored out easily via acting worst case. Is this what PM3 did though? Shipped one textual IL for all platforms, built m3cc (which doesn't /really/ require having cm3), then built everything from the portable IL, then rebuilt it all again more ideally? I think if a portable distribution format is to be had, maybe go all the way to using a C backend? However that doesn't solve all/many/any of the above problems, given how low level the IL is. - Jay From jay.krell at cornell.edu Sat Apr 25 01:24:30 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 24 Apr 2009 23:24:30 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <200904242303.n3ON3DO0018052@camembert.async.caltech.edu> References: Your message of "Fri, 24 Apr 2009 22:34:45 -0000." <200904242303.n3ON3DO0018052@camembert.async.caltech.edu> Message-ID: The main out of date thing about what Tony did is that sysutils might not have existed at the time. His statement as to "all" the one place to cheat on LONGINT is out of date too, it is used in more than one place, but you don't have do this anyway. You might also try a cross build.. :) - Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Fri, 24 Apr 2009 16:03:13 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] help booting CM3 on FreeBSD 4.11? > > yes it sounds like I'm just using the wrong bootstrapping order. > I'm going on an old email from Tony, but there were fewer updates > back then to worry about. > > I'll try your version and report back! > > Thanks! > > Mika > > Jay writes: >> >>> I'll fix handlerStack for you in a sec. >> >>No, nevermind that. >>Just use your installed m3core/libm3 and you don't need it "fixed". >>You already have it. >> >> >>You aren't bootstrapping in the right order I presume. >>Try upgrade.sh or upgrade.py. >>They build the current compiler against the existing runtime. >> >> >>Oh, I guess you'll hit a problem in sysutils. It uses Cerrno which is relative >>ly new. >>You can just comment that out -- assume there is no error. >>sysutils should maybe carry its own errno wrapper because of this. >> Trivial. >>I've hit it multiple times building on Darwin from older distributions. >> >> >> - Jay >> From jay.krell at cornell.edu Sat Apr 25 01:42:40 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 24 Apr 2009 23:42:40 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: References: Your message of "Fri, 24 Apr 2009 22:40:41 -0000." <200904242305.n3ON56IS018186@camembert.async.caltech.edu> Message-ID: > I said > word size and endianness are in the IL but I think only barely. [I think] Actually the front end lays out all the types, so word size is all over the place. It's actually a little bit bad, because the gcc backend performs the layout too and they have to match, and they don't always.. (x86 aligned double...) - Jay From jay.krell at cornell.edu Sat Apr 25 01:53:09 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 24 Apr 2009 23:53:09 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> References: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> Message-ID: This /might/ help: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-FreeBSD4-1-userthreads.tar.gz Assuming there are a small number of problems though, the best ways to get more rapid turnaround are to do a cross build or at least first make sure userthreads work on more recent FreeBSD. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu; m3devel at elegosoft.com > CC: mika at camembert.async.caltech.edu > Subject: RE: [M3devel] help booting CM3 on FreeBSD 4.11? > Date: Fri, 24 Apr 2009 22:40:41 +0000 > > >> >> Would help if you had pthreads though. > > > IF you have a working-enough pthreads, no matter what library they are in, take a look at: > > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-FreeBSD4-1.tar.gz > > > It's a little gross -- one directory with LOTS of files. > And a few subdirectories you don't need. > > > Be sure to look at the start of the Makefile and possibly adjust it. > There are some *.sh files, redundant with the Makefile. > > > The output of this is just cm3. > You can use that to then build up the system from the bottom of the dependeny tree and on up -- m3cc, m3core, libm3, etc. do-cm3-core.sh/do-cm3-core.py should do that. > This is different than "upgrade", which uses an existing m3core/libm3. > > This is how I do cross builds, both to existing systems and new systems. > It has worked several times for me. Most often from a Cygwin host but maybe not always, and it isn't Cygwin specific. > > > > If you really don't have a working pthreads, well, I'd just have to rebuild this with one edit...maybe I can do that quickly (it'll be -2 if so..), maybe it'll work...maybe... > > > - Jay From jay.krell at cornell.edu Sat Apr 25 02:05:21 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 00:05:21 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: References: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> Message-ID: ps: you'll want something like: C:\dev2\cm3.2\m3-libs\m3core\src>cvs -z3 diff thread.quake Index: thread.quake =================================================================== RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread.quake,v retrieving revision 1.5 diff -r1.5 thread.quake 40c40 < "FreeBSD4" : TRUE, --- > "FreeBSD4" : FALSE, or C:\dev2\cm3.2\m3-libs\m3core\src>grep defined thread.quake if (NO_USER_THREADS contains TARGET) or ((not defined("NOPTHREAD")) and USE_ PTHREADS{TARGET}) cm3 -DNOPTHREAD - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu; m3devel at elegosoft.com > Date: Fri, 24 Apr 2009 23:53:09 +0000 > CC: mika at camembert.async.caltech.edu > Subject: Re: [M3devel] help booting CM3 on FreeBSD 4.11? > > > This /might/ help: > > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-FreeBSD4-1-userthreads.tar.gz > > > Assuming there are a small number of problems though, the best ways to get more rapid turnaround are to do a cross build or at least first make sure userthreads work on more recent FreeBSD. > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: mika at async.caltech.edu; m3devel at elegosoft.com >> CC: mika at camembert.async.caltech.edu >> Subject: RE: [M3devel] help booting CM3 on FreeBSD 4.11? >> Date: Fri, 24 Apr 2009 22:40:41 +0000 >> >> >>> >>> Would help if you had pthreads though. >> >> >> IF you have a working-enough pthreads, no matter what library they are in, take a look at: >> >> >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-FreeBSD4-1.tar.gz >> >> >> It's a little gross -- one directory with LOTS of files. >> And a few subdirectories you don't need. >> >> >> Be sure to look at the start of the Makefile and possibly adjust it. >> There are some *.sh files, redundant with the Makefile. >> >> >> The output of this is just cm3. >> You can use that to then build up the system from the bottom of the dependeny tree and on up -- m3cc, m3core, libm3, etc. do-cm3-core.sh/do-cm3-core.py should do that. >> This is different than "upgrade", which uses an existing m3core/libm3. >> >> This is how I do cross builds, both to existing systems and new systems From mika at async.caltech.edu Sat Apr 25 05:38:17 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 24 Apr 2009 20:38:17 -0700 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: Your message of "Fri, 24 Apr 2009 22:40:41 -0000." Message-ID: <200904250338.n3P3cHlc030469@camembert.async.caltech.edu> Jay (and others), Success! I think.... I was able to build the compiler, after much experimentation, by using Jay's build order and linking with -libc_r. Mentor works, and that's usually a good sign. Jay, your assembly worked too! And as you say, it's much easier to bootstrap with that than to do what I was trying to do (but I did both, several times, just to make sure). I don't know why I was having linking problems with -libc_r earlier. Now it just seems to work. So, pthreads on FreeBSD 4. If I use user threads, it's a different story (which is probably too bad, as I know that user threads work absolutely fine in my old version of CM3): I can build a compiler fine, but the bootstrapped cm3 crashes in the user thread code. Note that exactly the same thing happens whether I bootstrap with the assembly version from Jay or from v. 5.3.4, which I think is what I had. Here we go: Starting program: /usr/local/cm3/pkg/cm3/FreeBSD4/cm3 Program received signal SIGSEGV, Segmentation fault. 16_82568bb in RTHooks.PushEFrame (frame=16_bfbff3f4) at ../src/thread/POSIX/ThreadPosix.m3:1599 1599 f.next := self.context.handlers; (gdb) where #0 16_82568bb in RTHooks.PushEFrame (frame=16_bfbff3f4) at ../src/thread/POSIX/ThreadPosix.m3:1599 #1 16_824c91e in RTType.Calloc (n=1024, n_bytes=4) at ../src/runtime/common/RTType.m3:815 #2 16_824c39a in RTType.Expand (m=RECORD name = 16_82f0e50; is_equal = 16_824c6a6; rehash = 16_824c6e8; initial_size = 1024; full = 512; cnt = 0; max = 1024; mask = 1023; map = NIL; END) at ../src/runtime/common/RTType.m3:724 #3 16_824c26f in RTType.FindSlot (m=RECORD name = 16_82f0e50; is_equal = 16_824c6a6; rehash = 16_824c6e8; initial_size = 1024; full = 512; cnt = 0; max = 1024; mask = 1023; map = NIL; END, key=-1025633461, aux=NIL) at ../src/runtime/common/RTType.m3:699 #4 16_824b007 in RTTypeSRC.AddTypecell (def=16_82eb8b4, m=16_82eb880) at ../src/runtime/common/RTType.m3:163 #5 16_8244d89 in RTLinker.DeclareModuleTypes (m=16_82eb880) at ../src/runtime/common/RTLinker.m3:280 #6 16_8244b52 in RTLinker.FixTypes () at ../src/runtime/common/RTLinker.m3:234 #7 16_82446f9 in RTLinker.AddUnitI (m=16_82eefa0) at ../src/runtime/common/RTLinker.m3:112 #8 16_824478f in RTLinker.AddUnit (b=16_82443e0) at ../src/runtime/common/RTLinker.m3:122 #9 16_8244493 in RTLinker.InitRuntime (p_argc=1, p_argv=16_bfbff68c, p_envp=16_bfbff694, p_instance=NIL) at ../src/runtime/common/RTLinker.m3:42 module "_m3main": missing debug info for global data I'm not able to print self in m3gdb, for some reason. Mika Jay writes: > >> >> Would help if you had pthreads though. > > >IF you have a working-enough pthreads, no matter what library they are in, take a look at: > > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-FreeBSD4-1.tar.gz > > >It's a little gross -- one directory with LOTS of files. >And a few subdirectories you don't need. > > >Be sure to look at the start of the Makefile and possibly adjust it. >There are some *.sh files, redundant with the Makefile. > > >The output of this is just cm3. >You can use that to then build up the system from the bottom of the dependeny tree and on up -- m3cc, m3core, libm3, etc. do-cm3-core.sh/do-cm3-core.py should do that. >This is different than "upgrade", which uses an existing m3core/libm3. > >This is how I do cross builds, both to existing systems and new systems. >It has worked several times for me. Most often from a Cygwin host but maybe not always, and it isn't Cygwin specific. > > > >If you really don't have a working pthreads, well, I'd just have to rebuild this with one edit...maybe I can do that quickly (it'll be -2 if so..), maybe it'll work...maybe... > > > - Jay From mika at async.caltech.edu Sat Apr 25 05:41:04 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 24 Apr 2009 20:41:04 -0700 Subject: [M3devel] inconsistencies in external interfaces Message-ID: <200904250341.n3P3f4O8030634@camembert.async.caltech.edu> All right, here's another little oddity. m3-libs/m3core/src/unix/freebsd-4/Utime.i3 has the following: time_t = int; (* seconds since the Epoch *) ... <*EXTERNAL*> PROCEDURE localtime (clock: long_star): struct_tm_star; Huh? What's the point of declaring time_t if you're not going to use it? (I think it used to be that long_star and time_t resolved to the same type, before the LONGINT work or some other foreign interface updating, but they no longer seem to...) Mika From jay.krell at cornell.edu Sat Apr 25 06:12:54 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 04:12:54 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <200904250338.n3P3cHlc030469@camembert.async.caltech.edu> References: Your message of "Fri, 24 Apr 2009 22:40:41 -0000." <200904250338.n3P3cHlc030469@camembert.async.caltech.edu> Message-ID: Cool. > If I use user threads, it's a different story (which is probably too bad, Oops, right, I forgot, I should have mentioned that, user threads have likely been broken on all platforms for a while. I noticed that on PPC_LINUX. I think it is trivial to fix. Or use pthreads.. - Jay > To: jay.krell at cornell.edu > Date: Fri, 24 Apr 2009 20:38:17 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] help booting CM3 on FreeBSD 4.11? > > Jay (and others), > > Success! I think.... I was able to build the compiler, after much > experimentation, by using Jay's build order and linking with -libc_r. > Mentor works, and that's usually a good sign. > > Jay, your assembly worked too! And as you say, it's much easier to > bootstrap with that than to do what I was trying to do (but I did > both, several times, just to make sure). > > I don't know why I was having linking problems with -libc_r earlier. > Now it just seems to work. So, pthreads on FreeBSD 4. > > If I use user threads, it's a different story (which is probably too bad, > as I know that user threads work absolutely fine in my old version of CM3): > > I can build a compiler fine, but the bootstrapped cm3 crashes in > the user thread code. Note that exactly the same thing happens whether > I bootstrap with the assembly version from Jay or from v. 5.3.4, which > I think is what I had. Here we go: > > Starting program: /usr/local/cm3/pkg/cm3/FreeBSD4/cm3 > > Program received signal SIGSEGV, Segmentation fault. > 16_82568bb in RTHooks.PushEFrame (frame=16_bfbff3f4) at ../src/thread/POSIX/ThreadPosix.m3:1599 > 1599 f.next := self.context.handlers; > (gdb) where > #0 16_82568bb in RTHooks.PushEFrame (frame=16_bfbff3f4) at ../src/thread/POSIX/ThreadPosix.m3:1599 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 25 06:50:44 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 04:50:44 +0000 Subject: [M3devel] inconsistencies in external interfaces In-Reply-To: <200904250341.n3P3f4O8030634@camembert.async.caltech.edu> References: <200904250341.n3P3f4O8030634@camembert.async.caltech.edu> Message-ID: 1) I THINK these files are often a pretty direct translation of /usr/include, dead stuff, comments, and all. Posix often mandates that certain types are certain headers, even if they aren't used by any function in that header. Utime.i3 would declare time_t not necessarily for its own purposes but so that C code (nonsense example but ok): #include int main() { time_t t = 0; /* ... */ } translates "directly" to Modula-3 (ha): IMPORT Utime; VAR t: Utime.time_t := 0 BEGIN (* ... *) END Main. 2) Almost everything in m3core/src/unix is dead anyway, outside of the common directory, and Usysdeps.i3, and the userthread support. Look at the m3makefile. It is mostly if'ed out. The only active platforms using their own full assortment of cloned /usr/include are I386_DARWIN and AMD64_DARWIN..until I get around to them. If OpenDarwin/x86 7.0 will run in a VM, I386_DARWIN will fall soon. AMD64_DARWIN must wait for additional hardware, or someone else to switch it (Tony?) - Jay > To: m3devel at elegosoft.com > Date: Fri, 24 Apr 2009 20:41:04 -0700 > From: mika at async.caltech.edu > Subject: [M3devel] inconsistencies in external interfaces > > > All right, here's another little oddity. > > m3-libs/m3core/src/unix/freebsd-4/Utime.i3 has the following: > > time_t = int; (* seconds since the Epoch *) > > ... > > <*EXTERNAL*> PROCEDURE localtime (clock: long_star): struct_tm_star; > > Huh? What's the point of declaring time_t if you're not going to > use it? > > (I think it used to be that long_star and time_t resolved to the > same type, before the LONGINT work or some other foreign interface > updating, but they no longer seem to...) > > Mika > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sat Apr 25 07:32:37 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 24 Apr 2009 22:32:37 -0700 Subject: [M3devel] inconsistencies in external interfaces In-Reply-To: Your message of "Sat, 25 Apr 2009 04:50:44 -0000." Message-ID: <200904250532.n3P5Wb7V035782@camembert.async.caltech.edu> Well, I hear you, but in this case I doubt it. /usr/include/time.h has struct tm *localtime __P((const time_t *)); and man localtime yields... struct tm * localtime(const time_t *clock); It looks like a manual job to me. Mika Jay writes: >--_7e282a72-e70c-455d-9d62-0c65873ebb2d_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >1) I THINK these files are often a pretty direct translation of /usr/includ= >e=2C dead stuff=2C comments=2C and all. Posix often mandates that certain t= >ypes are certain headers=2C even if they aren't used by any function in tha= >t header. > >=20 > >=20 > >Utime.i3 would declare time_t not necessarily for its own purposes but so t= >hat C code (nonsense example but ok): > >=20 > >=20 > >#include > >=20 > >int main() > >{ > > time_t t =3D 0=3B > > /* ... */ > >} > >=20 > >=20 >translates "directly" to Modula-3 (ha): > >=20 > >=20 > >IMPORT Utime=3B > >VAR > > t: Utime.time_t :=3D 0 > >BEGIN > > (* ... *) > >END Main. > > =20 > >2) Almost everything in m3core/src/unix is dead anyway=2C outside of the co= >mmon directory=2C and Usysdeps.i3=2C and the userthread support. > >Look at the m3makefile. It is mostly if'ed out. > >The only active platforms using their own full assortment of cloned /usr/in= >clude are I386_DARWIN and AMD64_DARWIN..until I get around to them. If Open= >Darwin/x86 7.0 will run in a VM=2C I386_DARWIN will fall soon. AMD64_DARWIN= > must wait for additional hardware=2C or someone else to switch it (Tony?) > >=20 > >=20 > > - Jay > >=20 >> To: m3devel at elegosoft.com >> Date: Fri=2C 24 Apr 2009 20:41:04 -0700 >> From: mika at async.caltech.edu >> Subject: [M3devel] inconsistencies in external interfaces >>=20 >>=20 >> All right=2C here's another little oddity. >>=20 >> m3-libs/m3core/src/unix/freebsd-4/Utime.i3 has the following: >>=20 >> time_t =3D int=3B (* seconds since the Epoch *) >>=20 >> ... >>=20 >> <*EXTERNAL*> PROCEDURE localtime (clock: long_star): struct_tm_star=3B >>=20 >> Huh? What's the point of declaring time_t if you're not going to >> use it? >>=20 >> (I think it used to be that long_star and time_t resolved to the >> same type=2C before the LONGINT work or some other foreign interface >> updating=2C but they no longer seem to...) >>=20 >> Mika >>=20 >>=20 > >--_7e282a72-e70c-455d-9d62-0c65873ebb2d_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >1) I THINK these files are often a pretty direct =3Btranslation of /usr= >/include=2C dead stuff=2C comments=2C and all. Posix often mandates that ce= >rtain types are certain headers=2C even if they aren't used by any function= > in that header.
> =3B
> =3B
>Utime.i3 would =3Bdeclare time_t not necessarily for its own purposes b= >ut so that C code (nonsense example but ok):
> =3B
> =3B
>#include <=3Btime.h>=3B
> =3B
>int main()
>{
> =3B =3Btime_t t =3D 0=3B
> =3B /* ... */
>}
> =3B
> =3B
>translates "directly" to Modula-3 (ha):
> =3B
> =3B
>IMPORT Utime=3B
>VAR
> =3B t: Utime.time_t =3B:=3D 0
>BEGIN
> =3B (* ... *)
>END Main.
> =3B

2) Almost everything in m3core/src/unix is dead anyway=2C = >outside of the common directory=2C and Usysdeps.i3=2C and the userthread su= >pport.
>Look at the m3makefile. It is mostly if'ed out.
>The only active platforms using their own full assortment of cloned /usr/in= >clude are I386_DARWIN and AMD64_DARWIN..until I get around to them. If Open= >Darwin/x86 7.0 will run in a VM=2C I386_DARWIN will fall soon. AMD64_DARWIN= > must wait for additional hardware=2C or someone else to switch it (Tony?)<= >BR> > =3B
> =3B
> =3B- Jay

 =3B
>=3B To: m3devel at elegosoft.com
>=3B= > Date: Fri=2C 24 Apr 2009 20:41:04 -0700
>=3B From: mika at async.caltech= >.edu
>=3B Subject: [M3devel] inconsistencies in external interfaces>>=3B
>=3B
>=3B All right=2C here's another little oddity.>>=3B
>=3B m3-libs/m3core/src/unix/freebsd-4/Utime.i3 has the follo= >wing:
>=3B
>=3B time_t =3D int=3B (* seconds since the Epoch *)<= >BR>>=3B
>=3B ...
>=3B
>=3B <=3B*EXTERNAL*>=3B PROCED= >URE localtime (clock: long_star): struct_tm_star=3B
>=3B
>=3B Hu= >h? What's the point of declaring time_t if you're not going to
>=3B us= >e it?
>=3B
>=3B (I think it used to be that long_star and time_t= > resolved to the
>=3B same type=2C before the LONGINT work or some oth= >er foreign interface
>=3B updating=2C but they no longer seem to...)R>>=3B
>=3B Mika
>=3B
>=3B
>= > >--_7e282a72-e70c-455d-9d62-0c65873ebb2d_-- From mika at async.caltech.edu Sat Apr 25 07:58:23 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 24 Apr 2009 22:58:23 -0700 Subject: [M3devel] Uresource on freebsd 4? Message-ID: <200904250558.n3P5wNE1036977@camembert.async.caltech.edu> Is there any particular reason Uresource no longer exists on FreeBSD4? The m3makefile m3core/src/unix/freebsd-4/m3makefile looks like the following, and Uresource isn't picked up anywhere else: if TRUE Module ("Usignal") Interface ("Uucontext") else Interface ("Udir") Interface ("Uerror") %Interface ("Ugrp") Interface ("Uipc") Interface ("Umman") Module ("Umsg") Interface ("Unix") Interface ("Uprocess") Interface ("Upthread") Interface ("Upwd") Interface ("Uresource") Interface ("Usem") Interface ("Usched") Interface ("Ushm") Module ("Usignal") Interface ("Ustat") Interface ("Usocket") Interface ("Usyslog") Interface ("Utime") Module ("Utypes") Interface ("Uucontext") Interface ("Uugid") Interface ("Uuio") Interface ("Uutsname") end From jay.krell at cornell.edu Sat Apr 25 08:14:28 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 06:14:28 +0000 Subject: [M3devel] Uresource on freebsd 4? In-Reply-To: <200904250558.n3P5wNE1036977@camembert.async.caltech.edu> References: <200904250558.n3P5wNE1036977@camembert.async.caltech.edu> Message-ID: Do you need it? Is there a sufficient common/Uresource.i3? I generally removed whatever isn't used, and made the remainders portable. I can look into restoring more, but what do you need and what is there? (I can look.) - Jay > To: m3devel at elegosoft.com > Date: Fri, 24 Apr 2009 22:58:23 -0700 > From: mika at async.caltech.edu > CC: mika at camembert.async.caltech.edu > Subject: [M3devel] Uresource on freebsd 4? > > > Is there any particular reason Uresource no longer exists on FreeBSD4? > The m3makefile > > m3core/src/unix/freebsd-4/m3makefile > > looks like the following, and Uresource isn't picked up anywhere else: > > if TRUE > > Module ("Usignal") > Interface ("Uucontext") > > else > > Interface ("Udir") > Interface ("Uerror") > %Interface ("Ugrp") > Interface ("Uipc") > Interface ("Umman") > Module ("Umsg") > Interface ("Unix") > Interface ("Uprocess") > Interface ("Upthread") > Interface ("Upwd") > Interface ("Uresource") > Interface ("Usem") > Interface ("Usched") > Interface ("Ushm") > Module ("Usignal") > Interface ("Ustat") > Interface ("Usocket") > Interface ("Usyslog") > Interface ("Utime") > Module ("Utypes") > Interface ("Uucontext") > Interface ("Uugid") > Interface ("Uuio") > Interface ("Uutsname") > > end > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sat Apr 25 08:32:29 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 24 Apr 2009 23:32:29 -0700 Subject: [M3devel] Uresource on freebsd 4? In-Reply-To: Your message of "Sat, 25 Apr 2009 06:14:28 -0000." Message-ID: <200904250632.n3P6WThS038574@camembert.async.caltech.edu> I use it for timing programs (getrusage). Is there another way of doing that in Modula-3? This declaration: <*EXTERNAL*> PROCEDURE getrusage (who: int; VAR rus: struct_rusage): int; I'm sure getrlimit is useful too. These things have been in Modula-3 for a long time... It's the only thing that's missing that I personally use. Except for some disturbances in m3tk things are now compiling for me... Mika Jay writes: >--_55ac72c8-d027-4bd6-a303-434a73dcc5db_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Do you need it? > >Is there a sufficient common/Uresource.i3? > >=20 > >I generally removed whatever isn't used=2C and made the remainders portable= >. > >I can look into restoring more=2C but what do you need and what is there? (= >I can look.) > >=20 > >=20 > > - Jay > >=20 >> To: m3devel at elegosoft.com >> Date: Fri=2C 24 Apr 2009 22:58:23 -0700 >> From: mika at async.caltech.edu >> CC: mika at camembert.async.caltech.edu >> Subject: [M3devel] Uresource on freebsd 4? >>=20 >>=20 >> Is there any particular reason Uresource no longer exists on FreeBSD4? >> The m3makefile >>=20 >> m3core/src/unix/freebsd-4/m3makefile >>=20 >> looks like the following=2C and Uresource isn't picked up anywhere else: >>=20 >> if TRUE >>=20 >> Module ("Usignal") >> Interface ("Uucontext") >>=20 >> else >>=20 >> Interface ("Udir") >> Interface ("Uerror") >> %Interface ("Ugrp") >> Interface ("Uipc") >> Interface ("Umman") >> Module ("Umsg") >> Interface ("Unix") >> Interface ("Uprocess") >> Interface ("Upthread") >> Interface ("Upwd") >> Interface ("Uresource") >> Interface ("Usem") >> Interface ("Usched") >> Interface ("Ushm") >> Module ("Usignal") >> Interface ("Ustat") >> Interface ("Usocket") >> Interface ("Usyslog") >> Interface ("Utime") >> Module ("Utypes") >> Interface ("Uucontext") >> Interface ("Uugid") >> Interface ("Uuio") >> Interface ("Uutsname") >>=20 >> end >>=20 > >--_55ac72c8-d027-4bd6-a303-434a73dcc5db_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >Do you need it?
>Is there a sufficient common/Uresource.i3?
> =3B
>I generally removed whatever isn't used=2C and made the remainders portable= >.
>I can look into restoring more=2C but what do you need and what is there? (= >I can look.)
> =3B
> =3B
> =3B- Jay

 =3B
>=3B To: m3devel at elegosoft.com
>=3B= > Date: Fri=2C 24 Apr 2009 22:58:23 -0700
>=3B From: mika at async.caltech= >.edu
>=3B CC: mika at camembert.async.caltech.edu
>=3B Subject: [M3d= >evel] Uresource on freebsd 4?
>=3B
>=3B
>=3B Is there any = >particular reason Uresource no longer exists on FreeBSD4?
>=3B The m3m= >akefile
>=3B
>=3B m3core/src/unix/freebsd-4/m3makefile
>=3B= >
>=3B looks like the following=2C and Uresource isn't picked up anywh= >ere else:
>=3B
>=3B if TRUE
>=3B
>=3B Module ("Usigna= >l")
>=3B Interface ("Uucontext")
>=3B
>=3B else
>=3B <= >BR>>=3B Interface ("Udir")
>=3B Interface ("Uerror")
>=3B %Inte= >rface ("Ugrp")
>=3B Interface ("Uipc")
>=3B Interface ("Umman")R>>=3B Module ("Umsg")
>=3B Interface ("Unix")
>=3B Interface (= >"Uprocess")
>=3B Interface ("Upthread")
>=3B Interface ("Upwd")R>>=3B Interface ("Uresource")
>=3B Interface ("Usem")
>=3B Int= >erface ("Usched")
>=3B Interface ("Ushm")
>=3B Module ("Usignal")= >
>=3B Interface ("Ustat")
>=3B Interface ("Usocket")
>=3B In= >terface ("Usyslog")
>=3B Interface ("Utime")
>=3B Module ("Utypes= >")
>=3B Interface ("Uucontext")
>=3B Interface ("Uugid")
>= >=3B Interface ("Uuio")
>=3B Interface ("Uutsname")
>=3B
>= >=3B end
>=3B
>= > >--_55ac72c8-d027-4bd6-a303-434a73dcc5db_-- From jay.krell at cornell.edu Sat Apr 25 09:52:31 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 07:52:31 +0000 Subject: [M3devel] Uresource on freebsd 4? In-Reply-To: <200904250632.n3P6WThS038574@camembert.async.caltech.edu> References: Your message of "Sat, 25 Apr 2009 06:14:28 -0000." <200904250632.n3P6WThS038574@camembert.async.caltech.edu> Message-ID: Does something like this suffice? Seconds used by current process as a float (including sub-second resolution). http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/runtime/POSIX/Attic/RTProcessPosix.i3?rev=1.1;content-type=text%2Fplain http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/runtime/POSIX/Attic/RTProcessPosixC.c?rev=1.7;content-type=text%2Fplain Notice it is in Attic. If not, can you write your own similar? The full getrusage has that huge struct.. seems best to not expose the whole thing but have folks write little C wrappers for just what they need. A portable wrapper would copy out all the fields, for "all the fields" defined as all the ones implemented by all systems. Only to have most users probably ignore most of them. Notice the cruft: struct_rusage = RECORD ru_utime: Utime.struct_timeval; (* user time used *) ru_stime: Utime.struct_timeval; (* system time used *) ru_maxrss: long; ru_ixrss: long; (* integral shared text size *) (* Unsupported in Linux 1.0: ru_ismrss: long; (* integral shared memory size*) ******************************) kind of makes you wonder....when the FreeBSD path has stuff commented out because Linux 1.0 doesn't support it, which parts are correct? And is it still correct in FreeBSD 5, 6, 7, 9, 10? (Did it get copied blindly to other directoryes, like maybe Darwin?) I guess the only client used utime and stime (based on the code in the Attic). Mistakes here -- such as commenting out fields that are actually there -- would generally result in stack corruption, which might be ok, on some days, on some systems, with some compilers, with some compiler flags, depending on what is nearby on the stack, and what it gets overwritten with. Very dangerous stuff.. For Win32, lookup GetProcessTimes and GetThreadTimes. getrlimit doesn't look so problematic, at least based on the FreeBSD4 version. (Something is really weird with mail encoding, could be me, using a variety of modern mail clients..) - Jay > To: jay.krell at cornell.edu > Date: Fri, 24 Apr 2009 23:32:29 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Uresource on freebsd 4? > > > I use it for timing programs (getrusage). Is there another way of > doing that in Modula-3? > > This declaration: > > <*EXTERNAL*> PROCEDURE getrusage (who: int; VAR rus: struct_rusage): int; > > I'm sure getrlimit is useful too. > > These things have been in Modula-3 for a long time... > > It's the only thing that's missing that I personally use. Except > for some disturbances in m3tk things are now compiling for me... > > Mika > > > Jay writes: > >--_55ac72c8-d027-4bd6-a303-434a73dcc5db_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Do you need it? > > > >Is there a sufficient common/Uresource.i3? > > > >=20 > > > >I generally removed whatever isn't used=2C and made the remainders portable= > >. > > > >I can look into restoring more=2C but what do you need and what is there? (= > >I can look.) > > > >=20 > > > >=20 > > > > - Jay > > > >=20 > >> To: m3devel at elegosoft.com > >> Date: Fri=2C 24 Apr 2009 22:58:23 -0700 > >> From: mika at async.caltech.edu > >> CC: mika at camembert.async.caltech.edu > >> Subject: [M3devel] Uresource on freebsd 4? > >>=20 > >>=20 > >> Is there any particular reason Uresource no longer exists on FreeBSD4? > >> The m3makefile > >>=20 > >> m3core/src/unix/freebsd-4/m3makefile > >>=20 > >> looks like the following=2C and Uresource isn't picked up anywhere else: > >>=20 > >> if TRUE > >>=20 > >> Module ("Usignal") > >> Interface ("Uucontext") > >>=20 > >> else > >>=20 > >> Interface ("Udir") > >> Interface ("Uerror") > >> %Interface ("Ugrp") > >> Interface ("Uipc") > >> Interface ("Umman") > >> Module ("Umsg") > >> Interface ("Unix") > >> Interface ("Uprocess") > >> Interface ("Upthread") > >> Interface ("Upwd") > >> Interface ("Uresource") > >> Interface ("Usem") > >> Interface ("Usched") > >> Interface ("Ushm") > >> Module ("Usignal") > >> Interface ("Ustat") > >> Interface ("Usocket") > >> Interface ("Usyslog") > >> Interface ("Utime") > >> Module ("Utypes") > >> Interface ("Uucontext") > >> Interface ("Uugid") > >> Interface ("Uuio") > >> Interface ("Uutsname") > >>=20 > >> end > >>=20 > > > >--_55ac72c8-d027-4bd6-a303-434a73dcc5db_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > >Do you need it?
> >Is there a sufficient common/Uresource.i3?
> > =3B
> >I generally removed whatever isn't used=2C and made the remainders portable= > >.
> >I can look into restoring more=2C but what do you need and what is there? (= > >I can look.)
> > =3B
> > =3B
> > =3B- Jay

 =3B
>=3B To: m3devel at elegosoft.com
>=3B= > > Date: Fri=2C 24 Apr 2009 22:58:23 -0700
>=3B From: mika at async.caltech= > >.edu
>=3B CC: mika at camembert.async.caltech.edu
>=3B Subject: [M3d= > >evel] Uresource on freebsd 4?
>=3B
>=3B
>=3B Is there any = > >particular reason Uresource no longer exists on FreeBSD4?
>=3B The m3m= > >akefile
>=3B
>=3B m3core/src/unix/freebsd-4/m3makefile
>=3B= > >
>=3B looks like the following=2C and Uresource isn't picked up anywh= > >ere else:
>=3B
>=3B if TRUE
>=3B
>=3B Module ("Usigna= > >l")
>=3B Interface ("Uucontext")
>=3B
>=3B else
>=3B <= > >BR>>=3B Interface ("Udir")
>=3B Interface ("Uerror")
>=3B %Inte= > >rface ("Ugrp")
>=3B Interface ("Uipc")
>=3B Interface ("Umman") >R>>=3B Module ("Umsg")
>=3B Interface ("Unix")
>=3B Interface (= > >"Uprocess")
>=3B Interface ("Upthread")
>=3B Interface ("Upwd") >R>>=3B Interface ("Uresource")
>=3B Interface ("Usem")
>=3B Int= > >erface ("Usched")
>=3B Interface ("Ushm")
>=3B Module ("Usignal")= > >
>=3B Interface ("Ustat")
>=3B Interface ("Usocket")
>=3B In= > >terface ("Usyslog")
>=3B Interface ("Utime")
>=3B Module ("Utypes= > >")
>=3B Interface ("Uucontext")
>=3B Interface ("Uugid")
>= > >=3B Interface ("Uuio")
>=3B Interface ("Uutsname")
>=3B
>= > >=3B end
>=3B
> >= > > > >--_55ac72c8-d027-4bd6-a303-434a73dcc5db_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 25 10:01:12 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 08:01:12 +0000 Subject: [M3devel] Uresource on freebsd 4? In-Reply-To: <200904250632.n3P6WThS038574@camembert.async.caltech.edu> References: Your message of "Sat, 25 Apr 2009 06:14:28 -0000." <200904250632.n3P6WThS038574@camembert.async.caltech.edu> Message-ID: I should have read the docs first. http://www.opengroup.org/onlinepubs/000095399/basedefs/sys/resource.h.html Only guarantees ru_utime and ru_stime. So maybe a portable wrapper isn't such a bad idea, since it'd only copy back so little. The various time_t, struct timeval, struct tm, struct itimerval, are some of the only system-dependent code/types remaining but maybe I should have to live with them not going away. Maybe. Modula-3 does layer over all of these anyway so more "refactoring" can probably remove them all. (ie: pushing some of the wrapping up to libm3). But if that's adequate -- exposing just ru_utime and ru_stime, then so is probably the old RTProcessPosix. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] Uresource on freebsd 4? Date: Sat, 25 Apr 2009 07:52:31 +0000 Does something like this suffice? Seconds used by current process as a float (including sub-second resolution). http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/runtime/POSIX/Attic/RTProcessPosix.i3?rev=1.1;content-type=text%2Fplain http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/runtime/POSIX/Attic/RTProcessPosixC.c?rev=1.7;content-type=text%2Fplain Notice it is in Attic. If not, can you write your own similar? The full getrusage has that huge struct.. seems best to not expose the whole thing but have folks write little C wrappers for just what they need. A portable wrapper would copy out all the fields, for "all the fields" defined as all the ones implemented by all systems. Only to have most users probably ignore most of them. Notice the cruft: struct_rusage = RECORD ru_utime: Utime.struct_timeval; (* user time used *) ru_stime: Utime.struct_timeval; (* system time used *) ru_maxrss: long; ru_ixrss: long; (* integral shared text size *) (* Unsupported in Linux 1.0: ru_ismrss: long; (* integral shared memory size*) ******************************) kind of makes you wonder....when the FreeBSD path has stuff commented out because Linux 1.0 doesn't support it, which parts are correct? And is it still correct in FreeBSD 5, 6, 7, 9, 10? (Did it get copied blindly to other directoryes, like maybe Darwin?) I guess the only client used utime and stime (based on the code in the Attic). Mistakes here -- such as commenting out fields that are actually there -- would generally result in stack corruption, which might be ok, on some days, on some systems, with some compilers, with some compiler flags, depending on what is nearby on the stack, and what it gets overwritten with. Very dangerous stuff.. For Win32, lookup GetProcessTimes and GetThreadTimes. getrlimit doesn't look so problematic, at least based on the FreeBSD4 version. (Something is really weird with mail encoding, could be me, using a variety of modern mail clients..) - Jay > To: jay.krell at cornell.edu > Date: Fri, 24 Apr 2009 23:32:29 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Uresource on freebsd 4? > > > I use it for timing programs (getrusage). Is there another way of > doing that in Modula-3? > > This declaration: > > <*EXTERNAL*> PROCEDURE getrusage (who: int; VAR rus: struct_rusage): int; > > I'm sure getrlimit is useful too. > > These things have been in Modula-3 for a long time... > > It's the only thing that's missing that I personally use. Except > for some disturbances in m3tk things are now compiling for me... > > Mika > > > Jay writes: > >--_55ac72c8-d027-4bd6-a303-434a73dcc5db_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Do you need it? > > > >Is there a sufficient common/Uresource.i3? > > > >=20 > > > >I generally removed whatever isn't used=2C and made the remainders portable= > >. > > > >I can look into restoring more=2C but what do you need and what is there? (= > >I can look.) > > > >=20 > > > >=20 > > > > - Jay > > > >=20 > >> To: m3devel at elegosoft.com > >> Date: Fri=2C 24 Apr 2009 22:58:23 -0700 > >> From: mika at async.caltech.edu > >> CC: mika at camembert.async.caltech.edu > >> Subject: [M3devel] Uresource on freebsd 4? > >>=20 > >>=20 > >> Is there any particular reason Uresource no longer exists on FreeBSD4? > >> The m3makefile > >>=20 > >> m3core/src/unix/freebsd-4/m3makefile > >>=20 > >> looks like the following=2C and Uresource isn't picked up anywhere else: > >>=20 > >> if TRUE > >>=20 > >> Module ("Usignal") > >> Interface ("Uucontext") > >>=20 > >> else > >>=20 > >> Interface ("Udir") > >> Interface ("Uerror") > >> %Interface ("Ugrp") > >> Interface ("Uipc") > >> Interface ("Umman") > >> Module ("Umsg") > >> Interface ("Unix") > >> Interface ("Uprocess") > >> Interface ("Upthread") > >> Interface ("Upwd") > >> Interface ("Uresource") > >> Interface ("Usem") > >> Interface ("Usched") > >> Interface ("Ushm") > >> Module ("Usignal") > >> Interface ("Ustat") > >> Interface ("Usocket") > >> Interface ("Usyslog") > >> Interface ("Utime") > >> Module ("Utypes") > >> Interface ("Uucontext") > >> Interface ("Uugid") > >> Interface ("Uuio") > >> Interface ("Uutsname") > >>=20 > >> end > >>=20 > > > >--_55ac72c8-d027-4bd6-a303-434a73dcc5db_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > >Do you need it?
> >Is there a sufficient common/Uresource.i3?
> > =3B
> >I generally removed whatever isn't used=2C and made the remainders portable= > >.
> >I can look into restoring more=2C but what do you need and what is there? (= > >I can look.)
> > =3B
> > =3B
> > =3B- Jay

 =3B
>=3B To: m3devel at elegosoft.com
>=3B= > > Date: Fri=2C 24 Apr 2009 22:58:23 -0700
>=3B From: mika at async.caltech= > >.edu
>=3B CC: mika at camembert.async.caltech.edu
>=3B Subject: [M3d= > >evel] Uresource on freebsd 4?
>=3B
>=3B
>=3B Is there any = > >particular reason Uresource no longer exists on FreeBSD4?
>=3B The m3m= > >akefile
>=3B
>=3B m3core/src/unix/freebsd-4/m3makefile
>=3B= > >
>=3B looks like the following=2C and Uresource isn't picked up anywh= > >ere else:
>=3B
>=3B if TRUE
>=3B
>=3B Module ("Usigna= > >l")
>=3B Interface ("Uucontext")
>=3B
>=3B else
>=3B <= > >BR>>=3B Interface ("Udir")
>=3B Interface ("Uerror")
>=3B %Inte= > >rface ("Ugrp")
>=3B Interface ("Uipc")
>=3B Interface ("Umman") >R>>=3B Module ("Umsg")
>=3B Interface ("Unix")
>=3B Interface (= > >"Uprocess")
>=3B Interface ("Upthread")
>=3B Interface ("Upwd") >R>>=3B Interface ("Uresource")
>=3B Interface ("Usem")
>=3B Int= > >erface ("Usched")
>=3B Interface ("Ushm")
>=3B Module ("Usignal")= > >
>=3B Interface ("Ustat")
>=3B Interface ("Usocket")
>=3B In= > >terface ("Usyslog")
>=3B Interface ("Utime")
>=3B Module ("Utypes= > >")
>=3B Interface ("Uucontext")
>=3B Interface ("Uugid")
>= > >=3B Interface ("Uuio")
>=3B Interface ("Uutsname")
>=3B
>= > >=3B end
>=3B
> >= > > > >--_55ac72c8-d027-4bd6-a303-434a73dcc5db_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 25 10:12:23 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 08:12:23 +0000 Subject: [M3devel] FW: Uresource on freebsd 4? In-Reply-To: <200904250632.n3P6WThS038574@camembert.async.caltech.edu> References: Your message of "Sat, 25 Apr 2009 06:14:28 -0000." <200904250632.n3P6WThS038574@camembert.async.caltech.edu> Message-ID: was slightly truncated: >> But if that's adequate -- exposing just ru_utime and ru_stime, then so is probably the old RTProcessPosix. The Linux/*BSD struct rusage documentation suggests they are all identical, so I admit, I was crying wolf/fire without knowing. But Solaris 2.9 documentation suggests ours is/was wrong, but I haven't really checked. It is fairly moot now anyway, unless someone really wants getrusage restored along with its full struct. Surely the options of a) do nothing b) restore RTProcessPosix c) add a new safe/copying wrapper that only return ru_[us]time are more likely.. [truncated deliberatley] -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 25 10:41:20 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 08:41:20 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <200904250338.n3P3cHlc030469@camembert.async.caltech.edu> References: Your message of "Fri, 24 Apr 2009 22:40:41 -0000." <200904250338.n3P3cHlc030469@camembert.async.caltech.edu> Message-ID: > Jay, your assembly worked too! And as you say, it's much easier to As an /experiment/ you might try building that assembly yourself? First you need to cd to m3cc and cm3 -DM3CC_TARGET=foo. My config files probe around for the correct seeming m3cg and use it. And then scripts/python/boot1.py foo. The point of the "experiment" would be see if anyone else can produce these "bootstrap" archives, as a possible first toward elevating their status -- ie: using them as a form of distribution. But not clear if they should be or not -- to what extent os /version/ is a problem and to what extent it should be dealt with, and if that should be via building on the various hosts or these "bootstrap" archives, or something else. You know, ideally, maybe, given time/energy, there'd be regulary produced (daily) "bootstrap" archives for "all" the platforms, "min", and "std". Including maybe even a cm3cg..though that cm3cg would be "Canadian" and seems maybe a dubious thing to depend on working regularly. So, while we might output binary distributions for various "current" platforms, these could be fallbacks for other older/newer versions. As well, esp. if the Canadian cm3cg worked out, these could even be the real distributions -- benefit being that they can all be cross built from one or a few machines -- without having to automate each host platform. Though maybe that's too much to do on one machine. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Apr 26 06:49:38 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Apr 2009 14:49:38 +1000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: References: Your message of "Fri, 24 Apr 2009 22:40:41 -0000." <200904242305.n3ON56IS018186@camembert.async.caltech.edu> Message-ID: <2D59910B-DD11-406E-BA79-C0891F4D7260@cs.purdue.edu> On 25 Apr 2009, at 09:21, Jay wrote: > >> By the way, I take it booting the compiler "old-fashionedly" with >> PM3 is out of the question? > > > What is the PM3 way? > The SRC way is out of the question at least (unless you want to / > start/ with it and go through a few releases...). > > I gather that the PM3 was good and could be resusitated. > But it is is some work..maybe too much. > > I gather that PM3 factored out word size and endianness from the IL? > And padding/alignment? And jmpbuf size? Nope. Same as cm3. > > And whatever else is target-dependent? > There isn't much. > Not impossible, but seems a bit onerous. > > padding/alignment actually don't have to be factored out, kind of. > They can be made "worst case", as long as the interactions with C > are correct. > > word size and endianness are in the IL but I think only barely. > > jmpbuf size is easy to factor out at a small perf cost. > or again, make it worst case. > > > These "worst cases" are likely to be pretty bad, such that they are > ok for building the first compiler, but then you'd want to > immediately rebuild it "ideally". > jmpbuf size varies from around 16 bytes to over 200 bytes for example. > You could also use > extern int jmpbufsize; > jmpbuf = alloca(jmpbufsize) > > > thereby not blowing stack, but still being slow. > Again, fine for bootstrap purposes but it should end there. > > > "aligned procedures" can be factored out easily via acting worst case. > > > Is this what PM3 did though? > Shipped one textual IL for all platforms, built m3cc (which doesn't / > really/ > require having cm3), then built everything from the portable IL, > then rebuilt it all again more ideally? > > I think if a portable distribution format is to be had, maybe go all > the way to using a C backend? However that doesn't solve all/many/ > any of the above problems, given how low level the IL is. > > > - Jay From hosking at cs.purdue.edu Sun Apr 26 06:51:45 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Apr 2009 14:51:45 +1000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: References: Your message of "Fri, 24 Apr 2009 22:40:41 -0000." <200904250338.n3P3cHlc030469@camembert.async.caltech.edu> Message-ID: Broken mostly because updated libraries detect forging of thread contexts (state) for security reasons and blow up. On 25 Apr 2009, at 14:12, Jay wrote: > Cool. > > > If I use user threads, it's a different story (which is probably > too bad, > > Oops, right, I forgot, I should have mentioned that, user threads > have likely been broken on all platforms for a while. I noticed that > on PPC_LINUX. I think it is trivial to fix. Or use pthreads.. > > > - Jay > > > > To: jay.krell at cornell.edu > > Date: Fri, 24 Apr 2009 20:38:17 -0700 > > From: mika at async.caltech.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] help booting CM3 on FreeBSD 4.11? > > > > Jay (and others), > > > > Success! I think.... I was able to build the compiler, after much > > experimentation, by using Jay's build order and linking with - > libc_r. > > Mentor works, and that's usually a good sign. > > > > Jay, your assembly worked too! And as you say, it's much easier to > > bootstrap with that than to do what I was trying to do (but I did > > both, several times, just to make sure). > > > > I don't know why I was having linking problems with -libc_r earlier. > > Now it just seems to work. So, pthreads on FreeBSD 4. > > > > If I use user threads, it's a different story (which is probably > too bad, > > as I know that user threads work absolutely fine in my old version > of CM3): > > > > I can build a compiler fine, but the bootstrapped cm3 crashes in > > the user thread code. Note that exactly the same thing happens > whether > > I bootstrap with the assembly version from Jay or from v. 5.3.4, > which > > I think is what I had. Here we go: > > > > Starting program: /usr/local/cm3/pkg/cm3/FreeBSD4/cm3 > > > > Program received signal SIGSEGV, Segmentation fault. > > 16_82568bb in RTHooks.PushEFrame (frame=16_bfbff3f4) at ../src/ > thread/POSIX/ThreadPosix.m3:1599 > > 1599 f.next := self.context.handlers; > > (gdb) where > > #0 16_82568bb in RTHooks.PushEFrame (frame=16_bfbff3f4) at ../src/ > thread/POSIX/ThreadPosix.m3:1599 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Apr 26 07:22:00 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 25 Apr 2009 22:22:00 -0700 Subject: [M3devel] Performance issues with CM3 Message-ID: <200904260522.n3Q5M01a000401@camembert.async.caltech.edu> Hello again, Now I've managed to get all the code up and running under CM3. I found and committed fixes to a bug in Wx and some code in one of the m3tk libraries that looked like it never was finished in the first place. As I mentioned earlier, I wasn't able to get user threads working in CM3 on FreeBSD 4.11. But with some help from Jay, I was able to get things working with libc_r. Performance, unfortunately, leaves something to be desired. For the first time I've been able to compare timings on identical hardware between the PM3 I was using and the CM3 that's out now. Note that optimization doesn't seem to work..? (Not even -O, much less -O3... the compiler segfaults.) Here's what I get, using no optimization either in PM3 or CM3. The test is my Scheme interpreter generating SQL and Modula-3 code (a bit like the Hibernate system you can get for Java): CPU seconds CM3 PM3 First version 5.269 1.366 Fewer NEWs 2.039 0.440 (code cleanup on my part) TYPECASE hack 1.770 (see below) Some "poor man's profiling" (i.e., ctrl-C'ing in m3gdb) suggests that most of the time is spent either in threading code (this could just be a lousy implementation in libc_r), the garbage collector, or in "ScanTypecase". The only one of these routines I am qualified to do anything about is ScanTypecase. I don't know why the Critical Mass people... .. all over this code. I assume it has something to do with Java. The PM3 code (from SRC?) has this wonderful, concise, efficient bit: PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = VAR t := Get (b); BEGIN IF (a >= RT0u.nTypes) THEN BadType (a) END; IF (a = 0) THEN RETURN TRUE END; RETURN (t.typecode <= a AND a <= t.lastSubTypeTC); END IsSubtype; replaced with the following absolute abomination in CM3: PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = VAR t: RT0.TypeDefn; BEGIN IF (a = RT0.NilTypecode) THEN RETURN TRUE END; t := Get (a); IF (t = NIL) THEN RETURN FALSE; END; IF (t.typecode = b) THEN RETURN TRUE END; WHILE (t.kind = ORD (TK.Obj)) DO IF (t.link_state = 0) THEN FinishTypecell (t, NIL); END; t := LOOPHOLE (t, RT0.ObjectTypeDefn).parent; IF (t = NIL) THEN RETURN FALSE; END; IF (t.typecode = b) THEN RETURN TRUE; END; END; IF (t.traced # 0) THEN RETURN (b = RT0.RefanyTypecode); ELSE RETURN (b = RT0.AddressTypecode); END; END IsSubtype; Furthermore, CM3 has a hook for "ScanTypecase" that's missing in PM3 (the older compiler actually generates code for this): PROCEDURE ScanTypecase (ref: REFANY; x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; BEGIN IF (ref = NIL) THEN RETURN 0; END; tc := TYPECODE (ref); p := x; i := 0; LOOP IF (p.uid = 0) THEN RETURN i; END; IF (p.defn = NIL) THEN p.defn := FindType (p.uid); IF (p.defn = NIL) THEN Fail (RTE.MissingType, RTModule.FromDataAddress(x), LOOPHOLE (p.uid, ADDRESS), NIL); END; END; xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; IF (tc = xc) OR IsSubtype (tc, xc) THEN RETURN i; END; INC (p, ADRSIZE (p^)); INC (i); END; END ScanTypecase; Where to begin? A loop with all kinds of runtime checks of properties that are supposedly known at compile time? IsSubtype (itself a loop) called from inside the loop? I was able to cut out almost all of the typecase activity from my program by using the following code in RTType.m3, which depends on the ADDRESS x never changing (well more specifically never being the same for two TYPECASE statements): TYPE TypeCaseResult = RECORD x : ADDRESS; tc : Typecode; arm : INTEGER; END; CONST TCCachePow = 6; TCCacheSize = Word.Shift(1,TCCachePow); TCMask = TCCacheSize-1; VAR TCCache := ARRAY [0..TCCacheSize-1] OF TypeCaseResult { TypeCaseResult { LOOPHOLE(0,ADDRESS), 0, -1 } , .. }; (* VAR tcScans := 0; tcHits := 0; (* instrumenting counters *) *) PROCEDURE ScanTypecase (ref: REFANY; x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; BEGIN tc := TYPECODE (ref); IF (ref = NIL) THEN RETURN 0; END; WITH hash = Word.And(Word.Times(tc, Word.RightShift(LOOPHOLE(x,Word.T),2)), TCMask), entry = TCCache[hash] DO (*INC(tcScans);*) IF entry.x = x AND entry.tc = tc THEN (*INC(tcHits);*) RETURN entry.arm END; p := x; i := 0; LOOP IF (p.uid = 0) THEN entry.x := x; entry.tc := tc; entry.arm := i; RETURN i; END; IF (p.defn = NIL) THEN p.defn := FindType (p.uid); IF (p.defn = NIL) THEN Fail (RTE.MissingType, RTModule.FromDataAddress(x), LOOPHOLE (p.uid, ADDRESS), NIL); END; END; xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; IF (tc = xc) OR IsSubtype (tc, xc) THEN entry.x := x; entry.tc := tc; entry.arm := i; RETURN i; END; INC (p, ADRSIZE (p^)); INC (i); END; END; END ScanTypecase; I'm guessing the speedup for TYPECASE itself is a factor of at least ten. But it's still a pretty nasty hack. And there is still a lot of IsSubtype activity from narrowing. I suppose that the way the typecodes are generated in CM3 is sufficiently different (meant to be extended at runtime?) from how it was done in PM3 that one can't really go back to the old code. Cardelli's idea of keeping an array of parents up to ROOT plus a "depth" for each type might have merit, though. To see if a is a subtype of b, something like: b = a.ancestors[a.depth-b.depth-1] (* with appropriate range checks *) Would this be easy to put in? I'm not sure how one can be sure that typecodes are done being generated? There's something called RTTypeSRC.FinishObjectTypes .. And PM3 still generates code that's four times faster. Mika From mika at async.caltech.edu Sun Apr 26 07:28:25 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 25 Apr 2009 22:28:25 -0700 Subject: [M3devel] Confusing, but non-critical bug... Message-ID: <200904260528.n3Q5SPcu000732@camembert.async.caltech.edu> So I have a library, built against m3tk. Everything compiles, but when cm3 tries to "ar" the library: new "TypeTranslator.io" -> archiving libsstubgen.a Fatal Error: incomplete library missing compiled interface "M3AST_all.io" imported by: M3AST_SM_F.i3 M3AST_PG.m3 M3AST_SM.m3 TypeNames.m3 AstToVal.m3 AstToType.m3 M3ASTScopeNames.m3 M3AST_PG_M.i3: missing object types: _t1ee311ce imported by: M3AST_PG.m3 M3AST_all.i3: missing object types: _t8eb32ef8 _t9ffde2a4 _ta2581bcc _t52bfa811 _t249b6ddc _t172a75ba _t774a90ea _tc92a7e8c _t1d23b703 _t2812849 _t1796950e _te47b91c _tccbf0da _tb53c334a _tf38721e4 _tbbcfc2cb _teec6ca97 imported by: M3AST_PG.m3 AstToType.m3 AstToVal.m3 M3AST_SM.m3 M3AST_SM_F.i3 missing compiled interface "M3AST_PG_M.io" imported by: M3AST_PG.m3 seconds #times operation 0.06 22 inhaling library link info 0.01 27 checking old link info 0.21 896 merging new link info 0.05 4 garbage collection --------------------------------------------------- 0.34 TOTAL rm m3make.args cd ../src So I add "IMPORT M3AST_all;" to one of my interfaces (it's not used there at all): (1943)trs80:~/t-cm3/mscheme/sstubgen/src>cm3 -x --- building in ../FreeBSD4 --- ignoring override("sstubgen", "/home/mika/t-cm3/mscheme") new source -> compiling TypeTranslator.i3 "../src/TypeTranslator.i3", line 12: warning: not used (M3AST_all) 1 warning encountered new source -> compiling TypeTranslator.m3 "../src/TypeTranslator.m3", line 353: warning: not used (Add) 1 warning encountered new opaque info -> recompiling TypeTranslator.m3 "../src/TypeTranslator.m3", line 353: warning: not used (Add) 1 warning encountered new "TypeTranslator.io" -> archiving libsstubgen.a (1944)trs80:~/t-cm3/mscheme/sstubgen/src> Hmmmmmmmmmmmmm....... is anyone interested in looking at this? As I said, it's non-critical (I can get things working, clearly, even with the bug present), but it's very confusing. I have to import an interface I'm not using...why? Where to begin looking? Mika From mika at async.caltech.edu Sun Apr 26 07:30:01 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 25 Apr 2009 22:30:01 -0700 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: Your message of "Sat, 25 Apr 2009 22:28:05 PDT." <0FB5E4EA-571C-4CB9-8606-92F12B91A40B@gmail.com> Message-ID: <200904260530.n3Q5U1NE000824@camembert.async.caltech.edu> User threads certainly work fine on this machine (see my previous email) with PM3... some would say they work "better"... :-) Jay writes: > >--Apple-Mail-1-423481883 >Content-Type: text/plain; > charset=us-ascii; > format=flowed; > delsp=yes >Content-Transfer-Encoding: 7bit > >I think also due to simple use before init. > > - Jay (phone) > >On Apr 25, 2009, at 9:51 PM, Tony Hosking wrote: > >> Broken mostly because updated libraries detect forging of thread >> contexts (state) for security reasons and blow up. >> >> On 25 Apr 2009, at 14:12, Jay wrote: >> >>> Cool. >>> >>> > If I use user threads, it's a different story (which is probably >>> too bad, >>> >>> Oops, right, I forgot, I should have mentioned that, user threads >>> have likely been broken on all platforms for a while. I noticed >>> that on PPC_LINUX. I > > >--Apple-Mail-1-423481883 >Content-Type: text/html; > charset=utf-8 >Content-Transfer-Encoding: quoted-printable > >
I think also due to simple use = >before init.

 - Jay (phonestyle=3D"-webkit-composition-fill-color: rgba(175, 192, 227, 0.231373); = >-webkit-composition-frame-color: rgba(77, 128, 180, 0.231373); = >">)

On Apr 25, 2009, at 9:51 PM, Tony Hosking = ><hosking at cs.purdue.edu> = >wrote:

apple-content-edited=3D"true">style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >normal; font-variant: normal; font-weight: normal; letter-spacing: = >normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; = >-khtml-line-break: after-white-space; ">style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >normal; font-variant: normal; font-weight: normal; letter-spacing: = >normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">Broken mostly = >because updated libraries detect forging of thread contexts (state) for = >security reasons and blow up.

On = >25 Apr 2009, at 14:12, Jay wrote:

class=3D"Apple-interchange-newline">
class=3D"Apple-style-span" style=3D"border-collapse: separate; color: = >rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >normal; font-variant: normal; font-weight: normal; letter-spacing: = >normal; line-height: normal; orphans: 2; text-align: auto; text-indent: = >0px; text-transform: none; white-space: normal; widows: 2; word-spacing: = >0px; -webkit-border-horizontal-spacing: 0px; = >-webkit-border-vertical-spacing: 0px; = >-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = >auto; -webkit-text-stroke-width: 0; ">
style=3D"font-size: 10pt; font-family: Verdana; = >">Cool.
 
 > If I use user threads, it's a different = >story (which is probably too bad,

Oops, right, I forgot, I should = >have mentioned that, user threads have likely been broken on all = >platforms for a while. I noticed that on PPC_LINUX. = >I

= > >--Apple-Mail-1-423481883-- From mika at async.caltech.edu Sun Apr 26 07:33:08 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 25 Apr 2009 22:33:08 -0700 Subject: [M3devel] FW: Uresource on freebsd 4? In-Reply-To: Your message of "Sat, 25 Apr 2009 08:12:23 -0000." Message-ID: <200904260533.n3Q5X8UW001003@camembert.async.caltech.edu> As far as I'm concerned, I've sucked in all the Uresource junk into interfaces inside my own application, so forget I said anything about it. (One day when I'm ambitious (or get weird segfaults!), I'll write the C wrappers; for now they're just copies of the old PM3 interfaces..) Mika Jay writes: >--_c686b76c-f145-4c40-913c-ad76373e06f4_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >was slightly truncated: > >=20 > > >> But if that's adequate -- exposing just ru_utime and ru_stime=2C then s= >o is probably the old RTProcessPosix. > > > >The Linux/*BSD struct rusage documentation suggests they are all identical= >=2C so I admit=2C I was crying wolf/fire without knowing. > >But Solaris 2.9 documentation suggests ours is/was wrong=2C but I haven't r= >eally checked. > >It is fairly moot now anyway=2C unless someone really wants getrusage resto= >red along with its full struct. Surely the options of a) do nothing b) rest= >ore RTProcessPosix c) add a new safe/copying wrapper that only return ru_[u= >s]time are more likely.. > >=20 > >=20 > > [truncated deliberatley]=20 > >--_c686b76c-f145-4c40-913c-ad76373e06f4_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >was slightly truncated:
> =3B
> =3B>=3B>=3B But if that's adequate -- exposing just ru_utime and r= >u_stime=2C then so is probably the old RTProcessPosix.


>The Linux/*BSD struct rusage documentation suggests they are all identical= >=2C so I admit=2C I was crying wolf/fire without knowing.
>But =3BSolaris 2.9 documentation suggests =3Bours is/was wrong=2C b= >ut I haven't really checked.
>It is fairly moot now anyway=2C unless someone really wants getrusage resto= >red along with its full struct. Surely the options of a) do nothing b) rest= >ore RTProcessPosix c) add a new =3Bsafe/copying wrapper that only retur= >n ru_[us]time are more likely..
> =3B
> =3B
> =3B[truncated deliberatley]
>= > >--_c686b76c-f145-4c40-913c-ad76373e06f4_-- From jay.krell at cornell.edu Sun Apr 26 07:37:04 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 22:37:04 -0700 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <2D59910B-DD11-406E-BA79-C0891F4D7260@cs.purdue.edu> References: Your message of "Fri, 24 Apr 2009 22:40:41 -0000." <200904242305.n3ON56IS018186@camembert.async.caltech.edu> <2D59910B-DD11-406E-BA79-C0891F4D7260@cs.purdue.edu> Message-ID: <3BD2A0FC-BDA0-4C43-A229-B8E042E76BA6@gmail.com> Oh phew. Someone said they played tricks with il, so I thought of beneficial but difficult tricks. Um but what is the CM3 way?(somewhat rhetorical..must stop,see signature..) - Jay (phone!) On Apr 25, 2009, at 9:49 PM, Tony Hosking wrote: > > On 25 Apr 2009, at 09:21, Jay wrote: > >> >>> By the way, I take it booting the compiler "old-fashionedly" with >>> PM3 is out of the question? >> >> >> What is the PM3 way? >> The SRC way is out of the question at least (unless you want to / >> start/ with it and go through a few releases...). >> >> I gather that the PM3 was good and could be resusitated. >> But it is is some work..maybe too much. >> >> I gather that PM3 factored out word size and endianness from the IL? >> And padding/alignment? And jmpbuf size? > > Nope. Same as cm3. > >> >> And whatever else is target-dependent? >> There isn't much. >> Not impossible, but seems a bit onerous. >> >> >> >> >> >> >> >> >> >> >> >> >> >> From jay.krell at cornell.edu Sun Apr 26 07:28:05 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 22:28:05 -0700 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: References: Your message of "Fri, 24 Apr 2009 22:40:41 -0000." <200904250338.n3P3cHlc030469@camembert.async.caltech.edu> Message-ID: <0FB5E4EA-571C-4CB9-8606-92F12B91A40B@gmail.com> I think also due to simple use before init. - Jay (phone) On Apr 25, 2009, at 9:51 PM, Tony Hosking wrote: > Broken mostly because updated libraries detect forging of thread > contexts (state) for security reasons and blow up. > > On 25 Apr 2009, at 14:12, Jay wrote: > >> Cool. >> >> > If I use user threads, it's a different story (which is probably >> too bad, >> >> Oops, right, I forgot, I should have mentioned that, user threads >> have likely been broken on all platforms for a while. I noticed >> that on PPC_LINUX. I -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 26 07:40:34 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 22:40:34 -0700 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <200904260530.n3Q5U1NE000824@camembert.async.caltech.edu> References: <200904260530.n3Q5U1NE000824@camembert.async.caltech.edu> Message-ID: <09E195AF-2D6E-4A76-9328-DC4F29049719@gmail.com> It is easy to fix for many non Linux systems.and possible for Linux. Fairly well worn topic. - Jay (phone) On Apr 25, 2009, at 10:30 PM, Mika Nystrom wrote: > User threads certainly work fine on this machine (see my previous > email) with PM3... some would say they work "better"... :-) > > Jay writes: >> >> --Apple-Mail-1-423481883 >> Content-Type: text/plain; >> charset=us-ascii; >> format=flowed; >> delsp=yes >> Content-Transfer-Encoding: 7bit >> >> I think also due to simple use before init. >> >> - Jay (phone) >> >> On Apr 25, 2009, at 9:51 PM, Tony Hosking >> wrote: >> >>> Broken mostly because updated libraries detect forging of thread >>> contexts (state) for security reasons and blow up. >>> >>> On 25 Apr 2009, at 14:12, Jay wrote: >>> >>>> Cool. >>>> >>>>> If I use user threads, it's a different story (which is probably >>>> too bad, >>>> >>>> Oops, right, I forgot, I should have mentioned that, user threads >>>> have likely been broken on all platforms for a while. I noticed >>>> that on PPC_LINUX. I >> >> >> --Apple-Mail-1-423481883 >> Content-Type: text/html; >> charset=utf-8 >> Content-Transfer-Encoding: quoted-printable >> >>
I think also due to simple use = >> before init.

 - Jay (phone> span" = >> style=3D"-webkit-composition-fill-color: rgba(175, 192, 227, >> 0.231373); = >> -webkit-composition-frame-color: rgba(77, 128, 180, 0.231373); = >> ">)

On Apr 25, 2009, at 9:51 PM, Tony Hosking = >> <hosking at cs.purdue.edu> a>> = >> wrote:

> apple-content-edited=3D"true">> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >> normal; font-variant: normal; font-weight: normal; letter-spacing: = >> normal; line-height: normal; text-align: auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">
> style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; = >> -khtml-line-break: after-white-space; ">> span" = >> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >> normal; font-variant: normal; font-weight: normal; letter-spacing: = >> normal; line-height: normal; text-align: auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">Broken mostly = >> because updated libraries detect forging of thread contexts (state) >> for = >> security reasons and blow up.
 > div>
On = >> 25 Apr 2009, at 14:12, Jay wrote:

> class=3D"Apple-interchange-newline">
> class=3D"Apple-style-span" style=3D"border-collapse: separate; >> color: = >> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >> normal; font-variant: normal; font-weight: normal; letter-spacing: = >> normal; line-height: normal; orphans: 2; text-align: auto; text- >> indent: = >> 0px; text-transform: none; white-space: normal; widows: 2; word- >> spacing: = >> 0px; -webkit-border-horizontal-spacing: 0px; = >> -webkit-border-vertical-spacing: 0px; = >> -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = >> auto; -webkit-text-stroke-width: 0; ">
> style=3D"font-size: 10pt; font-family: Verdana; = >> ">Cool.
 
 > If I use user threads, it's a >> different = >> story (which is probably too bad,

Oops, right, I forgot, I >> should = >> have mentioned that, user threads have likely been broken on all = >> platforms for a while. I noticed that on PPC_LINUX. = >> I

> body>= >> >> --Apple-Mail-1-423481883-- From jay.krell at cornell.edu Sun Apr 26 07:46:05 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 22:46:05 -0700 Subject: [M3devel] FW: Uresource on freebsd 4? In-Reply-To: <200904260533.n3Q5X8UW001003@camembert.async.caltech.edu> References: <200904260533.n3Q5X8UW001003@camembert.async.caltech.edu> Message-ID: <818A2D47-EEB1-4EFB-B779-8237076A4C89@gmail.com> Cool. But reasonable imho to see your code and restore rtprocessposix if it suffices.. Or maybe other. Double check what you have, it is dangerous. - Jay (phone) On Apr 25, 2009, at 10:33 PM, Mika Nystrom wrote: > > As far as I'm concerned, I've sucked in all the Uresource junk into > interfaces inside my own application, so forget I said anything > about it. (One day when I'm ambitious (or get weird segfaults!), > I'll write the C wrappers; for now they're just copies of the old > PM3 interfaces..) > > Mika > > Jay writes: >> >> >> >> >> >> >> >> >> >> From hosking at cs.purdue.edu Sun Apr 26 10:54:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Apr 2009 18:54:57 +1000 Subject: [M3devel] Performance issues with CM3 In-Reply-To: <200904260522.n3Q5M01a000401@camembert.async.caltech.edu> References: <200904260522.n3Q5M01a000401@camembert.async.caltech.edu> Message-ID: On 26 Apr 2009, at 15:22, Mika Nystrom wrote: > > Hello again, > > Now I've managed to get all the code up and running under CM3. I > found and committed fixes to a bug in Wx and some code in one of > the m3tk libraries that looked like it never was finished in the > first place. > > As I mentioned earlier, I wasn't able to get user threads working > in CM3 on FreeBSD 4.11. But with some help from Jay, I was able to > get things working with libc_r. Performance, unfortunately, > leaves something to be desired. > > For the first time I've been able to compare timings on identical > hardware between the PM3 I was using and the CM3 that's out now. > > Note that optimization doesn't seem to work..? (Not even -O, much > less -O3... the compiler segfaults.) Are you passing -gstabs? It should not segfault on -O3 - this is a regression if it does. > Here's what I get, using no optimization either in PM3 or CM3. The > test is my Scheme interpreter generating SQL and Modula-3 code > (a bit like the Hibernate system you can get for Java): > > > CPU seconds CM3 PM3 > First version 5.269 1.366 > Fewer NEWs 2.039 0.440 (code cleanup on my part) > TYPECASE hack 1.770 (see below) > > Some "poor man's profiling" (i.e., ctrl-C'ing in m3gdb) suggests that > most of the time is spent either in threading code (this could just > be a lousy implementation in libc_r), the garbage collector, or in > "ScanTypecase". > > The only one of these routines I am qualified to do anything about is > ScanTypecase. I don't know why the Critical Mass people... colorful > language can one use on m3devel?>.. all over this code. I assume it > has > something to do with Java. > > The PM3 code (from SRC?) has this wonderful, concise, efficient bit: > > PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = > VAR t := Get (b); > BEGIN > IF (a >= RT0u.nTypes) THEN BadType (a) END; > IF (a = 0) THEN RETURN TRUE END; > RETURN (t.typecode <= a AND a <= t.lastSubTypeTC); > END IsSubtype; > > replaced with the following absolute abomination in CM3: > > PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = > VAR t: RT0.TypeDefn; > BEGIN > IF (a = RT0.NilTypecode) THEN RETURN TRUE END; > t := Get (a); > IF (t = NIL) THEN RETURN FALSE; END; > IF (t.typecode = b) THEN RETURN TRUE END; > WHILE (t.kind = ORD (TK.Obj)) DO > IF (t.link_state = 0) THEN FinishTypecell (t, NIL); END; > t := LOOPHOLE (t, RT0.ObjectTypeDefn).parent; > IF (t = NIL) THEN RETURN FALSE; END; > IF (t.typecode = b) THEN RETURN TRUE; END; > END; > IF (t.traced # 0) > THEN RETURN (b = RT0.RefanyTypecode); > ELSE RETURN (b = RT0.AddressTypecode); > END; > END IsSubtype; This is all to support dynamic loading of libraries. > Furthermore, CM3 has a hook for "ScanTypecase" that's missing > in PM3 (the older compiler actually generates code for this): > > PROCEDURE ScanTypecase (ref: REFANY; > x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = > VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; > BEGIN > IF (ref = NIL) THEN RETURN 0; END; > tc := TYPECODE (ref); > p := x; i := 0; > LOOP > IF (p.uid = 0) THEN RETURN i; END; > IF (p.defn = NIL) THEN > p.defn := FindType (p.uid); > IF (p.defn = NIL) THEN > Fail (RTE.MissingType, RTModule.FromDataAddress(x), > LOOPHOLE (p.uid, ADDRESS), NIL); > END; > END; > xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; > IF (tc = xc) OR IsSubtype (tc, xc) THEN RETURN i; END; > INC (p, ADRSIZE (p^)); INC (i); > END; > END ScanTypecase; > > Where to begin? A loop with all kinds of runtime checks of properties > that are supposedly known at compile time? IsSubtype (itself a loop) > called from inside the loop? Not if dynamically loaded! > I was able to cut out almost all of the typecase activity from my > program by using the following code in RTType.m3, which depends on > the ADDRESS x never changing (well more specifically never being > the same for two TYPECASE statements): > > TYPE > TypeCaseResult = RECORD > x : ADDRESS; > tc : Typecode; > arm : INTEGER; > END; > > CONST > TCCachePow = 6; > TCCacheSize = Word.Shift(1,TCCachePow); > TCMask = TCCacheSize-1; > > VAR TCCache := ARRAY [0..TCCacheSize-1] OF TypeCaseResult { > TypeCaseResult { LOOPHOLE(0,ADDRESS), 0, -1 } , > .. > }; > > (* > VAR tcScans := 0; tcHits := 0; (* instrumenting counters *) > *) > > PROCEDURE ScanTypecase (ref: REFANY; > x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = > VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; > BEGIN > tc := TYPECODE (ref); > IF (ref = NIL) THEN RETURN 0; END; > > WITH hash = Word.And(Word.Times(tc, > > Word.RightShift(LOOPHOLE(x,Word.T),2)), > TCMask), > entry = TCCache[hash] DO > (*INC(tcScans);*) > IF entry.x = x AND entry.tc = tc THEN > (*INC(tcHits);*) > RETURN entry.arm > END; > > p := x; i := 0; > LOOP > IF (p.uid = 0) THEN entry.x := x; entry.tc := tc; > entry.arm := i; RETURN i; END; > IF (p.defn = NIL) THEN > p.defn := FindType (p.uid); > IF (p.defn = NIL) THEN > Fail (RTE.MissingType, RTModule.FromDataAddress(x), > LOOPHOLE (p.uid, ADDRESS), NIL); > END; > END; > xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; > IF (tc = xc) OR IsSubtype (tc, xc) THEN entry.x := x; > entry.tc := tc; entry.arm := i; RETURN i; END; > INC (p, ADRSIZE (p^)); INC (i); > END; > END; > END ScanTypecase; > > I'm guessing the speedup for TYPECASE itself is a factor of at least > ten. But it's still a pretty nasty hack. And there is still a lot > of IsSubtype activity from narrowing. > > I suppose that the way the typecodes are generated in CM3 is > sufficiently different (meant to be extended at runtime?) from how > it was done in PM3 that one can't really go back to the old code. > Cardelli's idea of keeping an array of parents up to ROOT plus a > "depth" for each type might have merit, though. > > To see if a is a subtype of b, something like: > > b = a.ancestors[a.depth-b.depth-1] (* with appropriate range checks *) > > Would this be easy to put in? I'm not sure how one can be sure > that typecodes are done being generated? There's something called > RTTypeSRC.FinishObjectTypes .. > > And PM3 still generates code that's four times faster. > > Mika > From hosking at cs.purdue.edu Sun Apr 26 11:08:22 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Apr 2009 19:08:22 +1000 Subject: [M3devel] Confusing, but non-critical bug... In-Reply-To: <200904260528.n3Q5SPcu000732@camembert.async.caltech.edu> References: <200904260528.n3Q5SPcu000732@camembert.async.caltech.edu> Message-ID: <388F44BC-9826-4E4E-AE6B-FD91AE2E9B35@cs.purdue.edu> Definitely something broken in the build. On 26 Apr 2009, at 15:28, Mika Nystrom wrote: > > So I have a library, built against m3tk. Everything compiles, but > when cm3 tries to "ar" the library: > > > new "TypeTranslator.io" -> archiving libsstubgen.a > > Fatal Error: incomplete library > > missing compiled interface "M3AST_all.io" imported by: M3AST_SM_F.i3 > M3AST_PG.m3 M3AST_SM.m3 TypeNames.m3 AstToVal.m3 AstToType.m3 > M3ASTScopeNames.m3 > M3AST_PG_M.i3: missing object types: _t1ee311ce > imported by: M3AST_PG.m3 > M3AST_all.i3: missing object types: _t8eb32ef8 _t9ffde2a4 > _ta2581bcc > _t52bfa811 _t249b6ddc _t172a75ba _t774a90ea _tc92a7e8c > _t1d23b703 > _t2812849 _t1796950e _te47b91c _tccbf0da _tb53c334a _tf38721e4 > _tbbcfc2cb _teec6ca97 > imported by: M3AST_PG.m3 AstToType.m3 AstToVal.m3 M3AST_SM.m3 > M3AST_SM_F.i3 > missing compiled interface "M3AST_PG_M.io" imported by: M3AST_PG.m3 > > seconds #times operation > 0.06 22 inhaling library link info > 0.01 27 checking old link info > 0.21 896 merging new link info > 0.05 4 garbage collection > --------------------------------------------------- > 0.34 TOTAL > > rm m3make.args > cd ../src > > So I add "IMPORT M3AST_all;" to one of my interfaces (it's not used > there at all): > > (1943)trs80:~/t-cm3/mscheme/sstubgen/src>cm3 -x > --- building in ../FreeBSD4 --- > > ignoring override("sstubgen", "/home/mika/t-cm3/mscheme") > > new source -> compiling TypeTranslator.i3 > "../src/TypeTranslator.i3", line 12: warning: not used (M3AST_all) > 1 warning encountered > new source -> compiling TypeTranslator.m3 > "../src/TypeTranslator.m3", line 353: warning: not used (Add) > 1 warning encountered > new opaque info -> recompiling TypeTranslator.m3 > "../src/TypeTranslator.m3", line 353: warning: not used (Add) > 1 warning encountered > new "TypeTranslator.io" -> archiving libsstubgen.a > (1944)trs80:~/t-cm3/mscheme/sstubgen/src> > > Hmmmmmmmmmmmmm....... is anyone interested in looking at this? > As I said, it's non-critical (I can get things working, clearly, > even with the bug present), but it's very confusing. I have to > import an interface I'm not using...why? Where to begin looking? > > Mika From mika at async.caltech.edu Sun Apr 26 20:12:35 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 26 Apr 2009 11:12:35 -0700 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: Your message of "Sun, 26 Apr 2009 18:54:57 +1000." Message-ID: <200904261812.n3QICZYX035390@camembert.async.caltech.edu> Hi Tony, I looked at this more closely, and I was wrong. The compiler doesn't actually segfault on -O. I was using -gstabs+ but switched to -gstabs after your email (doesn't seem to matter). I get a ton of warnings at either optimization level, and there are definitely bugs in the optimizer. The resulting code is generally not correct. (By comparison, I had to turn off PM3's optimizer for only one of the hundred or so packages I build.) Things often fail to compile, even at -O. At -O3, I get one segfault: new source -> compiling TextCommandQueueTbl.i3 cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack exception handling new source -> compiling CommandLoop.m3 cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack exception handling ../src/CommandLoop.m3: In function 'CommandLoop__Run': ../src/CommandLoop.m3:279: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: CommandLoop.mc new source -> compiling CommandLoopDefaultCommand.m3 cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack exception handling new source -> compiling TextCommandTbl.m3 where: 272 (***************************************************************************** 273 * * 274 * Command Loop Main * 275 * * 276 *****************************************************************************) 277 278 279 PROCEDURE Run(self: T; source: Pathname.T := NIL; term: Term.T := NIL) = 280 CONST 281 Comment = SET OF CHAR{'%','#'}; 282 VAR 283 completer := NEW(StdCompleter, loop:=self); 284 line: TEXT; 285 BEGIN 286 IF term = NIL THEN 287 self.term := Term.Default(); 288 ELSE 289 self.term := term; 290 END; 291 LOOP 292 TRY 293 IF source # NIL THEN 294 DoLoad(self.load, TextList.List2("",source), self.term); 295 source := NIL; ... Even at -O, things don't work right. Here's a typical output: new source -> compiling PassiveArb1.m3 "../src/PassiveArb1.m3", line 68: warning: not used (e) "../src/PassiveArb1.m3", line 45: warning: not used (newCon) 2 warnings encountered ../src/PassiveArb1.m3: In function 'PassiveArb1__FApply': ../src/PassiveArb1.m3:81: warning: variable 'M3_Cwb5VA_buyO' might be clobbered by 'longjmp' or 'vfork' ../src/PassiveArb1.m3:81: warning: variable 'M3_Cwb5VA_selO' might be clobbered by 'longjmp' or 'vfork' new source -> compiling PassiveArb2.i3 new source -> compiling ExecRecorder2.i3 new source -> compiling ArbPingPong.i3 new source -> compiling PassiveArb2.m3 ../src/PassiveArb2.m3: In function 'PassiveArb2__Apply': ../src/PassiveArb2.m3:388: warning: variable 'M3_EWPD1K_delta' might be clobbered by 'longjmp' or 'vfork' ../src/PassiveArb2.m3:388: warning: variable 'M3_Cwb5VA_toExec' might be clobbered by 'longjmp' or 'vfork' new source -> compiling Globals.i3 new source -> compiling ActiveArb1.i3 new source -> compiling ActiveArb1.m3 new source -> compiling ExecRecorder.i3 new source -> compiling ExecRecorder.m3 new source -> compiling ExecRec.i3 new source -> compiling ExecRecorder2.m3 new source -> compiling ExecRec.m3 new source -> compiling ArbPingPong.m3 new source -> compiling Main.m3 "../src/Main.m3", line 72: warning: potentially unhandled exception: OSError.E "../src/Main.m3", line 30: warning: potentially unhandled exceptions: Rd.EndOfFile, Rd.Failure, Thread.Alerted "../src/Main.m3", line 31: warning: potentially unhandled exceptions: Thread.Alerted, Wr.Failure "../src/Main.m3", line 32: warning: potentially unhandled exceptions: Thread.Alerted, Wr.Failure "../src/Main.m3", line 33: warning: potentially unhandled exceptions: Thread.Alerted, Wr.Failure "../src/Main.m3", line 118: warning: potentially unhandled exception: OSError.E "../src/Main.m3", line 204: warning: potentially unhandled exception: OSError.E 7 warnings encountered -> linking testtrade /usr/lib/libc.so: WARNING! setkey(3) not present in the system! /usr/lib/libc.so: warning: this program uses gets(), which is unsafe. /usr/lib/libc.so: warning: mktemp() possibly used unsafely; consider using mkstemp() /usr/lib/libc.so: WARNING! des_setkey(3) not present in the system! /usr/lib/libc.so: WARNING! encrypt(3) not present in the system! /usr/lib/libc.so: warning: tmpnam() possibly used unsafely; consider using mkstemp() /usr/lib/libc.so: warning: this program uses f_prealloc(), which is not recommended. /usr/lib/libc.so: WARNING! des_cipher(3) not present in the system! /usr/lib/libc.so: warning: tempnam() possibly used unsafely; consider using mkstemp() Main.mo: In function `Main_M3': ../src/Main.m3:164: undefined reference to `Main__5__1__1__CanStart.198' /home/mika/t-cm3/calarm/twslib/FreeBSD4/libtwslib.so: undefined reference to `TWSReader__RCApply__RD.332' m3_link => 1 linker failed linking: testtrade Fatal Error: package build failed Mika Tony Hosking writes: > >On 26 Apr 2009, at 15:22, Mika Nystrom wrote: > >> >> Hello again, >> >> Now I've managed to get all the code up and running under CM3. I >> found and committed fixes to a bug in Wx and some code in one of >> the m3tk libraries that looked like it never was finished in the >> first place. >> >> As I mentioned earlier, I wasn't able to get user threads working >> in CM3 on FreeBSD 4.11. But with some help from Jay, I was able to >> get things working with libc_r. Performance, unfortunately, >> leaves something to be desired. >> >> For the first time I've been able to compare timings on identical >> hardware between the PM3 I was using and the CM3 that's out now. >> >> Note that optimization doesn't seem to work..? (Not even -O, much >> less -O3... the compiler segfaults.) > >Are you passing -gstabs? It should not segfault on -O3 - this is a >regression if it does. > >> Here's what I get, using no optimization either in PM3 or CM3. The >> test is my Scheme interpreter generating SQL and Modula-3 code >> (a bit like the Hibernate system you can get for Java): >> >> >> CPU seconds CM3 PM3 >> First version 5.269 1.366 >> Fewer NEWs 2.039 0.440 (code cleanup on my part) >> TYPECASE hack 1.770 (see below) >> >> Some "poor man's profiling" (i.e., ctrl-C'ing in m3gdb) suggests that >> most of the time is spent either in threading code (this could just >> be a lousy implementation in libc_r), the garbage collector, or in >> "ScanTypecase". >> >> The only one of these routines I am qualified to do anything about is >> ScanTypecase. I don't know why the Critical Mass people... > colorful >> language can one use on m3devel?>.. all over this code. I assume it >> has >> something to do with Java. >> >> The PM3 code (from SRC?) has this wonderful, concise, efficient bit: >> >> PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = >> VAR t := Get (b); >> BEGIN >> IF (a >= RT0u.nTypes) THEN BadType (a) END; >> IF (a = 0) THEN RETURN TRUE END; >> RETURN (t.typecode <= a AND a <= t.lastSubTypeTC); >> END IsSubtype; >> >> replaced with the following absolute abomination in CM3: >> >> PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = >> VAR t: RT0.TypeDefn; >> BEGIN >> IF (a = RT0.NilTypecode) THEN RETURN TRUE END; >> t := Get (a); >> IF (t = NIL) THEN RETURN FALSE; END; >> IF (t.typecode = b) THEN RETURN TRUE END; >> WHILE (t.kind = ORD (TK.Obj)) DO >> IF (t.link_state = 0) THEN FinishTypecell (t, NIL); END; >> t := LOOPHOLE (t, RT0.ObjectTypeDefn).parent; >> IF (t = NIL) THEN RETURN FALSE; END; >> IF (t.typecode = b) THEN RETURN TRUE; END; >> END; >> IF (t.traced # 0) >> THEN RETURN (b = RT0.RefanyTypecode); >> ELSE RETURN (b = RT0.AddressTypecode); >> END; >> END IsSubtype; > >This is all to support dynamic loading of libraries. > >> Furthermore, CM3 has a hook for "ScanTypecase" that's missing >> in PM3 (the older compiler actually generates code for this): >> >> PROCEDURE ScanTypecase (ref: REFANY; >> x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = >> VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; >> BEGIN >> IF (ref = NIL) THEN RETURN 0; END; >> tc := TYPECODE (ref); >> p := x; i := 0; >> LOOP >> IF (p.uid = 0) THEN RETURN i; END; >> IF (p.defn = NIL) THEN >> p.defn := FindType (p.uid); >> IF (p.defn = NIL) THEN >> Fail (RTE.MissingType, RTModule.FromDataAddress(x), >> LOOPHOLE (p.uid, ADDRESS), NIL); >> END; >> END; >> xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; >> IF (tc = xc) OR IsSubtype (tc, xc) THEN RETURN i; END; >> INC (p, ADRSIZE (p^)); INC (i); >> END; >> END ScanTypecase; >> >> Where to begin? A loop with all kinds of runtime checks of properties >> that are supposedly known at compile time? IsSubtype (itself a loop) >> called from inside the loop? > >Not if dynamically loaded! > >> I was able to cut out almost all of the typecase activity from my >> program by using the following code in RTType.m3, which depends on >> the ADDRESS x never changing (well more specifically never being >> the same for two TYPECASE statements): >> >> TYPE >> TypeCaseResult = RECORD >> x : ADDRESS; >> tc : Typecode; >> arm : INTEGER; >> END; >> >> CONST >> TCCachePow = 6; >> TCCacheSize = Word.Shift(1,TCCachePow); >> TCMask = TCCacheSize-1; >> >> VAR TCCache := ARRAY [0..TCCacheSize-1] OF TypeCaseResult { >> TypeCaseResult { LOOPHOLE(0,ADDRESS), 0, -1 } , >> .. >> }; >> >> (* >> VAR tcScans := 0; tcHits := 0; (* instrumenting counters *) >> *) >> >> PROCEDURE ScanTypecase (ref: REFANY; >> x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = >> VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; >> BEGIN >> tc := TYPECODE (ref); >> IF (ref = NIL) THEN RETURN 0; END; >> >> WITH hash = Word.And(Word.Times(tc, >> >> Word.RightShift(LOOPHOLE(x,Word.T),2)), >> TCMask), >> entry = TCCache[hash] DO >> (*INC(tcScans);*) >> IF entry.x = x AND entry.tc = tc THEN >> (*INC(tcHits);*) >> RETURN entry.arm >> END; >> >> p := x; i := 0; >> LOOP >> IF (p.uid = 0) THEN entry.x := x; entry.tc := tc; >> entry.arm := i; RETURN i; END; >> IF (p.defn = NIL) THEN >> p.defn := FindType (p.uid); >> IF (p.defn = NIL) THEN >> Fail (RTE.MissingType, RTModule.FromDataAddress(x), >> LOOPHOLE (p.uid, ADDRESS), NIL); >> END; >> END; >> xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; >> IF (tc = xc) OR IsSubtype (tc, xc) THEN entry.x := x; >> entry.tc := tc; entry.arm := i; RETURN i; END; >> INC (p, ADRSIZE (p^)); INC (i); >> END; >> END; >> END ScanTypecase; >> >> I'm guessing the speedup for TYPECASE itself is a factor of at least >> ten. But it's still a pretty nasty hack. And there is still a lot >> of IsSubtype activity from narrowing. >> >> I suppose that the way the typecodes are generated in CM3 is >> sufficiently different (meant to be extended at runtime?) from how >> it was done in PM3 that one can't really go back to the old code. >> Cardelli's idea of keeping an array of parents up to ROOT plus a >> "depth" for each type might have merit, though. >> >> To see if a is a subtype of b, something like: >> >> b = a.ancestors[a.depth-b.depth-1] (* with appropriate range checks *) >> >> Would this be easy to put in? I'm not sure how one can be sure >> that typecodes are done being generated? There's something called >> RTTypeSRC.FinishObjectTypes .. >> >> And PM3 still generates code that's four times faster. >> >> Mika >> From mika at async.caltech.edu Sun Apr 26 22:08:00 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 26 Apr 2009 13:08:00 -0700 Subject: [M3devel] Performance issues with CM3 In-Reply-To: Your message of "Sun, 26 Apr 2009 18:54:57 +1000." Message-ID: <200904262008.n3QK80hc040654@camembert.async.caltech.edu> Tony Hosking writes: > >On 26 Apr 2009, at 15:22, Mika Nystrom wrote: > >> >> Hello again, ... >> PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = >> VAR t: RT0.TypeDefn; >> BEGIN >> IF (a = RT0.NilTypecode) THEN RETURN TRUE END; >> t := Get (a); >> IF (t = NIL) THEN RETURN FALSE; END; >> IF (t.typecode = b) THEN RETURN TRUE END; >> WHILE (t.kind = ORD (TK.Obj)) DO >> IF (t.link_state = 0) THEN FinishTypecell (t, NIL); END; >> t := LOOPHOLE (t, RT0.ObjectTypeDefn).parent; >> IF (t = NIL) THEN RETURN FALSE; END; >> IF (t.typecode = b) THEN RETURN TRUE; END; >> END; >> IF (t.traced # 0) >> THEN RETURN (b = RT0.RefanyTypecode); >> ELSE RETURN (b = RT0.AddressTypecode); >> END; >> END IsSubtype; > >This is all to support dynamic loading of libraries. > >> Furthermore, CM3 has a hook for "ScanTypecase" that's missing >> in PM3 (the older compiler actually generates code for this): >> >> PROCEDURE ScanTypecase (ref: REFANY; >> x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = >> VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; >> BEGIN >> IF (ref = NIL) THEN RETURN 0; END; >> tc := TYPECODE (ref); >> p := x; i := 0; >> LOOP >> IF (p.uid = 0) THEN RETURN i; END; >> IF (p.defn = NIL) THEN >> p.defn := FindType (p.uid); >> IF (p.defn = NIL) THEN >> Fail (RTE.MissingType, RTModule.FromDataAddress(x), >> LOOPHOLE (p.uid, ADDRESS), NIL); >> END; >> END; >> xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; >> IF (tc = xc) OR IsSubtype (tc, xc) THEN RETURN i; END; >> INC (p, ADRSIZE (p^)); INC (i); >> END; >> END ScanTypecase; >> >> Where to begin? A loop with all kinds of runtime checks of properties >> that are supposedly known at compile time? IsSubtype (itself a loop) >> called from inside the loop? > >Not if dynamically loaded! > Tony, all right, but the code is still an abomination! The program only gets loaded once (even if dynamically). The TYPECASE might be executed millions, billions, trillions of times... if you execute this code a billion times, those IF statements are only "effective" once and just return the same value 999,999,999 times. Surely this information can be pre-computed at load time and stored somewhere so the IFs don't have to be re-interpreted? I don't know what the best solution is here. Is it really impossible to construct and re-construct the data structures that PM3 uses, or something equivalent? For instance, Cardelli's method of keeping the supertypes of a given type in an array would work fine with dynamic loading. It's almost as fast as the PM3 method but takes a bit more memory. One could limit these arrays to a certain size and then skip to the next array, to make a hybrid between what we have now in CM3 and a full array for every type. Do you think my hash table approach is safe? It's not nearly as elegant as the Cardelli method, but it works really well for a quick and dirty. It's ugly, but it's very fast. Or can the arrays used by the TYPECASEs move during program execution? In any case, with the standard CM3 implementation, my program spends more time in TYPECASE than the whole thing does under PM3. Do we have any code in CM3 that loads new types dynamically? I can see loading code dynamically, but types...? I'm very curious, is there an interface for it that "mortals" can use? If we have the mechanism, might as well put it to work... Another thing that bothers me a bit is that PushEFrame (sp?) seems to take a lot of cycles. Is the use of this routine due to the absence of a "stack walker"? I thought FreeBSD had a working stack walker in the Modula-3 runtime...? The thing about PushEFrame is that it makes the programmer want to avoid procedure calls, which is a real pity. Sussman and Steele's railings against the inefficient procedure calls in PL/I circa 1975 are legendary. (It's true, procedural abstraction is really wonderful.) Mika P.S. My hash table code re-attached in case someone wants to look at it again (instrumenting code commented out): TYPE TypeCaseResult = RECORD x : ADDRESS; tc : Typecode; arm : INTEGER; END; CONST TCCachePow = 6; TCCacheSize = Word.Shift(1,TCCachePow); TCMask = TCCacheSize-1; VAR TCCache := ARRAY [0..TCCacheSize-1] OF TypeCaseResult { TypeCaseResult { LOOPHOLE(0,ADDRESS), 0, -1 } , .. }; (* VAR tcScans := 0; tcHits := 0; *) PROCEDURE ScanTypecase (ref: REFANY; x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; BEGIN tc := TYPECODE (ref); IF (ref = NIL) THEN RETURN 0; END; WITH hash = Word.And(Word.Times(tc, Word.RightShift(LOOPHOLE(x,Word.T),2)), TCMask), entry = TCCache[hash] DO (*INC(tcScans);*) IF entry.x = x AND entry.tc = tc THEN (*INC(tcHits);*) RETURN entry.arm END; p := x; i := 0; LOOP IF (p.uid = 0) THEN entry.x := x; entry.tc := tc; entry.arm := i; RETURN i; END; IF (p.defn = NIL) THEN p.defn := FindType (p.uid); IF (p.defn = NIL) THEN Fail (RTE.MissingType, RTModule.FromDataAddress(x), LOOPHOLE (p.uid, ADDRESS), NIL); END; END; xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; IF (tc = xc) OR IsSubtype (tc, xc) THEN entry.x := x; entry.tc := tc; entry.arm := i; RETURN i; END; INC (p, ADRSIZE (p^)); INC (i); END; END; END ScanTypecase; From hosking at cs.purdue.edu Mon Apr 27 02:04:26 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Apr 2009 10:04:26 +1000 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: <200904261812.n3QICZYX035390@camembert.async.caltech.edu> References: <200904261812.n3QICZYX035390@camembert.async.caltech.edu> Message-ID: <34EE25E2-4DE9-493A-AC88-8D11A8545536@cs.purdue.edu> I am very disturbed about this since it suggests a regression. I had spent a huge amount of time a year or so back making sure the backend would play properly with gcc -O3, but it seems we are now back in a bad place. I'm not sure what changes have occurred to the backend since then, but they would be the prime candidates. Unfortunately, I don't have a lot of time right now to try to debug these -O3 problems, but I do want to fix them since they will eventually impinge on my own work. It would be really good to get our regressions framework back up and running and to put -O3 in there as the default build option -- it seems there have been ongoing Tinderbox problems for a while now, since my SOLgnu regression runs appear to have stopped completely. I'll need to check the logs. On 27 Apr 2009, at 04:12, Mika Nystrom wrote: > Hi Tony, > > I looked at this more closely, and I was wrong. The compiler doesn't > actually segfault on -O. I was using -gstabs+ but switched to -gstabs > after your email (doesn't seem to matter). > > I get a ton of warnings at either optimization level, and there are > definitely bugs in the optimizer. The resulting code is generally > not correct. (By comparison, I had to turn off PM3's optimizer for > only one of the hundred or so packages I build.) Things often fail > to compile, even at -O. > > At -O3, I get one segfault: > > new source -> compiling TextCommandQueueTbl.i3 > cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack > exception handling > new source -> compiling CommandLoop.m3 > cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack > exception handling > ../src/CommandLoop.m3: In function 'CommandLoop__Run': > ../src/CommandLoop.m3:279: internal compiler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > m3_backend => 4 > m3cc (aka cm3cg) failed compiling: CommandLoop.mc > new source -> compiling CommandLoopDefaultCommand.m3 > cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack > exception handling > new source -> compiling TextCommandTbl.m3 > > where: > > 272 > (***************************************************************************** > 273 > * * > 274 * Command Loop > Main * > 275 > * * > 276 > *****************************************************************************) > 277 > 278 > 279 PROCEDURE Run(self: T; source: Pathname.T := NIL; term: > Term.T := NIL) = > 280 CONST > 281 Comment = SET OF CHAR{'%','#'}; > 282 VAR > 283 completer := NEW(StdCompleter, loop:=self); > 284 line: TEXT; > 285 BEGIN > 286 IF term = NIL THEN > 287 self.term := Term.Default(); > 288 ELSE > 289 self.term := term; > 290 END; > 291 LOOP > 292 TRY > 293 IF source # NIL THEN > 294 DoLoad(self.load, TextList.List2("",source), > self.term); > 295 source := NIL; > > ... > > Even at -O, things don't work right. Here's a typical output: > > new source -> compiling PassiveArb1.m3 > "../src/PassiveArb1.m3", line 68: warning: not used (e) > "../src/PassiveArb1.m3", line 45: warning: not used (newCon) > 2 warnings encountered > ../src/PassiveArb1.m3: In function 'PassiveArb1__FApply': > ../src/PassiveArb1.m3:81: warning: variable 'M3_Cwb5VA_buyO' might > be clobbered by 'longjmp' or 'vfork' > ../src/PassiveArb1.m3:81: warning: variable 'M3_Cwb5VA_selO' might > be clobbered by 'longjmp' or 'vfork' > new source -> compiling PassiveArb2.i3 > new source -> compiling ExecRecorder2.i3 > new source -> compiling ArbPingPong.i3 > new source -> compiling PassiveArb2.m3 > ../src/PassiveArb2.m3: In function 'PassiveArb2__Apply': > ../src/PassiveArb2.m3:388: warning: variable 'M3_EWPD1K_delta' might > be clobbered by 'longjmp' or 'vfork' > ../src/PassiveArb2.m3:388: warning: variable 'M3_Cwb5VA_toExec' > might be clobbered by 'longjmp' or 'vfork' > new source -> compiling Globals.i3 > new source -> compiling ActiveArb1.i3 > new source -> compiling ActiveArb1.m3 > new source -> compiling ExecRecorder.i3 > new source -> compiling ExecRecorder.m3 > new source -> compiling ExecRec.i3 > new source -> compiling ExecRecorder2.m3 > new source -> compiling ExecRec.m3 > new source -> compiling ArbPingPong.m3 > new source -> compiling Main.m3 > "../src/Main.m3", line 72: warning: potentially unhandled exception: > OSError.E > "../src/Main.m3", line 30: warning: potentially unhandled > exceptions: Rd.EndOfFile, Rd.Failure, Thread.Alerted > "../src/Main.m3", line 31: warning: potentially unhandled > exceptions: Thread.Alerted, Wr.Failure > "../src/Main.m3", line 32: warning: potentially unhandled > exceptions: Thread.Alerted, Wr.Failure > "../src/Main.m3", line 33: warning: potentially unhandled > exceptions: Thread.Alerted, Wr.Failure > "../src/Main.m3", line 118: warning: potentially unhandled > exception: OSError.E > "../src/Main.m3", line 204: warning: potentially unhandled > exception: OSError.E > 7 warnings encountered > -> linking testtrade > /usr/lib/libc.so: WARNING! setkey(3) not present in the system! > /usr/lib/libc.so: warning: this program uses gets(), which is unsafe. > /usr/lib/libc.so: warning: mktemp() possibly used unsafely; consider > using mkstemp() > /usr/lib/libc.so: WARNING! des_setkey(3) not present in the system! > /usr/lib/libc.so: WARNING! encrypt(3) not present in the system! > /usr/lib/libc.so: warning: tmpnam() possibly used unsafely; consider > using mkstemp() > /usr/lib/libc.so: warning: this program uses f_prealloc(), which is > not recommended. > /usr/lib/libc.so: WARNING! des_cipher(3) not present in the system! > /usr/lib/libc.so: warning: tempnam() possibly used unsafely; > consider using mkstemp() > Main.mo: In function `Main_M3': > ../src/Main.m3:164: undefined reference to `Main__5__1__1__CanStart. > 198' > /home/mika/t-cm3/calarm/twslib/FreeBSD4/libtwslib.so: undefined > reference to `TWSReader__RCApply__RD.332' > m3_link => 1 > linker failed linking: testtrade > Fatal Error: package build failed > > > Mika > > > > Tony Hosking writes: >> >> On 26 Apr 2009, at 15:22, Mika Nystrom wrote: >> >>> >>> Hello again, >>> >>> Now I've managed to get all the code up and running under CM3. I >>> found and committed fixes to a bug in Wx and some code in one of >>> the m3tk libraries that looked like it never was finished in the >>> first place. >>> >>> As I mentioned earlier, I wasn't able to get user threads working >>> in CM3 on FreeBSD 4.11. But with some help from Jay, I was able to >>> get things working with libc_r. Performance, unfortunately, >>> leaves something to be desired. >>> >>> For the first time I've been able to compare timings on identical >>> hardware between the PM3 I was using and the CM3 that's out now. >>> >>> Note that optimization doesn't seem to work..? (Not even -O, much >>> less -O3... the compiler segfaults.) >> >> Are you passing -gstabs? It should not segfault on -O3 - this is a >> regression if it does. >> >>> Here's what I get, using no optimization either in PM3 or CM3. The >>> test is my Scheme interpreter generating SQL and Modula-3 code >>> (a bit like the Hibernate system you can get for Java): >>> >>> >>> CPU seconds CM3 PM3 >>> First version 5.269 1.366 >>> Fewer NEWs 2.039 0.440 (code cleanup on my part) >>> TYPECASE hack 1.770 (see below) >>> >>> Some "poor man's profiling" (i.e., ctrl-C'ing in m3gdb) suggests >>> that >>> most of the time is spent either in threading code (this could just >>> be a lousy implementation in libc_r), the garbage collector, or in >>> "ScanTypecase". >>> >>> The only one of these routines I am qualified to do anything about >>> is >>> ScanTypecase. I don't know why the Critical Mass people... >> colorful >>> language can one use on m3devel?>.. all over this code. I assume it >>> has >>> something to do with Java. >>> >>> The PM3 code (from SRC?) has this wonderful, concise, efficient bit: >>> >>> PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = >>> VAR t := Get (b); >>> BEGIN >>> IF (a >= RT0u.nTypes) THEN BadType (a) END; >>> IF (a = 0) THEN RETURN TRUE END; >>> RETURN (t.typecode <= a AND a <= t.lastSubTypeTC); >>> END IsSubtype; >>> >>> replaced with the following absolute abomination in CM3: >>> >>> PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = >>> VAR t: RT0.TypeDefn; >>> BEGIN >>> IF (a = RT0.NilTypecode) THEN RETURN TRUE END; >>> t := Get (a); >>> IF (t = NIL) THEN RETURN FALSE; END; >>> IF (t.typecode = b) THEN RETURN TRUE END; >>> WHILE (t.kind = ORD (TK.Obj)) DO >>> IF (t.link_state = 0) THEN FinishTypecell (t, NIL); END; >>> t := LOOPHOLE (t, RT0.ObjectTypeDefn).parent; >>> IF (t = NIL) THEN RETURN FALSE; END; >>> IF (t.typecode = b) THEN RETURN TRUE; END; >>> END; >>> IF (t.traced # 0) >>> THEN RETURN (b = RT0.RefanyTypecode); >>> ELSE RETURN (b = RT0.AddressTypecode); >>> END; >>> END IsSubtype; >> >> This is all to support dynamic loading of libraries. >> >>> Furthermore, CM3 has a hook for "ScanTypecase" that's missing >>> in PM3 (the older compiler actually generates code for this): >>> >>> PROCEDURE ScanTypecase (ref: REFANY; >>> x: ADDRESS(*ARRAY [0..] OF Cell*)): >>> INTEGER = >>> VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; >>> BEGIN >>> IF (ref = NIL) THEN RETURN 0; END; >>> tc := TYPECODE (ref); >>> p := x; i := 0; >>> LOOP >>> IF (p.uid = 0) THEN RETURN i; END; >>> IF (p.defn = NIL) THEN >>> p.defn := FindType (p.uid); >>> IF (p.defn = NIL) THEN >>> Fail (RTE.MissingType, RTModule.FromDataAddress(x), >>> LOOPHOLE (p.uid, ADDRESS), NIL); >>> END; >>> END; >>> xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; >>> IF (tc = xc) OR IsSubtype (tc, xc) THEN RETURN i; END; >>> INC (p, ADRSIZE (p^)); INC (i); >>> END; >>> END ScanTypecase; >>> >>> Where to begin? A loop with all kinds of runtime checks of >>> properties >>> that are supposedly known at compile time? IsSubtype (itself a loop) >>> called from inside the loop? >> >> Not if dynamically loaded! >> >>> I was able to cut out almost all of the typecase activity from my >>> program by using the following code in RTType.m3, which depends on >>> the ADDRESS x never changing (well more specifically never being >>> the same for two TYPECASE statements): >>> >>> TYPE >>> TypeCaseResult = RECORD >>> x : ADDRESS; >>> tc : Typecode; >>> arm : INTEGER; >>> END; >>> >>> CONST >>> TCCachePow = 6; >>> TCCacheSize = Word.Shift(1,TCCachePow); >>> TCMask = TCCacheSize-1; >>> >>> VAR TCCache := ARRAY [0..TCCacheSize-1] OF TypeCaseResult { >>> TypeCaseResult { LOOPHOLE(0,ADDRESS), 0, -1 } , >>> .. >>> }; >>> >>> (* >>> VAR tcScans := 0; tcHits := 0; (* instrumenting counters *) >>> *) >>> >>> PROCEDURE ScanTypecase (ref: REFANY; >>> x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = >>> VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; >>> BEGIN >>> tc := TYPECODE (ref); >>> IF (ref = NIL) THEN RETURN 0; END; >>> >>> WITH hash = Word.And(Word.Times(tc, >>> >>> Word.RightShift(LOOPHOLE(x,Word.T),2)), >>> TCMask), >>> entry = TCCache[hash] DO >>> (*INC(tcScans);*) >>> IF entry.x = x AND entry.tc = tc THEN >>> (*INC(tcHits);*) >>> RETURN entry.arm >>> END; >>> >>> p := x; i := 0; >>> LOOP >>> IF (p.uid = 0) THEN entry.x := x; entry.tc := tc; >>> entry.arm := i; RETURN i; END; >>> IF (p.defn = NIL) THEN >>> p.defn := FindType (p.uid); >>> IF (p.defn = NIL) THEN >>> Fail (RTE.MissingType, RTModule.FromDataAddress(x), >>> LOOPHOLE (p.uid, ADDRESS), NIL); >>> END; >>> END; >>> xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; >>> IF (tc = xc) OR IsSubtype (tc, xc) THEN entry.x := x; >>> entry.tc := tc; entry.arm := i; RETURN i; END; >>> INC (p, ADRSIZE (p^)); INC (i); >>> END; >>> END; >>> END ScanTypecase; >>> >>> I'm guessing the speedup for TYPECASE itself is a factor of at least >>> ten. But it's still a pretty nasty hack. And there is still a lot >>> of IsSubtype activity from narrowing. >>> >>> I suppose that the way the typecodes are generated in CM3 is >>> sufficiently different (meant to be extended at runtime?) from how >>> it was done in PM3 that one can't really go back to the old code. >>> Cardelli's idea of keeping an array of parents up to ROOT plus a >>> "depth" for each type might have merit, though. >>> >>> To see if a is a subtype of b, something like: >>> >>> b = a.ancestors[a.depth-b.depth-1] (* with appropriate range >>> checks *) >>> >>> Would this be easy to put in? I'm not sure how one can be sure >>> that typecodes are done being generated? There's something called >>> RTTypeSRC.FinishObjectTypes .. >>> >>> And PM3 still generates code that's four times faster. >>> >>> Mika >>> From mika at async.caltech.edu Mon Apr 27 02:31:42 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 26 Apr 2009 17:31:42 -0700 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: Your message of "Mon, 27 Apr 2009 10:04:26 +1000." <34EE25E2-4DE9-493A-AC88-8D11A8545536@cs.purdue.edu> Message-ID: <200904270031.n3R0VgjC052408@camembert.async.caltech.edu> Tony, it might not be as bad as all that. Well, on one level it is. Things are certainly not perfect. But I am able to operate with m3core built with -O (as well as with -O3). Lots of scary-looking compiler warnings, but things do work. There are just a few programs that won't build. I didn't try "all" in the CM3 dist---only my own programs and m3core (since m3core has the biggest performance impact). With lots of tweaks and adjustments, I now see my code running about 100% slower under CM3 than the same code does under PM3 (on the same machine). This is including my typecase hacks, as described earlier today. I'm guessing most of it is the FreeBSD pthreads implementation in libc_r + the calls to PushEFrame. Mika Tony Hosking writes: >I am very disturbed about this since it suggests a regression. I had >spent a huge amount of time a year or so back making sure the backend >would play properly with gcc -O3, but it seems we are now back in a >bad place. I'm not sure what changes have occurred to the backend >since then, but they would be the prime candidates. Unfortunately, I >don't have a lot of time right now to try to debug these -O3 problems, >but I do want to fix them since they will eventually impinge on my own >work. It would be really good to get our regressions framework back >up and running and to put -O3 in there as the default build option -- >it seems there have been ongoing Tinderbox problems for a while now, >since my SOLgnu regression runs appear to have stopped completely. >I'll need to check the logs. > >On 27 Apr 2009, at 04:12, Mika Nystrom wrote: > >> Hi Tony, >> >> I looked at this more closely, and I was wrong. The compiler doesn't >> actually segfault on -O. I was using -gstabs+ but switched to -gstabs >> after your email (doesn't seem to matter). >> >> I get a ton of warnings at either optimization level, and there are >> definitely bugs in the optimizer. The resulting code is generally >> not correct. (By comparison, I had to turn off PM3's optimizer for >> only one of the hundred or so packages I build.) Things often fail >> to compile, even at -O. >> >> At -O3, I get one segfault: >> >> new source -> compiling TextCommandQueueTbl.i3 >> cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack >> exception handling >> new source -> compiling CommandLoop.m3 >> cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack >> exception handling >> ../src/CommandLoop.m3: In function 'CommandLoop__Run': >> ../src/CommandLoop.m3:279: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> m3_backend => 4 >> m3cc (aka cm3cg) failed compiling: CommandLoop.mc >> new source -> compiling CommandLoopDefaultCommand.m3 >> cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack >> exception handling >> new source -> compiling TextCommandTbl.m3 >> >> where: >> >> 272 >> (***************************************************************************** >> 273 >> * * >> 274 * Command Loop >> Main * >> 275 >> * * >> 276 >> *****************************************************************************) >> 277 >> 278 >> 279 PROCEDURE Run(self: T; source: Pathname.T := NIL; term: >> Term.T := NIL) = >> 280 CONST >> 281 Comment = SET OF CHAR{'%','#'}; >> 282 VAR >> 283 completer := NEW(StdCompleter, loop:=self); >> 284 line: TEXT; >> 285 BEGIN >> 286 IF term = NIL THEN >> 287 self.term := Term.Default(); >> 288 ELSE >> 289 self.term := term; >> 290 END; >> 291 LOOP >> 292 TRY >> 293 IF source # NIL THEN >> 294 DoLoad(self.load, TextList.List2("",source), >> self.term); >> 295 source := NIL; >> >> ... >> >> Even at -O, things don't work right. Here's a typical output: >> >> new source -> compiling PassiveArb1.m3 >> "../src/PassiveArb1.m3", line 68: warning: not used (e) >> "../src/PassiveArb1.m3", line 45: warning: not used (newCon) >> 2 warnings encountered >> ../src/PassiveArb1.m3: In function 'PassiveArb1__FApply': >> ../src/PassiveArb1.m3:81: warning: variable 'M3_Cwb5VA_buyO' might >> be clobbered by 'longjmp' or 'vfork' >> ../src/PassiveArb1.m3:81: warning: variable 'M3_Cwb5VA_selO' might >> be clobbered by 'longjmp' or 'vfork' >> new source -> compiling PassiveArb2.i3 >> new source -> compiling ExecRecorder2.i3 >> new source -> compiling ArbPingPong.i3 >> new source -> compiling PassiveArb2.m3 >> ../src/PassiveArb2.m3: In function 'PassiveArb2__Apply': >> ../src/PassiveArb2.m3:388: warning: variable 'M3_EWPD1K_delta' might >> be clobbered by 'longjmp' or 'vfork' >> ../src/PassiveArb2.m3:388: warning: variable 'M3_Cwb5VA_toExec' >> might be clobbered by 'longjmp' or 'vfork' >> new source -> compiling Globals.i3 >> new source -> compiling ActiveArb1.i3 >> new source -> compiling ActiveArb1.m3 >> new source -> compiling ExecRecorder.i3 >> new source -> compiling ExecRecorder.m3 >> new source -> compiling ExecRec.i3 >> new source -> compiling ExecRecorder2.m3 >> new source -> compiling ExecRec.m3 >> new source -> compiling ArbPingPong.m3 >> new source -> compiling Main.m3 >> "../src/Main.m3", line 72: warning: potentially unhandled exception: >> OSError.E >> "../src/Main.m3", line 30: warning: potentially unhandled >> exceptions: Rd.EndOfFile, Rd.Failure, Thread.Alerted >> "../src/Main.m3", line 31: warning: potentially unhandled >> exceptions: Thread.Alerted, Wr.Failure >> "../src/Main.m3", line 32: warning: potentially unhandled >> exceptions: Thread.Alerted, Wr.Failure >> "../src/Main.m3", line 33: warning: potentially unhandled >> exceptions: Thread.Alerted, Wr.Failure >> "../src/Main.m3", line 118: warning: potentially unhandled >> exception: OSError.E >> "../src/Main.m3", line 204: warning: potentially unhandled >> exception: OSError.E >> 7 warnings encountered >> -> linking testtrade >> /usr/lib/libc.so: WARNING! setkey(3) not present in the system! >> /usr/lib/libc.so: warning: this program uses gets(), which is unsafe. >> /usr/lib/libc.so: warning: mktemp() possibly used unsafely; consider >> using mkstemp() >> /usr/lib/libc.so: WARNING! des_setkey(3) not present in the system! >> /usr/lib/libc.so: WARNING! encrypt(3) not present in the system! >> /usr/lib/libc.so: warning: tmpnam() possibly used unsafely; consider >> using mkstemp() >> /usr/lib/libc.so: warning: this program uses f_prealloc(), which is >> not recommended. >> /usr/lib/libc.so: WARNING! des_cipher(3) not present in the system! >> /usr/lib/libc.so: warning: tempnam() possibly used unsafely; >> consider using mkstemp() >> Main.mo: In function `Main_M3': >> ../src/Main.m3:164: undefined reference to `Main__5__1__1__CanStart. >> 198' >> /home/mika/t-cm3/calarm/twslib/FreeBSD4/libtwslib.so: undefined >> reference to `TWSReader__RCApply__RD.332' >> m3_link => 1 >> linker failed linking: testtrade >> Fatal Error: package build failed >> >> >> Mika >> >> >> >> Tony Hosking writes: >>> >>> On 26 Apr 2009, at 15:22, Mika Nystrom wrote: >>> >>>> >>>> Hello again, >>>> >>>> Now I've managed to get all the code up and running under CM3. I >>>> found and committed fixes to a bug in Wx and some code in one of >>>> the m3tk libraries that looked like it never was finished in the >>>> first place. >>>> >>>> As I mentioned earlier, I wasn't able to get user threads working >>>> in CM3 on FreeBSD 4.11. But with some help from Jay, I was able to >>>> get things working with libc_r. Performance, unfortunately, >>>> leaves something to be desired. >>>> >>>> For the first time I've been able to compare timings on identical >>>> hardware between the PM3 I was using and the CM3 that's out now. >>>> >>>> Note that optimization doesn't seem to work..? (Not even -O, much >>>> less -O3... the compiler segfaults.) >>> >>> Are you passing -gstabs? It should not segfault on -O3 - this is a >>> regression if it does. >>> >>>> Here's what I get, using no optimization either in PM3 or CM3. The >>>> test is my Scheme interpreter generating SQL and Modula-3 code >>>> (a bit like the Hibernate system you can get for Java): >>>> >>>> >>>> CPU seconds CM3 PM3 >>>> First version 5.269 1.366 >>>> Fewer NEWs 2.039 0.440 (code cleanup on my part) >>>> TYPECASE hack 1.770 (see below) >>>> >>>> Some "poor man's profiling" (i.e., ctrl-C'ing in m3gdb) suggests >>>> that >>>> most of the time is spent either in threading code (this could just >>>> be a lousy implementation in libc_r), the garbage collector, or in >>>> "ScanTypecase". >>>> >>>> The only one of these routines I am qualified to do anything about >>>> is >>>> ScanTypecase. I don't know why the Critical Mass people... >>> colorful >>>> language can one use on m3devel?>.. all over this code. I assume it >>>> has >>>> something to do with Java. >>>> >>>> The PM3 code (from SRC?) has this wonderful, concise, efficient bit: >>>> >>>> PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = >>>> VAR t := Get (b); >>>> BEGIN >>>> IF (a >= RT0u.nTypes) THEN BadType (a) END; >>>> IF (a = 0) THEN RETURN TRUE END; >>>> RETURN (t.typecode <= a AND a <= t.lastSubTypeTC); >>>> END IsSubtype; >>>> >>>> replaced with the following absolute abomination in CM3: >>>> >>>> PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = >>>> VAR t: RT0.TypeDefn; >>>> BEGIN >>>> IF (a = RT0.NilTypecode) THEN RETURN TRUE END; >>>> t := Get (a); >>>> IF (t = NIL) THEN RETURN FALSE; END; >>>> IF (t.typecode = b) THEN RETURN TRUE END; >>>> WHILE (t.kind = ORD (TK.Obj)) DO >>>> IF (t.link_state = 0) THEN FinishTypecell (t, NIL); END; >>>> t := LOOPHOLE (t, RT0.ObjectTypeDefn).parent; >>>> IF (t = NIL) THEN RETURN FALSE; END; >>>> IF (t.typecode = b) THEN RETURN TRUE; END; >>>> END; >>>> IF (t.traced # 0) >>>> THEN RETURN (b = RT0.RefanyTypecode); >>>> ELSE RETURN (b = RT0.AddressTypecode); >>>> END; >>>> END IsSubtype; >>> >>> This is all to support dynamic loading of libraries. >>> >>>> Furthermore, CM3 has a hook for "ScanTypecase" that's missing >>>> in PM3 (the older compiler actually generates code for this): >>>> >>>> PROCEDURE ScanTypecase (ref: REFANY; >>>> x: ADDRESS(*ARRAY [0..] OF Cell*)): >>>> INTEGER = >>>> VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; >>>> BEGIN >>>> IF (ref = NIL) THEN RETURN 0; END; >>>> tc := TYPECODE (ref); >>>> p := x; i := 0; >>>> LOOP >>>> IF (p.uid = 0) THEN RETURN i; END; >>>> IF (p.defn = NIL) THEN >>>> p.defn := FindType (p.uid); >>>> IF (p.defn = NIL) THEN >>>> Fail (RTE.MissingType, RTModule.FromDataAddress(x), >>>> LOOPHOLE (p.uid, ADDRESS), NIL); >>>> END; >>>> END; >>>> xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; >>>> IF (tc = xc) OR IsSubtype (tc, xc) THEN RETURN i; END; >>>> INC (p, ADRSIZE (p^)); INC (i); >>>> END; >>>> END ScanTypecase; >>>> >>>> Where to begin? A loop with all kinds of runtime checks of >>>> properties >>>> that are supposedly known at compile time? IsSubtype (itself a loop) >>>> called from inside the loop? >>> >>> Not if dynamically loaded! >>> >>>> I was able to cut out almost all of the typecase activity from my >>>> program by using the following code in RTType.m3, which depends on >>>> the ADDRESS x never changing (well more specifically never being >>>> the same for two TYPECASE statements): >>>> >>>> TYPE >>>> TypeCaseResult = RECORD >>>> x : ADDRESS; >>>> tc : Typecode; >>>> arm : INTEGER; >>>> END; >>>> >>>> CONST >>>> TCCachePow = 6; >>>> TCCacheSize = Word.Shift(1,TCCachePow); >>>> TCMask = TCCacheSize-1; >>>> >>>> VAR TCCache := ARRAY [0..TCCacheSize-1] OF TypeCaseResult { >>>> TypeCaseResult { LOOPHOLE(0,ADDRESS), 0, -1 } , >>>> .. >>>> }; >>>> >>>> (* >>>> VAR tcScans := 0; tcHits := 0; (* instrumenting counters *) >>>> *) >>>> >>>> PROCEDURE ScanTypecase (ref: REFANY; >>>> x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = >>>> VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; >>>> BEGIN >>>> tc := TYPECODE (ref); >>>> IF (ref = NIL) THEN RETURN 0; END; >>>> >>>> WITH hash = Word.And(Word.Times(tc, >>>> >>>> Word.RightShift(LOOPHOLE(x,Word.T),2)), >>>> TCMask), >>>> entry = TCCache[hash] DO >>>> (*INC(tcScans);*) >>>> IF entry.x = x AND entry.tc = tc THEN >>>> (*INC(tcHits);*) >>>> RETURN entry.arm >>>> END; >>>> >>>> p := x; i := 0; >>>> LOOP >>>> IF (p.uid = 0) THEN entry.x := x; entry.tc := tc; >>>> entry.arm := i; RETURN i; END; >>>> IF (p.defn = NIL) THEN >>>> p.defn := FindType (p.uid); >>>> IF (p.defn = NIL) THEN >>>> Fail (RTE.MissingType, RTModule.FromDataAddress(x), >>>> LOOPHOLE (p.uid, ADDRESS), NIL); >>>> END; >>>> END; >>>> xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; >>>> IF (tc = xc) OR IsSubtype (tc, xc) THEN entry.x := x; >>>> entry.tc := tc; entry.arm := i; RETURN i; END; >>>> INC (p, ADRSIZE (p^)); INC (i); >>>> END; >>>> END; >>>> END ScanTypecase; >>>> >>>> I'm guessing the speedup for TYPECASE itself is a factor of at least >>>> ten. But it's still a pretty nasty hack. And there is still a lot >>>> of IsSubtype activity from narrowing. >>>> >>>> I suppose that the way the typecodes are generated in CM3 is >>>> sufficiently different (meant to be extended at runtime?) from how >>>> it was done in PM3 that one can't really go back to the old code. >>>> Cardelli's idea of keeping an array of parents up to ROOT plus a >>>> "depth" for each type might have merit, though. >>>> >>>> To see if a is a subtype of b, something like: >>>> >>>> b = a.ancestors[a.depth-b.depth-1] (* with appropriate range >>>> checks *) >>>> >>>> Would this be easy to put in? I'm not sure how one can be sure >>>> that typecodes are done being generated? There's something called >>>> RTTypeSRC.FinishObjectTypes .. >>>> >>>> And PM3 still generates code that's four times faster. >>>> >>>> Mika >>>> > From hosking at cs.purdue.edu Mon Apr 27 02:26:06 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Apr 2009 10:26:06 +1000 Subject: [M3devel] Performance issues with CM3 In-Reply-To: <200904262008.n3QK80hc040654@camembert.async.caltech.edu> References: <200904262008.n3QK80hc040654@camembert.async.caltech.edu> Message-ID: <7FA8A570-6672-4B29-8349-5A6EFA6F0562@cs.purdue.edu> >>> Tony, all right, but the code is still an abomination! The program > only gets loaded once (even if dynamically). The TYPECASE might > be executed millions, billions, trillions of times... if you > execute this code a billion times, those IF statements are only > "effective" once and just return the same value 999,999,999 times. > Surely this information can be pre-computed at load time and stored > somewhere so the IFs don't have to be re-interpreted? I haven't looked closely at this code but it's been there since the Critical Mass days. The dynamic loading I refer to is for explicit opening and linking of .so files -- not the usual dynamic linking that takes place with .so files resolved at link time. Anyway, perhaps the code can be cleaned up. > I don't know what the best solution is here. Is it really impossible > to construct and re-construct the data structures that PM3 uses, > or something equivalent? I don't know. Possibly. Again, I don't know enough about this corner of the world to answer all of the following questions: > For instance, Cardelli's method of keeping the supertypes of a given > type in an array would work fine with dynamic loading. It's almost > as fast as the PM3 method but takes a bit more memory. One could > limit these arrays to a certain size and then skip to the next > array, to make a hybrid between what we have now in CM3 and a full > array for every type. > > Do you think my hash table approach is safe? It's not nearly as > elegant as the Cardelli method, but it works really well for a quick > and dirty. It's ugly, but it's very fast. Or can the arrays used > by the TYPECASEs move during program execution? > > In any case, with the standard CM3 implementation, my program spends > more time in TYPECASE than the whole thing does under PM3. > > Do we have any code in CM3 that loads new types dynamically? I can > see loading code dynamically, but types...? I'm very curious, is > there an interface for it that "mortals" can use? If we have the > mechanism, might as well put it to work... AFAIK you need to invoke RTLinker.AddUnit after using the native dlopen/dlsym facilities to get the symbol corresponding to the unit being loaded. I've never tried using it but I did have some plans to do so back in my persistence days (when retrieving an instance of an unknown subtype we'd need to also dynamically load its defining module). > Another thing that bothers me a bit is that PushEFrame (sp?) seems to > take a lot of cycles. Is the use of this routine due to the absence > of a "stack walker"? I thought FreeBSD had a working stack walker > in the Modula-3 runtime...? The stack walker is not usable for exception handling, only for printing a stack dump (IIRC). Same was true for PM3. We should do something about using the gcc-backend native stack walking support. Most of the overhead for PushEFrame (as compared to user-threaded PM3) is obtaining the thread-local stack. For user-threaded PM3 it was a compiled in global variable (which obviously breaks for native threads). > The thing about PushEFrame is that it makes the programmer want to > avoid procedure calls, which is a real pity. Sussman and Steele's > railings against the inefficient procedure calls in PL/I circa 1975 > are legendary. (It's true, procedural abstraction is really > wonderful.) I agree. I've maintained the SOLgnu stack walking code for years so that I don't have to pay the overhead of the explicit exception stack. > > > Mika > > P.S. My hash table code re-attached in case someone wants to look at > it > again (instrumenting code commented out): > > TYPE > TypeCaseResult = RECORD > x : ADDRESS; > tc : Typecode; > arm : INTEGER; > END; > > CONST > TCCachePow = 6; > TCCacheSize = Word.Shift(1,TCCachePow); > TCMask = TCCacheSize-1; > > VAR TCCache := ARRAY [0..TCCacheSize-1] OF TypeCaseResult { > TypeCaseResult { LOOPHOLE(0,ADDRESS), 0, -1 } , > .. > }; > > (* > VAR tcScans := 0; tcHits := 0; > *) > > PROCEDURE ScanTypecase (ref: REFANY; > x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = > VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; > BEGIN > tc := TYPECODE (ref); > IF (ref = NIL) THEN RETURN 0; END; > > WITH hash = Word.And(Word.Times(tc, > > Word.RightShift(LOOPHOLE(x,Word.T),2)), > TCMask), > entry = TCCache[hash] DO > (*INC(tcScans);*) > IF entry.x = x AND entry.tc = tc THEN > (*INC(tcHits);*) > RETURN entry.arm > END; > > p := x; i := 0; > LOOP > IF (p.uid = 0) THEN entry.x := x; entry.tc := tc; > entry.arm := i; RETURN i; END; > IF (p.defn = NIL) THEN > p.defn := FindType (p.uid); > IF (p.defn = NIL) THEN > Fail (RTE.MissingType, RTModule.FromDataAddress(x), > LOOPHOLE (p.uid, ADDRESS), NIL); > END; > END; > xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; > IF (tc = xc) OR IsSubtype (tc, xc) THEN entry.x := x; > entry.tc := tc; entry.arm := i; RETURN i; END; > INC (p, ADRSIZE (p^)); INC (i); > END; > END; > END ScanTypecase; > From hosking at cs.purdue.edu Mon Apr 27 02:37:09 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Apr 2009 10:37:09 +1000 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: <200904270031.n3R0VgjC052408@camembert.async.caltech.edu> References: <200904270031.n3R0VgjC052408@camembert.async.caltech.edu> Message-ID: <678F2302-90D4-4F96-9EF6-7DA1167A97BA@cs.purdue.edu> On 27 Apr 2009, at 10:31, Mika Nystrom wrote: > > Tony, it might not be as bad as all that. Well, on one level it > is. Things are certainly not perfect. > > But I am able to operate with m3core built with -O (as well as with > -O3). Lots of scary-looking compiler warnings, but things do work. > There are just a few programs that won't build. I didn't try "all" > in the CM3 dist---only my own programs and m3core (since m3core has > the biggest performance impact). This is weird, since I assume you are targetting x86 which is the same (except I386_DARWIN in my case) as I have used -O3 for without problems previously. I shall have to rebuild everything in cm3 with - O3 to see if I can track down the problems. I can't remember the last time I checked that it all worked, but the CVS logs will probably reveal more (cf my log messages for parse.c in the gcc-based backend). > With lots of tweaks and adjustments, I now see my code running about > 100% slower under CM3 than the same code does under PM3 (on the > same machine). This is including my typecase hacks, as described > earlier today. I'm guessing most of it is the FreeBSD pthreads > implementation in libc_r + the calls to PushEFrame. Yikes! How much of this is module initialization (startup) time? > > > Mika > > Tony Hosking writes: >> I am very disturbed about this since it suggests a regression. I had >> spent a huge amount of time a year or so back making sure the backend >> would play properly with gcc -O3, but it seems we are now back in a >> bad place. I'm not sure what changes have occurred to the backend >> since then, but they would be the prime candidates. Unfortunately, I >> don't have a lot of time right now to try to debug these -O3 >> problems, >> but I do want to fix them since they will eventually impinge on my >> own >> work. It would be really good to get our regressions framework back >> up and running and to put -O3 in there as the default build option -- >> it seems there have been ongoing Tinderbox problems for a while now, >> since my SOLgnu regression runs appear to have stopped completely. >> I'll need to check the logs. >> >> On 27 Apr 2009, at 04:12, Mika Nystrom wrote: >> >>> Hi Tony, >>> >>> I looked at this more closely, and I was wrong. The compiler >>> doesn't >>> actually segfault on -O. I was using -gstabs+ but switched to - >>> gstabs >>> after your email (doesn't seem to matter). >>> >>> I get a ton of warnings at either optimization level, and there are >>> definitely bugs in the optimizer. The resulting code is generally >>> not correct. (By comparison, I had to turn off PM3's optimizer for >>> only one of the hundred or so packages I build.) Things often fail >>> to compile, even at -O. >>> >>> At -O3, I get one segfault: >>> >>> new source -> compiling TextCommandQueueTbl.i3 >>> cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack >>> exception handling >>> new source -> compiling CommandLoop.m3 >>> cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack >>> exception handling >>> ../src/CommandLoop.m3: In function 'CommandLoop__Run': >>> ../src/CommandLoop.m3:279: internal compiler error: Segmentation >>> fault >>> Please submit a full bug report, >>> with preprocessed source if appropriate. >>> See for instructions. >>> m3_backend => 4 >>> m3cc (aka cm3cg) failed compiling: CommandLoop.mc >>> new source -> compiling CommandLoopDefaultCommand.m3 >>> cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack >>> exception handling >>> new source -> compiling TextCommandTbl.m3 >>> >>> where: >>> >>> 272 >>> (***************************************************************************** >>> 273 >>> * * >>> 274 * Command Loop >>> Main * >>> 275 >>> * * >>> 276 >>> *****************************************************************************) >>> 277 >>> 278 >>> 279 PROCEDURE Run(self: T; source: Pathname.T := NIL; term: >>> Term.T := NIL) = >>> 280 CONST >>> 281 Comment = SET OF CHAR{'%','#'}; >>> 282 VAR >>> 283 completer := NEW(StdCompleter, loop:=self); >>> 284 line: TEXT; >>> 285 BEGIN >>> 286 IF term = NIL THEN >>> 287 self.term := Term.Default(); >>> 288 ELSE >>> 289 self.term := term; >>> 290 END; >>> 291 LOOP >>> 292 TRY >>> 293 IF source # NIL THEN >>> 294 DoLoad(self.load, TextList.List2("",source), >>> self.term); >>> 295 source := NIL; >>> >>> ... >>> >>> Even at -O, things don't work right. Here's a typical output: >>> >>> new source -> compiling PassiveArb1.m3 >>> "../src/PassiveArb1.m3", line 68: warning: not used (e) >>> "../src/PassiveArb1.m3", line 45: warning: not used (newCon) >>> 2 warnings encountered >>> ../src/PassiveArb1.m3: In function 'PassiveArb1__FApply': >>> ../src/PassiveArb1.m3:81: warning: variable 'M3_Cwb5VA_buyO' might >>> be clobbered by 'longjmp' or 'vfork' >>> ../src/PassiveArb1.m3:81: warning: variable 'M3_Cwb5VA_selO' might >>> be clobbered by 'longjmp' or 'vfork' >>> new source -> compiling PassiveArb2.i3 >>> new source -> compiling ExecRecorder2.i3 >>> new source -> compiling ArbPingPong.i3 >>> new source -> compiling PassiveArb2.m3 >>> ../src/PassiveArb2.m3: In function 'PassiveArb2__Apply': >>> ../src/PassiveArb2.m3:388: warning: variable 'M3_EWPD1K_delta' might >>> be clobbered by 'longjmp' or 'vfork' >>> ../src/PassiveArb2.m3:388: warning: variable 'M3_Cwb5VA_toExec' >>> might be clobbered by 'longjmp' or 'vfork' >>> new source -> compiling Globals.i3 >>> new source -> compiling ActiveArb1.i3 >>> new source -> compiling ActiveArb1.m3 >>> new source -> compiling ExecRecorder.i3 >>> new source -> compiling ExecRecorder.m3 >>> new source -> compiling ExecRec.i3 >>> new source -> compiling ExecRecorder2.m3 >>> new source -> compiling ExecRec.m3 >>> new source -> compiling ArbPingPong.m3 >>> new source -> compiling Main.m3 >>> "../src/Main.m3", line 72: warning: potentially unhandled exception: >>> OSError.E >>> "../src/Main.m3", line 30: warning: potentially unhandled >>> exceptions: Rd.EndOfFile, Rd.Failure, Thread.Alerted >>> "../src/Main.m3", line 31: warning: potentially unhandled >>> exceptions: Thread.Alerted, Wr.Failure >>> "../src/Main.m3", line 32: warning: potentially unhandled >>> exceptions: Thread.Alerted, Wr.Failure >>> "../src/Main.m3", line 33: warning: potentially unhandled >>> exceptions: Thread.Alerted, Wr.Failure >>> "../src/Main.m3", line 118: warning: potentially unhandled >>> exception: OSError.E >>> "../src/Main.m3", line 204: warning: potentially unhandled >>> exception: OSError.E >>> 7 warnings encountered >>> -> linking testtrade >>> /usr/lib/libc.so: WARNING! setkey(3) not present in the system! >>> /usr/lib/libc.so: warning: this program uses gets(), which is >>> unsafe. >>> /usr/lib/libc.so: warning: mktemp() possibly used unsafely; consider >>> using mkstemp() >>> /usr/lib/libc.so: WARNING! des_setkey(3) not present in the system! >>> /usr/lib/libc.so: WARNING! encrypt(3) not present in the system! >>> /usr/lib/libc.so: warning: tmpnam() possibly used unsafely; consider >>> using mkstemp() >>> /usr/lib/libc.so: warning: this program uses f_prealloc(), which is >>> not recommended. >>> /usr/lib/libc.so: WARNING! des_cipher(3) not present in the system! >>> /usr/lib/libc.so: warning: tempnam() possibly used unsafely; >>> consider using mkstemp() >>> Main.mo: In function `Main_M3': >>> ../src/Main.m3:164: undefined reference to `Main__5__1__1__CanStart. >>> 198' >>> /home/mika/t-cm3/calarm/twslib/FreeBSD4/libtwslib.so: undefined >>> reference to `TWSReader__RCApply__RD.332' >>> m3_link => 1 >>> linker failed linking: testtrade >>> Fatal Error: package build failed >>> >>> >>> Mika >>> >>> >>> >>> Tony Hosking writes: >>>> >>>> On 26 Apr 2009, at 15:22, Mika Nystrom wrote: >>>> >>>>> >>>>> Hello again, >>>>> >>>>> Now I've managed to get all the code up and running under CM3. I >>>>> found and committed fixes to a bug in Wx and some code in one of >>>>> the m3tk libraries that looked like it never was finished in the >>>>> first place. >>>>> >>>>> As I mentioned earlier, I wasn't able to get user threads working >>>>> in CM3 on FreeBSD 4.11. But with some help from Jay, I was able >>>>> to >>>>> get things working with libc_r. Performance, unfortunately, >>>>> leaves something to be desired. >>>>> >>>>> For the first time I've been able to compare timings on identical >>>>> hardware between the PM3 I was using and the CM3 that's out now. >>>>> >>>>> Note that optimization doesn't seem to work..? (Not even -O, much >>>>> less -O3... the compiler segfaults.) >>>> >>>> Are you passing -gstabs? It should not segfault on -O3 - this is a >>>> regression if it does. >>>> >>>>> Here's what I get, using no optimization either in PM3 or CM3. >>>>> The >>>>> test is my Scheme interpreter generating SQL and Modula-3 code >>>>> (a bit like the Hibernate system you can get for Java): >>>>> >>>>> >>>>> CPU seconds CM3 PM3 >>>>> First version 5.269 1.366 >>>>> Fewer NEWs 2.039 0.440 (code cleanup on my part) >>>>> TYPECASE hack 1.770 (see below) >>>>> >>>>> Some "poor man's profiling" (i.e., ctrl-C'ing in m3gdb) suggests >>>>> that >>>>> most of the time is spent either in threading code (this could >>>>> just >>>>> be a lousy implementation in libc_r), the garbage collector, or in >>>>> "ScanTypecase". >>>>> >>>>> The only one of these routines I am qualified to do anything about >>>>> is >>>>> ScanTypecase. I don't know why the Critical Mass people... >>>> colorful >>>>> language can one use on m3devel?>.. all over this code. I >>>>> assume it >>>>> has >>>>> something to do with Java. >>>>> >>>>> The PM3 code (from SRC?) has this wonderful, concise, efficient >>>>> bit: >>>>> >>>>> PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = >>>>> VAR t := Get (b); >>>>> BEGIN >>>>> IF (a >= RT0u.nTypes) THEN BadType (a) END; >>>>> IF (a = 0) THEN RETURN TRUE END; >>>>> RETURN (t.typecode <= a AND a <= t.lastSubTypeTC); >>>>> END IsSubtype; >>>>> >>>>> replaced with the following absolute abomination in CM3: >>>>> >>>>> PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = >>>>> VAR t: RT0.TypeDefn; >>>>> BEGIN >>>>> IF (a = RT0.NilTypecode) THEN RETURN TRUE END; >>>>> t := Get (a); >>>>> IF (t = NIL) THEN RETURN FALSE; END; >>>>> IF (t.typecode = b) THEN RETURN TRUE END; >>>>> WHILE (t.kind = ORD (TK.Obj)) DO >>>>> IF (t.link_state = 0) THEN FinishTypecell (t, NIL); END; >>>>> t := LOOPHOLE (t, RT0.ObjectTypeDefn).parent; >>>>> IF (t = NIL) THEN RETURN FALSE; END; >>>>> IF (t.typecode = b) THEN RETURN TRUE; END; >>>>> END; >>>>> IF (t.traced # 0) >>>>> THEN RETURN (b = RT0.RefanyTypecode); >>>>> ELSE RETURN (b = RT0.AddressTypecode); >>>>> END; >>>>> END IsSubtype; >>>> >>>> This is all to support dynamic loading of libraries. >>>> >>>>> Furthermore, CM3 has a hook for "ScanTypecase" that's missing >>>>> in PM3 (the older compiler actually generates code for this): >>>>> >>>>> PROCEDURE ScanTypecase (ref: REFANY; >>>>> x: ADDRESS(*ARRAY [0..] OF Cell*)): >>>>> INTEGER = >>>>> VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; >>>>> BEGIN >>>>> IF (ref = NIL) THEN RETURN 0; END; >>>>> tc := TYPECODE (ref); >>>>> p := x; i := 0; >>>>> LOOP >>>>> IF (p.uid = 0) THEN RETURN i; END; >>>>> IF (p.defn = NIL) THEN >>>>> p.defn := FindType (p.uid); >>>>> IF (p.defn = NIL) THEN >>>>> Fail (RTE.MissingType, RTModule.FromDataAddress(x), >>>>> LOOPHOLE (p.uid, ADDRESS), NIL); >>>>> END; >>>>> END; >>>>> xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; >>>>> IF (tc = xc) OR IsSubtype (tc, xc) THEN RETURN i; END; >>>>> INC (p, ADRSIZE (p^)); INC (i); >>>>> END; >>>>> END ScanTypecase; >>>>> >>>>> Where to begin? A loop with all kinds of runtime checks of >>>>> properties >>>>> that are supposedly known at compile time? IsSubtype (itself a >>>>> loop) >>>>> called from inside the loop? >>>> >>>> Not if dynamically loaded! >>>> >>>>> I was able to cut out almost all of the typecase activity from my >>>>> program by using the following code in RTType.m3, which depends on >>>>> the ADDRESS x never changing (well more specifically never being >>>>> the same for two TYPECASE statements): >>>>> >>>>> TYPE >>>>> TypeCaseResult = RECORD >>>>> x : ADDRESS; >>>>> tc : Typecode; >>>>> arm : INTEGER; >>>>> END; >>>>> >>>>> CONST >>>>> TCCachePow = 6; >>>>> TCCacheSize = Word.Shift(1,TCCachePow); >>>>> TCMask = TCCacheSize-1; >>>>> >>>>> VAR TCCache := ARRAY [0..TCCacheSize-1] OF TypeCaseResult { >>>>> TypeCaseResult { LOOPHOLE(0,ADDRESS), 0, -1 } , >>>>> .. >>>>> }; >>>>> >>>>> (* >>>>> VAR tcScans := 0; tcHits := 0; (* instrumenting counters *) >>>>> *) >>>>> >>>>> PROCEDURE ScanTypecase (ref: REFANY; >>>>> x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = >>>>> VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; >>>>> BEGIN >>>>> tc := TYPECODE (ref); >>>>> IF (ref = NIL) THEN RETURN 0; END; >>>>> >>>>> WITH hash = Word.And(Word.Times(tc, >>>>> >>>>> Word.RightShift(LOOPHOLE(x,Word.T),2)), >>>>> TCMask), >>>>> entry = TCCache[hash] DO >>>>> (*INC(tcScans);*) >>>>> IF entry.x = x AND entry.tc = tc THEN >>>>> (*INC(tcHits);*) >>>>> RETURN entry.arm >>>>> END; >>>>> >>>>> p := x; i := 0; >>>>> LOOP >>>>> IF (p.uid = 0) THEN entry.x := x; entry.tc := tc; >>>>> entry.arm := i; RETURN i; END; >>>>> IF (p.defn = NIL) THEN >>>>> p.defn := FindType (p.uid); >>>>> IF (p.defn = NIL) THEN >>>>> Fail (RTE.MissingType, RTModule.FromDataAddress(x), >>>>> LOOPHOLE (p.uid, ADDRESS), NIL); >>>>> END; >>>>> END; >>>>> xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; >>>>> IF (tc = xc) OR IsSubtype (tc, xc) THEN entry.x := x; >>>>> entry.tc := tc; entry.arm := i; RETURN i; END; >>>>> INC (p, ADRSIZE (p^)); INC (i); >>>>> END; >>>>> END; >>>>> END ScanTypecase; >>>>> >>>>> I'm guessing the speedup for TYPECASE itself is a factor of at >>>>> least >>>>> ten. But it's still a pretty nasty hack. And there is still a >>>>> lot >>>>> of IsSubtype activity from narrowing. >>>>> >>>>> I suppose that the way the typecodes are generated in CM3 is >>>>> sufficiently different (meant to be extended at runtime?) from how >>>>> it was done in PM3 that one can't really go back to the old code. >>>>> Cardelli's idea of keeping an array of parents up to ROOT plus a >>>>> "depth" for each type might have merit, though. >>>>> >>>>> To see if a is a subtype of b, something like: >>>>> >>>>> b = a.ancestors[a.depth-b.depth-1] (* with appropriate range >>>>> checks *) >>>>> >>>>> Would this be easy to put in? I'm not sure how one can be sure >>>>> that typecodes are done being generated? There's something called >>>>> RTTypeSRC.FinishObjectTypes .. >>>>> >>>>> And PM3 still generates code that's four times faster. >>>>> >>>>> Mika >>>>> >> From rodney.m.bates at cox.net Mon Apr 27 03:05:41 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Sun, 26 Apr 2009 20:05:41 -0500 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: <200904261812.n3QICZYX035390@camembert.async.caltech.edu> References: <200904261812.n3QICZYX035390@camembert.async.caltech.edu> Message-ID: <49F504E5.9000100@cox.net> FWIW, some m3gdb functions don't get the info they need with -gstabs, wereas -gstabx+ gives it to them. Mika Nystrom wrote: > Hi Tony, > > I looked at this more closely, and I was wrong. The compiler doesn't > actually segfault on -O. I was using -gstabs+ but switched to -gstabs > after your email (doesn't seem to matter). > > From mika at async.caltech.edu Mon Apr 27 03:17:24 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 26 Apr 2009 18:17:24 -0700 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: Your message of "Mon, 27 Apr 2009 10:37:09 +1000." <678F2302-90D4-4F96-9EF6-7DA1167A97BA@cs.purdue.edu> Message-ID: <200904270117.n3R1HOMt054469@camembert.async.caltech.edu> Tony Hosking writes: ... >> With lots of tweaks and adjustments, I now see my code running about >> 100% slower under CM3 than the same code does under PM3 (on the >> same machine). This is including my typecase hacks, as described >> earlier today. I'm guessing most of it is the FreeBSD pthreads >> implementation in libc_r + the calls to PushEFrame. > >Yikes! How much of this is module initialization (startup) time? > Ok, I re-checked just to make sure. As far as I know, exactly the same code, no initialization overhead (program's already running): CM3: > (time-call (lambda()(make-standard-stuff "Example"))) 1.309586018207483 > PM3: > (time-call (lambda()(make-standard-stuff "Example"))) 0.5641579627990723 > Bear in mind this is pretty close to a worst-case test for the "delta" between PM3 and CM3. Lots of small procedures, lots of typecases. Well, actually, I can make it worse. Turn on locking in the Scheme environments (so that they could be used by multi-threaded interpreters): CM3: > (time-call (lambda()(make-standard-stuff "Example"))) 2.1610950572649017 > PM3: > (time-call (lambda()(make-standard-stuff "Example"))) 0.6010241508483887 > CM3 without my change to RTType: > (time-call (lambda()(make-standard-stuff "Example"))) 2.2972461158642545 > 250% slower. But it is very demanding on pthreads. Lots of little procedures, lots of typecases, lots of locking. (No contention, though.) Mika P.S. the code in question is a scheme-m3 stub generator; it's making stub interfaces in the tests above. From hosking at cs.purdue.edu Mon Apr 27 03:29:04 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Apr 2009 11:29:04 +1000 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: <200904270117.n3R1HOMt054469@camembert.async.caltech.edu> References: <200904270117.n3R1HOMt054469@camembert.async.caltech.edu> Message-ID: Hmm. Interesting. What about exception scopes? On 27 Apr 2009, at 11:17, Mika Nystrom wrote: > Tony Hosking writes: > ... >>> With lots of tweaks and adjustments, I now see my code running about >>> 100% slower under CM3 than the same code does under PM3 (on the >>> same machine). This is including my typecase hacks, as described >>> earlier today. I'm guessing most of it is the FreeBSD pthreads >>> implementation in libc_r + the calls to PushEFrame. >> >> Yikes! How much of this is module initialization (startup) time? >> > > Ok, I re-checked just to make sure. As far as I know, exactly the > same code, > no initialization overhead (program's already running): > > CM3: > >> (time-call (lambda()(make-standard-stuff "Example"))) > 1.309586018207483 >> > > PM3: > >> (time-call (lambda()(make-standard-stuff "Example"))) > 0.5641579627990723 >> > > Bear in mind this is pretty close to a worst-case test for the > "delta" between > PM3 and CM3. Lots of small procedures, lots of typecases. > > Well, actually, I can make it worse. Turn on locking in the Scheme > environments > (so that they could be used by multi-threaded interpreters): > > CM3: > >> (time-call (lambda()(make-standard-stuff "Example"))) > 2.1610950572649017 >> > > PM3: > >> (time-call (lambda()(make-standard-stuff "Example"))) > 0.6010241508483887 >> > > CM3 without my change to RTType: > >> (time-call (lambda()(make-standard-stuff "Example"))) > 2.2972461158642545 >> > > 250% slower. > > But it is very demanding on pthreads. Lots of little procedures, > lots of typecases, lots of locking. (No contention, though.) > > Mika > > P.S. the code in question is a scheme-m3 stub generator; it's making > stub interfaces in the tests above. From hendrik at topoi.pooq.com Mon Apr 27 04:14:58 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 26 Apr 2009 22:14:58 -0400 Subject: [M3devel] Scheme in m3? In-Reply-To: <200904270117.n3R1HOMt054469@camembert.async.caltech.edu> References: <678F2302-90D4-4F96-9EF6-7DA1167A97BA@cs.purdue.edu> <200904270117.n3R1HOMt054469@camembert.async.caltech.edu> Message-ID: <20090427021457.GB6064@topoi.pooq.com> On Sun, Apr 26, 2009 at 06:17:24PM -0700, Mika Nystrom wrote: > > Well, actually, I can make it worse. Turn on locking in the Scheme environments ... > CM3: > > > (time-call (lambda()(make-standard-stuff "Example"))) > 2.1610950572649017 > > > > PM3: > > > (time-call (lambda()(make-standard-stuff "Example"))) > 0.6010241508483887 > > > A Scheme in M3? What do you do for tail-calls? -- hendrik From mika at async.caltech.edu Mon Apr 27 04:28:42 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 26 Apr 2009 19:28:42 -0700 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: Your message of "Mon, 27 Apr 2009 11:29:04 +1000." Message-ID: <200904270228.n3R2SgLC057723@camembert.async.caltech.edu> How would I know? I'm trying to turn on profiling but it seems to be a bit involved. Involves re-building all the libraries? (cm3 -profile seems to look for FreeBSD4p instead of plain FreeBSD4...) Mika Tony Hosking writes: >Hmm. Interesting. What about exception scopes? > >On 27 Apr 2009, at 11:17, Mika Nystrom wrote: > >> Tony Hosking writes: >> ... >>>> With lots of tweaks and adjustments, I now see my code running about >>>> 100% slower under CM3 than the same code does under PM3 (on the >>>> same machine). This is including my typecase hacks, as described >>>> earlier today. I'm guessing most of it is the FreeBSD pthreads >>>> implementation in libc_r + the calls to PushEFrame. >>> >> Yikes! How much of this is module initialization (startup) time? >>> >> >> Ok, I re-checked just to make sure. As far as I know, exactly the >> same code, >> no initialization overhead (program's already running): >> >> CM3: >> >>> (time-call (lambda()(make-standard-stuff "Example"))) >> 1.309586018207483 >>> >> >> PM3: >> >>> (time-call (lambda()(make-standard-stuff "Example"))) >> 0.5641579627990723 >>> >> >> Bear in mind this is pretty close to a worst-case test for the >> "delta" between >> PM3 and CM3. Lots of small procedures, lots of typecases. >> >> Well, actually, I can make it worse. Turn on locking in the Scheme >> environments >> (so that they could be used by multi-threaded interpreters): >> >> CM3: >> >>> (time-call (lambda()(make-standard-stuff "Example"))) >> 2.1610950572649017 >>> >> >> PM3: >> >>> (time-call (lambda()(make-standard-stuff "Example"))) >> 0.6010241508483887 >>> >> >> CM3 without my change to RTType: >> >>> (time-call (lambda()(make-standard-stuff "Example"))) >> 2.2972461158642545 >>> >> >> 250% slower. >> >> But it is very demanding on pthreads. Lots of little procedures, >> lots of typecases, lots of locking. (No contention, though.) >> >> Mika >> >> P.S. the code in question is a scheme-m3 stub generator; it's making >> stub interfaces in the tests above. > From hosking at cs.purdue.edu Mon Apr 27 04:37:17 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Apr 2009 12:37:17 +1000 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: <200904270228.n3R2SgLC057723@camembert.async.caltech.edu> References: <200904270228.n3R2SgLC057723@camembert.async.caltech.edu> Message-ID: <9AE70027-6818-4404-A4A6-BBEAD31B7935@cs.purdue.edu> I was just wondering if your code has a lot of TRY blocks, which come with the PushEFrame overhead. On 27 Apr 2009, at 12:28, Mika Nystrom wrote: > How would I know? I'm trying to turn on profiling but it seems to > be a > bit involved. Involves re-building all the libraries? > > (cm3 -profile seems to look for FreeBSD4p instead of plain > FreeBSD4...) > > Mika > > Tony Hosking writes: >> Hmm. Interesting. What about exception scopes? >> >> On 27 Apr 2009, at 11:17, Mika Nystrom wrote: >> >>> Tony Hosking writes: >>> ... >>>>> With lots of tweaks and adjustments, I now see my code running >>>>> about >>>>> 100% slower under CM3 than the same code does under PM3 (on the >>>>> same machine). This is including my typecase hacks, as described >>>>> earlier today. I'm guessing most of it is the FreeBSD pthreads >>>>> implementation in libc_r + the calls to PushEFrame. >>>> >>> Yikes! How much of this is module initialization (startup) time? >>>> >>> >>> Ok, I re-checked just to make sure. As far as I know, exactly the >>> same code, >>> no initialization overhead (program's already running): >>> >>> CM3: >>> >>>> (time-call (lambda()(make-standard-stuff "Example"))) >>> 1.309586018207483 >>>> >>> >>> PM3: >>> >>>> (time-call (lambda()(make-standard-stuff "Example"))) >>> 0.5641579627990723 >>>> >>> >>> Bear in mind this is pretty close to a worst-case test for the >>> "delta" between >>> PM3 and CM3. Lots of small procedures, lots of typecases. >>> >>> Well, actually, I can make it worse. Turn on locking in the Scheme >>> environments >>> (so that they could be used by multi-threaded interpreters): >>> >>> CM3: >>> >>>> (time-call (lambda()(make-standard-stuff "Example"))) >>> 2.1610950572649017 >>>> >>> >>> PM3: >>> >>>> (time-call (lambda()(make-standard-stuff "Example"))) >>> 0.6010241508483887 >>>> >>> >>> CM3 without my change to RTType: >>> >>>> (time-call (lambda()(make-standard-stuff "Example"))) >>> 2.2972461158642545 >>>> >>> >>> 250% slower. >>> >>> But it is very demanding on pthreads. Lots of little procedures, >>> lots of typecases, lots of locking. (No contention, though.) >>> >>> Mika >>> >>> P.S. the code in question is a scheme-m3 stub generator; it's making >>> stub interfaces in the tests above. >> From mika at async.caltech.edu Mon Apr 27 04:44:28 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 26 Apr 2009 19:44:28 -0700 Subject: [M3devel] Scheme in m3? In-Reply-To: Your message of "Sun, 26 Apr 2009 22:14:58 EDT." <20090427021457.GB6064@topoi.pooq.com> Message-ID: <200904270244.n3R2iSw8058447@camembert.async.caltech.edu> LOOP! I just copied Peter Norvig's Java code, as a starting point. (JScheme something or other.) Just like his interpreter, mine doesn't implement call-with-current-continuation completely. But normal tail calls are fine. An abbreviated version of eval: PROCEDURE Eval(env : Environment; x : Object) : Object = BEGIN LOOP IF x # NIL AND ISTYPE(x,Symbol) THEN RETURN env.lookup(x) ELSE VAR fn := x.car; BEGIN IF (* special forms *) THEN ... ELSE (* procedure call *) fn := Eval(fn, env); TYPECASE fn OF Closure(c) => x := c.body; (* tail call *) env := NEW(Environment).init(c.params,c.env) ... END END END END END END Eval; Mika hendrik at topoi.pooq.com writes: >On Sun, Apr 26, 2009 at 06:17:24PM -0700, Mika Nystrom wrote: > >> >> Well, actually, I can make it worse. Turn on locking in the Scheme environments >... >> CM3: >> >> > (time-call (lambda()(make-standard-stuff "Example"))) >> 2.1610950572649017 >> > >> >> PM3: >> >> > (time-call (lambda()(make-standard-stuff "Example"))) >> 0.6010241508483887 >> > >> > >A Scheme in M3? What do you do for tail-calls? > >-- hendrik From jay.krell at cornell.edu Mon Apr 27 04:32:12 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 26 Apr 2009 19:32:12 -0700 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: References: <200904270117.n3R1HOMt054469@camembert.async.caltech.edu> Message-ID: I think Tony means do you have many 'try' and hav you tried reducing them? That is where pusheframe comes from (and lock). We can give you back user threads, and probably speed up pthreads on some platforms with __thread instead of pthread_setspecific.on some platforms it exists and is more than just syntactic sugar, I think. I assume typecase can be much faster even with dynamic loading but need to dig, much later. - Jay (phone) On Apr 26, 2009, at 6:29 PM, Tony Hosking wrote: > Hmm. Interesting. What about exception scopes? > > On 27 Apr 2009, at 11:17, Mika Nystrom >>> >>> >> >> >>> >> >>> >> >> >> >>> >> >>> >> >>> >> >> >> >> From mika at async.caltech.edu Mon Apr 27 04:59:32 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 26 Apr 2009 19:59:32 -0700 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: Your message of "Mon, 27 Apr 2009 12:37:17 +1000." <9AE70027-6818-4404-A4A6-BBEAD31B7935@cs.purdue.edu> Message-ID: <200904270259.n3R2xWDX059155@camembert.async.caltech.edu> Ah, yeah... I have to admit it does. Whenever it pushes the stack in Scheme it makes a TRY block so it can print a pretty traceback if anything goes wrong... if something goes wrong deep into a call it prints an error message for every frame in Scheme (not tail calls obviously, see Hendrik's question), concatenating them as it pops out of the frames, until you're back at the REPL. Example: > (define (add1 x) ( + x 1)) add1 > (define (x) (map add1 '(1 2 3 junk))) x > (x) EXCEPTION! expected a double, got: junk (called from) eval (+ x 1) (called from) eval (x) > Hmm.. so if I disable tracebacks my code should get a lot faster. > (time-call (lambda()(make-standard-stuff "Example"))) 1.3191220290027559 > (toggle-tracebacks) #f > (time-call (lambda()(make-standard-stuff "Example"))) 1.1270759491017088 > Neat... sort of. 17% speedup is nothing to sneeze at, but I do like those tracebacks, too. Mika Tony Hosking writes: >I was just wondering if your code has a lot of TRY blocks, which come >with the PushEFrame overhead. > >On 27 Apr 2009, at 12:28, Mika Nystrom wrote: > >> How would I know? I'm trying to turn on profiling but it seems to >> be a >> bit involved. Involves re-building all the libraries? >> >> (cm3 -profile seems to look for FreeBSD4p instead of plain >> FreeBSD4...) >> >> Mika >> >> Tony Hosking writes: >>> Hmm. Interesting. What about exception scopes? >>> >>> On 27 Apr 2009, at 11:17, Mika Nystrom wrote: >>> >>>> Tony Hosking writes: >>>> ... >>>>>> With lots of tweaks and adjustments, I now see my code running >>>>>> about >>>>>> 100% slower under CM3 than the same code does under PM3 (on the >>>>>> same machine). This is including my typecase hacks, as described >>>>>> earlier today. I'm guessing most of it is the FreeBSD pthreads >>>>>> implementation in libc_r + the calls to PushEFrame. >>>>> >>>> Yikes! How much of this is module initialization (startup) time? >>>>> >>>> >>>> Ok, I re-checked just to make sure. As far as I know, exactly the >>>> same code, >>>> no initialization overhead (program's already running): >>>> >>>> CM3: >>>> >>>>> (time-call (lambda()(make-standard-stuff "Example"))) >>>> 1.309586018207483 >>>>> >>>> >>>> PM3: >>>> >>>>> (time-call (lambda()(make-standard-stuff "Example"))) >>>> 0.5641579627990723 >>>>> >>>> >>>> Bear in mind this is pretty close to a worst-case test for the >>>> "delta" between >>>> PM3 and CM3. Lots of small procedures, lots of typecases. >>>> >>>> Well, actually, I can make it worse. Turn on locking in the Scheme >>>> environments >>>> (so that they could be used by multi-threaded interpreters): >>>> >>>> CM3: >>>> >>>>> (time-call (lambda()(make-standard-stuff "Example"))) >>>> 2.1610950572649017 >>>>> >>>> >>>> PM3: >>>> >>>>> (time-call (lambda()(make-standard-stuff "Example"))) >>>> 0.6010241508483887 >>>>> >>>> >>>> CM3 without my change to RTType: >>>> >>>>> (time-call (lambda()(make-standard-stuff "Example"))) >>>> 2.2972461158642545 >>>>> >>>> >>>> 250% slower. >>>> >>>> But it is very demanding on pthreads. Lots of little procedures, >>>> lots of typecases, lots of locking. (No contention, though.) >>>> >>>> Mika >>>> >>>> P.S. the code in question is a scheme-m3 stub generator; it's making >>>> stub interfaces in the tests above. >>> > From jay.krell at cornell.edu Mon Apr 27 04:36:09 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 26 Apr 2009 19:36:09 -0700 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: <200904270228.n3R2SgLC057723@camembert.async.caltech.edu> References: <200904270228.n3R2SgLC057723@camembert.async.caltech.edu> Message-ID: <4F21234C-997C-485D-A02F-FBD85A0E0A57@hotmail.com> It does that, yes, but try hacking it out of the config file. - Jay (phone) On Apr 26, 2009, at 7:28 PM, Mika Nystrom wrote: > How would I know? I'm trying to turn on profiling but it seems to > be a > bit involved. Involves re-building all the libraries? > > (cm3 -profile seems to look for FreeBSD4p instead of plain > FreeBSD4...) > > Mika > > Tony Hosking writes: >> >>>> >>>> >>> >>> >>>> >>> >>>> >>> >>> >>> >>>> >>> >>>> >>> >>>> >>> >>> >>> >>> >> From wagner at elegosoft.com Mon Apr 27 08:46:18 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 27 Apr 2009 08:46:18 +0200 Subject: [M3devel] Fwd: Modula-2 to Modula-3 translator by Aachen University Message-ID: <20090427084618.hnk460mh440c880c@mail.elegosoft.com> Perhaps somebody on the public list knows something... ----- Forwarded message from trijezdci at gmail.com ----- Date: Sun, 26 Apr 2009 15:57:36 +0900 From: Benjamin Kowarsch Reply-To: Benjamin Kowarsch Subject: Modula-2 to Modula-3 translator by Aachen University To: m3-support at elego.de Dear Sirs, I am trying to get the Modula-2 section in the Catalog of Compilers updated and there is one entry of a Modula-2 to Modula-3 translator by Peter Klein at University of Aachen for which all links and email addresses seem to be dead. University of Aachen was unable to give me any information either. I wonder if you know whether this translator is still availabe and if so at which URL, or where his author Peter Klein can be contacted. thank you regards benjamin ----- 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 mika at async.caltech.edu Mon Apr 27 09:50:44 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 27 Apr 2009 00:50:44 -0700 Subject: [M3devel] RuntimeError doesn't work quite as advertised Message-ID: <200904270750.n3R7oiqH071966@camembert.async.caltech.edu> Maybe someone else knows more about this than me... The following program: MODULE Main; IMPORT RuntimeError, IO; PROCEDURE Range() = BEGIN EVAL VAL(-1,CARDINAL) END Range; PROCEDURE Assert() = BEGIN <*ASSERT FALSE*> END Assert; PROCEDURE NilJump() = VAR x : PROCEDURE() := NIL; BEGIN x() END NilJump; PROCEDURE NilDeref() = VAR x : REF INTEGER := NIL; b : INTEGER; BEGIN b := x^ END NilDeref; PROCEDURE NilMethod() = TYPE T = OBJECT METHODS m() END; VAR t : T; BEGIN t.m() END NilMethod; BEGIN WITH ps = ARRAY OF PROCEDURE() { Range, Assert, NilMethod, NilJump, NilDeref } DO FOR i := FIRST(ps) TO LAST(ps) DO TRY ps[i]() EXCEPT RuntimeError.E(e) => IO.Put("RuntimeError: " & RuntimeError.Tag(e) & " \n") END END END END Main. yields the following result: (1053)trs80:~/test/src>../FreeBSD4/prog RuntimeError: An enumeration or subrange value was out of range. RuntimeError: <*ASSERT*> failed. *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x8048a71 = NilMethod + 0x10 in ../src/Main.m3 *** Abort Seems to me I ought to see a few more exceptions and not a crash. I'm happy to investigate a bit more, but does anyone have a clue where to begin? Mika From mika at async.caltech.edu Mon Apr 27 10:31:21 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 27 Apr 2009 01:31:21 -0700 Subject: [M3devel] RuntimeError doesn't work quite as advertised In-Reply-To: Your message of "Mon, 27 Apr 2009 00:50:44 PDT." <200904270750.n3R7oiqH071966@camembert.async.caltech.edu> Message-ID: <200904270831.n3R8VLFe073838@camembert.async.caltech.edu> Ok so I tried the "obvious thing", namely, I changed RTSignal.SegV to do RAISE RuntimeError.E(RuntimeError.T.BadMemoryReference); Somewhat to my surprise, this does the right thing for a null method. But somewhat less surprisingly, it loops for NilJump and NilDeref. Is the machine jumping back and re-executing the same instructions after the signal handler returns? Would all hell break loose if one were to special-case EXCEPT RuntimeError.E to store a thread-local jmp_buf that one does a C-style longjmp to? (With a chain back to any higher RuntimeError.E handlers, I suppose...) Or is there a way to get the exception to work out of the signal handler with the normal exception mechanism? Mika Mika Nystrom writes: > >Maybe someone else knows more about this than me... > >The following program: > >MODULE Main; >IMPORT RuntimeError, IO; > >PROCEDURE Range() = BEGIN EVAL VAL(-1,CARDINAL) END Range; > >PROCEDURE Assert() = BEGIN <*ASSERT FALSE*> END Assert; > >PROCEDURE NilJump() = VAR x : PROCEDURE() := NIL; BEGIN x() END NilJump; > >PROCEDURE NilDeref() = > VAR x : REF INTEGER := NIL; b : INTEGER; > BEGIN b := x^ END NilDeref; > >PROCEDURE NilMethod() = > TYPE T = OBJECT METHODS m() END; > VAR t : T; BEGIN t.m() END NilMethod; > >BEGIN > WITH ps = ARRAY OF PROCEDURE() { Range, Assert, NilMethod, NilJump, NilDeref } DO > FOR i := FIRST(ps) TO LAST(ps) DO > TRY > ps[i]() > EXCEPT > RuntimeError.E(e) => IO.Put("RuntimeError: " & RuntimeError.Tag(e) & " \n") > END > END > END >END Main. > >yields the following result: > >(1053)trs80:~/test/src>../FreeBSD4/prog >RuntimeError: An enumeration or subrange value was out of range. >RuntimeError: <*ASSERT*> failed. > > >*** >*** runtime error: >*** Segmentation violation - possible attempt to dereference NIL >*** pc = 0x8048a71 = NilMethod + 0x10 in ../src/Main.m3 >*** > >Abort > >Seems to me I ought to see a few more exceptions and not a crash. > >I'm happy to investigate a bit more, but does anyone have a clue where >to begin? > > Mika From wagner at elegosoft.com Mon Apr 27 14:24:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 27 Apr 2009 14:24:26 +0200 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <09E195AF-2D6E-4A76-9328-DC4F29049719@gmail.com> References: <200904260530.n3Q5U1NE000824@camembert.async.caltech.edu> <09E195AF-2D6E-4A76-9328-DC4F29049719@gmail.com> Message-ID: <20090427142426.tlx54313ms88sgk0@mail.elegosoft.com> Quoting Jay : > It is easy to fix for many non Linux systems.and possible for Linux. > Fairly well worn topic. Could you please just fix it if it's easy? User threads always worked reliably and very fast on FreeBSD systems. As I stated earlier, I'd deem it a regrettable loss. Thanks in advance, Olaf > - Jay (phone) > > On Apr 25, 2009, at 10:30 PM, Mika Nystrom wrote: > >> User threads certainly work fine on this machine (see my previous >> email) with PM3... some would say they work "better"... :-) >> >> Jay writes: >>> >>> --Apple-Mail-1-423481883 >>> Content-Type: text/plain; >>> charset=us-ascii; >>> format=flowed; >>> delsp=yes >>> Content-Transfer-Encoding: 7bit >>> >>> I think also due to simple use before init. >>> >>> - Jay (phone) >>> >>> On Apr 25, 2009, at 9:51 PM, Tony Hosking wrote: >>> >>>> Broken mostly because updated libraries detect forging of thread >>>> contexts (state) for security reasons and blow up. >>>> >>>> On 25 Apr 2009, at 14:12, Jay wrote: >>>> >>>>> Cool. >>>>> >>>>>> If I use user threads, it's a different story (which is probably >>>>> too bad, >>>>> >>>>> Oops, right, I forgot, I should have mentioned that, user threads >>>>> have likely been broken on all platforms for a while. I noticed >>>>> that on PPC_LINUX. I >>> >>> >>> --Apple-Mail-1-423481883 >>> Content-Type: text/html; >>> charset=utf-8 >>> Content-Transfer-Encoding: quoted-printable >>> >>>
I think also due to simple use = >>> before init.

 - Jay (phone>> style=3D"-webkit-composition-fill-color: rgba(175, 192, 227, 0.231373); = >>> -webkit-composition-frame-color: rgba(77, 128, 180, 0.231373); = >>> ">)
>> apple-content-edited=3D"true">>> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >>> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >>> normal; font-variant: normal; font-weight: normal; letter-spacing: = >>> normal; line-height: normal; text-align: auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; ">
>> style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; = >>> -khtml-line-break: after-white-space; ">>> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >>> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >>> normal; font-variant: normal; font-weight: normal; letter-spacing: = >>> normal; line-height: normal; text-align: auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; ">Broken mostly = >>> because updated libraries detect forging of thread contexts (state) for = >>> security reasons and blow up.

On = >>> 25 Apr 2009, at 14:12, Jay wrote:

>> class=3D"Apple-interchange-newline">
>> class=3D"Apple-style-span" style=3D"border-collapse: separate; color: = >>> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >>> normal; font-variant: normal; font-weight: normal; letter-spacing: = >>> normal; line-height: normal; orphans: 2; text-align: auto; text-indent: = >>> 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: = >>> 0px; -webkit-border-horizontal-spacing: 0px; = >>> -webkit-border-vertical-spacing: 0px; = >>> -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = >>> auto; -webkit-text-stroke-width: 0; ">
>> style=3D"font-size: 10pt; font-family: Verdana; = >>> ">Cool.
 
 > If I use user threads, it's a different = >>> story (which is probably too bad,

Oops, right, I forgot, I should = >>> have mentioned that, user threads have likely been broken on all = >>> platforms for a while. I noticed that on PPC_LINUX. = >>> I

= >>> >>> --Apple-Mail-1-423481883-- -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Mon Apr 27 14:23:41 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Apr 2009 22:23:41 +1000 Subject: [M3devel] RuntimeError doesn't work quite as advertised In-Reply-To: <200904270831.n3R8VLFe073838@camembert.async.caltech.edu> References: <200904270831.n3R8VLFe073838@camembert.async.caltech.edu> Message-ID: <7F78EA61-BF67-4C18-85D4-F0CC5B45276A@cs.purdue.edu> It's probably not generally safe to use RAISE inside a signal handler. There are esoteric rules as to what signal handlers can handle... I think we need to think harder on how best to reflect NIL dereference as a signal. Perhaps we need explicit NIL checks after all... On 27 Apr 2009, at 18:31, Mika Nystrom wrote: > Ok so I tried the "obvious thing", namely, I changed RTSignal.SegV to > do > > RAISE RuntimeError.E(RuntimeError.T.BadMemoryReference); > > Somewhat to my surprise, this does the right thing for a null method. > But somewhat less surprisingly, it loops for NilJump and NilDeref. > Is the machine jumping back and re-executing the same instructions > after the signal handler returns? > > Would all hell break loose if one were to special-case EXCEPT > RuntimeError.E to store a thread-local jmp_buf that one does a > C-style longjmp to? (With a chain back to any higher RuntimeError.E > handlers, I suppose...) Or is there a way to get the exception to > work out of the signal handler with the normal exception mechanism? > > Mika > > Mika Nystrom writes: >> >> Maybe someone else knows more about this than me... >> >> The following program: >> >> MODULE Main; >> IMPORT RuntimeError, IO; >> >> PROCEDURE Range() = BEGIN EVAL VAL(-1,CARDINAL) END Range; >> >> PROCEDURE Assert() = BEGIN <*ASSERT FALSE*> END Assert; >> >> PROCEDURE NilJump() = VAR x : PROCEDURE() := NIL; BEGIN x() END >> NilJump; >> >> PROCEDURE NilDeref() = >> VAR x : REF INTEGER := NIL; b : INTEGER; >> BEGIN b := x^ END NilDeref; >> >> PROCEDURE NilMethod() = >> TYPE T = OBJECT METHODS m() END; >> VAR t : T; BEGIN t.m() END NilMethod; >> >> BEGIN >> WITH ps = ARRAY OF PROCEDURE() { Range, Assert, NilMethod, NilJump, >> NilDeref } DO >> FOR i := FIRST(ps) TO LAST(ps) DO >> TRY >> ps[i]() >> EXCEPT >> RuntimeError.E(e) => IO.Put("RuntimeError: " & >> RuntimeError.Tag(e) & " \n") >> END >> END >> END >> END Main. >> >> yields the following result: >> >> (1053)trs80:~/test/src>../FreeBSD4/prog >> RuntimeError: An enumeration or subrange value was out of range. >> RuntimeError: <*ASSERT*> failed. >> >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL >> *** pc = 0x8048a71 = NilMethod + 0x10 in ../src/Main.m3 >> *** >> >> Abort >> >> Seems to me I ought to see a few more exceptions and not a crash. >> >> I'm happy to investigate a bit more, but does anyone have a clue >> where >> to begin? >> >> Mika From rodney.m.bates at cox.net Mon Apr 27 16:27:39 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 27 Apr 2009 09:27:39 -0500 Subject: [M3devel] Fwd: Modula-2 to Modula-3 translator by Aachen University In-Reply-To: <20090427084618.hnk460mh440c880c@mail.elegosoft.com> References: <20090427084618.hnk460mh440c880c@mail.elegosoft.com> Message-ID: <49F5C0DB.5010409@cox.net> I have a local copy of it, but haven't built/run it in several years. I have used it successfully on two or three conversions in the past. Can we make space at elegosoft? I'm pretty busy moving house now, but could quickly put my current files up, then try in a couple of months to see if it has suffered any bitrot. Olaf Wagner wrote: > Perhaps somebody on the public list knows something... > > ----- Forwarded message from trijezdci at gmail.com ----- > Date: Sun, 26 Apr 2009 15:57:36 +0900 > From: Benjamin Kowarsch > Reply-To: Benjamin Kowarsch > Subject: Modula-2 to Modula-3 translator by Aachen University > To: m3-support at elego.de > > Dear Sirs, > > I am trying to get the Modula-2 section in the Catalog of Compilers > updated and there is one entry of a Modula-2 to Modula-3 translator by > Peter Klein at University of Aachen for which all links and email > addresses seem to be dead. University of Aachen was unable to give me > any information either. > > I wonder if you know whether this translator is still availabe and if > so at which URL, or where his author Peter Klein can be contacted. > > thank you > regards > benjamin > > > ----- End forwarded message ----- > > Rodney Bates rodney.m.bates at cox.net From mika at async.caltech.edu Tue Apr 28 03:18:10 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 27 Apr 2009 18:18:10 -0700 Subject: [M3devel] RuntimeError doesn't work quite as advertised In-Reply-To: Your message of "Mon, 27 Apr 2009 22:23:41 +1000." <7F78EA61-BF67-4C18-85D4-F0CC5B45276A@cs.purdue.edu> Message-ID: <200904280118.n3S1IAQ2021489@camembert.async.caltech.edu> I think it ought to be safe to use siglongjmp. So we could attach a sigjmpbuf to whatever structure PushEFrame builds only when it's doing it for a "RuntimeError", and on a runtime error that's not handled otherwise, we catch the unix signal and call siglongjmp to get back to the exception handler... Here's an example in C: #include #include sigjmp_buf env; void handler(int x) { siglongjmp(env,1); } main() { signal(SIGSEGV, handler); if(sigsetjmp(env,1)) { printf("caught signal\n"); exit(0); } else { printf("initialized env\n"); } { int *a=(void *)0; printf("a is %d\n", *a /* SEGV */); /* not reached */ } } Mika Tony Hosking writes: >It's probably not generally safe to use RAISE inside a signal >handler. There are esoteric rules as to what signal handlers can >handle... > >I think we need to think harder on how best to reflect NIL dereference >as a signal. Perhaps we need explicit NIL checks after all... > >On 27 Apr 2009, at 18:31, Mika Nystrom wrote: > >> Ok so I tried the "obvious thing", namely, I changed RTSignal.SegV to >> do >> >> RAISE RuntimeError.E(RuntimeError.T.BadMemoryReference); >> >> Somewhat to my surprise, this does the right thing for a null method. >> But somewhat less surprisingly, it loops for NilJump and NilDeref. >> Is the machine jumping back and re-executing the same instructions >> after the signal handler returns? >> >> Would all hell break loose if one were to special-case EXCEPT >> RuntimeError.E to store a thread-local jmp_buf that one does a >> C-style longjmp to? (With a chain back to any higher RuntimeError.E >> handlers, I suppose...) Or is there a way to get the exception to >> work out of the signal handler with the normal exception mechanism? >> >> Mika > >> Mika Nystrom writes: >>> >>> Maybe someone else knows more about this than me... >>> >>> The following program: >>> >>> MODULE Main; >>> IMPORT RuntimeError, IO; >>> >>> PROCEDURE Range() = BEGIN EVAL VAL(-1,CARDINAL) END Range; >>> >>> PROCEDURE Assert() = BEGIN <*ASSERT FALSE*> END Assert; >>> >>> PROCEDURE NilJump() = VAR x : PROCEDURE() := NIL; BEGIN x() END >>> NilJump; >>> >>> PROCEDURE NilDeref() = >>> VAR x : REF INTEGER := NIL; b : INTEGER; >>> BEGIN b := x^ END NilDeref; >>> >>> PROCEDURE NilMethod() = >>> TYPE T = OBJECT METHODS m() END; >>> VAR t : T; BEGIN t.m() END NilMethod; >>> >>> BEGIN >>> WITH ps = ARRAY OF PROCEDURE() { Range, Assert, NilMethod, NilJump, >>> NilDeref } DO >>> FOR i := FIRST(ps) TO LAST(ps) DO >>> TRY >>> ps[i]() >>> EXCEPT >>> RuntimeError.E(e) => IO.Put("RuntimeError: " & >>> RuntimeError.Tag(e) & " \n") >>> END >>> END >>> END >>> END Main. >>> >>> yields the following result: >>> >>> (1053)trs80:~/test/src>../FreeBSD4/prog >>> RuntimeError: An enumeration or subrange value was out of range. >>> RuntimeError: <*ASSERT*> failed. >>> >>> >>> *** >>> *** runtime error: >>> *** Segmentation violation - possible attempt to dereference NIL >>> *** pc = 0x8048a71 = NilMethod + 0x10 in ../src/Main.m3 >>> *** >>> >>> Abort >>> >>> Seems to me I ought to see a few more exceptions and not a crash. >>> >>> I'm happy to investigate a bit more, but does anyone have a clue >>> where >>> to begin? >>> >>> Mika From hosking at cs.purdue.edu Tue Apr 28 03:48:34 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 28 Apr 2009 11:48:34 +1000 Subject: [M3devel] RuntimeError doesn't work quite as advertised In-Reply-To: <200904280118.n3S1IAQ2021489@camembert.async.caltech.edu> References: <200904280118.n3S1IAQ2021489@camembert.async.caltech.edu> Message-ID: <186B6F66-B42D-4AB4-8151-470FE0296013@cs.purdue.edu> On 28 Apr 2009, at 11:18, Mika Nystrom wrote: > I think it ought to be safe to use siglongjmp. > > So we could attach a sigjmpbuf to whatever structure PushEFrame > builds only when it's doing it for a "RuntimeError", and on a runtime > error that's not handled otherwise, we catch the unix signal and > call siglongjmp to get back to the exception handler... I'm not sure we can statically determine how a frame will be used. Can someone (Jay?) confirm whether signal handling on platforms without a stack walker are actually already using siglongjmp? I have a feeling this may already be the case. > Here's an example in C: > > #include > #include > > sigjmp_buf env; > > void handler(int x) { siglongjmp(env,1); } > > main() > { > signal(SIGSEGV, handler); > > if(sigsetjmp(env,1)) { > printf("caught signal\n"); > exit(0); > } else { > printf("initialized env\n"); > } > > { > int *a=(void *)0; > printf("a is %d\n", *a /* SEGV */); > /* not reached */ > } > } > > Mika > > > Tony Hosking writes: >> It's probably not generally safe to use RAISE inside a signal >> handler. There are esoteric rules as to what signal handlers can >> handle... >> >> I think we need to think harder on how best to reflect NIL >> dereference >> as a signal. Perhaps we need explicit NIL checks after all... >> >> On 27 Apr 2009, at 18:31, Mika Nystrom wrote: >> >>> Ok so I tried the "obvious thing", namely, I changed RTSignal.SegV >>> to >>> do >>> >>> RAISE RuntimeError.E(RuntimeError.T.BadMemoryReference); >>> >>> Somewhat to my surprise, this does the right thing for a null >>> method. >>> But somewhat less surprisingly, it loops for NilJump and NilDeref. >>> Is the machine jumping back and re-executing the same instructions >>> after the signal handler returns? >>> >>> Would all hell break loose if one were to special-case EXCEPT >>> RuntimeError.E to store a thread-local jmp_buf that one does a >>> C-style longjmp to? (With a chain back to any higher RuntimeError.E >>> handlers, I suppose...) Or is there a way to get the exception to >>> work out of the signal handler with the normal exception mechanism? >>> >>> Mika >> >>> Mika Nystrom writes: >>>> >>>> Maybe someone else knows more about this than me... >>>> >>>> The following program: >>>> >>>> MODULE Main; >>>> IMPORT RuntimeError, IO; >>>> >>>> PROCEDURE Range() = BEGIN EVAL VAL(-1,CARDINAL) END Range; >>>> >>>> PROCEDURE Assert() = BEGIN <*ASSERT FALSE*> END Assert; >>>> >>>> PROCEDURE NilJump() = VAR x : PROCEDURE() := NIL; BEGIN x() END >>>> NilJump; >>>> >>>> PROCEDURE NilDeref() = >>>> VAR x : REF INTEGER := NIL; b : INTEGER; >>>> BEGIN b := x^ END NilDeref; >>>> >>>> PROCEDURE NilMethod() = >>>> TYPE T = OBJECT METHODS m() END; >>>> VAR t : T; BEGIN t.m() END NilMethod; >>>> >>>> BEGIN >>>> WITH ps = ARRAY OF PROCEDURE() { Range, Assert, NilMethod, NilJump, >>>> NilDeref } DO >>>> FOR i := FIRST(ps) TO LAST(ps) DO >>>> TRY >>>> ps[i]() >>>> EXCEPT >>>> RuntimeError.E(e) => IO.Put("RuntimeError: " & >>>> RuntimeError.Tag(e) & " \n") >>>> END >>>> END >>>> END >>>> END Main. >>>> >>>> yields the following result: >>>> >>>> (1053)trs80:~/test/src>../FreeBSD4/prog >>>> RuntimeError: An enumeration or subrange value was out of range. >>>> RuntimeError: <*ASSERT*> failed. >>>> >>>> >>>> *** >>>> *** runtime error: >>>> *** Segmentation violation - possible attempt to dereference NIL >>>> *** pc = 0x8048a71 = NilMethod + 0x10 in ../src/Main.m3 >>>> *** >>>> >>>> Abort >>>> >>>> Seems to me I ought to see a few more exceptions and not a crash. >>>> >>>> I'm happy to investigate a bit more, but does anyone have a clue >>>> where >>>> to begin? >>>> >>>> Mika From jay.krell at cornell.edu Tue Apr 28 03:50:58 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 01:50:58 +0000 Subject: [M3devel] RuntimeError doesn't work quite as advertised In-Reply-To: <200904280118.n3S1IAQ2021489@camembert.async.caltech.edu> References: Your message of "Mon, 27 Apr 2009 22:23:41 +1000." <7F78EA61-BF67-4C18-85D4-F0CC5B45276A@cs.purdue.edu> <200904280118.n3S1IAQ2021489@camembert.async.caltech.edu> Message-ID: 1) Should we just always use sigsetjmp/siglongjmp? Or, getting the signal mask is much extra expense usually unnecesary? (imagine the case of there being a stack walker, where not even setjmp is paid for) Folks aren't supposed to muck with it willy nilly and should expect raising/catching an exception to restore to that which it was at the point of the try? 2) The inlined NULL checks arounds the "barrier" calls: - Aren't they just bloating the code for the unusual case? - Aren't they better left in the barrier functions themselves? - Besides leading to smaller and therefore faster code (except in the usual case of there being a NULL pointer deref, which is always going to be slow anyway), can't this then double or mostly double for a place to fix this? That is, IF, but I doubt this is true, IF every pointer deref goes through a "barrier" function, the exceptions could be raised from them, right? Are the barrier calls placed adequately maybe????? I don't think they are placed for untraced derefs (a fix Tony recently put in) and I imagine you might want those to act the same as traced null derefs. Maybe a pragma??? - Jay > To: hosking at cs.purdue.edu > Date: Mon, 27 Apr 2009 18:18:10 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RuntimeError doesn't work quite as advertised > > I think it ought to be safe to use siglongjmp. > > So we could attach a sigjmpbuf to whatever structure PushEFrame > builds only when it's doing it for a "RuntimeError", and on a runtime > error that's not handled otherwise, we catch the unix signal and > call siglongjmp to get back to the exception handler... > > Here's an example in C: > > #include > #include > > sigjmp_buf env; > > void handler(int x) { siglongjmp(env,1); } > > main() > { > signal(SIGSEGV, handler); > > if(sigsetjmp(env,1)) { > printf("caught signal\n"); > exit(0); > } else { > printf("initialized env\n"); > } > > { > int *a=(void *)0; > printf("a is %d\n", *a /* SEGV */); > /* not reached */ > } > } > > Mika > > > Tony Hosking writes: > >It's probably not generally safe to use RAISE inside a signal > >handler. There are esoteric rules as to what signal handlers can > >handle... > > > >I think we need to think harder on how best to reflect NIL dereference > >as a signal. Perhaps we need explicit NIL checks after all... > > > >On 27 Apr 2009, at 18:31, Mika Nystrom wrote: > > > >> Ok so I tried the "obvious thing", namely, I changed RTSignal.SegV to > >> do > >> > >> RAISE RuntimeError.E(RuntimeError.T.BadMemoryReference); > >> > >> Somewhat to my surprise, this does the right thing for a null method. > >> But somewhat less surprisingly, it loops for NilJump and NilDeref. > >> Is the machine jumping back and re-executing the same instructions > >> after the signal handler returns? > >> > >> Would all hell break loose if one were to special-case EXCEPT > >> RuntimeError.E to store a thread-local jmp_buf that one does a > >> C-style longjmp to? (With a chain back to any higher RuntimeError.E > >> handlers, I suppose...) Or is there a way to get the exception to > >> work out of the signal handler with the normal exception mechanism? > >> > >> Mika > > > >> Mika Nystrom writes: > >>> > >>> Maybe someone else knows more about this than me... > >>> > >>> The following program: > >>> > >>> MODULE Main; > >>> IMPORT RuntimeError, IO; > >>> > >>> PROCEDURE Range() = BEGIN EVAL VAL(-1,CARDINAL) END Range; > >>> > >>> PROCEDURE Assert() = BEGIN <*ASSERT FALSE*> END Assert; > >>> > >>> PROCEDURE NilJump() = VAR x : PROCEDURE() := NIL; BEGIN x() END > >>> NilJump; > >>> > >>> PROCEDURE NilDeref() = > >>> VAR x : REF INTEGER := NIL; b : INTEGER; > >>> BEGIN b := x^ END NilDeref; > >>> > >>> PROCEDURE NilMethod() = > >>> TYPE T = OBJECT METHODS m() END; > >>> VAR t : T; BEGIN t.m() END NilMethod; > >>> > >>> BEGIN > >>> WITH ps = ARRAY OF PROCEDURE() { Range, Assert, NilMethod, NilJump, > >>> NilDeref } DO > >>> FOR i := FIRST(ps) TO LAST(ps) DO > >>> TRY > >>> ps[i]() > >>> EXCEPT > >>> RuntimeError.E(e) => IO.Put("RuntimeError: " & > >>> RuntimeError.Tag(e) & " \n") > >>> END > >>> END > >>> END > >>> END Main. > >>> > >>> yields the following result: > >>> > >>> (1053)trs80:~/test/src>../FreeBSD4/prog > >>> RuntimeError: An enumeration or subrange value was out of range. > >>> RuntimeError: <*ASSERT*> failed. > >>> > >>> > >>> *** > >>> *** runtime error: > >>> *** Segmentation violation - possible attempt to dereference NIL > >>> *** pc = 0x8048a71 = NilMethod + 0x10 in ../src/Main.m3 > >>> *** > >>> > >>> Abort > >>> > >>> Seems to me I ought to see a few more exceptions and not a crash. > >>> > >>> I'm happy to investigate a bit more, but does anyone have a clue > >>> where > >>> to begin? > >>> > >>> Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Apr 28 04:23:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 28 Apr 2009 12:23:57 +1000 Subject: [M3devel] RuntimeError doesn't work quite as advertised In-Reply-To: References: Your message of "Mon, 27 Apr 2009 22:23:41 +1000." <7F78EA61-BF67-4C18-85D4-F0CC5B45276A@cs.purdue.edu> <200904280118.n3S1IAQ2021489@camembert.async.caltech.edu> Message-ID: On 28 Apr 2009, at 11:50, Jay wrote: > 1) Should we just always use sigsetjmp/siglongjmp? > Or, getting the signal mask is much extra expense usually unnecesary? > (imagine the case of there being a stack walker, where not even > setjmp is paid for) > Folks aren't supposed to muck with it willy nilly and should expect > raising/catching an exception to restore to that which it was at the > point of the try? I would have thought so, yes. I thought I had seen use of setjmp/ longjmp instead of _setjmp/_longjmp but it appears some platforms don't restore signal masks (viz. I386_DARWIN). > 2) The inlined NULL checks arounds the "barrier" calls: > - Aren't they just bloating the code for the unusual case? > - Aren't they better left in the barrier functions themselves? > - Besides leading to smaller and therefore faster code (except in > the usual > case of there being a NULL pointer deref, which is always going to > be slow anyway), > can't this then double or mostly double for a place to fix this? > That is, IF, but I doubt this is true, IF every pointer deref goes > through a "barrier" > function, the exceptions could be raised from them, right The point is that we want to do a fast inline check via non-NIL references, so we need to explicitly check for those. This is not the standard NIL check, since it is legal to load NIL from the heap. There are no exceptions to be raised here. The explicit check for loading NIL is only for loads from the heap. Not for stores to the heap. > ? > > > Are the barrier calls placed adequately maybe????? > I don't think they are placed for untraced derefs (a fix Tony > recently put in) > and I imagine you might want those to act the same as traced null > derefs. > Maybe a pragma??? > > > - Jay > > > > To: hosking at cs.purdue.edu > > Date: Mon, 27 Apr 2009 18:18:10 -0700 > > From: mika at async.caltech.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] RuntimeError doesn't work quite as advertised > > > > I think it ought to be safe to use siglongjmp. > > > > So we could attach a sigjmpbuf to whatever structure PushEFrame > > builds only when it's doing it for a "RuntimeError", and on a > runtime > > error that's not handled otherwise, we catch the unix signal and > > call siglongjmp to get back to the exception handler... > > > > Here's an example in C: > > > > #include > > #include > > > > sigjmp_buf env; > > > > void handler(int x) { siglongjmp(env,1); } > > > > main() > > { > > signal(SIGSEGV, handler); > > > > if(sigsetjmp(env,1)) { > > printf("caught signal\n"); > > exit(0); > > } else { > > printf("initialized env\n"); > > } > > > > { > > int *a=(void *)0; > > printf("a is %d\n", *a /* SEGV */); > > /* not reached */ > > } > > } > > > > Mika > > > > > > Tony Hosking writes: > > >It's probably not generally safe to use RAISE inside a signal > > >handler. There are esoteric rules as to what signal handlers can > > >handle... > > > > > >I think we need to think harder on how best to reflect NIL > dereference > > >as a signal. Perhaps we need explicit NIL checks after all... > > > > > >On 27 Apr 2009, at 18:31, Mika Nystrom wrote: > > > > > >> Ok so I tried the "obvious thing", namely, I changed > RTSignal.SegV to > > >> do > > >> > > >> RAISE RuntimeError.E(RuntimeError.T.BadMemoryReference); > > >> > > >> Somewhat to my surprise, this does the right thing for a null > method. > > >> But somewhat less surprisingly, it loops for NilJump and > NilDeref. > > >> Is the machine jumping back and re-executing the same > instructions > > >> after the signal handler returns? > > >> > > >> Would all hell break loose if one were to special-case EXCEPT > > >> RuntimeError.E to store a thread-local jmp_buf that one does a > > >> C-style longjmp to? (With a chain back to any higher > RuntimeError.E > > >> handlers, I suppose...) Or is there a way to get the exception to > > >> work out of the signal handler with the normal exception > mechanism? > > >> > > >> Mika > > > > > >> Mika Nystrom writes: > > >>> > > >>> Maybe someone else knows more about this than me... > > >>> > > >>> The following program: > > >>> > > >>> MODULE Main; > > >>> IMPORT RuntimeError, IO; > > >>> > > >>> PROCEDURE Range() = BEGIN EVAL VAL(-1,CARDINAL) END Range; > > >>> > > >>> PROCEDURE Assert() = BEGIN <*ASSERT FALSE*> END Assert; > > >>> > > >>> PROCEDURE NilJump() = VAR x : PROCEDURE() := NIL; BEGIN x() END > > >>> NilJump; > > >>> > > >>> PROCEDURE NilDeref() = > > >>> VAR x : REF INTEGER := NIL; b : INTEGER; > > >>> BEGIN b := x^ END NilDeref; > > >>> > > >>> PROCEDURE NilMethod() = > > >>> TYPE T = OBJECT METHODS m() END; > > >>> VAR t : T; BEGIN t.m() END NilMethod; > > >>> > > >>> BEGIN > > >>> WITH ps = ARRAY OF PROCEDURE() { Range, Assert, NilMethod, > NilJump, > > >>> NilDeref } DO > > >>> FOR i := FIRST(ps) TO LAST(ps) DO > > >>> TRY > > >>> ps[i]() > > >>> EXCEPT > > >>> RuntimeError.E(e) => IO.Put("RuntimeError: " & > > >>> RuntimeError.Tag(e) & " \n") > > >>> END > > >>> END > > >>> END > > >>> END Main. > > >>> > > >>> yields the following result: > > >>> > > >>> (1053)trs80:~/test/src>../FreeBSD4/prog > > >>> RuntimeError: An enumeration or subrange value was out of range. > > >>> RuntimeError: <*ASSERT*> failed. > > >>> > > >>> > > >>> *** > > >>> *** runtime error: > > >>> *** Segmentation violation - possible attempt to dereference NIL > > >>> *** pc = 0x8048a71 = NilMethod + 0x10 in ../src/Main.m3 > > >>> *** > > >>> > > >>> Abort > > >>> > > >>> Seems to me I ought to see a few more exceptions and not a > crash. > > >>> > > >>> I'm happy to investigate a bit more, but does anyone have a clue > > >>> where > > >>> to begin? > > >>> > > >>> Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Apr 28 08:29:37 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 28 Apr 2009 08:29:37 +0200 Subject: [M3devel] CM3 release build regression tests not terminating Message-ID: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> Hi, does anybody know what's keeping the release-build tests for tinderbox from terminating? I've got lots of stalled regression process trees on my system, and the tinderbox display indicates that none of the release builds seem to succeed. Has anybody changed anything in the scripts? On a closer look, upgrade seems to be stuck in the installer: % ps -axwww 25310 PID TT STAT TIME COMMAND 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/luthien/current -o Jay, did you change any config files recently? Regression tests seemed to have been running again for some days, and then stopped again. I'll try to investigate further this evening, but must leave now for other work... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Tue Apr 28 08:45:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 28 Apr 2009 16:45:29 +1000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> Message-ID: <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> Yes, I had noticed this too. On 28 Apr 2009, at 16:29, Olaf Wagner wrote: > Hi, > > does anybody know what's keeping the release-build tests for tinderbox > from terminating? I've got lots of stalled regression process trees on > my system, and the tinderbox display indicates that none of the > release > builds seem to succeed. Has anybody changed anything in the scripts? > > On a closer look, upgrade seems to be stuck in the installer: > > % ps -axwww 25310 > PID TT STAT TIME COMMAND > 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ > pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ > luthien/current -o > > Jay, did you change any config files recently? > Regression tests seemed to have been running again for some days, > and then > stopped again. > > I'll try to investigate further this evening, but must leave now for > other work... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From jay.krell at cornell.edu Tue Apr 28 09:45:14 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 07:45:14 +0000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> Message-ID: I've never been able to get the tinderbox stuff to work for me. I'll try again. Nothing much from me lately -- pthreads movement to C, and then back. >> Jay, did you change any config files recently? FreeBSD config file changes on 2009-04-13. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: wagner at elegosoft.com > Date: Tue, 28 Apr 2009 16:45:29 +1000 > CC: m3devel at elegosoft.com; manderson at elegosoft.com > Subject: Re: [M3devel] CM3 release build regression tests not terminating > > Yes, I had noticed this too. > > On 28 Apr 2009, at 16:29, Olaf Wagner wrote: > >> Hi, >> >> does anybody know what's keeping the release-build tests for tinderbox >> from terminating? I've got lots of stalled regression process trees on >> my system, and the tinderbox display indicates that none of the >> release >> builds seem to succeed. Has anybody changed anything in the scripts? >> >> On a closer look, upgrade seems to be stuck in the installer: >> >> % ps -axwww 25310 >> PID TT STAT TIME COMMAND >> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >> luthien/current -o >> >> Jay, did you change any config files recently? >> Regression tests seemed to have been running again for some days, >> and then >> stopped again. >> >> I'll try to investigate further this evening, but must leave now for >> other work... >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >> Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> > From jay.krell at cornell.edu Tue Apr 28 10:03:13 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 08:03:13 +0000 Subject: [M3devel] how to find dependent .so files? Message-ID: Normally we have: /usr/local/cm3/bin/someexe /usr/local/cm3/lib/libfoo.so symlink to ../pkg/foo/target/libfoo.so /usr/local/cm3/lib/libbar.so symlink to ../pkg/bar/target/libbar.so Linking from someexe to $ORIGIN/../lib works, ok. But from libfoo to libbar requires $ORIGIN/../../../lib. or $ORIGIN/../../bar/target. Currently on FreeBSD I set the runpath to $ORIGIN/../lib:$ORIGIN/../../../lib or maybe $ORIGIN/../lib:$ORIGIN/../../lib:$ORIGIN/../../../lib I want to claim this is working, but there are unresolved Tinderbox problems. Let's assume for now it does. I find something as long as "../../.." starts feeling dangerous. It could land somewhere unrelated. I'd prefer a shorter runpath like just $ORIGIN/../lib. To fix this I propose one of two changes. 1) Reverse the symlink relationship: replace /usr/local/cm3/lib/libfoo.so symlink to ../pkg/foo/target/libfoo.so with /usr/local/cm3/lib/libfoo.so real file /usr/local/cm3/pkg/foo/target/libfoo.so symlink to previous This is kind of model changing. There is a package store and all files do really ship into it. Shorter more convenient paths are a higher level construct. I guess. It's a nice model, kind of, but also inconvenient. or 2) Make them hardlinks. Does that work? It seems less model changing. Sort of. It's really extremely similar to previous, except that the package store remains rather self contained. Meanwhile, shipped non-public binaries: /usr/local/cm3/pkg/someexe/target/someexe would would not work. I think they exist though, e.g. obliq. Maybe ship them to /usr/local/cm3/lib? NT386 isn't relevant, so go ahead apply symlinks/hardlinks to the problem pretty arbitrarily I think. There all the .so files (.dll) are in \cm3\bin next to the .exes. The searchpath for .dlls and .exes is roughly the same. NTFS has always had hardlinks. NTFS as of Vista has symlinks. FAT does not have either. Cygwin supports symlinks anywhere via higher level mechanisms (either its own files or usermode Explorer "shortcuts" (think of Mac "aliases")). - Jay From jay.krell at cornell.edu Tue Apr 28 11:14:47 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 09:14:47 +0000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> Message-ID: Well, on FreeBSD 7.0, I get as far as: ew source -> compiling EnvUtils.i3 libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" ew source -> compiling EnvUtils.m3 libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" ew source -> compiling FingerprintFmt.i3 libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" ew source -> compiling TextUtils.i3 libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" Yeah, I understand, I have libc.so.7. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; wagner at elegosoft.com > Date: Tue, 28 Apr 2009 07:45:14 +0000 > CC: m3devel at elegosoft.com; manderson at elegosoft.com > Subject: Re: [M3devel] CM3 release build regression tests not terminating > > > I've never been able to get the tinderbox stuff to work for me. > I'll try again. > Nothing much from me lately -- pthreads movement to C, and then back. > >>> Jay, did you change any config files recently? > > FreeBSD config file changes on 2009-04-13. > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: wagner at elegosoft.com >> Date: Tue, 28 Apr 2009 16:45:29 +1000 >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: Re: [M3devel] CM3 release build regression tests not terminating >> >> Yes, I had noticed this too. >> >> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >> >>> Hi, >>> >>> does anybody know what's keeping the release-build tests for tinderbox >>> from terminating? I've got lots of stalled regression process trees on >>> my system, and the tinderbox display indicates that none of the >>> release >>> builds seem to succeed. Has anybody changed anything in the scripts? >>> >>> On a closer look, upgrade seems to be stuck in the installer: >>> >>> % ps -axwww 25310 >>> PID TT STAT TIME COMMAND >>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>> luthien/current -o >>> >>> Jay, did you change any config files recently? >>> Regression tests seemed to have been running again for some days, >>> and then >>> stopped again. >>> >>> I'll try to investigate further this evening, but must leave now for >>> other work... >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> >> From wagner at elegosoft.com Tue Apr 28 11:40:00 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 28 Apr 2009 11:40:00 +0200 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> Message-ID: <20090428114000.kghi05wbw484cook@mail.elegosoft.com> Quoting Jay : > > Well, on FreeBSD 7.0, I get as far as: > > ew source -> compiling EnvUtils.i3 > libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" > ew source -> compiling EnvUtils.m3 > libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" > ew source -> compiling FingerprintFmt.i3 > libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" > ew source -> compiling TextUtils.i3 > libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" > > Yeah, I understand, I have libc.so.7. You need to install the FreeBSD compat packages for backward compatibility. Should work fine then (until cminstall hangs?). Olaf > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu; wagner at elegosoft.com >> Date: Tue, 28 Apr 2009 07:45:14 +0000 >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: Re: [M3devel] CM3 release build regression tests not terminating >> >> >> I've never been able to get the tinderbox stuff to work for me. >> I'll try again. >> Nothing much from me lately -- pthreads movement to C, and then back. >> >>>> Jay, did you change any config files recently? >> >> FreeBSD config file changes on 2009-04-13. >> >> - Jay >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: wagner at elegosoft.com >>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>> >>> Yes, I had noticed this too. >>> >>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>> >>>> Hi, >>>> >>>> does anybody know what's keeping the release-build tests for tinderbox >>>> from terminating? I've got lots of stalled regression process trees on >>>> my system, and the tinderbox display indicates that none of the >>>> release >>>> builds seem to succeed. Has anybody changed anything in the scripts? >>>> >>>> On a closer look, upgrade seems to be stuck in the installer: >>>> >>>> % ps -axwww 25310 >>>> PID TT STAT TIME COMMAND >>>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>>> luthien/current -o >>>> >>>> Jay, did you change any config files recently? >>>> Regression tests seemed to have been running again for some days, >>>> and then >>>> stopped again. >>>> >>>> I'll try to investigate further this evening, but must leave now for >>>> other work... >>>> >>>> Olaf >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>> Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>> 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>> Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> >>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 28 11:45:32 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 28 Apr 2009 11:45:32 +0200 Subject: [M3devel] Fwd: Modula-2 to Modula-3 translator by Aachen University In-Reply-To: <49F5C0DB.5010409@cox.net> References: <20090427084618.hnk460mh440c880c@mail.elegosoft.com> <49F5C0DB.5010409@cox.net> Message-ID: <20090428114532.sy26ftrzdgc448kw@mail.elegosoft.com> Hi Michael, could you take care of that and host Rodney's archives on birch with public access? If you drop me the URL, I'll insert it into the CM3 and/or modula3.org pages then. Thanks in advance, Olaf Quoting "Rodney M. Bates" : > I have a local copy of it, but haven't built/run it in several years. > I have used it successfully on two or three conversions in the past. > Can we make space at elegosoft? I'm pretty busy moving house now, > but could quickly put my current files up, then try in a couple of > months to see if it has suffered any bitrot. > > Olaf Wagner wrote: >> Perhaps somebody on the public list knows something... >> >> ----- Forwarded message from trijezdci at gmail.com ----- >> Date: Sun, 26 Apr 2009 15:57:36 +0900 >> From: Benjamin Kowarsch >> Reply-To: Benjamin Kowarsch >> Subject: Modula-2 to Modula-3 translator by Aachen University >> To: m3-support at elego.de >> >> Dear Sirs, >> >> I am trying to get the Modula-2 section in the Catalog of Compilers >> updated and there is one entry of a Modula-2 to Modula-3 translator by >> Peter Klein at University of Aachen for which all links and email >> addresses seem to be dead. University of Aachen was unable to give me >> any information either. >> >> I wonder if you know whether this translator is still availabe and if >> so at which URL, or where his author Peter Klein can be contacted. >> >> thank you >> regards >> benjamin >> >> >> ----- End forwarded message ----- >> >> > Rodney Bates > rodney.m.bates at cox.net -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 28 11:58:56 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 09:58:56 +0000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <20090428114000.kghi05wbw484cook@mail.elegosoft.com> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> Message-ID: Right, now it hangs having printed..I know this looks a bit of nonsense..stuff from right around: M3_BACKEND_MODE = "3" % -- defines how the frontend, backend, and assembler interact % "0" -- don't call m3_backend, M3CG produces object code % "1" -- don't call m3_backend, M3CG produces assembly code % "2" -- call m3_backend, it produces object code % "3" -- call m3_backend, it produces assembly code however, this is noticably pretty close to the last BEGIN_CONFIG. Maybe the carriage returns confused it. I'll see.. I did introduce them recently by accident. gdb reported some errors and no symbols in the callstack having connected to it, on FreeBSD. If need be I can try debugging it on another system.. (aside, philosophy: all text processing code should treat \n, \r, and \r\n in put the same, unless you are writing a terminal driver, then \r has a separate meaning useful for implementing spinners..) - Jay ---------------------------------------- > Date: Tue, 28 Apr 2009 11:40:00 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com > Subject: RE: [M3devel] CM3 release build regression tests not terminating > > Quoting Jay : > >> >> Well, on FreeBSD 7.0, I get as far as: >> >> ew source -> compiling EnvUtils.i3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" >> ew source -> compiling EnvUtils.m3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" >> ew source -> compiling FingerprintFmt.i3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" >> ew source -> compiling TextUtils.i3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" >> >> Yeah, I understand, I have libc.so.7. > > You need to install the FreeBSD compat packages for backward > compatibility. Should work fine then (until cminstall hangs?). > > Olaf > >> >> - Jay >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>> >>> >>> I've never been able to get the tinderbox stuff to work for me. >>> I'll try again. >>> Nothing much from me lately -- pthreads movement to C, and then back. >>> >>>>> Jay, did you change any config files recently? >>> >>> FreeBSD config file changes on 2009-04-13. >>> >>> - Jay >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> To: wagner at elegosoft.com >>>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>>> >>>> Yes, I had noticed this too. >>>> >>>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>>> >>>>> Hi, >>>>> >>>>> does anybody know what's keeping the release-build tests for tinderbox >>>>> from terminating? I've got lots of stalled regression process trees on >>>>> my system, and the tinderbox display indicates that none of the >>>>> release >>>>> builds seem to succeed. Has anybody changed anything in the scripts? >>>>> >>>>> On a closer look, upgrade seems to be stuck in the installer: >>>>> >>>>> % ps -axwww 25310 >>>>> PID TT STAT TIME COMMAND >>>>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>>>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>>>> luthien/current -o >>>>> >>>>> Jay, did you change any config files recently? >>>>> Regression tests seemed to have been running again for some days, >>>>> and then >>>>> stopped again. >>>>> >>>>> I'll try to investigate further this evening, but must leave now for >>>>> other work... >>>>> >>>>> Olaf >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>>> Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>> 45 86 95 >>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>>> Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>> DE163214194 >>>>> >>>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 28 12:14:37 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 10:14:37 +0000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <20090428114000.kghi05wbw484cook@mail.elegosoft.com> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> Message-ID: It creates a file named "df-k" and hangs here: (gdb) where #0 0x080f417f in select () #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, writefds=0x28127138, exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/FreeBSD4/select.c:13 #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, M3_CEtG8K_timeout=0xbfbfe6d8) at ThreadPosix.m3:714 #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, M3_AicXUJ_alertable=0 '\0') at ThreadPosix.m3:555 #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at ThreadPosix.m3:539 #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at ProcessPosix.m3:294 #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at System.m3:527 #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, M3_EkfbeH_env=0x0, M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at OSPOSIX.m3:19 #10 0x0804c31c in Main__DoIt () at Main.m3:122 #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at RTLinker.m3:395 #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at RTLinker.m3:109 #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at RTLinker.m3:118 #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at _m3main.mc:4 Notice it using user threads, so old m3core/libm3. df doesn't appear to be any longer running. Why it prints about the backend mode, I don't know. (and yes, I get it -- df -k is directly related to GetDiskSpace..if this is how one checks diskspace on Unix...I think we should punt, unless posix actually specifies the precise output format of this command it is very reliably parsed...) - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com > Subject: RE: [M3devel] CM3 release build regression tests not terminating > Date: Tue, 28 Apr 2009 09:58:56 +0000 > > > Right, now it hangs having printed..I know this looks a bit of nonsense..stuff from right around: > > > M3_BACKEND_MODE = "3" > % -- defines how the frontend, backend, and assembler interact > % "0" -- don't call m3_backend, M3CG produces object code > % "1" -- don't call m3_backend, M3CG produces assembly code > % "2" -- call m3_backend, it produces object code > % "3" -- call m3_backend, it produces assembly code > > > however, this is noticably pretty close to the last BEGIN_CONFIG. > > Maybe the carriage returns confused it. I'll see.. > I did introduce them recently by accident. > gdb reported some errors and no symbols in the callstack having connected to it, on FreeBSD. If need be I can try debugging it on another system.. > > > (aside, philosophy: all text processing code should treat \n, \r, and \r\n in put the same, unless you are writing a terminal driver, then \r has a separate meaning useful for implementing spinners..) > > > - Jay > > > ---------------------------------------- >> Date: Tue, 28 Apr 2009 11:40:00 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: RE: [M3devel] CM3 release build regression tests not terminating >> >> Quoting Jay : >> >>> >>> Well, on FreeBSD 7.0, I get as far as: >>> >>> ew source -> compiling EnvUtils.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" >>> ew source -> compiling EnvUtils.m3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" >>> ew source -> compiling FingerprintFmt.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" >>> ew source -> compiling TextUtils.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" >>> >>> Yeah, I understand, I have libc.so.7. >> >> You need to install the FreeBSD compat packages for backward >> compatibility. Should work fine then (until cminstall hangs?). >> >> Olaf >> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>>> >>>> >>>> I've never been able to get the tinderbox stuff to work for me. >>>> I'll try again. >>>> Nothing much from me lately -- pthreads movement to C, and then back. >>>> >>>>>> Jay, did you change any config files recently? >>>> >>>> FreeBSD config file changes on 2009-04-13. >>>> >>>> - Jay >>>> >>>> ---------------------------------------- >>>>> From: hosking at cs.purdue.edu >>>>> To: wagner at elegosoft.com >>>>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>>>> >>>>> Yes, I had noticed this too. >>>>> >>>>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> does anybody know what's keeping the release-build tests for tinderbox >>>>>> from terminating? I've got lots of stalled regression process trees on >>>>>> my system, and the tinderbox display indicates that none of the >>>>>> release >>>>>> builds seem to succeed. Has anybody changed anything in the scripts? >>>>>> >>>>>> On a closer look, upgrade seems to be stuck in the installer: >>>>>> >>>>>> % ps -axwww 25310 >>>>>> PID TT STAT TIME COMMAND >>>>>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>>>>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>>>>> luthien/current -o >>>>>> >>>>>> Jay, did you change any config files recently? >>>>>> Regression tests seemed to have been running again for some days, >>>>>> and then >>>>>> stopped again. >>>>>> >>>>>> I'll try to investigate further this evening, but must leave now for >>>>>> other work... >>>>>> >>>>>> Olaf >>>>>> -- >>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>>>> Germany >>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>>> 45 86 95 >>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>>>> Berlin >>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>> DE163214194 >>>>>> >>>>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 28 12:48:55 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 28 Apr 2009 12:48:55 +0200 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> Message-ID: <20090428124855.paxjik1misgc00ow@mail.elegosoft.com> Quoting Jay : > > It creates a file named "df-k" and hangs here: > > (gdb) where > #0 0x080f417f in select () > #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, writefds=0x28127138, > exceptfds=0x28127148, timeout=0xbfbfe6d8) at > ../src/runtime/FreeBSD4/select.c:13 > #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, > M3_CEtG8K_timeout=0xbfbfe6d8) > at ThreadPosix.m3:714 > #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 > #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, > M3_AicXUJ_alertable=0 '\0') > at ThreadPosix.m3:555 > #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at > ThreadPosix.m3:539 > #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at > ProcessPosix.m3:294 > #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at System.m3:527 > #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, > M3_EkfbeH_env=0x0, > M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 > #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at > OSPOSIX.m3:19 > #10 0x0804c31c in Main__DoIt () at Main.m3:122 > #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 > #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at > RTLinker.m3:395 > #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at > RTLinker.m3:109 > #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at > RTLinker.m3:118 > #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at > _m3main.mc:4 > > Notice it using user threads, so old m3core/libm3. > df doesn't appear to be any longer running. > Why it prints about the backend mode, I don't know. > > (and yes, I get it -- df -k is directly related to GetDiskSpace..if > this is how one checks diskspace on Unix...I think we should punt, > unless posix actually specifies the precise output format of this > command it is very reliably parsed...) You mean it's trying to _read_ df-k, which should have been created by the packaging scripts? If so, it's my fault; it should not try to read a file that isn't there. Or do you really mean it's hanging when trying to create that file? Creating df-k should be pretty straight forward on any POSIX system, as long as the file system isn't corrupt. Olaf > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: RE: [M3devel] CM3 release build regression tests not terminating >> Date: Tue, 28 Apr 2009 09:58:56 +0000 >> >> >> Right, now it hangs having printed..I know this looks a bit of >> nonsense..stuff from right around: >> >> >> M3_BACKEND_MODE = "3" >> % -- defines how the frontend, backend, and assembler interact >> % "0" -- don't call m3_backend, M3CG produces object code >> % "1" -- don't call m3_backend, M3CG produces assembly code >> % "2" -- call m3_backend, it produces object code >> % "3" -- call m3_backend, it produces assembly code >> >> >> however, this is noticably pretty close to the last BEGIN_CONFIG. >> >> Maybe the carriage returns confused it. I'll see.. >> I did introduce them recently by accident. >> gdb reported some errors and no symbols in the callstack having >> connected to it, on FreeBSD. If need be I can try debugging it on >> another system.. >> >> >> (aside, philosophy: all text processing code should treat \n, \r, >> and \r\n in put the same, unless you are writing a terminal driver, >> then \r has a separate meaning useful for implementing spinners..) >> >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Tue, 28 Apr 2009 11:40:00 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: RE: [M3devel] CM3 release build regression tests not terminating >>> >>> Quoting Jay : >>> >>>> >>>> Well, on FreeBSD 7.0, I get as far as: >>>> >>>> ew source -> compiling EnvUtils.i3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> ew source -> compiling EnvUtils.m3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> ew source -> compiling FingerprintFmt.i3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> ew source -> compiling TextUtils.i3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> >>>> Yeah, I understand, I have libc.so.7. >>> >>> You need to install the FreeBSD compat packages for backward >>> compatibility. Should work fine then (until cminstall hangs?). >>> >>> Olaf >>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>>>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>>>> >>>>> >>>>> I've never been able to get the tinderbox stuff to work for me. >>>>> I'll try again. >>>>> Nothing much from me lately -- pthreads movement to C, and then back. >>>>> >>>>>>> Jay, did you change any config files recently? >>>>> >>>>> FreeBSD config file changes on 2009-04-13. >>>>> >>>>> - Jay >>>>> >>>>> ---------------------------------------- >>>>>> From: hosking at cs.purdue.edu >>>>>> To: wagner at elegosoft.com >>>>>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>>> terminating >>>>>> >>>>>> Yes, I had noticed this too. >>>>>> >>>>>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> does anybody know what's keeping the release-build tests for tinderbox >>>>>>> from terminating? I've got lots of stalled regression process trees on >>>>>>> my system, and the tinderbox display indicates that none of the >>>>>>> release >>>>>>> builds seem to succeed. Has anybody changed anything in the scripts? >>>>>>> >>>>>>> On a closer look, upgrade seems to be stuck in the installer: >>>>>>> >>>>>>> % ps -axwww 25310 >>>>>>> PID TT STAT TIME COMMAND >>>>>>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>>>>>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>>>>>> luthien/current -o >>>>>>> >>>>>>> Jay, did you change any config files recently? >>>>>>> Regression tests seemed to have been running again for some days, >>>>>>> and then >>>>>>> stopped again. >>>>>>> >>>>>>> I'll try to investigate further this evening, but must leave now for >>>>>>> other work... >>>>>>> >>>>>>> Olaf >>>>>>> -- >>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>>>>> Germany >>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>>>> 45 86 95 >>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>>>>> Berlin >>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>>> DE163214194 >>>>>>> >>>>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From michael.anderson at elego.de Tue Apr 28 12:58:00 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Tue, 28 Apr 2009 12:58:00 +0200 Subject: [M3devel] Fwd: Modula-2 to Modula-3 translator by Aachen University In-Reply-To: <20090428114532.sy26ftrzdgc448kw@mail.elegosoft.com> References: <20090427084618.hnk460mh440c880c@mail.elegosoft.com> <49F5C0DB.5010409@cox.net> <20090428114532.sy26ftrzdgc448kw@mail.elegosoft.com> Message-ID: <20090428125800.4y2x5a4m8kk4ssoo@mail.elegosoft.com> Hi Rodney, If you'd like to upload the archives to birch:/var/www/m2tom3/ , I'll get a public area set up for them. Cheers, -Mike Zitat von Olaf Wagner : > Hi Michael, > > could you take care of that and host Rodney's archives on birch > with public access? If you drop me the URL, I'll insert it into > the CM3 and/or modula3.org pages then. > > Thanks in advance, > > Olaf > > Quoting "Rodney M. Bates" : > >> I have a local copy of it, but haven't built/run it in several years. >> I have used it successfully on two or three conversions in the past. >> Can we make space at elegosoft? I'm pretty busy moving house now, >> but could quickly put my current files up, then try in a couple of >> months to see if it has suffered any bitrot. >> >> Olaf Wagner wrote: >>> Perhaps somebody on the public list knows something... >>> >>> ----- Forwarded message from trijezdci at gmail.com ----- >>> Date: Sun, 26 Apr 2009 15:57:36 +0900 >>> From: Benjamin Kowarsch >>> Reply-To: Benjamin Kowarsch >>> Subject: Modula-2 to Modula-3 translator by Aachen University >>> To: m3-support at elego.de >>> >>> Dear Sirs, >>> >>> I am trying to get the Modula-2 section in the Catalog of Compilers >>> updated and there is one entry of a Modula-2 to Modula-3 translator by >>> Peter Klein at University of Aachen for which all links and email >>> addresses seem to be dead. University of Aachen was unable to give me >>> any information either. >>> >>> I wonder if you know whether this translator is still availabe and if >>> so at which URL, or where his author Peter Klein can be contacted. >>> >>> thank you >>> regards >>> benjamin >>> >>> >>> ----- End forwarded message ----- >>> >>> >> Rodney Bates >> rodney.m.bates at cox.net > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From hosking at cs.purdue.edu Tue Apr 28 13:11:42 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 28 Apr 2009 21:11:42 +1000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> Message-ID: <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> What could possibly have changed here. It used to work fine on multiple platforms. On 28 Apr 2009, at 20:14, Jay wrote: > > It creates a file named "df-k" and hangs here: > > (gdb) where > #0 0x080f417f in select () > #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, > writefds=0x28127138, > exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ > FreeBSD4/select.c:13 > #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, > M3_CEtG8K_timeout=0xbfbfe6d8) > at ThreadPosix.m3:714 > #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 > #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, > M3_AicXUJ_alertable=0 '\0') > at ThreadPosix.m3:555 > #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at > ThreadPosix.m3:539 > #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at > ProcessPosix.m3:294 > #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at > System.m3:527 > #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, > M3_EkfbeH_env=0x0, > M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 > #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at > OSPOSIX.m3:19 > #10 0x0804c31c in Main__DoIt () at Main.m3:122 > #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 > #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at > RTLinker.m3:395 > #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at > RTLinker.m3:109 > #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at > RTLinker.m3:118 > #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at > _m3main.mc:4 > > Notice it using user threads, so old m3core/libm3. > df doesn't appear to be any longer running. > Why it prints about the backend mode, I don't know. > > (and yes, I get it -- df -k is directly related to GetDiskSpace..if > this is how one checks diskspace on Unix...I think we should punt, > unless posix actually specifies the precise output format of this > command it is very reliably parsed...) > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: RE: [M3devel] CM3 release build regression tests not >> terminating >> Date: Tue, 28 Apr 2009 09:58:56 +0000 >> >> >> Right, now it hangs having printed..I know this looks a bit of >> nonsense..stuff from right around: >> >> >> M3_BACKEND_MODE = "3" >> % -- defines how the frontend, backend, and assembler interact >> % "0" -- don't call m3_backend, M3CG produces object code >> % "1" -- don't call m3_backend, M3CG produces assembly code >> % "2" -- call m3_backend, it produces object code >> % "3" -- call m3_backend, it produces assembly code >> >> >> however, this is noticably pretty close to the last BEGIN_CONFIG. >> >> Maybe the carriage returns confused it. I'll see.. >> I did introduce them recently by accident. >> gdb reported some errors and no symbols in the callstack having >> connected to it, on FreeBSD. If need be I can try debugging it on >> another system.. >> >> >> (aside, philosophy: all text processing code should treat \n, \r, >> and \r\n in put the same, unless you are writing a terminal driver, >> then \r has a separate meaning useful for implementing spinners..) >> >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Tue, 28 Apr 2009 11:40:00 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: RE: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> Quoting Jay : >>> >>>> >>>> Well, on FreeBSD 7.0, I get as far as: >>>> >>>> ew source -> compiling EnvUtils.i3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> ew source -> compiling EnvUtils.m3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> ew source -> compiling FingerprintFmt.i3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> ew source -> compiling TextUtils.i3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> >>>> Yeah, I understand, I have libc.so.7. >>> >>> You need to install the FreeBSD compat packages for backward >>> compatibility. Should work fine then (until cminstall hangs?). >>> >>> Olaf >>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>>>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>> terminating >>>>> >>>>> >>>>> I've never been able to get the tinderbox stuff to work for me. >>>>> I'll try again. >>>>> Nothing much from me lately -- pthreads movement to C, and then >>>>> back. >>>>> >>>>>>> Jay, did you change any config files recently? >>>>> >>>>> FreeBSD config file changes on 2009-04-13. >>>>> >>>>> - Jay >>>>> >>>>> ---------------------------------------- >>>>>> From: hosking at cs.purdue.edu >>>>>> To: wagner at elegosoft.com >>>>>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>>> terminating >>>>>> >>>>>> Yes, I had noticed this too. >>>>>> >>>>>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> does anybody know what's keeping the release-build tests for >>>>>>> tinderbox >>>>>>> from terminating? I've got lots of stalled regression process >>>>>>> trees on >>>>>>> my system, and the tinderbox display indicates that none of the >>>>>>> release >>>>>>> builds seem to succeed. Has anybody changed anything in the >>>>>>> scripts? >>>>>>> >>>>>>> On a closer look, upgrade seems to be stuck in the installer: >>>>>>> >>>>>>> % ps -axwww 25310 >>>>>>> PID TT STAT TIME COMMAND >>>>>>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>>>>>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>>>>>> luthien/current -o >>>>>>> >>>>>>> Jay, did you change any config files recently? >>>>>>> Regression tests seemed to have been running again for some >>>>>>> days, >>>>>>> and then >>>>>>> stopped again. >>>>>>> >>>>>>> I'll try to investigate further this evening, but must leave >>>>>>> now for >>>>>>> other work... >>>>>>> >>>>>>> Olaf >>>>>>> -- >>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>>>>> Germany >>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>>> 23 >>>>>>> 45 86 95 >>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>>>>> Berlin >>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>>> DE163214194 >>>>>>> >>>>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 28 13:17:29 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 11:17:29 +0000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> Message-ID: The changes went in two weeks ago 4/14, were they definitely working? I can try it again, hopefully without the full tinderbox stuff. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 28 Apr 2009 21:11:42 +1000 > CC: m3devel at elegosoft.com; manderson at elegosoft.com > Subject: Re: [M3devel] CM3 release build regression tests not terminating > > What could possibly have changed here. It used to work fine on > multiple platforms. > > On 28 Apr 2009, at 20:14, Jay wrote: > >> >> It creates a file named "df-k" and hangs here: >> >> (gdb) where >> #0 0x080f417f in select () >> #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, >> writefds=0x28127138, >> exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ >> FreeBSD4/select.c:13 >> #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, >> M3_CEtG8K_timeout=0xbfbfe6d8) >> at ThreadPosix.m3:714 >> #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 >> #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, >> M3_AicXUJ_alertable=0 '\0') >> at ThreadPosix.m3:555 >> #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at >> ThreadPosix.m3:539 >> #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at >> ProcessPosix.m3:294 >> #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at >> System.m3:527 >> #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, >> M3_EkfbeH_env=0x0, >> M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 >> #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at >> OSPOSIX.m3:19 >> #10 0x0804c31c in Main__DoIt () at Main.m3:122 >> #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 >> #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at >> RTLinker.m3:395 >> #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at >> RTLinker.m3:109 >> #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at >> RTLinker.m3:118 >> #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at >> _m3main.mc:4 >> >> Notice it using user threads, so old m3core/libm3. >> df doesn't appear to be any longer running. >> Why it prints about the backend mode, I don't know. >> >> (and yes, I get it -- df -k is directly related to GetDiskSpace..if >> this is how one checks diskspace on Unix...I think we should punt, >> unless posix actually specifies the precise output format of this >> command it is very reliably parsed...) >> >> - Jay >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com >>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: RE: [M3devel] CM3 release build regression tests not >>> terminating >>> Date: Tue, 28 Apr 2009 09:58:56 +0000 >>> >>> >>> Right, now it hangs having printed..I know this looks a bit of >>> nonsense..stuff from right around: >>> >>> >>> M3_BACKEND_MODE = "3" >>> % -- defines how the frontend, backend, and assembler interact >>> % "0" -- don't call m3_backend, M3CG produces object code >>> % "1" -- don't call m3_backend, M3CG produces assembly code >>> % "2" -- call m3_backend, it produces object code >>> % "3" -- call m3_backend, it produces assembly code >>> >>> >>> however, this is noticably pretty close to the last BEGIN_CONFIG. >>> >>> Maybe the carriage returns confused it. I'll see.. >>> I did introduce them recently by accident. >>> gdb reported some errors and no symbols in the callstack having >>> connected to it, on FreeBSD. If need be I can try debugging it on >>> another system.. >>> >>> >>> (aside, philosophy: all text processing code should treat \n, \r, >>> and \r\n in put the same, unless you are writing a terminal driver, >>> then \r has a separate meaning useful for implementing spinners..) >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> Date: Tue, 28 Apr 2009 11:40:00 +0200 >>>> From: wagner at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>>> Subject: RE: [M3devel] CM3 release build regression tests not >>>> terminating >>>> >>>> Quoting Jay : >>>> >>>>> >>>>> Well, on FreeBSD 7.0, I get as far as: >>>>> >>>>> ew source -> compiling EnvUtils.i3 >>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>> required by "cm3cg" >>>>> ew source -> compiling EnvUtils.m3 >>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>> required by "cm3cg" >>>>> ew source -> compiling FingerprintFmt.i3 >>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>> required by "cm3cg" >>>>> ew source -> compiling TextUtils.i3 >>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>> required by "cm3cg" >>>>> >>>>> Yeah, I understand, I have libc.so.7. >>>> >>>> You need to install the FreeBSD compat packages for backward >>>> compatibility. Should work fine then (until cminstall hangs?). >>>> >>>> Olaf >>>> >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>>>>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>>> terminating >>>>>> >>>>>> >>>>>> I've never been able to get the tinderbox stuff to work for me. >>>>>> I'll try again. >>>>>> Nothing much from me lately -- pthreads movement to C, and then >>>>>> back. >>>>>> >>>>>>>> Jay, did you change any config files recently? >>>>>> >>>>>> FreeBSD config file changes on 2009-04-13. >>>>>> >>>>>> - Jay >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: hosking at cs.purdue.edu >>>>>>> To: wagner at elegosoft.com >>>>>>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>>>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>>>> terminating >>>>>>> >>>>>>> Yes, I had noticed this too. >>>>>>> >>>>>>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> does anybody know what's keeping the release-build tests for >>>>>>>> tinderbox >>>>>>>> from terminating? I've got lots of stalled regression process >>>>>>>> trees on >>>>>>>> my system, and the tinderbox display indicates that none of the >>>>>>>> release >>>>>>>> builds seem to succeed. Has anybody changed anything in the >>>>>>>> scripts? >>>>>>>> >>>>>>>> On a closer look, upgrade seems to be stuck in the installer: >>>>>>>> >>>>>>>> % ps -axwww 25310 >>>>>>>> PID TT STAT TIME COMMAND >>>>>>>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>>>>>>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>>>>>>> luthien/current -o >>>>>>>> >>>>>>>> Jay, did you change any config files recently? >>>>>>>> Regression tests seemed to have been running again for some >>>>>>>> days, >>>>>>>> and then >>>>>>>> stopped again. >>>>>>>> >>>>>>>> I'll try to investigate further this evening, but must leave >>>>>>>> now for >>>>>>>> other work... >>>>>>>> >>>>>>>> Olaf >>>>>>>> -- >>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>>>>>> Germany >>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>>>> 23 >>>>>>>> 45 86 95 >>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>>>>>> Berlin >>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>>>> DE163214194 >>>>>>>> >>>>>>> >>>> >>>> >>>> >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 28 13:43:40 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 11:43:40 +0000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> Message-ID: Just a reminder, I THINK the hang is almost entirely in a 5.4 system. At least it is in m3core 5.4. And current sysutils/cminstall. And probably 5.4 cm3cg but I don't know for certain yet. Look at the stack below. Do we really care? I haven't tested if it hangs against current compiler/runtime. Here is a suggestion -- ok, bootstrapping from 5.4 is reasonable -- build the compiler -- but must tinderbox include running cminstall build against 5.4? I could be wrong, misobserving, whatever. I can go and fix user threads and see if cminstall hangs with that -- there is an issue of being inefficient wrt waitpid(nohang vs. 0). It is very easy to reproduce. Install 5.4 (which tinderbox does). Do a normal bootstrap thing -- skip m3core, libm3, but otherwise build up to cminstall. And then gdb --args cminstall -dumpcfg wait a sec, control-c. I'm assuming, but haven't tested, that it works ok against current. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com; manderson at elegosoft.com > Subject: RE: [M3devel] CM3 release build regression tests not terminating > Date: Tue, 28 Apr 2009 11:17:29 +0000 > > > The changes went in two weeks ago 4/14, were they definitely working? > I can try it again, hopefully without the full tinderbox stuff. > > - Jay > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Tue, 28 Apr 2009 21:11:42 +1000 >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: Re: [M3devel] CM3 release build regression tests not terminating >> >> What could possibly have changed here. It used to work fine on >> multiple platforms. >> >> On 28 Apr 2009, at 20:14, Jay wrote: >> >>> >>> It creates a file named "df-k" and hangs here: >>> >>> (gdb) where >>> #0 0x080f417f in select () >>> #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, >>> writefds=0x28127138, >>> exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ >>> FreeBSD4/select.c:13 >>> #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, >>> M3_CEtG8K_timeout=0xbfbfe6d8) >>> at ThreadPosix.m3:714 >>> #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 >>> #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, >>> M3_AicXUJ_alertable=0 '\0') >>> at ThreadPosix.m3:555 >>> #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at >>> ThreadPosix.m3:539 >>> #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at >>> ProcessPosix.m3:294 >>> #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at >>> System.m3:527 >>> #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, >>> M3_EkfbeH_env=0x0, >>> M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 >>> #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at >>> OSPOSIX.m3:19 >>> #10 0x0804c31c in Main__DoIt () at Main.m3:122 >>> #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 >>> #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at >>> RTLinker.m3:395 >>> #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at >>> RTLinker.m3:109 >>> #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at >>> RTLinker.m3:118 >>> #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at >>> _m3main.mc:4 >>> >>> Notice it using user threads, so old m3core/libm3. >>> df doesn't appear to be any longer running. >>> Why it prints about the backend mode, I don't know. >>> >>> (and yes, I get it -- df -k is directly related to GetDiskSpace..if >>> this is how one checks diskspace on Unix...I think we should punt, >>> unless posix actually specifies the precise output format of this >>> command it is very reliably parsed...) >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: wagner at elegosoft.com >>>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>>> Subject: RE: [M3devel] CM3 release build regression tests not >>>> terminating >>>> Date: Tue, 28 Apr 2009 09:58:56 +0000 >>>> >>>> >>>> Right, now it hangs having printed..I know this looks a bit of >>>> nonsense..stuff from right around: >>>> >>>> >>>> M3_BACKEND_MODE = "3" >>>> % -- defines how the frontend, backend, and assembler interact >>>> % "0" -- don't call m3_backend, M3CG produces object code >>>> % "1" -- don't call m3_backend, M3CG produces assembly code >>>> % "2" -- call m3_backend, it produces object code >>>> % "3" -- call m3_backend, it produces assembly code >>>> >>>> >>>> however, this is noticably pretty close to the last BEGIN_CONFIG. >>>> >>>> Maybe the carriage returns confused it. I'll see.. >>>> I did introduce them recently by accident. >>>> gdb reported some errors and no symbols in the callstack having >>>> connected to it, on FreeBSD. If need be I can try debugging it on >>>> another system.. >>>> >>>> >>>> (aside, philosophy: all text processing code should treat \n, \r, >>>> and \r\n in put the same, unless you are writing a terminal driver, >>>> then \r has a separate meaning useful for implementing spinners..) >>>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> Date: Tue, 28 Apr 2009 11:40:00 +0200 >>>>> From: wagner at elegosoft.com >>>>> To: jay.krell at cornell.edu >>>>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>>>> Subject: RE: [M3devel] CM3 release build regression tests not >>>>> terminating >>>>> >>>>> Quoting Jay : >>>>> >>>>>> >>>>>> Well, on FreeBSD 7.0, I get as far as: >>>>>> >>>>>> ew source -> compiling EnvUtils.i3 >>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>> required by "cm3cg" >>>>>> ew source -> compiling EnvUtils.m3 >>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>> required by "cm3cg" >>>>>> ew source -> compiling FingerprintFmt.i3 >>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>> required by "cm3cg" >>>>>> ew source -> compiling TextUtils.i3 >>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>> required by "cm3cg" >>>>>> >>>>>> Yeah, I understand, I have libc.so.7. >>>>> >>>>> You need to install the FreeBSD compat packages for backward >>>>> compatibility. Should work fine then (until cminstall hangs?). >>>>> >>>>> Olaf >>>>> >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>>>>>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>>>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>>>> terminating >>>>>>> >>>>>>> >>>>>>> I've never been able to get the tinderbox stuff to work for me. >>>>>>> I'll try again. >>>>>>> Nothing much from me lately -- pthreads movement to C, and then >>>>>>> back. >>>>>>> >>>>>>>>> Jay, did you change any config files recently? >>>>>>> >>>>>>> FreeBSD config file changes on 2009-04-13. >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: hosking at cs.purdue.edu >>>>>>>> To: wagner at elegosoft.com >>>>>>>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>>>>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>>>>> terminating >>>>>>>> >>>>>>>> Yes, I had noticed this too. >>>>>>>> >>>>>>>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> does anybody know what's keeping the release-build tests for >>>>>>>>> tinderbox >>>>>>>>> from terminating? I've got lots of stalled regression process >>>>>>>>> trees on >>>>>>>>> my system, and the tinderbox display indicates that none of the >>>>>>>>> release >>>>>>>>> builds seem to succeed. Has anybody changed anything in the >>>>>>>>> scripts? >>>>>>>>> >>>>>>>>> On a closer look, upgrade seems to be stuck in the installer: >>>>>>>>> >>>>>>>>> % ps -axwww 25310 >>>>>>>>> PID TT STAT TIME COMMAND >>>>>>>>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>>>>>>>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>>>>>>>> luthien/current -o >>>>>>>>> >>>>>>>>> Jay, did you change any config files recently? >>>>>>>>> Regression tests seemed to have been running again for some >>>>>>>>> days, >>>>>>>>> and then >>>>>>>>> stopped again. >>>>>>>>> >>>>>>>>> I'll try to investigate further this evening, but must leave >>>>>>>>> now for >>>>>>>>> other work... >>>>>>>>> >>>>>>>>> Olaf >>>>>>>>> -- >>>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>>>>>>> Germany >>>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>>>>> 23 >>>>>>>>> 45 86 95 >>>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>>>>>>> Berlin >>>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>>>>> DE163214194 >>>>>>>>> >>>>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 28 13:45:43 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 11:45:43 +0000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> Message-ID: once you control-c in gdb it completes with an error the df-k file is zero length.. I can poke more... but I doubt we care about the 5.4 mix.. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Tue, 28 Apr 2009 11:43:40 +0000 > CC: m3devel at elegosoft.com; manderson at elegosoft.com > Subject: Re: [M3devel] CM3 release build regression tests not terminating > > > Just a reminder, I THINK the hang is almost entirely in a 5.4 system. > At least it is in m3core 5.4. > And current sysutils/cminstall. > And probably 5.4 cm3cg but I don't know for certain yet. > Look at the stack below. > Do we really care? > > > I haven't tested if it hangs against current compiler/runtime. > > > Here is a suggestion -- ok, bootstrapping from 5.4 is reasonable -- build the compiler -- but must tinderbox include running cminstall build against 5.4? > > > I could be wrong, misobserving, whatever. > I can go and fix user threads and see if cminstall hangs with that -- there is an issue of being inefficient wrt waitpid(nohang vs. 0). > > > It is very easy to reproduce. > Install 5.4 (which tinderbox does). > Do a normal bootstrap thing -- skip m3core, libm3, but otherwise build up to cminstall. And then gdb --args cminstall -dumpcfg wait a sec, control-c. > > I'm assuming, but haven't tested, that it works ok against current. > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: RE: [M3devel] CM3 release build regression tests not terminating >> Date: Tue, 28 Apr 2009 11:17:29 +0000 >> >> >> The changes went in two weeks ago 4/14, were they definitely working? >> I can try it again, hopefully without the full tinderbox stuff. >> >> - Jay >> >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Tue, 28 Apr 2009 21:11:42 +1000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>> >>> What could possibly have changed here. It used to work fine on >>> multiple platforms. >>> >>> On 28 Apr 2009, at 20:14, Jay wrote: >>> >>>> >>>> It creates a file named "df-k" and hangs here: >>>> >>>> (gdb) where >>>> #0 0x080f417f in select () >>>> #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, >>>> writefds=0x28127138, >>>> exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ >>>> FreeBSD4/select.c:13 >>>> #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, >>>> M3_CEtG8K_timeout=0xbfbfe6d8) >>>> at ThreadPosix.m3:714 >>>> #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 >>>> #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, >>>> M3_AicXUJ_alertable=0 '\0') >>>> at ThreadPosix.m3:555 >>>> #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at >>>> ThreadPosix.m3:539 >>>> #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at >>>> ProcessPosix.m3:294 >>>> #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at >>>> System.m3:527 >>>> #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, >>>> M3_EkfbeH_env=0x0, >>>> M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 >>>> #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at >>>> OSPOSIX.m3:19 >>>> #10 0x0804c31c in Main__DoIt () at Main.m3:122 >>>> #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 >>>> #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at >>>> RTLinker.m3:395 >>>> #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at >>>> RTLinker.m3:109 >>>> #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at >>>> RTLinker.m3:118 >>>> #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at >>>> _m3main.mc:4 >>>> >>>> Notice it using user threads, so old m3core/libm3. >>>> df doesn't appear to be any longer running. >>>> Why it prints about the backend mode, I don't know. >>>> >>>> (and yes, I get it -- df -k is directly related to GetDiskSpace..if >>>> this is how one checks diskspace on Unix...I think we should punt, >>>> unless posix actually specifies the precise output format of this >>>> command it is very reliably parsed...) >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: wagner at elegosoft.com >>>>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>>>> Subject: RE: [M3devel] CM3 release build regression tests not >>>>> terminating >>>>> Date: Tue, 28 Apr 2009 09:58:56 +0000 >>>>> >>>>> >>>>> Right, now it hangs having printed..I know this looks a bit of >>>>> nonsense..stuff from right around: >>>>> >>>>> >>>>> M3_BACKEND_MODE = "3" >>>>> % -- defines how the frontend, backend, and assembler interact >>>>> % "0" -- don't call m3_backend, M3CG produces object code >>>>> % "1" -- don't call m3_backend, M3CG produces assembly code >>>>> % "2" -- call m3_backend, it produces object code >>>>> % "3" -- call m3_backend, it produces assembly code >>>>> >>>>> >>>>> however, this is noticably pretty close to the last BEGIN_CONFIG. >>>>> >>>>> Maybe the carriage returns confused it. I'll see.. >>>>> I did introduce them recently by accident. >>>>> gdb reported some errors and no symbols in the callstack having >>>>> connected to it, on FreeBSD. If need be I can try debugging it on >>>>> another system.. >>>>> >>>>> >>>>> (aside, philosophy: all text processing code should treat \n, \r, >>>>> and \r\n in put the same, unless you are writing a terminal driver, >>>>> then \r has a separate meaning useful for implementing spinners..) >>>>> >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ---------------------------------------- >>>>>> Date: Tue, 28 Apr 2009 11:40:00 +0200 >>>>>> From: wagner at elegosoft.com >>>>>> To: jay.krell at cornell.edu >>>>>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>>>>> Subject: RE: [M3devel] CM3 release build regression tests not >>>>>> terminating >>>>>> >>>>>> Quoting Jay : >>>>>> >>>>>>> >>>>>>> Well, on FreeBSD 7.0, I get as far as: >>>>>>> >>>>>>> ew source -> compiling EnvUtils.i3 >>>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>>> required by "cm3cg" >>>>>>> ew source -> compiling EnvUtils.m3 >>>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>>> required by "cm3cg" >>>>>>> ew source -> compiling FingerprintFmt.i3 >>>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>>> required by "cm3cg" >>>>>>> ew source -> compiling TextUtils.i3 >>>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>>> required by "cm3cg" >>>>>>> >>>>>>> Yeah, I understand, I have libc.so.7. >>>>>> >>>>>> You need to install the FreeBSD compat packages for backward >>>>>> compatibility. Should work fine then (until cminstall hangs?). >>>>>> >>>>>> Olaf >>>>>> >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: jay.krell at cornell.edu >>>>>>>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>>>>>>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>>>>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>>>>> terminating >>>>>>>> >>>>>>>> >>>>>>>> I've never been able to get the tinderbox stuff to work for me. >>>>>>>> I'll try again. >>>>>>>> Nothing much from me lately -- pthreads movement to C, and then >>>>>>>> back. >>>>>>>> >>>>>>>>>> Jay, did you change any config files recently? >>>>>>>> >>>>>>>> FreeBSD config file changes on 2009-04-13. >>>>>>>> >>>>>>>> - Jay >>>>>>>> >>>>>>>> ---------------------------------------- >>>>>>>>> From: hosking at cs.purdue.edu >>>>>>>>> To: wagner at elegosoft.com >>>>>>>>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>>>>>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>>>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>>>>>> terminating >>>>>>>>> >>>>>>>>> Yes, I had noticed this too. >>>>>>>>> >>>>>>>>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> does anybody know what's keeping the release-build tests for >>>>>>>>>> tinderbox >>>>>>>>>> from terminating? I've got lots of stalled regression process >>>>>>>>>> trees on >>>>>>>>>> my system, and the tinderbox display indicates that none of the >>>>>>>>>> release >>>>>>>>>> builds seem to succeed. Has anybody changed anything in the >>>>>>>>>> scripts? >>>>>>>>>> >>>>>>>>>> On a closer look, upgrade seems to be stuck in the installer: >>>>>>>>>> >>>>>>>>>> % ps -axwww 25310 >>>>>>>>>> PID TT STAT TIME COMMAND >>>>>>>>>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>>>>>>>>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>>>>>>>>> luthien/current -o >>>>>>>>>> >>>>>>>>>> Jay, did you change any config files recently? >>>>>>>>>> Regression tests seemed to have been running again for some >>>>>>>>>> days, >>>>>>>>>> and then >>>>>>>>>> stopped again. >>>>>>>>>> >>>>>>>>>> I'll try to investigate further this evening, but must leave >>>>>>>>>> now for >>>>>>>>>> other work... >>>>>>>>>> >>>>>>>>>> Olaf >>>>>>>>>> -- >>>>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>>>>>>>> Germany >>>>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>>>>>> 23 >>>>>>>>>> 45 86 95 >>>>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>>>>>>>> Berlin >>>>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>>>>>> DE163214194 >>>>>>>>>> >>>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 28 13:49:32 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 28 Apr 2009 21:49:32 +1000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> Message-ID: <9AC96562-7045-418A-A069-84EE8613498A@cs.purdue.edu> Sounds about right. 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 28 Apr 2009, at 21:17, Jay wrote: > > The changes went in two weeks ago 4/14, were they definitely working? > I can try it again, hopefully without the full tinderbox stuff. > > - Jay > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Tue, 28 Apr 2009 21:11:42 +1000 >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: Re: [M3devel] CM3 release build regression tests not >> terminating >> >> What could possibly have changed here. It used to work fine on >> multiple platforms. >> >> On 28 Apr 2009, at 20:14, Jay wrote: >> >>> >>> It creates a file named "df-k" and hangs here: >>> >>> (gdb) where >>> #0 0x080f417f in select () >>> #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, >>> writefds=0x28127138, >>> exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ >>> FreeBSD4/select.c:13 >>> #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, >>> M3_CEtG8K_timeout=0xbfbfe6d8) >>> at ThreadPosix.m3:714 >>> #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 >>> #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, >>> M3_AicXUJ_alertable=0 '\0') >>> at ThreadPosix.m3:555 >>> #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at >>> ThreadPosix.m3:539 >>> #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at >>> ProcessPosix.m3:294 >>> #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at >>> System.m3:527 >>> #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, >>> M3_EkfbeH_env=0x0, >>> M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 >>> #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at >>> OSPOSIX.m3:19 >>> #10 0x0804c31c in Main__DoIt () at Main.m3:122 >>> #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 >>> #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at >>> RTLinker.m3:395 >>> #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at >>> RTLinker.m3:109 >>> #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at >>> RTLinker.m3:118 >>> #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at >>> _m3main.mc:4 >>> >>> Notice it using user threads, so old m3core/libm3. >>> df doesn't appear to be any longer running. >>> Why it prints about the backend mode, I don't know. >>> >>> (and yes, I get it -- df -k is directly related to GetDiskSpace..if >>> this is how one checks diskspace on Unix...I think we should punt, >>> unless posix actually specifies the precise output format of this >>> command it is very reliably parsed...) >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: wagner at elegosoft.com >>>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>>> Subject: RE: [M3devel] CM3 release build regression tests not >>>> terminating >>>> Date: Tue, 28 Apr 2009 09:58:56 +0000 >>>> >>>> >>>> Right, now it hangs having printed..I know this looks a bit of >>>> nonsense..stuff from right around: >>>> >>>> >>>> M3_BACKEND_MODE = "3" >>>> % -- defines how the frontend, backend, and assembler interact >>>> % "0" -- don't call m3_backend, M3CG produces object code >>>> % "1" -- don't call m3_backend, M3CG produces assembly code >>>> % "2" -- call m3_backend, it produces object code >>>> % "3" -- call m3_backend, it produces assembly code >>>> >>>> >>>> however, this is noticably pretty close to the last BEGIN_CONFIG. >>>> >>>> Maybe the carriage returns confused it. I'll see.. >>>> I did introduce them recently by accident. >>>> gdb reported some errors and no symbols in the callstack having >>>> connected to it, on FreeBSD. If need be I can try debugging it on >>>> another system.. >>>> >>>> >>>> (aside, philosophy: all text processing code should treat \n, \r, >>>> and \r\n in put the same, unless you are writing a terminal driver, >>>> then \r has a separate meaning useful for implementing spinners..) >>>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> Date: Tue, 28 Apr 2009 11:40:00 +0200 >>>>> From: wagner at elegosoft.com >>>>> To: jay.krell at cornell.edu >>>>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>>>> Subject: RE: [M3devel] CM3 release build regression tests not >>>>> terminating >>>>> >>>>> Quoting Jay : >>>>> >>>>>> >>>>>> Well, on FreeBSD 7.0, I get as far as: >>>>>> >>>>>> ew source -> compiling EnvUtils.i3 >>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>> required by "cm3cg" >>>>>> ew source -> compiling EnvUtils.m3 >>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>> required by "cm3cg" >>>>>> ew source -> compiling FingerprintFmt.i3 >>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>> required by "cm3cg" >>>>>> ew source -> compiling TextUtils.i3 >>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>> required by "cm3cg" >>>>>> >>>>>> Yeah, I understand, I have libc.so.7. >>>>> >>>>> You need to install the FreeBSD compat packages for backward >>>>> compatibility. Should work fine then (until cminstall hangs?). >>>>> >>>>> Olaf >>>>> >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>>>>>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>>>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>>>> terminating >>>>>>> >>>>>>> >>>>>>> I've never been able to get the tinderbox stuff to work for me. >>>>>>> I'll try again. >>>>>>> Nothing much from me lately -- pthreads movement to C, and then >>>>>>> back. >>>>>>> >>>>>>>>> Jay, did you change any config files recently? >>>>>>> >>>>>>> FreeBSD config file changes on 2009-04-13. >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: hosking at cs.purdue.edu >>>>>>>> To: wagner at elegosoft.com >>>>>>>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>>>>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>>>>> terminating >>>>>>>> >>>>>>>> Yes, I had noticed this too. >>>>>>>> >>>>>>>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> does anybody know what's keeping the release-build tests for >>>>>>>>> tinderbox >>>>>>>>> from terminating? I've got lots of stalled regression process >>>>>>>>> trees on >>>>>>>>> my system, and the tinderbox display indicates that none of >>>>>>>>> the >>>>>>>>> release >>>>>>>>> builds seem to succeed. Has anybody changed anything in the >>>>>>>>> scripts? >>>>>>>>> >>>>>>>>> On a closer look, upgrade seems to be stuck in the installer: >>>>>>>>> >>>>>>>>> % ps -axwww 25310 >>>>>>>>> PID TT STAT TIME COMMAND >>>>>>>>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>>>>>>>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3- >>>>>>>>> inst/ >>>>>>>>> luthien/current -o >>>>>>>>> >>>>>>>>> Jay, did you change any config files recently? >>>>>>>>> Regression tests seemed to have been running again for some >>>>>>>>> days, >>>>>>>>> and then >>>>>>>>> stopped again. >>>>>>>>> >>>>>>>>> I'll try to investigate further this evening, but must leave >>>>>>>>> now for >>>>>>>>> other work... >>>>>>>>> >>>>>>>>> Olaf >>>>>>>>> -- >>>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>>>>>>> Germany >>>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>>>>> 23 >>>>>>>>> 45 86 95 >>>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | >>>>>>>>> Sitz: >>>>>>>>> Berlin >>>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt- >>>>>>>>> IdNr: >>>>>>>>> DE163214194 >>>>>>>>> >>>>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Apr 28 14:13:17 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 12:13:17 +0000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <9AC96562-7045-418A-A069-84EE8613498A@cs.purdue.edu> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> <9AC96562-7045-418A-A069-84EE8613498A@cs.purdue.edu> Message-ID: Tony can you clarify? Things stopped working two weeks ago? Or things were working until more recently? It seems like the select call never returns. Whatever is going on, it troubles debugging tools. gdb won't follow the children..which is probably ok, they aren't the problem. truss can't be control-c'ed, but can be killed. "info locals" in gdb often hangs and I have to pkill gdb. Not that info locals ever works well, but it usually doesn't hang gdb. I started putting in RTIO calls. WaitForAll's finishes one Wait call but then hangs on the next. I think we should not run cminstall against 5.4 runtime. Enable user threads as some related scenario.. - Jay ________________________________ > CC: m3devel at elegosoft.com; manderson at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] CM3 release build regression tests not terminating > Date: Tue, 28 Apr 2009 21:49:32 +1000 > > Sounds about right. > > 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 28 Apr 2009, at 21:17, Jay wrote: > > > The changes went in two weeks ago 4/14, were they definitely working? > I can try it again, hopefully without the full tinderbox stuff. > > - Jay > > > ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 28 Apr 2009 21:11:42 +1000 > CC: m3devel at elegosoft.com; manderson at elegosoft.com > Subject: Re: [M3devel] CM3 release build regression tests not terminating > > What could possibly have changed here. It used to work fine on > multiple platforms. > > On 28 Apr 2009, at 20:14, Jay wrote: > > > It creates a file named "df-k" and hangs here: > > (gdb) where > #0 0x080f417f in select () > #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, > writefds=0x28127138, > exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ > FreeBSD4/select.c:13 > #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, > M3_CEtG8K_timeout=0xbfbfe6d8) > at ThreadPosix.m3:714 > #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 > #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, > M3_AicXUJ_alertable=0 '\0') > at ThreadPosix.m3:555 > #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at > ThreadPosix.m3:539 > #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at > ProcessPosix.m3:294 > #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at > System.m3:527 > #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, > M3_EkfbeH_env=0x0, > M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 > #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at > OSPOSIX.m3:19 > #10 0x0804c31c in Main__DoIt () at Main.m3:122 > #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 > #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at > RTLinker.m3:395 > #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at > RTLinker.m3:109 > #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at > RTLinker.m3:118 > #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at > _m3main.mc:4 > > Notice it using user threads, so old m3core/libm3. > df doesn't appear to be any longer running. > Why it prints about the backend mode, I don't know. > > (and yes, I get it -- df -k is directly related to GetDiskSpace..if > this is how one checks diskspace on Unix...I think we should punt, > unless posix actually specifies the precise output format of this > command it is very reliably parsed...) > > - Jay > > > ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com > Subject: RE: [M3devel] CM3 release build regression tests not > terminating > Date: Tue, 28 Apr 2009 09:58:56 +0000 > > > Right, now it hangs having printed..I know this looks a bit of > nonsense..stuff from right around: > > > M3_BACKEND_MODE = "3" > % -- defines how the frontend, backend, and assembler interact > % "0" -- don't call m3_backend, M3CG produces object code > % "1" -- don't call m3_backend, M3CG produces assembly code > % "2" -- call m3_backend, it produces object code > % "3" -- call m3_backend, it produces assembly code > > > however, this is noticably pretty close to the last BEGIN_CONFIG. > > Maybe the carriage returns confused it. I'll see.. > I did introduce them recently by accident. > gdb reported some errors and no symbols in the callstack having > connected to it, on FreeBSD. If need be I can try debugging it on > another system.. > > > (aside, philosophy: all text processing code should treat \n, \r, > and \r\n in put the same, unless you are writing a terminal driver, > then \r has a separate meaning useful for implementing spinners..) > > > - Jay > > > ---------------------------------------- > Date: Tue, 28 Apr 2009 11:40:00 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com > Subject: RE: [M3devel] CM3 release build regression tests not > terminating > > Quoting Jay : > > > Well, on FreeBSD 7.0, I get as far as: > > ew source -> compiling EnvUtils.i3 > libexec/ld-elf.so.1: Shared object "libc.so.6" not found, > required by "cm3cg" > ew source -> compiling EnvUtils.m3 > libexec/ld-elf.so.1: Shared object "libc.so.6" not found, > required by "cm3cg" > ew source -> compiling FingerprintFmt.i3 > libexec/ld-elf.so.1: Shared object "libc.so.6" not found, > required by "cm3cg" > ew source -> compiling TextUtils.i3 > libexec/ld-elf.so.1: Shared object "libc.so.6" not found, > required by "cm3cg" > > Yeah, I understand, I have libc.so.7. > > You need to install the FreeBSD compat packages for backward > compatibility. Should work fine then (until cminstall hangs?). > > Olaf > > > - Jay > > > ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; wagner at elegosoft.com > Date: Tue, 28 Apr 2009 07:45:14 +0000 > CC: m3devel at elegosoft.com; manderson at elegosoft.com > Subject: Re: [M3devel] CM3 release build regression tests not > terminating > > > I've never been able to get the tinderbox stuff to work for me. > I'll try again. > Nothing much from me lately -- pthreads movement to C, and then > back. > > Jay, did you change any config files recently? > > FreeBSD config file changes on 2009-04-13. > > - Jay > > ---------------------------------------- > From: hosking at cs.purdue.edu > To: wagner at elegosoft.com > Date: Tue, 28 Apr 2009 16:45:29 +1000 > CC: m3devel at elegosoft.com; manderson at elegosoft.com > Subject: Re: [M3devel] CM3 release build regression tests not > terminating > > Yes, I had noticed this too. > > On 28 Apr 2009, at 16:29, Olaf Wagner wrote: > > Hi, > > does anybody know what's keeping the release-build tests for > tinderbox > from terminating? I've got lots of stalled regression process > trees on > my system, and the tinderbox display indicates that none of the > release > builds seem to succeed. Has anybody changed anything in the > scripts? > > On a closer look, upgrade seems to be stuck in the installer: > > % ps -axwww 25310 > PID TT STAT TIME COMMAND > 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ > pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ > luthien/current -o > > Jay, did you change any config files recently? > Regression tests seemed to have been running again for some > days, > and then > stopped again. > > I'll try to investigate further this evening, but must leave > now for > other work... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 > 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > > From vapier at gentoo.org Tue Apr 28 15:00:26 2009 From: vapier at gentoo.org (Mike Frysinger) Date: Tue, 28 Apr 2009 09:00:26 -0400 Subject: [M3devel] how to find dependent .so files? In-Reply-To: References: Message-ID: <200904280900.27606.vapier@gentoo.org> On Tuesday 28 April 2009 04:03:13 Jay wrote: > Normally we have: > > /usr/local/cm3/bin/someexe > /usr/local/cm3/lib/libfoo.so symlink to ../pkg/foo/target/libfoo.so > /usr/local/cm3/lib/libbar.so symlink to ../pkg/bar/target/libbar.so > > Linking from someexe to $ORIGIN/../lib works, ok. > But from libfoo to libbar requires $ORIGIN/../../../lib. > or $ORIGIN/../../bar/target. what's wrong with just $ORIGIN ? they're in the same directory already. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From jay.krell at cornell.edu Tue Apr 28 15:15:06 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 13:15:06 +0000 Subject: [M3devel] how to find dependent .so files? In-Reply-To: <200904280900.27606.vapier@gentoo.org> References: <200904280900.27606.vapier@gentoo.org> Message-ID: If you take one of my suggestions, then yes you can do that for .sos. But $ORIGIN/../lib is one generic perhaps inefficient runpath for .sos and executables, and hypothetically also for non-public shipped executables (with my suggestion that they go to lib, if they don't already), that's why. The next step is just to smush lib and bin together, as is done on NT386. Probably people won't like that, keep files out of $PATH. I don't believe $ORIGIN works asis. if /cm3/lib/libfoo.so symlinks to /cm3/pkg/foo/target/libfoo.so then $ORIGIN is /cm3/pkg/foo/target, not /cm3/lib. I'd like to be wrong here but I don't think I am. So reversing the symlinks or making them hardlinks is ok? - Jay ---------------------------------------- > From: vapier at gentoo.org > To: m3devel at elegosoft.com > Date: Tue, 28 Apr 2009 09:00:26 -0400 > CC: jay.krell at cornell.edu > Subject: Re: [M3devel] how to find dependent .so files? > > On Tuesday 28 April 2009 04:03:13 Jay wrote: >> Normally we have: >> >> /usr/local/cm3/bin/someexe >> /usr/local/cm3/lib/libfoo.so symlink to ../pkg/foo/target/libfoo.so >> /usr/local/cm3/lib/libbar.so symlink to ../pkg/bar/target/libbar.so >> >> Linking from someexe to $ORIGIN/../lib works, ok. >> But from libfoo to libbar requires $ORIGIN/../../../lib. >> or $ORIGIN/../../bar/target. > > what's wrong with just $ORIGIN ? they're in the same directory already. > -mike From jay.krell at cornell.edu Tue Apr 28 16:15:50 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 14:15:50 +0000 Subject: [M3devel] manual initialization order? Message-ID: Um, if initializers are so acceptable (I'm skeptical, but everyone here disagrees with me..) and circularities are not allowed (that helps I guess..but is it really true? the garbage collector uses threads, the threading library allocates traced references..I sense circularity...)...why does RTLinker manually pick an initialization order? This is fragile. (* initialize the rest of the modules we'll be calling *) AddUnit (RTLinkerX.RTLinker_I3); (* myself! *) AddUnit (RTLinkerX.RT0_I3); AddUnit (RTLinkerX.RTSignal_I3); AddUnit (RTLinkerX.RTParams_I3); AddUnit (RTLinkerX.RTDebug_I3); AddUnit (RTLinkerX.RTError_I3); AddUnit (RTLinkerX.RTHeapRep_I3); AddUnit (RTLinkerX.ThreadF_I3); AddUnit (RTLinkerX.RTHeapInfo_I3); AddUnit (RTLinkerX.RTIO_I3); AddUnit (RTLinkerX.RTCollectorSRC_I3); AddUnit (RTLinkerX.Word_I3); (* finally, initialize the runtime. *) RTSignal.InstallHandlers (); RTParams.Init (); RTHeapRep.Init (); ThreadF.Init (); RTDebug.Init (); RTHeapInfo.Init (); IF RTParams.IsPresent("tracelinker") THEN traceInit := TRUE; END; AddUnit (RTLinkerX.RTDebug_M3); AddUnit (RTLinkerX.RTError_M3); AddUnit (RTLinkerX.RTType_M3); AddUnit (RTLinkerX.RTPacking_M3); AddUnit (RTLinkerX.RTTipe_M3); AddUnit (RTLinkerX.RTException_M3); From rcoleburn at scires.com Tue Apr 28 17:25:52 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 28 Apr 2009 11:25:52 -0400 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> Message-ID: <49F6E76E.1E75.00D7.1@scires.com> >>> Jay jay.krell at cornell.edu> 4/28/2009 5:58 AM >> ( mailto:jay.krell at cornell.edu> ) (aside, philosophy: all text processing code should treat \n, \r, and \r\n in put the same, unless you are writing a terminal driver, then \r has a separate meaning useful for implementing spinners..) - Jay That may be a nice philosophy, but we can't implement it because in practice not everybody adheres to it. I have written extensive text processing code that has to differentiate between these variants in order to properly interface with and interpret I/O from other systems. --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 mika at async.caltech.edu Tue Apr 28 17:36:44 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 28 Apr 2009 08:36:44 -0700 Subject: [M3devel] Text processing Message-ID: <200904281536.n3SFaiNs060605@camembert.async.caltech.edu> Speaking of text processing, I was very surprised at the bug I found in Wx the other day (and checked in a fix for). I'm 99% certain my fix is correct, but I'm very surprised no one found this bug before. Wx was inserting spurious nulls at the end of every generated TEXT. Is it possible someone is using this interface and depending on the buggy behavior? m3ide and m3browser import it. Mika From rcoleburn at scires.com Tue Apr 28 17:49:35 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 28 Apr 2009 11:49:35 -0400 Subject: [M3devel] Text processing In-Reply-To: <200904281536.n3SFaiNs060605@camembert.async.caltech.edu> References: <200904281536.n3SFaiNs060605@camembert.async.caltech.edu> Message-ID: <49F6ECFD.1E75.00D7.1@scires.com> There is a bug in CM3IDE that may be the result of this problem. I'll need to get your fix and try it. --Randy >>> Mika Nystrom 4/28/2009 11:36 AM >>> Speaking of text processing, I was very surprised at the bug I found in Wx the other day (and checked in a fix for). I'm 99% certain my fix is correct, but I'm very surprised no one found this bug before. Wx was inserting spurious nulls at the end of every generated TEXT. Is it possible someone is using this interface and depending on the buggy behavior? m3ide and m3browser import it. Mika 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 mika at async.caltech.edu Tue Apr 28 18:26:24 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 28 Apr 2009 09:26:24 -0700 Subject: [M3devel] Text processing In-Reply-To: Your message of "Tue, 28 Apr 2009 11:49:35 EDT." <49F6ECFD.1E75.00D7.1@scires.com> Message-ID: <200904281626.n3SGQO92063132@camembert.async.caltech.edu> Hmm cm3ide has its own Wx. It doesn't use that? It looks different from the standard one in cm3. In the *standard* one, that is, m3-libs/libbuf/src/Wx.m3, the fix is the following: PROCEDURE ToText (t: T): TEXT = VAR txt := Text8.Create(t.nFull * ChunkSize + t.next); c := t.head; n := 0; BEGIN There used to be a "+ 1" in the call to Text8.Create. It's crud from converting from the old array TEXTs. I've already checked this in to the cm3 distribution. Mika "Randy Coleburn" writes: >This is a MIME message. If you are reading this text, you may want to >consider changing to a mail reader or gateway that understands how to >properly handle MIME multipart messages. > >--=__Part6C44DF9F.0__= >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: quoted-printable > >There is a bug in CM3IDE that may be the result of this problem. I'll = >need to get your fix and try it. >--Randy > >>>> Mika Nystrom 4/28/2009 11:36 AM >>> > >Speaking of text processing, I was very surprised at the bug I found >in Wx the other day (and checked in a fix for). I'm 99% certain my >fix is correct, but I'm very surprised no one found this bug before. > >Wx was inserting spurious nulls at the end of every generated TEXT. > >Is it possible someone is using this interface and depending on the >buggy behavior? m3ide and m3browser import it. > > Mika > > >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. > > >--=__Part6C44DF9F.0__= >Content-Type: text/html; charset=US-ASCII >Content-Transfer-Encoding: quoted-printable >Content-Description: HTML > > >"> > > >
There is a bug in CM3IDE that may be the result of this problem. = > I'll need to get your fix and try it.
>
--Randy

>>> Mika Nystrom <mika at async.caltech.edu>= >; 4/28/2009 11:36 AM >>>

Speaking of text processing, I = >was very surprised at the bug I found
in Wx the other day (and checked = >in a fix for).  I'm 99% certain my
fix is correct, but I'm very = >surprised no one found this bug before.

Wx was inserting spurious = >nulls at the end of every generated TEXT.

Is it possible someone is = >using this interface and depending on the
buggy behavior?  m3ide = >and m3browser import it.

     Mika

= > > >--=__Part6C44DF9F.0__=-- From jay.krell at cornell.edu Tue Apr 28 18:30:11 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 16:30:11 +0000 Subject: [M3devel] Text processing In-Reply-To: <200904281626.n3SGQO92063132@camembert.async.caltech.edu> References: Your message of "Tue, 28 Apr 2009 11:49:35 EDT." <49F6ECFD.1E75.00D7.1@scires.com> <200904281626.n3SGQO92063132@camembert.async.caltech.edu> Message-ID: Are the nulls included in the length? If so, that'd be a likely bug. If not, it'd be a /possible/ feature. Seriously. I deal with "lengthed" strings a lot, but my "duplicate" and "concat" functions add them, and don't put them in the length, for interop with all the other code out there.. But it is a little sleazy my pattern and we do have explicit functions for C interop. - Jay ---------------------------------------- > To: rcoleburn at scires.com > Date: Tue, 28 Apr 2009 09:26:24 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Text processing > > Hmm cm3ide has its own Wx. It doesn't use that? It looks different > from the standard one in cm3. > > In the *standard* one, that is, m3-libs/libbuf/src/Wx.m3, > the fix is the following: > > PROCEDURE ToText (t: T): TEXT = > VAR txt := Text8.Create(t.nFull * ChunkSize + t.next); > c := t.head; n := 0; > BEGIN > > There used to be a "+ 1" in the call to Text8.Create. It's crud > from converting from the old array TEXTs. > > I've already checked this in to the cm3 distribution. > > Mika > > "Randy Coleburn" writes: >>This is a MIME message. If you are reading this text, you may want to >>consider changing to a mail reader or gateway that understands how to >>properly handle MIME multipart messages. >> >>--=__Part6C44DF9F.0__= >>Content-Type: text/plain; charset=US-ASCII >>Content-Transfer-Encoding: quoted-printable >> >>There is a bug in CM3IDE that may be the result of this problem. I'll = >>need to get your fix and try it. >>--Randy >> >>>>> Mika Nystrom 4/28/2009 11:36 AM>>> >> >>Speaking of text processing, I was very surprised at the bug I found >>in Wx the other day (and checked in a fix for). I'm 99% certain my >>fix is correct, but I'm very surprised no one found this bug before. >> >>Wx was inserting spurious nulls at the end of every generated TEXT. >> >>Is it possible someone is using this interface and depending on the >>buggy behavior? m3ide and m3browser import it. >> >> Mika >> >> >>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. >> >> >>--=__Part6C44DF9F.0__= >>Content-Type: text/html; charset=US-ASCII >>Content-Transfer-Encoding: quoted-printable >>Content-Description: HTML >> >> >>>>"> >> >> >> There is a bug in CM3IDE that may be the result of this problem. = >> I'll need to get your fix and try it. >> --Randy >>> Mika Nystrom = >>; 4/28/2009 11:36 AM>>> Speaking of text processing, I = >>was very surprised at the bug I found in Wx the other day (and checked = >>in a fix for). I'm 99% certain my fix is correct, but I'm very = >>surprised no one found this bug before. Wx was inserting spurious = >>nulls at the end of every generated TEXT. Is it possible someone is = >>using this interface and depending on the buggy behavior? m3ide = >>and m3browser import it. Mika = >> >> >>--=__Part6C44DF9F.0__=-- From jay.krell at cornell.edu Tue Apr 28 18:32:16 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 16:32:16 +0000 Subject: [M3devel] __thread? Message-ID: Mika, please let me know what this does for you, on the old FreeBSD 4.x? Probably it'll give some compiler errors, but if not, excellent. Our usess of pthread_get/setspecific should use __thread where it is available. Below is FreeBSD/i386 7.0. Nice and efficient (even better with -O2). Actually, "everyone", I'm interested in this. Probably we should do a little local autoconfery in the m3core m3makefile. If the below program compiles/links, use __thread, else pthread_get/setspecific. Another option is determine that it is widely supported and use #if or find out if there are specific #ifs associated with it. I know Cygwin doesn't support it. [jay at jkfbsd1 ~]$ cat 1.c #include __thread int a,b,c,d; int main() { printf("%p%p%p%p\n", &a,&b,&c,&d); return 0; } [jay at jkfbsd1 ~]$ gcc -S 1.c [jay at jkfbsd1 ~]$ cat 1.s .file "1.c" .section .rodata .LC0: .string "%p%p%p%p\n" .text .p2align 4,,15 .globl main .type main, @function main: leal 4(%esp), %ecx andl $-16, %esp pushl -4(%ecx) pushl %ebp movl %esp, %ebp pushl %ecx subl $20, %esp movl %gs:0, %eax leal d at NTPOFF(%eax), %eax movl %eax, 16(%esp) movl %gs:0, %eax leal c at NTPOFF(%eax), %eax movl %eax, 12(%esp) movl %gs:0, %eax leal b at NTPOFF(%eax), %eax movl %eax, 8(%esp) movl %gs:0, %eax leal a at NTPOFF(%eax), %eax movl %eax, 4(%esp) movl $.LC0, (%esp) call printf movl $0, %eax addl $20, %esp popl %ecx popl %ebp leal -4(%ecx), %esp ret .size main, .-main .globl a .section .tbss,"awT", at nobits ... - Jay From jay.krell at cornell.edu Tue Apr 28 18:38:09 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 16:38:09 +0000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <49F6E76E.1E75.00D7.1@scires.com> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <49F6E76E.1E75.00D7.1@scires.com> Message-ID: Randy just because everyone else does it poorly does not generally tie your hands. I said on input, not on output. Output does often tie your hands. Or do they actually have different meanings? That'd be wierd. The only useful semantic difference I've ever seen is that carriagereturn alone can be used to implement little spinnies. Otherwise, all three sequences have identical meaning. And various code out there does treat them identically, just not necessarily does one code treat them all the same, you have to at worst find three programs to find the same treatment. We /can/ implement it, anywhere we have text processing code. Reading quake files. I think it already does. It was just a red herring. Libraries that return "lines". You know, one common pattern is on Unix to split on \n and on NT to split on \r\n. Well, that means the same code deals in one format one platform, one on the other, and just acts wierdly when presented with the "wrong" format. There's no reason it can't just act platform independent and treat both formats always correctly. The compiler frontend must do this, based on experience and reasonable expectations. Most C compilers these days ditto. - Jay ________________________________ > Date: Tue, 28 Apr 2009 11:25:52 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 release build regression tests not terminating > > > > > > > >>>> Jay jay.krell at cornell.edu> 4/28/2009 5:58 AM>>%204/28/2009%205:58%20AM%20>>> > > (aside, philosophy: all text processing code should treat \n, \r, and \r\n in put the same, unless you are writing a terminal driver, then \r has a separate meaning useful for implementing spinners..) > - Jay > > That may be a nice philosophy, but we can't implement it because in practice not everybody adheres to it. I have written extensive text processing code that has to differentiate between these variants in order to properly interface with and interpret I/O from other systems. > > --Randy From jay.krell at cornell.edu Tue Apr 28 18:54:03 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 16:54:03 +0000 Subject: [M3devel] user threads Message-ID: User threads seem to work on on FreeBSD/x86 7.0. Mika can you report back the perf cm3 vs. pm3? Still, kernel threads have been around a long time and imho should be strongly favored.. Kernel threads should be a /little/ faster than they were -- PushEFrame removed from successful heap allocations. And should be further improvable via __thread where it is supported -- probably not FreeBSD 4.x, sometimes older is not better. :) I've temporarily switched FreeBSD/x86 to userthreads by default but I think that's just an experiment and should be undone shortly, maybe work out some other story for easily switching between them, or just keep the existing story of "you get to rebuild everything". Tony, can you look into GetGCRatio? I removed the call to it. The "fatal" pragma invokes PushEFrame apparently. We should now "fix" Win32 and pthreads to not have GetActivation initialize on-demand, just leave Init to initialize always. This should shave a few more cycles from PushEFrame. - Jay From mika at async.caltech.edu Tue Apr 28 18:55:00 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 28 Apr 2009 09:55:00 -0700 Subject: [M3devel] Text processing In-Reply-To: Your message of "Tue, 28 Apr 2009 16:30:11 -0000." Message-ID: <200904281655.n3SGt0iJ064555@camembert.async.caltech.edu> I think whenever Modula-3 TEXTs are represented as arrays (including *all* m3 TEXTs in SRC and P M3), there's a null at the end. It's not included in the "length of the string" but obviously it *is* included in the "length of the array". That's precisely the source of the bug. The old version allocates "length of string plus one", which is the wrong number to pass to the new interfaces (which don't expose the trailing zero, but keep it, just the same). Yes, the idea is you can pass Modula-3 TEXTs freely (cheaply) to C routines. Well, you used to be able to, before TEXTs were "improved" by Critical Mass. The code would have been something like this...? IMPORT TextF; VAR txt : TEXT; ... some_c_function(ADR(txt[0])) ... No I don't miss this feature much. There are other improvements that bug me a lot more. But this is all about to be fixed with the new Text implementation, right? :-) Mika Jay writes: > >Are the nulls included in the length? > >If so, that'd be a likely bug. If not, it'd be a /possible/ feature. Seriously >. >I deal with "lengthed" strings a lot, but my "duplicate" and "concat" function >s add them, and don't put them in the length, for interop with all the other c >ode out there.. >But it is a little sleazy my pattern and we do have explicit functions for C i >nterop. > > > - Jay > > >---------------------------------------- >> To: rcoleburn at scires.com >> Date: Tue, 28 Apr 2009 09:26:24 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Text processing >> >> Hmm cm3ide has its own Wx. It doesn't use that? It looks different >> from the standard one in cm3. >> >> In the *standard* one, that is, m3-libs/libbuf/src/Wx.m3, >> the fix is the following: >> >> PROCEDURE ToText (t: T): TEXT = >> VAR txt := Text8.Create(t.nFull * ChunkSize + t.next); >> c := t.head; n := 0; >> BEGIN >> >> There used to be a "+ 1" in the call to Text8.Create. It's crud >> from converting from the old array TEXTs. >> >> I've already checked this in to the cm3 distribution. >> >> Mika >> >> "Randy Coleburn" writes: >>>This is a MIME message. If you are reading this text, you may want to >>>consider changing to a mail reader or gateway that understands how to >>>properly handle MIME multipart messages. >>> >>>--=__Part6C44DF9F.0__= >>>Content-Type: text/plain; charset=US-ASCII >>>Content-Transfer-Encoding: quoted-printable >>> >>>There is a bug in CM3IDE that may be the result of this problem. I'll = >>>need to get your fix and try it. >>>--Randy >>> >>>>>> Mika Nystrom 4/28/2009 11:36 AM>>> >>> >>>Speaking of text processing, I was very surprised at the bug I found >>>in Wx the other day (and checked in a fix for). I'm 99% certain my >>>fix is correct, but I'm very surprised no one found this bug before. >>> >>>Wx was inserting spurious nulls at the end of every generated TEXT. >>> >>>Is it possible someone is using this interface and depending on the >>>buggy behavior? m3ide and m3browser import it. >>> >>> Mika >>> >>> >>>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. >>> >>> >>>--=__Part6C44DF9F.0__= >>>Content-Type: text/html; charset=US-ASCII >>>Content-Transfer-Encoding: quoted-printable >>>Content-Description: HTML >>> >>> >>>>>"> >>> > >>> >>> >There is a bug in CM3IDE that may be the result of this problem. = >>> I'll need to get your fix and try it. >>> >--Randy > >>>> Mika Nystrom = >>>; 4/28/2009 11:36 AM>>> > >Speaking of text processing, I = >>>was very surprised at the bug I found >in Wx the other day (and checked = >>>in a fix for). I'm 99% certain my >fix is correct, but I'm very = >>>surprised no one found this bug before. > >Wx was inserting spurious = >>>nulls at the end of every generated TEXT. > >Is it possible someone is = >>>using this interface and depending on the >buggy behavior? m3ide = >>>and m3browser import it. > > Mika > >= >>> >>> >>>--=__Part6C44DF9F.0__=-- From wagner at elegosoft.com Tue Apr 28 19:39:39 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 28 Apr 2009 19:39:39 +0200 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> <9AC96562-7045-418A-A069-84EE8613498A@cs.purdue.edu> Message-ID: <20090428193939.f037r1dkowg0ks4o@mail.elegosoft.com> Hi Jay, thanks for reverting the offending changes to the installer. I'm sure they were working OK when I tested them locally, and they looked innocent enough. Sigh. Perhaps not worth to pursue the installer issues further though. Have you found out why it hangs though? I haven't really understood the problem yet. Sorry for the disturbances, Olaf Quoting Jay : > Tony can you clarify? Things stopped working two weeks ago? > Or things were working until more recently? > > It seems like the select call never returns. > Whatever is going on, it troubles debugging tools. > gdb won't follow the children..which is probably ok, they aren't the problem. > truss can't be control-c'ed, but can be killed. > "info locals" in gdb often hangs and I have to pkill gdb. > Not that info locals ever works well, but it usually doesn't hang gdb. > I started putting in RTIO calls. > WaitForAll's finishes one Wait call but then hangs on the next. > > I think we should not run cminstall against 5.4 runtime. > Enable user threads as some related scenario.. > > > - Jay > > > ________________________________ >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Subject: Re: [M3devel] CM3 release build regression tests not terminating >> Date: Tue, 28 Apr 2009 21:49:32 +1000 >> >> Sounds about right. >> >> 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 28 Apr 2009, at 21:17, Jay wrote: >> >> >> The changes went in two weeks ago 4/14, were they definitely working? >> I can try it again, hopefully without the full tinderbox stuff. >> >> - Jay >> >> >> ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Tue, 28 Apr 2009 21:11:42 +1000 >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: Re: [M3devel] CM3 release build regression tests not terminating >> >> What could possibly have changed here. It used to work fine on >> multiple platforms. >> >> On 28 Apr 2009, at 20:14, Jay wrote: >> >> >> It creates a file named "df-k" and hangs here: >> >> (gdb) where >> #0 0x080f417f in select () >> #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, >> writefds=0x28127138, >> exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ >> FreeBSD4/select.c:13 >> #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, >> M3_CEtG8K_timeout=0xbfbfe6d8) >> at ThreadPosix.m3:714 >> #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 >> #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, >> M3_AicXUJ_alertable=0 '\0') >> at ThreadPosix.m3:555 >> #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at >> ThreadPosix.m3:539 >> #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at >> ProcessPosix.m3:294 >> #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at >> System.m3:527 >> #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, >> M3_EkfbeH_env=0x0, >> M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 >> #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at >> OSPOSIX.m3:19 >> #10 0x0804c31c in Main__DoIt () at Main.m3:122 >> #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 >> #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at >> RTLinker.m3:395 >> #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at >> RTLinker.m3:109 >> #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at >> RTLinker.m3:118 >> #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at >> _m3main.mc:4 >> >> Notice it using user threads, so old m3core/libm3. >> df doesn't appear to be any longer running. >> Why it prints about the backend mode, I don't know. >> >> (and yes, I get it -- df -k is directly related to GetDiskSpace..if >> this is how one checks diskspace on Unix...I think we should punt, >> unless posix actually specifies the precise output format of this >> command it is very reliably parsed...) >> >> - Jay >> >> >> ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: RE: [M3devel] CM3 release build regression tests not >> terminating >> Date: Tue, 28 Apr 2009 09:58:56 +0000 >> >> >> Right, now it hangs having printed..I know this looks a bit of >> nonsense..stuff from right around: >> >> >> M3_BACKEND_MODE = "3" >> % -- defines how the frontend, backend, and assembler interact >> % "0" -- don't call m3_backend, M3CG produces object code >> % "1" -- don't call m3_backend, M3CG produces assembly code >> % "2" -- call m3_backend, it produces object code >> % "3" -- call m3_backend, it produces assembly code >> >> >> however, this is noticably pretty close to the last BEGIN_CONFIG. >> >> Maybe the carriage returns confused it. I'll see.. >> I did introduce them recently by accident. >> gdb reported some errors and no symbols in the callstack having >> connected to it, on FreeBSD. If need be I can try debugging it on >> another system.. >> >> >> (aside, philosophy: all text processing code should treat \n, \r, >> and \r\n in put the same, unless you are writing a terminal driver, >> then \r has a separate meaning useful for implementing spinners..) >> >> >> - Jay >> >> >> ---------------------------------------- >> Date: Tue, 28 Apr 2009 11:40:00 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: RE: [M3devel] CM3 release build regression tests not >> terminating >> >> Quoting Jay : >> >> >> Well, on FreeBSD 7.0, I get as far as: >> >> ew source -> compiling EnvUtils.i3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >> required by "cm3cg" >> ew source -> compiling EnvUtils.m3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >> required by "cm3cg" >> ew source -> compiling FingerprintFmt.i3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >> required by "cm3cg" >> ew source -> compiling TextUtils.i3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >> required by "cm3cg" >> >> Yeah, I understand, I have libc.so.7. >> >> You need to install the FreeBSD compat packages for backward >> compatibility. Should work fine then (until cminstall hangs?). >> >> Olaf >> >> >> - Jay >> >> >> ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu; wagner at elegosoft.com >> Date: Tue, 28 Apr 2009 07:45:14 +0000 >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: Re: [M3devel] CM3 release build regression tests not >> terminating >> >> >> I've never been able to get the tinderbox stuff to work for me. >> I'll try again. >> Nothing much from me lately -- pthreads movement to C, and then >> back. >> >> Jay, did you change any config files recently? >> >> FreeBSD config file changes on 2009-04-13. >> >> - Jay >> >> ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: wagner at elegosoft.com >> Date: Tue, 28 Apr 2009 16:45:29 +1000 >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: Re: [M3devel] CM3 release build regression tests not >> terminating >> >> Yes, I had noticed this too. >> >> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >> >> Hi, >> >> does anybody know what's keeping the release-build tests for >> tinderbox >> from terminating? I've got lots of stalled regression process >> trees on >> my system, and the tinderbox display indicates that none of the >> release >> builds seem to succeed. Has anybody changed anything in the >> scripts? >> >> On a closer look, upgrade seems to be stuck in the installer: >> >> % ps -axwww 25310 >> PID TT STAT TIME COMMAND >> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >> luthien/current -o >> >> Jay, did you change any config files recently? >> Regression tests seemed to have been running again for some >> days, >> and then >> stopped again. >> >> I'll try to investigate further this evening, but must leave >> now for >> other work... >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >> Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >> 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> >> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 hendrik at topoi.pooq.com Tue Apr 28 19:59:17 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 28 Apr 2009 13:59:17 -0400 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <49F6E76E.1E75.00D7.1@scires.com> Message-ID: <20090428175916.GA9048@topoi.pooq.com> On Tue, Apr 28, 2009 at 04:38:09PM +0000, Jay wrote: > > Randy just because everyone else does it poorly does not generally tie your hands. > I said on input, not on output. > Output does often tie your hands. There are situations wheere you need to recognize multiple ways of representing newline without normalizing them. If you are writing an editor for text that is under revision control, and you standardize newlines on input, and then write it out in any consistent convention, you run the risk that revision control will think that huge numbers of lines have been changed. Of course, they have been, but not intentionally. -- hendrik From neels at elego.de Tue Apr 28 21:14:18 2009 From: neels at elego.de (Neels J Hofmeyr) Date: Tue, 28 Apr 2009 21:14:18 +0200 Subject: [M3devel] Modula-2 to Modula-3 translator by Aachen University In-Reply-To: <3d6568a70904252357u3c69dc3do136fcb2a27ffd9ea@mail.gmail.com> References: <3d6568a70904252354n2688dee9k3459399ab59b2495@mail.gmail.com> <3d6568a70904252357u3c69dc3do136fcb2a27ffd9ea@mail.gmail.com> Message-ID: <49F7558A.8060904@elego.de> Benjamin Kowarsch wrote: > Dear Sirs, > > I am trying to get the Modula-2 section in the Catalog of Compilers > updated and there is one entry of a Modula-2 to Modula-3 translator by > Peter Klein at University of Aachen for which all links and email > addresses seem to be dead. University of Aachen was unable to give me > any information either. > > I wonder if you know whether this translator is still availabe and if > so at which URL, or where his author Peter Klein can be contacted. > > thank you > regards > benjamin Sorry, don't know anything about it/him. Anyone else? ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From hosking at cs.purdue.edu Tue Apr 28 23:41:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 29 Apr 2009 07:41:19 +1000 Subject: [M3devel] manual initialization order? In-Reply-To: References: Message-ID: <557AEC0D-E50B-4A74-95B3-37AC2123878D@cs.purdue.edu> Indeed it is fragile, but necessary to bootstrap the system. On 29 Apr 2009, at 00:15, Jay wrote: > > Um, if initializers are so acceptable (I'm skeptical, but everyone > here disagrees with me..) and circularities are not allowed (that > helps I guess..but is it really true? the garbage collector uses > threads, the threading library allocates traced references..I sense > circularity...)...why does RTLinker manually pick an initialization > order? This is fragile. > > > (* initialize the rest of the modules we'll be calling *) > AddUnit (RTLinkerX.RTLinker_I3); (* myself! *) > AddUnit (RTLinkerX.RT0_I3); > AddUnit (RTLinkerX.RTSignal_I3); > AddUnit (RTLinkerX.RTParams_I3); > AddUnit (RTLinkerX.RTDebug_I3); > AddUnit (RTLinkerX.RTError_I3); > AddUnit (RTLinkerX.RTHeapRep_I3); > AddUnit (RTLinkerX.ThreadF_I3); > AddUnit (RTLinkerX.RTHeapInfo_I3); > AddUnit (RTLinkerX.RTIO_I3); > AddUnit (RTLinkerX.RTCollectorSRC_I3); > AddUnit (RTLinkerX.Word_I3); > > > > (* finally, initialize the runtime. *) > RTSignal.InstallHandlers (); > RTParams.Init (); > RTHeapRep.Init (); > ThreadF.Init (); > RTDebug.Init (); > RTHeapInfo.Init (); > IF RTParams.IsPresent("tracelinker") THEN > traceInit := TRUE; > END; > > > AddUnit (RTLinkerX.RTDebug_M3); > AddUnit (RTLinkerX.RTError_M3); > AddUnit (RTLinkerX.RTType_M3); > AddUnit (RTLinkerX.RTPacking_M3); > AddUnit (RTLinkerX.RTTipe_M3); > AddUnit (RTLinkerX.RTException_M3); From hosking at cs.purdue.edu Tue Apr 28 23:51:49 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 29 Apr 2009 07:51:49 +1000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> <9AC96562-7045-418A-A069-84EE8613498A@cs.purdue.edu> Message-ID: <2565931E-F3F3-4832-8582-C1D227B556DA@cs.purdue.edu> Whatever changed in the last 24 hours has my tinderbox runs completing now. On 28 Apr 2009, at 22:13, Jay wrote: > > Tony can you clarify? Things stopped working two weeks ago? > Or things were working until more recently? > > > > It seems like the select call never returns. > Whatever is going on, it troubles debugging tools. > gdb won't follow the children..which is probably ok, they aren't the > problem. > truss can't be control-c'ed, but can be killed. > "info locals" in gdb often hangs and I have to pkill gdb. > Not that info locals ever works well, but it usually doesn't hang gdb. > I started putting in RTIO calls. > WaitForAll's finishes one Wait call but then hangs on the next. > > > I think we should not run cminstall against 5.4 runtime. > Enable user threads as some related scenario.. > > > - Jay > > > ________________________________ >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Subject: Re: [M3devel] CM3 release build regression tests not >> terminating >> Date: Tue, 28 Apr 2009 21:49:32 +1000 >> >> Sounds about right. >> >> 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 28 Apr 2009, at 21:17, Jay wrote: >> >> >> The changes went in two weeks ago 4/14, were they definitely working? >> I can try it again, hopefully without the full tinderbox stuff. >> >> - Jay >> >> >> ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Tue, 28 Apr 2009 21:11:42 +1000 >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: Re: [M3devel] CM3 release build regression tests not >> terminating >> >> What could possibly have changed here. It used to work fine on >> multiple platforms. >> >> On 28 Apr 2009, at 20:14, Jay wrote: >> >> >> It creates a file named "df-k" and hangs here: >> >> (gdb) where >> #0 0x080f417f in select () >> #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, >> writefds=0x28127138, >> exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ >> FreeBSD4/select.c:13 >> #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, >> M3_CEtG8K_timeout=0xbfbfe6d8) >> at ThreadPosix.m3:714 >> #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 >> #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, >> M3_AicXUJ_alertable=0 '\0') >> at ThreadPosix.m3:555 >> #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at >> ThreadPosix.m3:539 >> #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at >> ProcessPosix.m3:294 >> #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at >> System.m3:527 >> #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, >> M3_EkfbeH_env=0x0, >> M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 >> #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at >> OSPOSIX.m3:19 >> #10 0x0804c31c in Main__DoIt () at Main.m3:122 >> #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 >> #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at >> RTLinker.m3:395 >> #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at >> RTLinker.m3:109 >> #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at >> RTLinker.m3:118 >> #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at >> _m3main.mc:4 >> >> Notice it using user threads, so old m3core/libm3. >> df doesn't appear to be any longer running. >> Why it prints about the backend mode, I don't know. >> >> (and yes, I get it -- df -k is directly related to GetDiskSpace..if >> this is how one checks diskspace on Unix...I think we should punt, >> unless posix actually specifies the precise output format of this >> command it is very reliably parsed...) >> >> - Jay >> >> >> ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: RE: [M3devel] CM3 release build regression tests not >> terminating >> Date: Tue, 28 Apr 2009 09:58:56 +0000 >> >> >> Right, now it hangs having printed..I know this looks a bit of >> nonsense..stuff from right around: >> >> >> M3_BACKEND_MODE = "3" >> % -- defines how the frontend, backend, and assembler interact >> % "0" -- don't call m3_backend, M3CG produces object code >> % "1" -- don't call m3_backend, M3CG produces assembly code >> % "2" -- call m3_backend, it produces object code >> % "3" -- call m3_backend, it produces assembly code >> >> >> however, this is noticably pretty close to the last BEGIN_CONFIG. >> >> Maybe the carriage returns confused it. I'll see.. >> I did introduce them recently by accident. >> gdb reported some errors and no symbols in the callstack having >> connected to it, on FreeBSD. If need be I can try debugging it on >> another system.. >> >> >> (aside, philosophy: all text processing code should treat \n, \r, >> and \r\n in put the same, unless you are writing a terminal driver, >> then \r has a separate meaning useful for implementing spinners..) >> >> >> - Jay >> >> >> ---------------------------------------- >> Date: Tue, 28 Apr 2009 11:40:00 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: RE: [M3devel] CM3 release build regression tests not >> terminating >> >> Quoting Jay : >> >> >> Well, on FreeBSD 7.0, I get as far as: >> >> ew source -> compiling EnvUtils.i3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >> required by "cm3cg" >> ew source -> compiling EnvUtils.m3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >> required by "cm3cg" >> ew source -> compiling FingerprintFmt.i3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >> required by "cm3cg" >> ew source -> compiling TextUtils.i3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >> required by "cm3cg" >> >> Yeah, I understand, I have libc.so.7. >> >> You need to install the FreeBSD compat packages for backward >> compatibility. Should work fine then (until cminstall hangs?). >> >> Olaf >> >> >> - Jay >> >> >> ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu; wagner at elegosoft.com >> Date: Tue, 28 Apr 2009 07:45:14 +0000 >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: Re: [M3devel] CM3 release build regression tests not >> terminating >> >> >> I've never been able to get the tinderbox stuff to work for me. >> I'll try again. >> Nothing much from me lately -- pthreads movement to C, and then >> back. >> >> Jay, did you change any config files recently? >> >> FreeBSD config file changes on 2009-04-13. >> >> - Jay >> >> ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: wagner at elegosoft.com >> Date: Tue, 28 Apr 2009 16:45:29 +1000 >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: Re: [M3devel] CM3 release build regression tests not >> terminating >> >> Yes, I had noticed this too. >> >> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >> >> Hi, >> >> does anybody know what's keeping the release-build tests for >> tinderbox >> from terminating? I've got lots of stalled regression process >> trees on >> my system, and the tinderbox display indicates that none of the >> release >> builds seem to succeed. Has anybody changed anything in the >> scripts? >> >> On a closer look, upgrade seems to be stuck in the installer: >> >> % ps -axwww 25310 >> PID TT STAT TIME COMMAND >> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >> luthien/current -o >> >> Jay, did you change any config files recently? >> Regression tests seemed to have been running again for some >> days, >> and then >> stopped again. >> >> I'll try to investigate further this evening, but must leave >> now for >> other work... >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >> Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >> 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> >> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 29 01:10:47 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 23:10:47 +0000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <20090428193939.f037r1dkowg0ks4o@mail.elegosoft.com> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> <9AC96562-7045-418A-A069-84EE8613498A@cs.purdue.edu> <20090428193939.f037r1dkowg0ks4o@mail.elegosoft.com> Message-ID: > Have you found out why it hangs though? I haven't really understood > the problem yet. No. But you understand this is against a 5.4 runtime, right? Is that really so interesting? Can you consider: a) using system() and/or b) removing "bootstrapped cminstall" from the automation. Just make it work with current and don't worry about 5.4 or lastrel. and/or c) Or wait and put it back after current release when lastrel becomes 5.8. You know, I think you'd want to exercise lastrel/5.4 as little as possible in getting current working and I think using cminstall goes past that. It is subjective though. I haven't actually tested the code with current yet, oops. - Jay ---------------------------------------- > Date: Tue, 28 Apr 2009 19:39:39 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 release build regression tests not terminating > > Hi Jay, > > thanks for reverting the offending changes to the installer. > I'm sure they were working OK when I tested them locally, and they > looked innocent enough. Sigh. Perhaps not worth to pursue the installer > issues further though. > > Have you found out why it hangs though? I haven't really understood > the problem yet. > > Sorry for the disturbances, > > Olaf > > Quoting Jay : > >> Tony can you clarify? Things stopped working two weeks ago? >> Or things were working until more recently? >> >> It seems like the select call never returns. >> Whatever is going on, it troubles debugging tools. >> gdb won't follow the children..which is probably ok, they aren't the problem. >> truss can't be control-c'ed, but can be killed. >> "info locals" in gdb often hangs and I have to pkill gdb. >> Not that info locals ever works well, but it usually doesn't hang gdb. >> I started putting in RTIO calls. >> WaitForAll's finishes one Wait call but then hangs on the next. >> >> I think we should not run cminstall against 5.4 runtime. >> Enable user threads as some related scenario.. >> >> >> - Jay >> >> >> ________________________________ >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>> Date: Tue, 28 Apr 2009 21:49:32 +1000 >>> >>> Sounds about right. >>> >>> 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 28 Apr 2009, at 21:17, Jay wrote: >>> >>> >>> The changes went in two weeks ago 4/14, were they definitely working? >>> I can try it again, hopefully without the full tinderbox stuff. >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Tue, 28 Apr 2009 21:11:42 +1000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>> >>> What could possibly have changed here. It used to work fine on >>> multiple platforms. >>> >>> On 28 Apr 2009, at 20:14, Jay wrote: >>> >>> >>> It creates a file named "df-k" and hangs here: >>> >>> (gdb) where >>> #0 0x080f417f in select () >>> #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, >>> writefds=0x28127138, >>> exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ >>> FreeBSD4/select.c:13 >>> #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, >>> M3_CEtG8K_timeout=0xbfbfe6d8) >>> at ThreadPosix.m3:714 >>> #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 >>> #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, >>> M3_AicXUJ_alertable=0 '\0') >>> at ThreadPosix.m3:555 >>> #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at >>> ThreadPosix.m3:539 >>> #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at >>> ProcessPosix.m3:294 >>> #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at >>> System.m3:527 >>> #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, >>> M3_EkfbeH_env=0x0, >>> M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 >>> #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at >>> OSPOSIX.m3:19 >>> #10 0x0804c31c in Main__DoIt () at Main.m3:122 >>> #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 >>> #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at >>> RTLinker.m3:395 >>> #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at >>> RTLinker.m3:109 >>> #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at >>> RTLinker.m3:118 >>> #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at >>> _m3main.mc:4 >>> >>> Notice it using user threads, so old m3core/libm3. >>> df doesn't appear to be any longer running. >>> Why it prints about the backend mode, I don't know. >>> >>> (and yes, I get it -- df -k is directly related to GetDiskSpace..if >>> this is how one checks diskspace on Unix...I think we should punt, >>> unless posix actually specifies the precise output format of this >>> command it is very reliably parsed...) >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com >>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: RE: [M3devel] CM3 release build regression tests not >>> terminating >>> Date: Tue, 28 Apr 2009 09:58:56 +0000 >>> >>> >>> Right, now it hangs having printed..I know this looks a bit of >>> nonsense..stuff from right around: >>> >>> >>> M3_BACKEND_MODE = "3" >>> % -- defines how the frontend, backend, and assembler interact >>> % "0" -- don't call m3_backend, M3CG produces object code >>> % "1" -- don't call m3_backend, M3CG produces assembly code >>> % "2" -- call m3_backend, it produces object code >>> % "3" -- call m3_backend, it produces assembly code >>> >>> >>> however, this is noticably pretty close to the last BEGIN_CONFIG. >>> >>> Maybe the carriage returns confused it. I'll see.. >>> I did introduce them recently by accident. >>> gdb reported some errors and no symbols in the callstack having >>> connected to it, on FreeBSD. If need be I can try debugging it on >>> another system.. >>> >>> >>> (aside, philosophy: all text processing code should treat \n, \r, >>> and \r\n in put the same, unless you are writing a terminal driver, >>> then \r has a separate meaning useful for implementing spinners..) >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> Date: Tue, 28 Apr 2009 11:40:00 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: RE: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> Quoting Jay : >>> >>> >>> Well, on FreeBSD 7.0, I get as far as: >>> >>> ew source -> compiling EnvUtils.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> ew source -> compiling EnvUtils.m3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> ew source -> compiling FingerprintFmt.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> ew source -> compiling TextUtils.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> >>> Yeah, I understand, I have libc.so.7. >>> >>> You need to install the FreeBSD compat packages for backward >>> compatibility. Should work fine then (until cminstall hangs?). >>> >>> Olaf >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> >>> I've never been able to get the tinderbox stuff to work for me. >>> I'll try again. >>> Nothing much from me lately -- pthreads movement to C, and then >>> back. >>> >>> Jay, did you change any config files recently? >>> >>> FreeBSD config file changes on 2009-04-13. >>> >>> - Jay >>> >>> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: wagner at elegosoft.com >>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> Yes, I had noticed this too. >>> >>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>> >>> Hi, >>> >>> does anybody know what's keeping the release-build tests for >>> tinderbox >>> from terminating? I've got lots of stalled regression process >>> trees on >>> my system, and the tinderbox display indicates that none of the >>> release >>> builds seem to succeed. Has anybody changed anything in the >>> scripts? >>> >>> On a closer look, upgrade seems to be stuck in the installer: >>> >>> % ps -axwww 25310 >>> PID TT STAT TIME COMMAND >>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>> luthien/current -o >>> >>> Jay, did you change any config files recently? >>> Regression tests seemed to have been running again for some >>> days, >>> and then >>> stopped again. >>> >>> I'll try to investigate further this evening, but must leave >>> now for >>> other work... >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>> 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> >>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Apr 29 01:11:47 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 23:11:47 +0000 Subject: [M3devel] __thread? Message-ID: Angle brackets tend to get broken in my emails, very annoying, that should have stdio.h. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: __thread? > Date: Tue, 28 Apr 2009 16:32:16 +0000 > > > Mika, please let me know what this does for you, on the old FreeBSD 4.x? > > [jay at jkfbsd1 ~]$ cat 1.c > #include From jay.krell at cornell.edu Wed Apr 29 03:20:36 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 28 Apr 2009 18:20:36 -0700 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <20090428175916.GA9048@topoi.pooq.com> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <49F6E76E.1E75.00D7.1@scires.com> <20090428175916.GA9048@topoi.pooq.com> Message-ID: <9D57919B-69BA-4BEC-9319-5AC51E6CB6F1@hotmail.com> You can normalize the 'presentation' while maintaining the multiple forms..just because two things look the same on screen does mean they are the same, for better and worse. Most but not all code can be 'reasonable' and allow either or a mix. Just giving guidance for folks, subjective, as a user and implementer.. - Jay (phone) On Apr 28, 2009, at 10:59 AM, hendrik at topoi.pooq.com wrote: > On Tue, Apr 28, 2009 at 04:38:09PM +0000, Jay wrote: >> >> Randy just because everyone else does it poorly does not generally >> tie your hands. >> I said on input, not on output. >> Output does often tie your hands. > > There are situations wheere you need to recognize multiple ways of > representing newline without normalizing them. > > If you are writing an editor for text that is under revision control, > and you standardize newlines on input, and then write it out in any > consistent convention, you run the risk that revision control will > think > that huge numbers of lines have been changed. Of course, they have > been, but not intentionally. > > -- hendrik > From jay.krell at cornell.edu Wed Apr 29 03:57:23 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 28 Apr 2009 18:57:23 -0700 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <2565931E-F3F3-4832-8582-C1D227B556DA@cs.purdue.edu> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> <9AC96562-7045-418A-A069-84EE8613498A@cs.purdue.edu> <2565931E-F3F3-4832-8582-C1D227B556DA@cs.purdue.edu> Message-ID: <4FBC0000-EF60-4890-B125-7CB566813931@hotmail.com> Was it broken for two weeks, or shorter? - Jay (phone) On Apr 28, 2009, at 2:51 PM, Tony Hosking wrote: > Whatever changed in the last 24 hours has my tinderbox runs > completing now. > > On 28 Apr 2009, at 22:13, Jay wrote: > >> >> Tony can you clarify? Things stopped working two weeks ago? >> Or things were working until more recently? >> >> >> >> It seems like the select call never returns. >> Whatever is going on, it troubles debugging tools. >> gdb won't follow the children..which is probably ok, they aren't >> the problem. >> truss can't be control-c'ed, but can be killed. >> "info locals" in gdb often hangs and I have to pkill gdb. >> Not that info locals ever works well, but it usually doesn't hang >> gdb. >> I started putting in RTIO calls. >> WaitForAll's finishes one Wait call but then hangs on the next. >> >> >> I think we should not run cminstall against 5.4 runtime. >> Enable user threads as some related scenario.. >> >> >> - Jay >> >> >> ________________________________ >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Subject: Re: [M3devel] CM3 release build regression tests not >>> terminating >>> Date: Tue, 28 Apr 2009 21:49:32 +1000 >>> >>> Sounds about right. >>> >>> 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 28 Apr 2009, at 21:17, Jay wrote: >>> >>> >>> The changes went in two weeks ago 4/14, were they definitely >>> working? >>> I can try it again, hopefully without the full tinderbox stuff. >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Tue, 28 Apr 2009 21:11:42 +1000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> What could possibly have changed here. It used to work fine on >>> multiple platforms. >>> >>> On 28 Apr 2009, at 20:14, Jay wrote: >>> >>> >>> It creates a file named "df-k" and hangs here: >>> >>> (gdb) where >>> #0 0x080f417f in select () >>> #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, >>> writefds=0x28127138, >>> exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ >>> FreeBSD4/select.c:13 >>> #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, >>> M3_CEtG8K_timeout=0xbfbfe6d8) >>> at ThreadPosix.m3:714 >>> #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 >>> #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, >>> M3_AicXUJ_alertable=0 '\0') >>> at ThreadPosix.m3:555 >>> #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at >>> ThreadPosix.m3:539 >>> #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at >>> ProcessPosix.m3:294 >>> #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at >>> System.m3:527 >>> #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, >>> M3_EkfbeH_env=0x0, >>> M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 >>> #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at >>> OSPOSIX.m3:19 >>> #10 0x0804c31c in Main__DoIt () at Main.m3:122 >>> #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 >>> #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at >>> RTLinker.m3:395 >>> #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at >>> RTLinker.m3:109 >>> #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at >>> RTLinker.m3:118 >>> #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at >>> _m3main.mc:4 >>> >>> Notice it using user threads, so old m3core/libm3. >>> df doesn't appear to be any longer running. >>> Why it prints about the backend mode, I don't know. >>> >>> (and yes, I get it -- df -k is directly related to GetDiskSpace..if >>> this is how one checks diskspace on Unix...I think we should punt, >>> unless posix actually specifies the precise output format of this >>> command it is very reliably parsed...) >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com >>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: RE: [M3devel] CM3 release build regression tests not >>> terminating >>> Date: Tue, 28 Apr 2009 09:58:56 +0000 >>> >>> >>> Right, now it hangs having printed..I know this looks a bit of >>> nonsense..stuff from right around: >>> >>> >>> M3_BACKEND_MODE = "3" >>> % -- defines how the frontend, backend, and assembler interact >>> % "0" -- don't call m3_backend, M3CG produces object code >>> % "1" -- don't call m3_backend, M3CG produces assembly code >>> % "2" -- call m3_backend, it produces object code >>> % "3" -- call m3_backend, it produces assembly code >>> >>> >>> however, this is noticably pretty close to the last BEGIN_CONFIG. >>> >>> Maybe the carriage returns confused it. I'll see.. >>> I did introduce them recently by accident. >>> gdb reported some errors and no symbols in the callstack having >>> connected to it, on FreeBSD. If need be I can try debugging it on >>> another system.. >>> >>> >>> (aside, philosophy: all text processing code should treat \n, \r, >>> and \r\n in put the same, unless you are writing a terminal driver, >>> then \r has a separate meaning useful for implementing spinners..) >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> Date: Tue, 28 Apr 2009 11:40:00 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: RE: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> Quoting Jay : >>> >>> >>> Well, on FreeBSD 7.0, I get as far as: >>> >>> ew source -> compiling EnvUtils.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> ew source -> compiling EnvUtils.m3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> ew source -> compiling FingerprintFmt.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> ew source -> compiling TextUtils.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> >>> Yeah, I understand, I have libc.so.7. >>> >>> You need to install the FreeBSD compat packages for backward >>> compatibility. Should work fine then (until cminstall hangs?). >>> >>> Olaf >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> >>> I've never been able to get the tinderbox stuff to work for me. >>> I'll try again. >>> Nothing much from me lately -- pthreads movement to C, and then >>> back. >>> >>> Jay, did you change any config files recently? >>> >>> FreeBSD config file changes on 2009-04-13. >>> >>> - Jay >>> >>> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: wagner at elegosoft.com >>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> Yes, I had noticed this too. >>> >>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>> >>> Hi, >>> >>> does anybody know what's keeping the release-build tests for >>> tinderbox >>> from terminating? I've got lots of stalled regression process >>> trees on >>> my system, and the tinderbox display indicates that none of the >>> release >>> builds seem to succeed. Has anybody changed anything in the >>> scripts? >>> >>> On a closer look, upgrade seems to be stuck in the installer: >>> >>> % ps -axwww 25310 >>> PID TT STAT TIME COMMAND >>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>> luthien/current -o >>> >>> Jay, did you change any config files recently? >>> Regression tests seemed to have been running again for some >>> days, >>> and then >>> stopped again. >>> >>> I'll try to investigate further this evening, but must leave >>> now for >>> other work... >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>> 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> >>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 29 03:35:28 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 28 Apr 2009 18:35:28 -0700 Subject: [M3devel] manual initialization order? In-Reply-To: <557AEC0D-E50B-4A74-95B3-37AC2123878D@cs.purdue.edu> References: <557AEC0D-E50B-4A74-95B3-37AC2123878D@cs.purdue.edu> Message-ID: Ok I figured it might be. These modules should probably be disallowed from having any initializers, via a pragma. Require it all to be more explicit, in init. - Jay (phone) On Apr 28, 2009, at 2:41 PM, Tony Hosking wrote: > Indeed it is fragile, but necessary to bootstrap the system. > > On 29 Apr 2009, at 00:15, Jay wrote: > >> >> Um, if initializers are so acceptable (I'm skeptical, but everyone >> here disagrees with me..) and circularities are not allowed (that >> helps I guess..but is it really true? the garbage collector uses >> threads, the threading library allocates traced references..I sense >> circularity...)...why does RTLinker manually pick an initialization >> order? This is fragile. >> >> >> (* initialize the rest of the modules we'll be calling *) >> AddUnit (RTLinkerX.RTLinker_I3); (* myself! *) >> AddUnit (RTLinkerX.RT0_I3); >> AddUnit (RTLinkerX.RTSignal_I3); >> AddUnit (RTLinkerX.RTParams_I3); >> AddUnit (RTLinkerX.RTDebug_I3); >> AddUnit (RTLinkerX.RTError_I3); >> AddUnit (RTLinkerX.RTHeapRep_I3); >> AddUnit (RTLinkerX.ThreadF_I3); >> AddUnit (RTLinkerX.RTHeapInfo_I3); >> AddUnit (RTLinkerX.RTIO_I3); >> AddUnit (RTLinkerX.RTCollectorSRC_I3); >> AddUnit (RTLinkerX.Word_I3); >> >> >> >> (* finally, initialize the runtime. *) >> RTSignal.InstallHandlers (); >> RTParams.Init (); >> RTHeapRep.Init (); >> ThreadF.Init (); >> RTDebug.Init (); >> RTHeapInfo.Init (); >> IF RTParams.IsPresent("tracelinker") THEN >> traceInit := TRUE; >> END; >> >> >> AddUnit (RTLinkerX.RTDebug_M3); >> AddUnit (RTLinkerX.RTError_M3); >> AddUnit (RTLinkerX.RTType_M3); >> AddUnit (RTLinkerX.RTPacking_M3); >> AddUnit (RTLinkerX.RTTipe_M3); >> AddUnit (RTLinkerX.RTException_M3); > > From wagner at elegosoft.com Wed Apr 29 08:20:06 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 29 Apr 2009 08:20:06 +0200 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <2565931E-F3F3-4832-8582-C1D227B556DA@cs.purdue.edu> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> <9AC96562-7045-418A-A069-84EE8613498A@cs.purdue.edu> <2565931E-F3F3-4832-8582-C1D227B556DA@cs.purdue.edu> Message-ID: <20090429082006.pchddoojkw8kckgk@mail.elegosoft.com> Quoting Tony Hosking : > Whatever changed in the last 24 hours has my tinderbox runs completing now. Hm. The process doesn't hang anymore; I get the following errors though: (1) === package m3-libs/unittest-numeric === +++ /home/wagner/tmp/cm3/luthien/cm3/bin/cm3 -build -override -DROOT='/u/cm3/cm 3-ws/luthien-2009-04-29-01-30-32/cm3' +++ --- building in FreeBSD4 --- unable to read ../src/m3overrides, options "-override" and "-x" ignored. "/u/cm3/cm3-ws/luthien-2009-04-29-01-30-32/cm3/m3-libs/unittest-numeric/src/m3ma kefile", line 1: quake runtime error: unable to open "/home/wagner/tmp/cm3/luthi en/cm3/pkg/libm3/FreeBSD4/.M3EXPORTS" for reading --procedure-- -line- -file--- import -- include_dir 1 /u/cm3/cm3-ws/luthien-2009-04-29-01-30-32/cm3/m3-libs/uni ttest-numeric/src/m3makefile 5 /u/cm3/cm3-ws/luthien-2009-04-29-01-30-32/cm3/m3-libs/uni ttest-numeric/FreeBSD4/m3make.args Fatal Error: package build failed ==> m3-libs/unittest-numeric done (2) === package m3-sys/cm3ide === +++ /home/wagner/tmp/cm3/luthien/cm3/bin/cm3 -build -override -DROOT='/u/cm3/cm 3-ws/luthien-2009-04-29-01-30-32/cm3' +++ --- building in FreeBSD4 --- "/u/cm3/cm3-ws/luthien-2009-04-29-01-30-32/cm3/m3-sys/cm3ide/src/m3makefile", li ne 9: quake runtime error: unable to open "/u/cm3/cm3-ws/luthien-2009-04-29-01-3 0-32/cm3/m3-libs/tcp/FreeBSD4/.M3EXPORTS" for reading --procedure-- -line- -file--- import -- include_dir 9 /u/cm3/cm3-ws/luthien-2009-04-29-01-30-32/cm3/m3-sys/cm3i de/src/m3makefile 6 /u/cm3/cm3-ws/luthien-2009-04-29-01-30-32/cm3/m3-sys/cm3i de/FreeBSD4/m3make.args Fatal Error: package build failed ==> m3-sys/cm3ide done (3) === package m3-comm/stubgen === +++ /home/wagner/tmp/cm3/luthien/cm3/bin/cm3 -build -override -DROOT='/u/cm3/cm 3-ws/luthien-2009-04-29-01-30-32/cm3' +++ --- building in FreeBSD4 --- new source -> compiling Value.i3 new source -> compiling Type.i3 new source -> compiling ValueProc.i3 new source -> compiling Protocol.i3 new source -> compiling TypeNames.i3 new source -> compiling TypeNames.m3 new source -> compiling StubUtils.i3 new source -> compiling Type.m3 "../src/Type.m3", line 291: types are not assignable 1 error encountered new source -> compiling Value.m3 new source -> compiling AstToType.i3 new source -> compiling AstToVal.i3 new source -> compiling AstToVal.m3 new source -> compiling StubCode.i3 new source -> compiling FRefRefTbl.i3 new source -> compiling AstToType.m3 new source -> compiling ModuleStubCode.i3 new source -> compiling IntfStubCode.i3 new source -> compiling CodeForType.i3 new source -> compiling StubCode.m3 new source -> compiling CodeForType.m3 new source -> compiling ModuleStubCode.m3 new source -> compiling IntfStubCode.m3 new source -> compiling StubGenTool.i3 new source -> compiling StubGenTool.m3 new source -> compiling StubUtils.m3 new source -> compiling FRefRefTbl.m3 new source -> compiling Main.m3 new exporters -> recompiling ValueProc.i3 new exporters -> recompiling Type.i3 new opaque info -> recompiling TypeNames.m3 new opaque info -> recompiling AstToVal.m3 new opaque info -> recompiling AstToType.m3 new opaque info -> recompiling StubGenTool.m3 compilation failed => not building program "stubgen" Fatal Error: package build failed *** execution of /home/wagner/tmp/cm3/luthien/cm3/bin/cm3 -build -override -DROOT='/u/cm3/cm3-ws/luthien-2009-04-29-01-30-32/cm3' failed *** real 82m36.775s user 25m38.739s sys 14m12.884s Tinderbox currently does not show any success, too. It seems that still more is amiss. Olaf > > On 28 Apr 2009, at 22:13, Jay wrote: > >> >> Tony can you clarify? Things stopped working two weeks ago? >> Or things were working until more recently? >> >> >> >> It seems like the select call never returns. >> Whatever is going on, it troubles debugging tools. >> gdb won't follow the children..which is probably ok, they aren't >> the problem. >> truss can't be control-c'ed, but can be killed. >> "info locals" in gdb often hangs and I have to pkill gdb. >> Not that info locals ever works well, but it usually doesn't hang gdb. >> I started putting in RTIO calls. >> WaitForAll's finishes one Wait call but then hangs on the next. >> >> >> I think we should not run cminstall against 5.4 runtime. >> Enable user threads as some related scenario.. >> >> >> - Jay >> >> >> ________________________________ >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>> Date: Tue, 28 Apr 2009 21:49:32 +1000 >>> >>> Sounds about right. >>> >>> 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 28 Apr 2009, at 21:17, Jay wrote: >>> >>> >>> The changes went in two weeks ago 4/14, were they definitely working? >>> I can try it again, hopefully without the full tinderbox stuff. >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Tue, 28 Apr 2009 21:11:42 +1000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>> >>> What could possibly have changed here. It used to work fine on >>> multiple platforms. >>> >>> On 28 Apr 2009, at 20:14, Jay wrote: >>> >>> >>> It creates a file named "df-k" and hangs here: >>> >>> (gdb) where >>> #0 0x080f417f in select () >>> #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, >>> writefds=0x28127138, >>> exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ >>> FreeBSD4/select.c:13 >>> #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, >>> M3_CEtG8K_timeout=0xbfbfe6d8) >>> at ThreadPosix.m3:714 >>> #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 >>> #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, >>> M3_AicXUJ_alertable=0 '\0') >>> at ThreadPosix.m3:555 >>> #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at >>> ThreadPosix.m3:539 >>> #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at >>> ProcessPosix.m3:294 >>> #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at >>> System.m3:527 >>> #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, >>> M3_EkfbeH_env=0x0, >>> M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 >>> #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at >>> OSPOSIX.m3:19 >>> #10 0x0804c31c in Main__DoIt () at Main.m3:122 >>> #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 >>> #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at >>> RTLinker.m3:395 >>> #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at >>> RTLinker.m3:109 >>> #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at >>> RTLinker.m3:118 >>> #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at >>> _m3main.mc:4 >>> >>> Notice it using user threads, so old m3core/libm3. >>> df doesn't appear to be any longer running. >>> Why it prints about the backend mode, I don't know. >>> >>> (and yes, I get it -- df -k is directly related to GetDiskSpace..if >>> this is how one checks diskspace on Unix...I think we should punt, >>> unless posix actually specifies the precise output format of this >>> command it is very reliably parsed...) >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com >>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: RE: [M3devel] CM3 release build regression tests not >>> terminating >>> Date: Tue, 28 Apr 2009 09:58:56 +0000 >>> >>> >>> Right, now it hangs having printed..I know this looks a bit of >>> nonsense..stuff from right around: >>> >>> >>> M3_BACKEND_MODE = "3" >>> % -- defines how the frontend, backend, and assembler interact >>> % "0" -- don't call m3_backend, M3CG produces object code >>> % "1" -- don't call m3_backend, M3CG produces assembly code >>> % "2" -- call m3_backend, it produces object code >>> % "3" -- call m3_backend, it produces assembly code >>> >>> >>> however, this is noticably pretty close to the last BEGIN_CONFIG. >>> >>> Maybe the carriage returns confused it. I'll see.. >>> I did introduce them recently by accident. >>> gdb reported some errors and no symbols in the callstack having >>> connected to it, on FreeBSD. If need be I can try debugging it on >>> another system.. >>> >>> >>> (aside, philosophy: all text processing code should treat \n, \r, >>> and \r\n in put the same, unless you are writing a terminal driver, >>> then \r has a separate meaning useful for implementing spinners..) >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> Date: Tue, 28 Apr 2009 11:40:00 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: RE: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> Quoting Jay : >>> >>> >>> Well, on FreeBSD 7.0, I get as far as: >>> >>> ew source -> compiling EnvUtils.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> ew source -> compiling EnvUtils.m3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> ew source -> compiling FingerprintFmt.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> ew source -> compiling TextUtils.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> >>> Yeah, I understand, I have libc.so.7. >>> >>> You need to install the FreeBSD compat packages for backward >>> compatibility. Should work fine then (until cminstall hangs?). >>> >>> Olaf >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> >>> I've never been able to get the tinderbox stuff to work for me. >>> I'll try again. >>> Nothing much from me lately -- pthreads movement to C, and then >>> back. >>> >>> Jay, did you change any config files recently? >>> >>> FreeBSD config file changes on 2009-04-13. >>> >>> - Jay >>> >>> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: wagner at elegosoft.com >>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> Yes, I had noticed this too. >>> >>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>> >>> Hi, >>> >>> does anybody know what's keeping the release-build tests for >>> tinderbox >>> from terminating? I've got lots of stalled regression process >>> trees on >>> my system, and the tinderbox display indicates that none of the >>> release >>> builds seem to succeed. Has anybody changed anything in the >>> scripts? >>> >>> On a closer look, upgrade seems to be stuck in the installer: >>> >>> % ps -axwww 25310 >>> PID TT STAT TIME COMMAND >>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>> luthien/current -o >>> >>> Jay, did you change any config files recently? >>> Regression tests seemed to have been running again for some >>> days, >>> and then >>> stopped again. >>> >>> I'll try to investigate further this evening, but must leave >>> now for >>> other work... >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>> 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> >>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 mika at async.caltech.edu Wed Apr 29 08:22:35 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 28 Apr 2009 23:22:35 -0700 Subject: [M3devel] [M3commit] how to switch userthreads on/off In-Reply-To: Your message of "Wed, 29 Apr 2009 00:06:02 -0000." Message-ID: <200904290622.n3T6MZBR003219@camembert.async.caltech.edu> Jay writes: ... > >Maybe just leave it as an option in m3core's m3makefile and people can twiddle it if they want and rebuild the entire system like it is today? >That is a bit onerous, but maybe it's all userthreads deserve? >? > > >Anyone who actually wanted to switch back and forth (Mika) would just have two installs and two source trees? > > > - Jay I just want to clarify. I'm not really that interested in switching back and forth. I'm just a little disturbed by the sometimes huge performance loss due to the introduction of kernel threads. I knew that this would happen in certain highly multithreaded applications, but I'm surprised it happens in a more or less single-threaded application. I think I've just been spoiled by 10 years of using SRCM3 and PM3 for FreeBSD w/o kernel threads in the sense that I've learned that using LOCK has essentially no cost. On a shared-memory multiprocessor, I really don't expect that to remain the case... physics won't allow it. So now I just have to go through my code and find all the places where I lock too much and remove them. But the memory allocator and garbage collector do it too, no? I also think that this idea of being able to use either is great. Mainly single-threaded programs should definitely not use kernel threads! As for reaching the "thread locals", there is one slightly crazy idea that one could borrow from Sussman and Steele: add another implicit argument to every Modula-3 routine. In that argument, pass a pointer to the thread locals. For EXTERNAL calls (in or out), make it NIL (somehow, maybe involving pragmas), and in that case (only), use the pthreads routines to access the thread locals. Ok so it sounds kind of nuts, but with this approach you could avoid locking or even calling into the pthreads libs almost entirely for a single-threaded program. You could even have a thread-local memory allocator that would only lock when it needs to request memory from the "global allocator"... in fact there are lots of things you can do with this sort of thing. Dynamically scoped variables in Scheme (a la MacLisp?) is what they originally proposed it for but then they suggested all kinds of tricks related to continuations with it. Mika From mika at async.caltech.edu Wed Apr 29 08:53:32 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 28 Apr 2009 23:53:32 -0700 Subject: [M3devel] user threads In-Reply-To: Your message of "Tue, 28 Apr 2009 16:54:03 -0000." Message-ID: <200904290653.n3T6rW8b004699@camembert.async.caltech.edu> Ok, it works! Numbers: Timings in milliseconds, three samples, filesystem "warmed up" by doing one dummy run before launching the real ones. -unsafe means that I use non-locking Scheme environments, otherwise they lock for every variable update. ave CM3 last week, kernel threads, -unsafe 1460 1482 1437 1460 CM3 last week, kernel threads, 2392 2402 2376 2390 CM3 this week, kernel threads, -unsafe 1455 1458 1490 1468 (*) CM3 this week, user threads, -unsafe 914 934 914 921 CM3 this week, user threads, 967 965 986 973 PM3 -unsafe 678 657 682 672 PM3 709 714 700 708 (*) not entirely sure this got linked correctly. Mika Jay writes: > >User threads seem to work on on FreeBSD/x86 7.0. >Mika can you report back the perf cm3 vs. pm3? >Still, kernel threads have been around a long time and imho should be strongly favored.. > > >Kernel threads should be a /little/ faster than they were -- PushEFrame removed from successful heap allocations. And should be further improvable via __thread where it is supported -- probably not FreeBSD 4. >x, sometimes older is not better. :) > > >I've temporarily switched FreeBSD/x86 to userthreads by default but I think that's just an experiment and should be undone shortly, maybe work out some other story for easily switching between them, or just k >eep the existing story of "you get to rebuild everything". > > >Tony, can you look into GetGCRatio? I removed the call to it. The "fatal" pragma invokes PushEFrame apparently. > > >We should now "fix" Win32 and pthreads to not have GetActivation initialize on-demand, just leave Init to initialize always. This should shave a few more cycles from PushEFrame. > > > - Jay From mika at async.caltech.edu Wed Apr 29 08:58:16 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 28 Apr 2009 23:58:16 -0700 Subject: [M3devel] user threads In-Reply-To: Your message of "Tue, 28 Apr 2009 23:53:32 PDT." <200904290653.n3T6rW8b004699@camembert.async.caltech.edu> Message-ID: <200904290658.n3T6wGl3004945@camembert.async.caltech.edu> By the way, *all* my CM3 timings have my Typecase modification, which isn't checked in to the distribution. I think they would all be about 400 ms slower if they didn't have that. A bit of "poor man's profiling" shows the program still spending quite some time in RTType.IsSubtype (called from CheckIsType). I think that accounts for most of the remaining difference between PM3 and CM3. Mika Mika Nystrom writes: >Ok, it works! > >Numbers: > >Timings in milliseconds, three samples, filesystem "warmed up" by >doing one dummy run before launching the real ones. > >-unsafe means that I use non-locking Scheme environments, otherwise >they lock for every variable update. > ave >CM3 last week, kernel threads, -unsafe 1460 1482 1437 1460 >CM3 last week, kernel threads, 2392 2402 2376 2390 >CM3 this week, kernel threads, -unsafe 1455 1458 1490 1468 (*) >CM3 this week, user threads, -unsafe 914 934 914 921 >CM3 this week, user threads, 967 965 986 973 >PM3 -unsafe 678 657 682 672 >PM3 709 714 700 708 > >(*) not entirely sure this got linked correctly. > > Mika > > >Jay writes: >> >>User threads seem to work on on FreeBSD/x86 7.0. >>Mika can you report back the perf cm3 vs. pm3? >>Still, kernel threads have been around a long time and imho should be strongly favored.. >> >> >>Kernel threads should be a /little/ faster than they were -- PushEFrame removed from successful heap allocations. And should be further improvable via __thread where it is supported -- probably not FreeBSD 4 >. >>x, sometimes older is not better. :) >> >> >>I've temporarily switched FreeBSD/x86 to userthreads by default but I think that's just an experiment and should be undone shortly, maybe work out some other story for easily switching between them, or just >k >>eep the existing story of "you get to rebuild everything". >> >> >>Tony, can you look into GetGCRatio? I removed the call to it. The "fatal" pragma invokes PushEFrame apparently. >> >> >>We should now "fix" Win32 and pthreads to not have GetActivation initialize on-demand, just leave Init to initialize always. This should shave a few more cycles from PushEFrame. >> >> >> - Jay From jay.krell at cornell.edu Wed Apr 29 09:05:10 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 29 Apr 2009 07:05:10 +0000 Subject: [M3devel] user threads In-Reply-To: <200904290653.n3T6rW8b004699@camembert.async.caltech.edu> References: Your message of "Tue, 28 Apr 2009 16:54:03 -0000." <200904290653.n3T6rW8b004699@camembert.async.caltech.edu> Message-ID: Mika, thanks. Want to try the next variation? look at m3-libs/m3core/src/thread/PTHREAD/ThreadPThreadC.c. See THREAD_LOCAL, THREAD_LOCAL_SLOW, THREAD_LOCAL_FAST? Try switching THREAD_LOCAL to use THREAD_LOCAL_FAST instead of _SLOW. On FreeBSD 5.x or newer. It won't compile for 4.x we know. Thanks, - Jay > To: jay.krell at cornell.edu > Date: Tue, 28 Apr 2009 23:53:32 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] user threads > > Ok, it works! > > Numbers: > > Timings in milliseconds, three samples, filesystem "warmed up" by > doing one dummy run before launching the real ones. > > -unsafe means that I use non-locking Scheme environments, otherwise > they lock for every variable update. > ave > CM3 last week, kernel threads, -unsafe 1460 1482 1437 1460 > CM3 last week, kernel threads, 2392 2402 2376 2390 > CM3 this week, kernel threads, -unsafe 1455 1458 1490 1468 (*) > CM3 this week, user threads, -unsafe 914 934 914 921 > CM3 this week, user threads, 967 965 986 973 > PM3 -unsafe 678 657 682 672 > PM3 709 714 700 708 > > (*) not entirely sure this got linked correctly. > > Mika > > > Jay writes: > > > >User threads seem to work on on FreeBSD/x86 7.0. > >Mika can you report back the perf cm3 vs. pm3? > >Still, kernel threads have been around a long time and imho should be strongly favored.. > > > > > >Kernel threads should be a /little/ faster than they were -- PushEFrame removed from successful heap allocations. And should be further improvable via __thread where it is supported -- probably not FreeBSD 4. > >x, sometimes older is not better. :) > > > > > >I've temporarily switched FreeBSD/x86 to userthreads by default but I think that's just an experiment and should be undone shortly, maybe work out some other story for easily switching between them, or just k > >eep the existing story of "you get to rebuild everything". > > > > > >Tony, can you look into GetGCRatio? I removed the call to it. The "fatal" pragma invokes PushEFrame apparently. > > > > > >We should now "fix" Win32 and pthreads to not have GetActivation initialize on-demand, just leave Init to initialize always. This should shave a few more cycles from PushEFrame. > > > > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Apr 29 09:18:42 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 29 Apr 2009 00:18:42 -0700 Subject: [M3devel] user threads In-Reply-To: Your message of "Tue, 28 Apr 2009 23:58:16 PDT." <200904290658.n3T6wGl3004945@camembert.async.caltech.edu> Message-ID: <200904290718.n3T7Ig6b005836@camembert.async.caltech.edu> Of course I just realized this typecase business doesn't work. Not thread-safe. The numbers for CM3 are worse than I write... sigh, ok, back to the drawing board. Mika Nystrom writes: >By the way, *all* my CM3 timings have my Typecase modification, >which isn't checked in to the distribution. I think they would all >be about 400 ms slower if they didn't have that. > >A bit of "poor man's profiling" shows the program still spending >quite some time in RTType.IsSubtype (called from CheckIsType). >I think that accounts for most of the remaining difference between >PM3 and CM3. > > Mika > >Mika Nystrom writes: >>Ok, it works! >> >>Numbers: >> >>Timings in milliseconds, three samples, filesystem "warmed up" by >>doing one dummy run before launching the real ones. >> >>-unsafe means that I use non-locking Scheme environments, otherwise >>they lock for every variable update. >> ave >>CM3 last week, kernel threads, -unsafe 1460 1482 1437 1460 >>CM3 last week, kernel threads, 2392 2402 2376 2390 >>CM3 this week, kernel threads, -unsafe 1455 1458 1490 1468 (*) >>CM3 this week, user threads, -unsafe 914 934 914 921 >>CM3 this week, user threads, 967 965 986 973 >>PM3 -unsafe 678 657 682 672 >>PM3 709 714 700 708 >> >>(*) not entirely sure this got linked correctly. >> >> Mika >> >> >>Jay writes: >>> >>>User threads seem to work on on FreeBSD/x86 7.0. >>>Mika can you report back the perf cm3 vs. pm3? >>>Still, kernel threads have been around a long time and imho should be strongly favored.. >>> >>> >>>Kernel threads should be a /little/ faster than they were -- PushEFrame removed from successful heap allocations. And should be further improvable via __thread where it is supported -- probably not FreeBSD >4 >>. >>>x, sometimes older is not better. :) >>> >>> >>>I've temporarily switched FreeBSD/x86 to userthreads by default but I think that's just an experiment and should be undone shortly, maybe work out some other story for easily switching between them, or just > >>k >>>eep the existing story of "you get to rebuild everything". >>> >>> >>>Tony, can you look into GetGCRatio? I removed the call to it. The "fatal" pragma invokes PushEFrame apparently. >>> >>> >>>We should now "fix" Win32 and pthreads to not have GetActivation initialize on-demand, just leave Init to initialize always. This should shave a few more cycles from PushEFrame. >>> >>> >>> - Jay From jay.krell at cornell.edu Wed Apr 29 09:26:05 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 29 Apr 2009 07:26:05 +0000 Subject: [M3devel] [M3commit] how to switch userthreads on/off In-Reply-To: <200904290622.n3T6MZBR003219@camembert.async.caltech.edu> References: Your message of "Wed, 29 Apr 2009 00:06:02 -0000." <200904290622.n3T6MZBR003219@camembert.async.caltech.edu> Message-ID: > But the memory allocator and garbage collector do it too, no? Right, the garbage collector runs a separate thread. > As for reaching the "thread locals", there is one slightly crazy > idea that one could borrow from Sussman and Steele: add another > implicit argument to every Modula-3 routine. In that argument, > pass a pointer to the thread locals. For EXTERNAL calls (in or This is basically how it works already on many systems. Just not FreeBSD <5, where there's no kernel thread support for managing the register at thread switch time. Look at the assembly code for __thread on FreeBSD 5. Notice that they do dedicate a register to thread locals. So it is about the same as what you propose, but better because they use a wierdo (segment) register that otherwise was unused. (Most other architectures can afford to give up a regular register. The "better" part is specific to x86 having so few registers.) I'm hoping to lay most of the blame on FreeBSD 4.x pthread_get/setspecific. But there is still setjmp lurking in there, even on PM3, no matter user or pthreads. Do you have numbers for FreeBSD 5 PM3 vs. CM3 pthreads? __thread should be faster than pthread_get/setspecific, but pthread_get/setspecific are probably also way better with kernel threads vs. FreeBSD 4 usermode pthreads.. Olaf, your recall that FreeBSD userthreads were "fast"..is that based on FreeBSD 4.x by chance? Maybe they don't have much advantage on any other system? You know...FreeBSD 4.x pthreads are also userthreads, not really a fair comparison maybe with other pthreads implementations and maybe give pthreads a bad name? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 29 14:27:48 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 29 Apr 2009 12:27:48 +0000 Subject: [M3devel] coping with low memory/resources? Message-ID: coping with low memory/resources? We have code that does like r := pthread_do_something() assert(r == 0); where for example: [EAGAIN] The system lacked the necessary resources (other than memory) to initialise another mutex. [ENOMEM] Insufficient memory exists to initialise the mutex. I'll fix it to raise an out of memory exception for ENOMEM. Ok. But what about EAGAIN? Retry? That is what "again" means, right? In an infinite loop? Or just a few times? You know -- overall system might be low but other parts might reduce, or the Modula-3 code itself might be hogging resources and retry might just sit there forever. Raise some other exception? For now I'll leave it asserting. - Jay From jay.krell at cornell.edu Wed Apr 29 16:12:37 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 29 Apr 2009 14:12:37 +0000 Subject: [M3devel] any limitations on __thread? Message-ID: Anyone have expertise on __thread? In particular, on Windows there is a close analog __declspec(thread) that generally would seem to work and work well, except that, per documentation, prior to Vista, it doesn't work if you are loaded with LoadLibrary (dlopen), only if the main executable uses your .so, directly or indirectly. To me that's a pretty big limitation so I wouldn't use it. I haven't seen any documentation on __thread giving this caveat though so it seems ok to use. I changed m3core to use it if sample code seems to compile, link, and execute correctly with it. - Jay From mika at async.caltech.edu Wed Apr 29 18:22:36 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 29 Apr 2009 09:22:36 -0700 Subject: [M3devel] [M3commit] how to switch userthreads on/off In-Reply-To: Your message of "Wed, 29 Apr 2009 07:26:05 -0000." Message-ID: <200904291622.n3TGMaEA031447@camembert.async.caltech.edu> Jay: I understand now. I should do more research first. libc_r is a user-level threads package, and not a very good one at that. The built-into-Modula-3 threads offer all the same facilities as FreeBSD's libc_r, as well as much higher performance. In view of that, I think it's great that you've resurrected CM3's user threads. No reason not to use them on FreeBSD4. Now to test on FreeBSD5. I still don't quite understand why kernel threads should be faster than user threads. But since all I have at the moment is libc_r, I can't back up my doubts with any numbers. Mika Jay writes: >--_2ce3dd88-b4b7-4b0b-8d3d-405d9122c9e1_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > But the memory allocator and garbage collector do it too=2C no?=20 > >=20 > >=20 > >Right=2C the garbage collector runs a separate thread. > >=20 > > > > As for reaching the "thread locals"=2C there is one slightly crazy=20 > > idea that one could borrow from Sussman and Steele: add another=20 > > implicit argument to every Modula-3 routine. In that argument=2C=20 > > pass a pointer to the thread locals. For EXTERNAL calls (in or=20 > > >=20 > >This is basically how it works already on many systems. > >Just not FreeBSD <5=2C where there's no kernel thread support for managing > >the register at thread switch time. > >=20 > >Look at the assembly code for __thread on FreeBSD 5. > >=20 > >Notice that they do dedicate a register to thread locals. > >So it is about the same as what you propose=2C but better because they use = >a wierdo (segment) register that otherwise was unused. (Most other architec= >tures can afford to give up a regular register. The "better" part is specif= >ic to x86 having so few registers.) > >=20 > >=20 > >I'm hoping to lay most of the blame on FreeBSD 4.x pthread_get/setspecific. > >But there is still setjmp lurking in there=2C even on PM3=2C no matter user= > or pthreads. > >=20 > >=20 > >Do you have numbers for FreeBSD 5 PM3 vs. CM3 pthreads? > >__thread should be faster than pthread_get/setspecific=2C but pthread_get/s= >etspecific are probably also way better with kernel threads vs. FreeBSD 4 u= >sermode pthreads.. > >=20 > >=20 > >Olaf=2C your recall that FreeBSD userthreads were "fast"..is that based on = >FreeBSD 4.x by chance? Maybe they don't have much advantage on any other sy= >stem? > >You know...FreeBSD 4.x pthreads are also userthreads=2C not really a fair c= >omparison maybe with other pthreads implementations and maybe give pthreads= > a bad name? > >=20 > >=20 > > - Jay > >=20 > >--_2ce3dd88-b4b7-4b0b-8d3d-405d9122c9e1_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > > =3B>=3B But the memory allocator and garbage collector do it too=2C = >no?
> =3B
> =3B
>Right=2C the garbage collector runs a separate thread.
> =3B
>
 =3B>=3B As for reaching the "thread locals"=2C there is one slig= >htly crazy
 =3B>=3B idea that one could borrow from Sussman and S= >teele: add another
 =3B>=3B implicit argument to every Modula-3 r= >outine. In that argument=2C
 =3B>=3B pass a pointer to the thread= > locals. For EXTERNAL calls (in or

> =3B
>This is basically how it works already on many systems.
>Just not FreeBSD <=3B5=2C where there's no kernel thread support for mana= >ging
>the register at thread switch time.
> =3B
>Look at the assembly code for __thread on FreeBSD 5.
> =3B
>Notice that they do dedicate a register to thread locals.
>So it is about the same as what you propose=2C but better because they = >=3Buse a wierdo (segment) register that otherwise was unused. (Most other a= >rchitectures can afford to give up a regular register. The "better" part is= > specific to x86 having so few registers.)
> =3B
> =3B
>I'm hoping to lay most of the blame on FreeBSD 4.x pthread_get/setspecific.= >
>But there is still setjmp lurking in there=2C even on PM3=2C no matter user= > or pthreads.
> =3B
> =3B
>Do you have numbers for FreeBSD 5 PM3 vs. CM3 pthreads?
>__thread should be faster than pthread_get/setspecific=2C but pthread_get/s= >etspecific are probably also way better with kernel threads vs. =3BFree= >BSD 4 usermode pthreads..
> =3B
> =3B
>Olaf=2C =3Byour recall that FreeBSD userthreads were =3B"fast"..is = >that based on FreeBSD 4.x by chance? Maybe they don't have much advantage o= >n any other system?
>You know...FreeBSD 4.x pthreads are also userthreads=2C not really a fair c= >omparison maybe with other pthreads implementations and maybe give pthreads= > a bad name?
> =3B
> =3B
> =3B- Jay
> =3B
>= > >--_2ce3dd88-b4b7-4b0b-8d3d-405d9122c9e1_-- From hosking at cs.purdue.edu Wed Apr 29 20:00:09 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 30 Apr 2009 04:00:09 +1000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <4FBC0000-EF60-4890-B125-7CB566813931@hotmail.com> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> <9AC96562-7045-418A-A069-84EE8613498A@cs.purdue.edu> <2565931E-F3F3-4832-8582-C1D227B556DA@cs.purdue.edu> <4FBC0000-EF60-4890-B125-7CB566813931@hotmail.com> Message-ID: I'd say about 2 weeks. On 29 Apr 2009, at 11:57, jay.krell at cornell.edu wrote: > Was it broken for two weeks, or shorter? > > - Jay (phone) > > On Apr 28, 2009, at 2:51 PM, Tony Hosking > wrote: > >> Whatever changed in the last 24 hours has my tinderbox runs >> completing now. >> >> On 28 Apr 2009, at 22:13, Jay wrote: >> >>> >>> Tony can you clarify? Things stopped working two weeks ago? >>> Or things were working until more recently? >>> >>> >>> >>> It seems like the select call never returns. >>> Whatever is going on, it troubles debugging tools. >>> gdb won't follow the children..which is probably ok, they aren't >>> the problem. >>> truss can't be control-c'ed, but can be killed. >>> "info locals" in gdb often hangs and I have to pkill gdb. >>> Not that info locals ever works well, but it usually doesn't hang >>> gdb. >>> I started putting in RTIO calls. >>> WaitForAll's finishes one Wait call but then hangs on the next. >>> >>> >>> I think we should not run cminstall against 5.4 runtime. >>> Enable user threads as some related scenario.. >>> >>> >>> - Jay >>> >>> >>> ________________________________ >>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>> From: hosking at cs.purdue.edu >>>> To: jay.krell at cornell.edu >>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>> terminating >>>> Date: Tue, 28 Apr 2009 21:49:32 +1000 >>>> >>>> Sounds about right. >>>> >>>> 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 28 Apr 2009, at 21:17, Jay wrote: >>>> >>>> >>>> The changes went in two weeks ago 4/14, were they definitely >>>> working? >>>> I can try it again, hopefully without the full tinderbox stuff. >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> To: jay.krell at cornell.edu >>>> Date: Tue, 28 Apr 2009 21:11:42 +1000 >>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>> terminating >>>> >>>> What could possibly have changed here. It used to work fine on >>>> multiple platforms. >>>> >>>> On 28 Apr 2009, at 20:14, Jay wrote: >>>> >>>> >>>> It creates a file named "df-k" and hangs here: >>>> >>>> (gdb) where >>>> #0 0x080f417f in select () >>>> #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, >>>> writefds=0x28127138, >>>> exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ >>>> FreeBSD4/select.c:13 >>>> #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, >>>> M3_CEtG8K_timeout=0xbfbfe6d8) >>>> at ThreadPosix.m3:714 >>>> #3 0x080c993b in ThreadPosix__InternalYield () at >>>> ThreadPosix.m3:985 >>>> #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, >>>> M3_AicXUJ_alertable=0 '\0') >>>> at ThreadPosix.m3:555 >>>> #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at >>>> ThreadPosix.m3:539 >>>> #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at >>>> ProcessPosix.m3:294 >>>> #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at >>>> System.m3:527 >>>> #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, >>>> M3_EkfbeH_env=0x0, >>>> M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 >>>> #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at >>>> OSPOSIX.m3:19 >>>> #10 0x0804c31c in Main__DoIt () at Main.m3:122 >>>> #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 >>>> #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at >>>> RTLinker.m3:395 >>>> #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at >>>> RTLinker.m3:109 >>>> #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at >>>> RTLinker.m3:118 >>>> #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) >>>> at >>>> _m3main.mc:4 >>>> >>>> Notice it using user threads, so old m3core/libm3. >>>> df doesn't appear to be any longer running. >>>> Why it prints about the backend mode, I don't know. >>>> >>>> (and yes, I get it -- df -k is directly related to GetDiskSpace..if >>>> this is how one checks diskspace on Unix...I think we should punt, >>>> unless posix actually specifies the precise output format of this >>>> command it is very reliably parsed...) >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: wagner at elegosoft.com >>>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>>> Subject: RE: [M3devel] CM3 release build regression tests not >>>> terminating >>>> Date: Tue, 28 Apr 2009 09:58:56 +0000 >>>> >>>> >>>> Right, now it hangs having printed..I know this looks a bit of >>>> nonsense..stuff from right around: >>>> >>>> >>>> M3_BACKEND_MODE = "3" >>>> % -- defines how the frontend, backend, and assembler interact >>>> % "0" -- don't call m3_backend, M3CG produces object code >>>> % "1" -- don't call m3_backend, M3CG produces assembly code >>>> % "2" -- call m3_backend, it produces object code >>>> % "3" -- call m3_backend, it produces assembly code >>>> >>>> >>>> however, this is noticably pretty close to the last BEGIN_CONFIG. >>>> >>>> Maybe the carriage returns confused it. I'll see.. >>>> I did introduce them recently by accident. >>>> gdb reported some errors and no symbols in the callstack having >>>> connected to it, on FreeBSD. If need be I can try debugging it on >>>> another system.. >>>> >>>> >>>> (aside, philosophy: all text processing code should treat \n, \r, >>>> and \r\n in put the same, unless you are writing a terminal driver, >>>> then \r has a separate meaning useful for implementing spinners..) >>>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>> Date: Tue, 28 Apr 2009 11:40:00 +0200 >>>> From: wagner at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>>> Subject: RE: [M3devel] CM3 release build regression tests not >>>> terminating >>>> >>>> Quoting Jay : >>>> >>>> >>>> Well, on FreeBSD 7.0, I get as far as: >>>> >>>> ew source -> compiling EnvUtils.i3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> ew source -> compiling EnvUtils.m3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> ew source -> compiling FingerprintFmt.i3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> ew source -> compiling TextUtils.i3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> >>>> Yeah, I understand, I have libc.so.7. >>>> >>>> You need to install the FreeBSD compat packages for backward >>>> compatibility. Should work fine then (until cminstall hangs?). >>>> >>>> Olaf >>>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>> terminating >>>> >>>> >>>> I've never been able to get the tinderbox stuff to work for me. >>>> I'll try again. >>>> Nothing much from me lately -- pthreads movement to C, and then >>>> back. >>>> >>>> Jay, did you change any config files recently? >>>> >>>> FreeBSD config file changes on 2009-04-13. >>>> >>>> - Jay >>>> >>>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> To: wagner at elegosoft.com >>>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>> terminating >>>> >>>> Yes, I had noticed this too. >>>> >>>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>>> >>>> Hi, >>>> >>>> does anybody know what's keeping the release-build tests for >>>> tinderbox >>>> from terminating? I've got lots of stalled regression process >>>> trees on >>>> my system, and the tinderbox display indicates that none of the >>>> release >>>> builds seem to succeed. Has anybody changed anything in the >>>> scripts? >>>> >>>> On a closer look, upgrade seems to be stuck in the installer: >>>> >>>> % ps -axwww 25310 >>>> PID TT STAT TIME COMMAND >>>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>>> luthien/current -o >>>> >>>> Jay, did you change any config files recently? >>>> Regression tests seemed to have been running again for some >>>> days, >>>> and then >>>> stopped again. >>>> >>>> I'll try to investigate further this evening, but must leave >>>> now for >>>> other work... >>>> >>>> Olaf >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>> Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>> 23 >>>> 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>> Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Wed Apr 29 20:04:22 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 30 Apr 2009 04:04:22 +1000 Subject: [M3devel] user threads In-Reply-To: <200904290653.n3T6rW8b004699@camembert.async.caltech.edu> References: <200904290653.n3T6rW8b004699@camembert.async.caltech.edu> Message-ID: <736196D3-6AA1-49C4-80E8-4EEB05B38CFC@cs.purdue.edu> Mika, it is not surprising that your lock-on-every variable update will cost a lot in any non-user-level threading scheme. You should consider using different mechanisms for this degree of locking in Scheme (based on some of the non-blocking lock implementations for Java perhaps). I don't expect any implementation of locking for a multi-core/-processor will ever perform as well as user-level threads. On 29 Apr 2009, at 16:53, Mika Nystrom wrote: > Ok, it works! > > Numbers: > > Timings in milliseconds, three samples, filesystem "warmed up" by > doing one dummy run before launching the real ones. > > -unsafe means that I use non-locking Scheme environments, otherwise > they lock for every variable update. > ave > CM3 last week, kernel threads, -unsafe 1460 1482 1437 1460 > CM3 last week, kernel threads, 2392 2402 2376 2390 > CM3 this week, kernel threads, -unsafe 1455 1458 1490 1468 (*) > CM3 this week, user threads, -unsafe 914 934 914 921 > CM3 this week, user threads, 967 965 986 973 > PM3 -unsafe 678 657 682 672 > PM3 709 714 700 708 > > (*) not entirely sure this got linked correctly. > > Mika > > > Jay writes: >> >> User threads seem to work on on FreeBSD/x86 7.0. >> Mika can you report back the perf cm3 vs. pm3? >> Still, kernel threads have been around a long time and imho should >> be strongly favored.. >> >> >> Kernel threads should be a /little/ faster than they were -- >> PushEFrame removed from successful heap allocations. And should be >> further improvable via __thread where it is supported -- probably >> not FreeBSD 4. >> x, sometimes older is not better. :) >> >> >> I've temporarily switched FreeBSD/x86 to userthreads by default but >> I think that's just an experiment and should be undone shortly, >> maybe work out some other story for easily switching between them, >> or just k >> eep the existing story of "you get to rebuild everything". >> >> >> Tony, can you look into GetGCRatio? I removed the call to it. The >> "fatal" pragma invokes PushEFrame apparently. >> >> >> We should now "fix" Win32 and pthreads to not have GetActivation >> initialize on-demand, just leave Init to initialize always. This >> should shave a few more cycles from PushEFrame. >> >> >> - Jay From hosking at cs.purdue.edu Wed Apr 29 20:05:22 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 30 Apr 2009 04:05:22 +1000 Subject: [M3devel] user threads In-Reply-To: References: Your message of "Tue, 28 Apr 2009 16:54:03 -0000." <200904290653.n3T6rW8b004699@camembert.async.caltech.edu> Message-ID: <92CEDBEA-5C93-402F-A3C0-6AEAFAB4665B@cs.purdue.edu> Jay, I think you are trying to optimize the unoptimizable if I understand that Mika uses locking as heavily as he seems to. On 29 Apr 2009, at 17:05, Jay wrote: > Mika, thanks. Want to try the next variation? look at m3-libs/m3core/ > src/thread/PTHREAD/ThreadPThreadC.c. > See THREAD_LOCAL, THREAD_LOCAL_SLOW, THREAD_LOCAL_FAST? Try > switching THREAD_LOCAL to use THREAD_LOCAL_FAST instead of _SLOW. On > FreeBSD 5.x or newer. > It won't compile for 4.x we know. > > Thanks, > - Jay > > > > To: jay.krell at cornell.edu > > Date: Tue, 28 Apr 2009 23:53:32 -0700 > > From: mika at async.caltech.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] user threads > > > > Ok, it works! > > > > Numbers: > > > > Timings in milliseconds, three samples, filesystem "warmed up" by > > doing one dummy run before launching the real ones. > > > > -unsafe means that I use non-locking Scheme environments, otherwise > > they lock for every variable update. > > ave > > CM3 last week, kernel threads, -unsafe 1460 1482 1437 1460 > > CM3 last week, kernel threads, 2392 2402 2376 2390 > > CM3 this week, kernel threads, -unsafe 1455 1458 1490 1468 (*) > > CM3 this week, user threads, -unsafe 914 934 914 921 > > CM3 this week, user threads, 967 965 986 973 > > PM3 -unsafe 678 657 682 672 > > PM3 709 714 700 708 > > > > (*) not entirely sure this got linked correctly. > > > > Mika > > > > > > Jay writes: > > > > > >User threads seem to work on on FreeBSD/x86 7.0. > > >Mika can you report back the perf cm3 vs. pm3? > > >Still, kernel threads have been around a long time and imho > should be strongly favored.. > > > > > > > > >Kernel threads should be a /little/ faster than they were -- > PushEFrame removed from successful heap allocations. And should be > further improvable via __thread where it is supported -- probably > not FreeBSD 4. > > >x, sometimes older is not better. :) > > > > > > > > >I've temporarily switched FreeBSD/x86 to userthreads by default > but I think that's just an experiment and should be undone shortly, > maybe work out some other story for easily switching between them, > or just k > > >eep the existing story of "you get to rebuild everything". > > > > > > > > >Tony, can you look into GetGCRatio? I removed the call to it. The > "fatal" pragma invokes PushEFrame apparently. > > > > > > > > >We should now "fix" Win32 and pthreads to not have GetActivation > initialize on-demand, just leave Init to initialize always. This > should shave a few more cycles from PushEFrame. > > > > > > > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Apr 29 20:12:12 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 30 Apr 2009 04:12:12 +1000 Subject: [M3devel] Fwd: Output from "cron" command References: <200904291321.n3TDLGNt022671@niagara.cs.purdue.edu> Message-ID: Now I am getting compile errors. Recent checkins are culpable. Begin forwarded message: > From: Tony Hosking > Date: 29 April 2009 23:21:16 GMT+10:00 > To: hosking at cs.purdue.edu > Subject: Output from "cron" command > > Your "cron" job on niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/cron.sh > > produced the following output: > > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-10-30-05 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSUSER= > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara release-build" > > creating log file /tmp/build-cm3-20090429-063007-_Laq8F/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.04.29 06:30:07 -- checkout in progress. > [start checkout 2009.04.29 06:30:09] > cd /tmp/build-cm3-20090429-063007-_Laq8F/build > cvs return value: 0 > [end checkout 2009.04.29 06:49:37] > CHECKOUT_RETURN = 0 > -- > 2009.04.29 06:49:41 -- compile in progress. > [start compile 2009.04.29 06:49:41] > compile return value: 0 > [end compile 2009.04.29 08:10:32] > COMPILE_RETURN = 1 > *** COMPILE FAILED > removing build tree /tmp/build-cm3-20090429-063007-_Laq8F ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-12-12-22 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSUSER= > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" > > creating log file /tmp/build-cm3-20090429-081224-i9aWYM/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.04.29 08:12:24 -- checkout in progress. > [start checkout 2009.04.29 08:12:26] > cd /tmp/build-cm3-20090429-081224-i9aWYM/build > cvs return value: 0 > [end checkout 2009.04.29 08:32:34] > CHECKOUT_RETURN = 0 > -- > 2009.04.29 08:32:38 -- compile in progress. > [start compile 2009.04.29 08:32:38] > compile return value: 0 > [end compile 2009.04.29 09:19:20] > COMPILE_RETURN = 0 > 2009.04.29 09:19:24 -- tests in progress. > [start run-tests 2009.04.29 09:19:24] > cd /tmp/build-cm3-20090429-081224-i9aWYM/build > [end run-tests 2009.04.29 09:19:24] > TESTS_RETURN = 0 > 2009.04.29 09:19:24 -- checkout, compile and test run done. > > --- > > removing build tree /tmp/build-cm3-20090429-081224-i9aWYM ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > done. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Apr 29 20:32:25 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 29 Apr 2009 11:32:25 -0700 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: Your message of "Thu, 30 Apr 2009 04:12:12 +1000." Message-ID: <200904291832.n3TIWPNo038139@camembert.async.caltech.edu> I found I had made a typo in my m3tk check-in. Is there an easy way to see what the error is? Mika Tony Hosking writes: > >--Apple-Mail-6-728527402 >Content-Type: text/plain; > charset=US-ASCII; > format=flowed >Content-Transfer-Encoding: 7bit > >Now I am getting compile errors. Recent checkins are culpable. > >Begin forwarded message: > >> From: Tony Hosking >> Date: 29 April 2009 23:21:16 GMT+10:00 >> To: hosking at cs.purdue.edu >> Subject: Output from "cron" command >> >> Your "cron" job on niagara.cs.purdue.edu >> $HOME/cm3/scripts/regression/cron.sh >> >> produced the following output: >> >> TESTHOSTNAME=niagara >> WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-10-30-05 >> LASTREL=5.4.0 >> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >> CM3_OSTYPE=POSIX >> CM3_TARGET=SOLgnu >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> CM3CVSSERVER=birch.elegosoft.com >> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> CM3CVSUSER= >> testing ssh birch.elegosoft.com.. >> ssh birch.elegosoft.com ok >> Building cm3. >> Tinderbox Tree: "cm3" >> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >> >> creating log file /tmp/build-cm3-20090429-063007-_Laq8F/log.txt >> >> --- >> >> checkout, compile and test of cm3 ... >> 2009.04.29 06:30:07 -- checkout in progress. >> [start checkout 2009.04.29 06:30:09] >> cd /tmp/build-cm3-20090429-063007-_Laq8F/build >> cvs return value: 0 >> [end checkout 2009.04.29 06:49:37] >> CHECKOUT_RETURN = 0 >> -- >> 2009.04.29 06:49:41 -- compile in progress. >> [start compile 2009.04.29 06:49:41] >> compile return value: 0 >> [end compile 2009.04.29 08:10:32] >> COMPILE_RETURN = 1 >> *** COMPILE FAILED >> removing build tree /tmp/build-cm3-20090429-063007-_Laq8F ... >> cleaning CM3 workspaces... >> /homes/hosking/work/cm3-ws/niagara-* >> >> cleaning regression test log files... >> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >> >> cleaning m3test log files... >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >> >> cleaning snapshot files... >> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >> >> cleaning package reports... >> /tmp/cm3-pkg-report-SOLgnu-*.html >> >> TESTHOSTNAME=niagara >> WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-12-12-22 >> LASTREL=5.4.0 >> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >> CM3_OSTYPE=POSIX >> CM3_TARGET=SOLgnu >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> CM3CVSSERVER=birch.elegosoft.com >> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> CM3CVSUSER= >> testing ssh birch.elegosoft.com.. >> ssh birch.elegosoft.com ok >> Building cm3. >> Tinderbox Tree: "cm3" >> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >> >> creating log file /tmp/build-cm3-20090429-081224-i9aWYM/log.txt >> >> --- >> >> checkout, compile and test of cm3 ... >> 2009.04.29 08:12:24 -- checkout in progress. >> [start checkout 2009.04.29 08:12:26] >> cd /tmp/build-cm3-20090429-081224-i9aWYM/build >> cvs return value: 0 >> [end checkout 2009.04.29 08:32:34] >> CHECKOUT_RETURN = 0 >> -- >> 2009.04.29 08:32:38 -- compile in progress. >> [start compile 2009.04.29 08:32:38] >> compile return value: 0 >> [end compile 2009.04.29 09:19:20] >> COMPILE_RETURN = 0 >> 2009.04.29 09:19:24 -- tests in progress. >> [start run-tests 2009.04.29 09:19:24] >> cd /tmp/build-cm3-20090429-081224-i9aWYM/build >> [end run-tests 2009.04.29 09:19:24] >> TESTS_RETURN = 0 >> 2009.04.29 09:19:24 -- checkout, compile and test run done. >> >> --- >> >> removing build tree /tmp/build-cm3-20090429-081224-i9aWYM ... >> cleaning CM3 workspaces... >> /homes/hosking/work/cm3-ws/niagara-* >> >> cleaning regression test log files... >> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >> >> cleaning m3test log files... >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >> >> cleaning snapshot files... >> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >> >> cleaning package reports... >> /tmp/cm3-pkg-report-SOLgnu-*.html >> >> done. > > >--Apple-Mail-6-728527402 >Content-Type: text/html; > charset=US-ASCII >Content-Transfer-Encoding: quoted-printable > >-webkit-line-break: after-white-space; ">
apple-content-edited=3D"true">style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >normal; font-variant: normal; font-weight: normal; letter-spacing: = >normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; = >-khtml-line-break: after-white-space; ">style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >normal; font-variant: normal; font-weight: normal; letter-spacing: = >normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">class=3D"Apple-style-span" style=3D"border-collapse: separate; = >border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; = >font-size: 12px; font-style: normal; font-variant: normal; font-weight: = >normal; letter-spacing: normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">class=3D"Apple-style-span" style=3D"border-collapse: separate; = >border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; = >font-size: 12px; font-style: normal; font-variant: normal; font-weight: = >normal; letter-spacing: normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">class=3D"Apple-style-span" style=3D"border-collapse: separate; = >border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; = >font-size: 12px; font-style: normal; font-variant: normal; font-weight: = >normal; letter-spacing: normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">class=3D"Apple-style-span" style=3D"border-collapse: separate; = >border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; = >font-size: 12px; font-style: normal; font-variant: normal; font-weight: = >normal; letter-spacing: normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">class=3D"Apple-style-span" style=3D"border-collapse: separate; = >border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; = >font-size: 12px; font-style: normal; font-variant: normal; font-weight: = >normal; letter-spacing: normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">class=3D"Apple-style-span" style=3D"border-collapse: separate; = >border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; = >font-size: 12px; font-style: normal; font-variant: normal; font-weight: = >normal; letter-spacing: normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">class=3D"Apple-style-span" style=3D"border-collapse: separate; = >border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; = >font-size: 12px; font-style: normal; font-variant: normal; font-weight: = >normal; letter-spacing: normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">
Now I am = >getting compile errors.  Recent checkins are = >culpable.
iv>

Begin forwarded message:

class=3D"Apple-interchange-newline">
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >margin-left: 0px; ">style=3D"font: 12.0px Helvetica; color: #000000">From: = >Helvetica">Tony Hosking <href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu>iv>
margin-left: 0px; ">style=3D"font: 12.0px Helvetica; color: #000000">Date: = >Helvetica">29 April 2009 23:21:16 GMT+10:00
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >margin-left: 0px; ">style=3D"font: 12.0px Helvetica; color: #000000">To: face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.eduv>
margin-left: 0px; ">style=3D"font: 12.0px Helvetica; color: #000000">Subject: = >Helvetica">Output from "cron" command
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >margin-left: 0px; min-height: 14px; ">
Your "cron" = >job on = >niagara.cs.purdue.edu
$HOME/cm3/scripts/regression/cron.sh

produ= >ced the following = >output:

TESTHOSTNAME=3Dniagara
WS=3D/homes/hosking/work/cm3-ws/n= >iagara-2009-04-29-10-30-05
LASTREL=3D5.4.0
INSTROOT_REL=3D/homes/hos= >king/work/cm3-inst/niagara/rel-5.4.0
INSTROOT_POK=3D/homes/hosking/work= >/cm3-inst/niagara/prev-ok
INSTROOT_LOK=3D/homes/hosking/work/cm3-inst/n= >iagara/last-ok
INSTROOT_CUR=3D/homes/hosking/work/cm3-inst/niagara/curr= >ent
CM3_OSTYPE=3DPOSIX
CM3_TARGET=3DSOLgnu
BINDISTMIN=3D/homes/ho= >sking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
CM3CVSSERVER=3Dbirch.elegosof= >t.com
CM3CVSROOT=3Dbirch.elegosoft.com:/usr/cvs
BINDISTMIN_NAME=3Dcm= >3-min-POSIX-SOLgnu-5.4.0.tgz
BINDISTMIN=3D/homes/hosking/work/cm3-min-P= >OSIX-SOLgnu-5.4.0.tgz
CM3CVSUSER=3D
testing ssh = >birch.elegosoft.com..
ssh birch.elegosoft.com ok
Building = >cm3.
Tinderbox Tree:   "cm3"
Buildname: = >       "SOLgnu SunOS 5.10 niagara = >release-build"

creating log file = >/tmp/build-cm3-20090429-063007-_Laq8F/log.txt

---

checkout, = >compile and test of cm3 ...
2009.04.29 06:30:07 -- checkout in = >progress.
[start checkout 2009.04.29 06:30:09]
cd = >/tmp/build-cm3-20090429-063007-_Laq8F/build
cvs return value: = >0
[end checkout 2009.04.29 06:49:37]
CHECKOUT_RETURN =3D = 0
--
2009.04.29 06:49:41 -- compile in progress.
[start compile = >2009.04.29 06:49:41]
compile return value: 0
[end compile = >2009.04.29 08:10:32]
COMPILE_RETURN =3D 1
*** COMPILE = >FAILED
removing build tree /tmp/build-cm3-20090429-063007-_Laq8F = >...
cleaning CM3 = >workspaces...
/homes/hosking/work/cm3-ws/niagara-*

cleaning = >regression test log = >files...
/homes/hosking/tmp/cm3/niagara/cm3-rlog-*

cleaning = >m3test log = >files...
/homes/hosking/tmp/cm3/niagara/m3tests-*.stdout

/homes/= >hosking/tmp/cm3/niagara/m3tests-*.stderr

/homes/hosking/tmp/cm3/nia= >gara/m3tests-*.stderr.extract

cleaning snapshot = >files...
/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz>
cleaning package = >reports...
/tmp/cm3-pkg-report-SOLgnu-*.html

TESTHOSTNAME=3Dniag= >ara
WS=3D/homes/hosking/work/cm3-ws/niagara-2009-04-29-12-12-22
LAST= >REL=3D5.4.0
INSTROOT_REL=3D/homes/hosking/work/cm3-inst/niagara/rel-5.4= >.0
INSTROOT_POK=3D/homes/hosking/work/cm3-inst/niagara/prev-ok
INSTR= >OOT_LOK=3D/homes/hosking/work/cm3-inst/niagara/last-ok
INSTROOT_CUR=3D/= >homes/hosking/work/cm3-inst/niagara/current
CM3_OSTYPE=3DPOSIX
CM3_T= >ARGET=3DSOLgnu
BINDISTMIN=3D/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.= >4.0.tgz
CM3CVSSERVER=3Dbirch.elegosoft.com
CM3CVSROOT=3Dbirch.elegos= >oft.com:/usr/cvs
BINDISTMIN_NAME=3Dcm3-min-POSIX-SOLgnu-5.4.0.tgz
BI= >NDISTMIN=3D/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
CM3CVSUSE= >R=3D
testing ssh birch.elegosoft.com..
ssh birch.elegosoft.com = >ok
Building cm3.
Tinderbox Tree:   "cm3"
Buildname: = >       "SOLgnu SunOS 5.10 niagara = >lastok-build"

creating log file = >/tmp/build-cm3-20090429-081224-i9aWYM/log.txt

---

checkout, = >compile and test of cm3 ...
2009.04.29 08:12:24 -- checkout in = >progress.
[start checkout 2009.04.29 08:12:26]
cd = >/tmp/build-cm3-20090429-081224-i9aWYM/build
cvs return value: = >0
[end checkout 2009.04.29 08:32:34]
CHECKOUT_RETURN =3D = >0
--
2009.04.29 08:32:38 -- compile in progress.
[start compile = >2009.04.29 08:32:38]
compile return value: 0
[end compile = >2009.04.29 09:19:20]
COMPILE_RETURN =3D 0
2009.04.29 09:19:24 -- = >tests in progress.
[start run-tests 2009.04.29 09:19:24]
cd = >/tmp/build-cm3-20090429-081224-i9aWYM/build
[end run-tests 2009.04.29 = >09:19:24]
TESTS_RETURN =3D 0
2009.04.29 09:19:24 -- checkout, = compile and test run done.

---

removing build tree = >/tmp/build-cm3-20090429-081224-i9aWYM ...
cleaning CM3 = >workspaces...
/homes/hosking/work/cm3-ws/niagara-*

cleaning = >regression test log = >files...
/homes/hosking/tmp/cm3/niagara/cm3-rlog-*

cleaning = >m3test log = >files...
/homes/hosking/tmp/cm3/niagara/m3tests-*.stdout

/homes/= >hosking/tmp/cm3/niagara/m3tests-*.stderr

/homes/hosking/tmp/cm3/nia= >gara/m3tests-*.stderr.extract

cleaning snapshot = >files...
/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz>
cleaning package = >reports...
/tmp/cm3-pkg-report-SOLgnu-*.html

done.
ockquote>

= > >--Apple-Mail-6-728527402-- From hosking at cs.purdue.edu Wed Apr 29 20:33:01 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 30 Apr 2009 04:33:01 +1000 Subject: [M3devel] [M3commit] how to switch userthreads on/off In-Reply-To: <200904290622.n3T6MZBR003219@camembert.async.caltech.edu> References: <200904290622.n3T6MZBR003219@camembert.async.caltech.edu> Message-ID: <69291A6D-E915-41C9-B4FB-AB7F5CF398EE@cs.purdue.edu> Mika, With the current implementation of M3 MUTEX 1-1 as pthread mutex you are bound to have significant overhead for any locking code even in single-threaded apps. We need to move towards a thin-lock implementation for mutex (as used in modern Java implementations) to avoid overhead for uncontended locks. It's not too hard to implement. The idea is to represent a mutex as a tagged word. The word contains either NIL, the thread holding the lock, or a pointer to a full-blown (inflated) pthread mutex. We can use GC and other opportunities to deflate locks as needs. Checking the tag requires a CAS. There are other techniques that further eliminate the CAS for the uncontended case. But, generally, you should consider LOCK to be a fairly high-overhead operation for now. 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 29 Apr 2009, at 16:22, Mika Nystrom wrote: > Jay writes: > ... >> >> Maybe just leave it as an option in m3core's m3makefile and people >> can twiddle it if they want and rebuild the entire system like it >> is today? >> That is a bit onerous, but maybe it's all userthreads deserve? >> ? >> >> >> Anyone who actually wanted to switch back and forth (Mika) would >> just have two installs and two source trees? >> >> >> - Jay > > I just want to clarify. I'm not really that interested in switching > back and forth. I'm just a little disturbed by the sometimes huge > performance loss due to the introduction of kernel threads. I knew > that this would happen in certain highly multithreaded applications, > but I'm surprised it happens in a more or less single-threaded > application. > > I think I've just been spoiled by 10 years of using SRCM3 and PM3 > for FreeBSD w/o kernel threads in the sense that I've learned that > using LOCK has essentially no cost. On a shared-memory > multiprocessor, > I really don't expect that to remain the case... physics won't allow > it. So now I just have to go through my code and find all the places > where I lock too much and remove them. > > But the memory allocator and garbage collector do it too, no? > > I also think that this idea of being able to use either is great. > Mainly single-threaded programs should definitely not use kernel > threads! > > As for reaching the "thread locals", there is one slightly crazy > idea that one could borrow from Sussman and Steele: add another > implicit argument to every Modula-3 routine. In that argument, > pass a pointer to the thread locals. For EXTERNAL calls (in or > out), make it NIL (somehow, maybe involving pragmas), and in that > case (only), use the pthreads routines to access the thread locals. > Ok so it sounds kind of nuts, but with this approach you could avoid > locking or even calling into the pthreads libs almost entirely for > a single-threaded program. You could even have a thread-local > memory allocator that would only lock when it needs to request > memory from the "global allocator"... in fact there are lots of > things you can do with this sort of thing. Dynamically scoped > variables in Scheme (a la MacLisp?) is what they originally proposed > it for but then they suggested all kinds of tricks related to > continuations with it. > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Apr 29 20:34:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 30 Apr 2009 04:34:07 +1000 Subject: [M3devel] [M3commit] how to switch userthreads on/off In-Reply-To: <200904290622.n3T6MZBR003219@camembert.async.caltech.edu> References: <200904290622.n3T6MZBR003219@camembert.async.caltech.edu> Message-ID: <6F6E80BC-1DF9-4121-834B-370567EA21D5@cs.purdue.edu> There is no lock in the fast path for traced allocation. GC has some locking that I am working on improving/eliminating. Watch this space. On 29 Apr 2009, at 16:22, Mika Nystrom wrote: > Jay writes: > ... >> >> Maybe just leave it as an option in m3core's m3makefile and people >> can twiddle it if they want and rebuild the entire system like it >> is today? >> That is a bit onerous, but maybe it's all userthreads deserve? >> ? >> >> >> Anyone who actually wanted to switch back and forth (Mika) would >> just have two installs and two source trees? >> >> >> - Jay > > I just want to clarify. I'm not really that interested in switching > back and forth. I'm just a little disturbed by the sometimes huge > performance loss due to the introduction of kernel threads. I knew > that this would happen in certain highly multithreaded applications, > but I'm surprised it happens in a more or less single-threaded > application. > > I think I've just been spoiled by 10 years of using SRCM3 and PM3 > for FreeBSD w/o kernel threads in the sense that I've learned that > using LOCK has essentially no cost. On a shared-memory > multiprocessor, > I really don't expect that to remain the case... physics won't allow > it. So now I just have to go through my code and find all the places > where I lock too much and remove them. > > But the memory allocator and garbage collector do it too, no? > > I also think that this idea of being able to use either is great. > Mainly single-threaded programs should definitely not use kernel > threads! > > As for reaching the "thread locals", there is one slightly crazy > idea that one could borrow from Sussman and Steele: add another > implicit argument to every Modula-3 routine. In that argument, > pass a pointer to the thread locals. For EXTERNAL calls (in or > out), make it NIL (somehow, maybe involving pragmas), and in that > case (only), use the pthreads routines to access the thread locals. > Ok so it sounds kind of nuts, but with this approach you could avoid > locking or even calling into the pthreads libs almost entirely for > a single-threaded program. You could even have a thread-local > memory allocator that would only lock when it needs to request > memory from the "global allocator"... in fact there are lots of > things you can do with this sort of thing. Dynamically scoped > variables in Scheme (a la MacLisp?) is what they originally proposed > it for but then they suggested all kinds of tricks related to > continuations with it. > > Mika From hosking at cs.purdue.edu Wed Apr 29 20:35:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 30 Apr 2009 04:35:07 +1000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <200904291832.n3TIWPNo038139@camembert.async.caltech.edu> References: <200904291832.n3TIWPNo038139@camembert.async.caltech.edu> Message-ID: Tinderbox... On 30 Apr 2009, at 04:32, Mika Nystrom wrote: > > I found I had made a typo in my m3tk check-in. Is there an easy > way to see what the error is? > > Mika > > Tony Hosking writes: >> >> --Apple-Mail-6-728527402 >> Content-Type: text/plain; >> charset=US-ASCII; >> format=flowed >> Content-Transfer-Encoding: 7bit >> >> Now I am getting compile errors. Recent checkins are culpable. >> >> Begin forwarded message: >> >>> From: Tony Hosking >>> Date: 29 April 2009 23:21:16 GMT+10:00 >>> To: hosking at cs.purdue.edu >>> Subject: Output from "cron" command >>> >>> Your "cron" job on niagara.cs.purdue.edu >>> $HOME/cm3/scripts/regression/cron.sh >>> >>> produced the following output: >>> >>> TESTHOSTNAME=niagara >>> WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-10-30-05 >>> LASTREL=5.4.0 >>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>> CM3_OSTYPE=POSIX >>> CM3_TARGET=SOLgnu >>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> CM3CVSSERVER=birch.elegosoft.com >>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> CM3CVSUSER= >>> testing ssh birch.elegosoft.com.. >>> ssh birch.elegosoft.com ok >>> Building cm3. >>> Tinderbox Tree: "cm3" >>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>> >>> creating log file /tmp/build-cm3-20090429-063007-_Laq8F/log.txt >>> >>> --- >>> >>> checkout, compile and test of cm3 ... >>> 2009.04.29 06:30:07 -- checkout in progress. >>> [start checkout 2009.04.29 06:30:09] >>> cd /tmp/build-cm3-20090429-063007-_Laq8F/build >>> cvs return value: 0 >>> [end checkout 2009.04.29 06:49:37] >>> CHECKOUT_RETURN = 0 >>> -- >>> 2009.04.29 06:49:41 -- compile in progress. >>> [start compile 2009.04.29 06:49:41] >>> compile return value: 0 >>> [end compile 2009.04.29 08:10:32] >>> COMPILE_RETURN = 1 >>> *** COMPILE FAILED >>> removing build tree /tmp/build-cm3-20090429-063007-_Laq8F ... >>> cleaning CM3 workspaces... >>> /homes/hosking/work/cm3-ws/niagara-* >>> >>> cleaning regression test log files... >>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>> >>> cleaning m3test log files... >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>> >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>> >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>> >>> cleaning snapshot files... >>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>> >>> cleaning package reports... >>> /tmp/cm3-pkg-report-SOLgnu-*.html >>> >>> TESTHOSTNAME=niagara >>> WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-12-12-22 >>> LASTREL=5.4.0 >>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>> CM3_OSTYPE=POSIX >>> CM3_TARGET=SOLgnu >>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> CM3CVSSERVER=birch.elegosoft.com >>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> CM3CVSUSER= >>> testing ssh birch.elegosoft.com.. >>> ssh birch.elegosoft.com ok >>> Building cm3. >>> Tinderbox Tree: "cm3" >>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>> >>> creating log file /tmp/build-cm3-20090429-081224-i9aWYM/log.txt >>> >>> --- >>> >>> checkout, compile and test of cm3 ... >>> 2009.04.29 08:12:24 -- checkout in progress. >>> [start checkout 2009.04.29 08:12:26] >>> cd /tmp/build-cm3-20090429-081224-i9aWYM/build >>> cvs return value: 0 >>> [end checkout 2009.04.29 08:32:34] >>> CHECKOUT_RETURN = 0 >>> -- >>> 2009.04.29 08:32:38 -- compile in progress. >>> [start compile 2009.04.29 08:32:38] >>> compile return value: 0 >>> [end compile 2009.04.29 09:19:20] >>> COMPILE_RETURN = 0 >>> 2009.04.29 09:19:24 -- tests in progress. >>> [start run-tests 2009.04.29 09:19:24] >>> cd /tmp/build-cm3-20090429-081224-i9aWYM/build >>> [end run-tests 2009.04.29 09:19:24] >>> TESTS_RETURN = 0 >>> 2009.04.29 09:19:24 -- checkout, compile and test run done. >>> >>> --- >>> >>> removing build tree /tmp/build-cm3-20090429-081224-i9aWYM ... >>> cleaning CM3 workspaces... >>> /homes/hosking/work/cm3-ws/niagara-* >>> >>> cleaning regression test log files... >>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>> >>> cleaning m3test log files... >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>> >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>> >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>> >>> cleaning snapshot files... >>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>> >>> cleaning package reports... >>> /tmp/cm3-pkg-report-SOLgnu-*.html >>> >>> done. >> >> >> --Apple-Mail-6-728527402 >> Content-Type: text/html; >> charset=US-ASCII >> Content-Transfer-Encoding: quoted-printable >> >> > space; = >> -webkit-line-break: after-white-space; ">
> apple-content-edited=3D"true">> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >> normal; font-variant: normal; font-weight: normal; letter-spacing: = >> normal; line-height: normal; text-align: auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">
> style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; = >> -khtml-line-break: after-white-space; ">> span" = >> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >> normal; font-variant: normal; font-weight: normal; letter-spacing: = >> normal; line-height: normal; text-align: auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >> Helvetica; = >> font-size: 12px; font-style: normal; font-variant: normal; font- >> weight: = >> normal; letter-spacing: normal; line-height: normal; text-align: >> auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >> Helvetica; = >> font-size: 12px; font-style: normal; font-variant: normal; font- >> weight: = >> normal; letter-spacing: normal; line-height: normal; text-align: >> auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >> Helvetica; = >> font-size: 12px; font-style: normal; font-variant: normal; font- >> weight: = >> normal; letter-spacing: normal; line-height: normal; text-align: >> auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >> Helvetica; = >> font-size: 12px; font-style: normal; font-variant: normal; font- >> weight: = >> normal; letter-spacing: normal; line-height: normal; text-align: >> auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >> Helvetica; = >> font-size: 12px; font-style: normal; font-variant: normal; font- >> weight: = >> normal; letter-spacing: normal; line-height: normal; text-align: >> auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >> Helvetica; = >> font-size: 12px; font-style: normal; font-variant: normal; font- >> weight: = >> normal; letter-spacing: normal; line-height: normal; text-align: >> auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >> Helvetica; = >> font-size: 12px; font-style: normal; font-variant: normal; font- >> weight: = >> normal; letter-spacing: normal; line-height: normal; text-align: >> auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">
Now I am = >> getting compile errors.  Recent checkins are = >> culpable.
> span>> iv>

Begin forwarded message:

> class=3D"Apple-interchange-newline">
> type=3D"cite">
> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >> margin-left: 0px; ">> color=3D"#000000" = >> style=3D"font: 12.0px Helvetica; color: #000000">From: = >> > 12.0px = >> Helvetica">Tony Hosking <> href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu>> font>> iv>
> 0px; = >> margin-left: 0px; ">> color=3D"#000000" = >> style=3D"font: 12.0px Helvetica; color: #000000">Date: = >> > 12.0px = >> Helvetica">29 April 2009 23:21:16 GMT+10:00
> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >> margin-left: 0px; ">> color=3D"#000000" = >> style=3D"font: 12.0px Helvetica; color: #000000">To: > font>> face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">> href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu> font>> v>
> 0px; = >> margin-left: 0px; ">> color=3D"#000000" = >> style=3D"font: 12.0px Helvetica; color: #000000">Subject: = >> > 12.0px = >> Helvetica">Output from "cron" command
> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >> margin-left: 0px; min-height: 14px; ">
Your >> "cron" = >> job on = >> niagara.cs.purdue.edu
$HOME/cm3/scripts/regression/ >> cron.sh

produ= >> ced the following = >> output:

TESTHOSTNAME=3Dniagara
WS=3D/homes/hosking/work/ >> cm3-ws/n= >> iagara-2009-04-29-10-30-05
LASTREL=3D5.4.0
INSTROOT_REL=3D/ >> homes/hos= >> king/work/cm3-inst/niagara/rel-5.4.0
INSTROOT_POK=3D/homes/ >> hosking/work= >> /cm3-inst/niagara/prev-ok
INSTROOT_LOK=3D/homes/hosking/work/cm3- >> inst/n= >> iagara/last-ok
INSTROOT_CUR=3D/homes/hosking/work/cm3-inst/ >> niagara/curr= >> ent
CM3_OSTYPE=3DPOSIX
CM3_TARGET=3DSOLgnu
BINDISTMIN=3D/ >> homes/ho= >> sking/work/cm3-min-POSIX- >> SOLgnu-5.4.0.tgz
CM3CVSSERVER=3Dbirch.elegosof= >> t.com
CM3CVSROOT=3Dbirch.elegosoft.com:/usr/ >> cvs
BINDISTMIN_NAME=3Dcm= >> 3-min-POSIX-SOLgnu-5.4.0.tgz
BINDISTMIN=3D/homes/hosking/work/ >> cm3-min-P= >> OSIX-SOLgnu-5.4.0.tgz
CM3CVSUSER=3D
testing ssh = >> birch.elegosoft.com..
ssh birch.elegosoft.com ok
Building = >> cm3.
Tinderbox Tree:   "cm3"
Buildname: = >>        "SOLgnu SunOS 5.10 >> niagara = >> release-build"

creating log file = >> /tmp/build-cm3-20090429-063007-_Laq8F/log.txt

--- >>

checkout, = >> compile and test of cm3 ...
2009.04.29 06:30:07 -- checkout in = >> progress.
[start checkout 2009.04.29 06:30:09]
cd = >> /tmp/build-cm3-20090429-063007-_Laq8F/build
cvs return value: = >> 0
[end checkout 2009.04.29 06:49:37]
CHECKOUT_RETURN =3D = > 0
--
2009.04.29 06:49:41 -- compile in progress.
[start > compile = >> 2009.04.29 06:49:41]
compile return value: 0
[end compile = >> 2009.04.29 08:10:32]
COMPILE_RETURN =3D 1
*** COMPILE = >> FAILED
removing build tree /tmp/build-cm3-20090429-063007-_Laq8F = >> ...
cleaning CM3 = >> workspaces...
/homes/hosking/work/cm3-ws/niagara- >> *

cleaning = >> regression test log = >> files...
/homes/hosking/tmp/cm3/niagara/cm3-rlog- >> *

cleaning = >> m3test log = >> files...
/homes/hosking/tmp/cm3/niagara/m3tests-*.stdout

/ >> homes/= >> hosking/tmp/cm3/niagara/m3tests-*.stderr

/homes/hosking/tmp/ >> cm3/nia= >> gara/m3tests-*.stderr.extract

cleaning snapshot = >> files...
/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >> *.tgz>>
cleaning package = >> reports...
/tmp/cm3-pkg-report-SOLgnu- >> *.html

TESTHOSTNAME=3Dniag= >> ara
WS=3D/homes/hosking/work/cm3-ws/ >> niagara-2009-04-29-12-12-22
LAST= >> REL=3D5.4.0
INSTROOT_REL=3D/homes/hosking/work/cm3-inst/niagara/ >> rel-5.4= >> .0
INSTROOT_POK=3D/homes/hosking/work/cm3-inst/niagara/prev- >> ok
INSTR= >> OOT_LOK=3D/homes/hosking/work/cm3-inst/niagara/last- >> ok
INSTROOT_CUR=3D/= >> homes/hosking/work/cm3-inst/niagara/ >> current
CM3_OSTYPE=3DPOSIX
CM3_T= >> ARGET=3DSOLgnu
BINDISTMIN=3D/homes/hosking/work/cm3-min-POSIX- >> SOLgnu-5.= >> 4.0 >> .tgz >>
CM3CVSSERVER=3Dbirch.elegosoft.com
CM3CVSROOT=3Dbirch.elegos= >> oft.com:/usr/cvs
BINDISTMIN_NAME=3Dcm3-min-POSIX- >> SOLgnu-5.4.0.tgz
BI= >> NDISTMIN=3D/homes/hosking/work/cm3-min-POSIX- >> SOLgnu-5.4.0.tgz
CM3CVSUSE= >> R=3D
testing ssh birch.elegosoft.com..
ssh >> birch.elegosoft.com = >> ok
Building cm3.
Tinderbox Tree: >>   "cm3"
Buildname: = >>        "SOLgnu SunOS 5.10 >> niagara = >> lastok-build"

creating log file = >> /tmp/build-cm3-20090429-081224-i9aWYM/log.txt

--- >>

checkout, = >> compile and test of cm3 ...
2009.04.29 08:12:24 -- checkout in = >> progress.
[start checkout 2009.04.29 08:12:26]
cd = >> /tmp/build-cm3-20090429-081224-i9aWYM/build
cvs return value: = >> 0
[end checkout 2009.04.29 08:32:34]
CHECKOUT_RETURN =3D = >> 0
--
2009.04.29 08:32:38 -- compile in progress.
[start >> compile = >> 2009.04.29 08:32:38]
compile return value: 0
[end compile = >> 2009.04.29 09:19:20]
COMPILE_RETURN =3D 0
2009.04.29 09:19:24 >> -- = >> tests in progress.
[start run-tests 2009.04.29 09:19:24]
cd = >> /tmp/build-cm3-20090429-081224-i9aWYM/build
[end run-tests >> 2009.04.29 = >> 09:19:24]
TESTS_RETURN =3D 0
2009.04.29 09:19:24 -- checkout, = > compile and test run done.

---

removing build tree = >> /tmp/build-cm3-20090429-081224-i9aWYM ...
cleaning CM3 = >> workspaces...
/homes/hosking/work/cm3-ws/niagara- >> *

cleaning = >> regression test log = >> files...
/homes/hosking/tmp/cm3/niagara/cm3-rlog- >> *

cleaning = >> m3test log = >> files...
/homes/hosking/tmp/cm3/niagara/m3tests-*.stdout

/ >> homes/= >> hosking/tmp/cm3/niagara/m3tests-*.stderr

/homes/hosking/tmp/ >> cm3/nia= >> gara/m3tests-*.stderr.extract

cleaning snapshot = >> files...
/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >> *.tgz>>
cleaning package = >> reports...
/tmp/cm3-pkg-report-SOLgnu-*.html

done.
> div>> ockquote>

= >> >> --Apple-Mail-6-728527402-- From mika at async.caltech.edu Wed Apr 29 20:46:03 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 29 Apr 2009 11:46:03 -0700 Subject: [M3devel] user threads In-Reply-To: Your message of "Thu, 30 Apr 2009 04:04:22 +1000." <736196D3-6AA1-49C4-80E8-4EEB05B38CFC@cs.purdue.edu> Message-ID: <200904291846.n3TIk3F6038926@camembert.async.caltech.edu> Tony, no of course it's not surprising. -unsafe removes the lock-on-every update (in the global environment---pushed environments are always "unsafe"). In fact since there are hardly any updates in the global environment, it's locking on reading that's hurting. [Tony, I'm curious how you'd go about implementing the sort of "non-blocking lock" you mention.] But what Jay has pointed out is that what I labeled as "kernel threads" in the attached table aren't kernel threads at all but libc_r threads, which provide the same facilities (as far as I know) as M3's "user threads". In this case M3's user threads are simply superior to what the system provides. Much superior. I think if possible "M3 user threads" should definitely be the default on FreeBSD4 and earlier, rather than "system user threads". I think people who want to implement coroutines and occam-like things with threads would also be happy if user threads were very easy to enable. Although I agree they should certainly not normally be the default and it is probably unnecessary to be able to enable them at runtime. A compile/link-time option would be nice though.... Rather than having to recompile the whole M3 distribution, that is. I know of two important classes of applications where user threads are likely to be superior to kernel threads: 1. occam-like things, as described above. Not uncommon in hardware circles! 2. applications that use RMI (e.g., Network Objects) to communicate between separate runtimes that are mapped exactly one runtime to each physical core. For case 2, readers may be interested in the following report: http://caltechcstr.library.caltech.edu/218/ Mika Tony Hosking writes: >Mika, it is not surprising that your lock-on-every variable update >will cost a lot in any non-user-level threading scheme. You should >consider using different mechanisms for this degree of locking in >Scheme (based on some of the non-blocking lock implementations for >Java perhaps). I don't expect any implementation of locking for a >multi-core/-processor will ever perform as well as user-level threads. > >On 29 Apr 2009, at 16:53, Mika Nystrom wrote: > >> Ok, it works! >> >> Numbers: >> >> Timings in milliseconds, three samples, filesystem "warmed up" by >> doing one dummy run before launching the real ones. >> >> -unsafe means that I use non-locking Scheme environments, otherwise >> they lock for every variable update. >> ave >> CM3 last week, kernel threads, -unsafe 1460 1482 1437 1460 >> CM3 last week, kernel threads, 2392 2402 2376 2390 >> CM3 this week, kernel threads, -unsafe 1455 1458 1490 1468 (*) >> CM3 this week, user threads, -unsafe 914 934 914 921 >> CM3 this week, user threads, 967 965 986 973 >> PM3 -unsafe 678 657 682 672 >> PM3 709 714 700 708 >> >> (*) not entirely sure this got linked correctly. >> >> Mika >> >> >> Jay writes: >>> >>> User threads seem to work on on FreeBSD/x86 7.0. >>> Mika can you report back the perf cm3 vs. pm3? >>> Still, kernel threads have been around a long time and imho should >>> be strongly favored.. >>> >>> >>> Kernel threads should be a /little/ faster than they were -- >>> PushEFrame removed from successful heap allocations. And should be >>> further improvable via __thread where it is supported -- probably >>> not FreeBSD 4. >>> x, sometimes older is not better. :) >>> >>> >>> I've temporarily switched FreeBSD/x86 to userthreads by default but >>> I think that's just an experiment and should be undone shortly, >>> maybe work out some other story for easily switching between them, >>> or just k >>> eep the existing story of "you get to rebuild everything". >>> >>> >>> Tony, can you look into GetGCRatio? I removed the call to it. The >>> "fatal" pragma invokes PushEFrame apparently. >>> >>> >>> We should now "fix" Win32 and pthreads to not have GetActivation >>> initialize on-demand, just leave Init to initialize always. This >>> should shave a few more cycles from PushEFrame. >>> >>> >>> - Jay From hosking at cs.purdue.edu Wed Apr 29 20:58:06 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 30 Apr 2009 04:58:06 +1000 Subject: [M3devel] user threads In-Reply-To: <200904291846.n3TIk3F6038926@camembert.async.caltech.edu> References: <200904291846.n3TIk3F6038926@camembert.async.caltech.edu> Message-ID: On 30 Apr 2009, at 04:46, Mika Nystrom wrote: > Tony, no of course it's not surprising. -unsafe removes the > lock-on-every update (in the global environment---pushed environments > are always "unsafe"). In fact since there are hardly any updates > in the global environment, it's locking on reading that's hurting. > > [Tony, I'm curious how you'd go about implementing the sort of > "non-blocking lock" you mention.] > > But what Jay has pointed out is that what I labeled as "kernel > threads" in the attached table aren't kernel threads at all but > libc_r threads, which provide the same facilities (as far as I know) > as M3's "user threads". In this case M3's user threads are simply > superior to what the system provides. Much superior. Ah, understood. > I think if possible "M3 user threads" should definitely be the > default on FreeBSD4 and earlier, rather than "system user threads". Fair enough. Old thread libraries were pretty substandard. > I think people who want to implement coroutines and occam-like > things with threads would also be happy if user threads were very > easy to enable. Although I agree they should certainly not normally > be the default and it is probably unnecessary to be able to enable > them at runtime. A compile/link-time option would be nice though.... > Rather than having to recompile the whole M3 distribution, that is. For a systems programming language like Modula-3 I think the general expectation should be that m3-thread = system thread (i.e., something scheduled on a physical processor by the operating system). Anyone wanting Occam-like things and co-routines should think hard about what they need and devise a scheme for multi-plexing them on each of the processors. Perhaps it could be made available as a library. > I know of two important classes of applications where user threads > are likely to be superior to kernel threads: > > 1. occam-like things, as described above. Not uncommon in hardware > circles! But on modern hardware we'd need them to be scheduled across multiple processors. > 2. applications that use RMI (e.g., Network Objects) to communicate > between separate runtimes that are mapped exactly one runtime > to each physical core. Hmm, perhaps... > > > For case 2, readers may be interested in the following report: > > http://caltechcstr.library.caltech.edu/218/ > > Mika > > Tony Hosking writes: >> Mika, it is not surprising that your lock-on-every variable update >> will cost a lot in any non-user-level threading scheme. You should >> consider using different mechanisms for this degree of locking in >> Scheme (based on some of the non-blocking lock implementations for >> Java perhaps). I don't expect any implementation of locking for a >> multi-core/-processor will ever perform as well as user-level >> threads. >> >> On 29 Apr 2009, at 16:53, Mika Nystrom wrote: >> >>> Ok, it works! >>> >>> Numbers: >>> >>> Timings in milliseconds, three samples, filesystem "warmed up" by >>> doing one dummy run before launching the real ones. >>> >>> -unsafe means that I use non-locking Scheme environments, otherwise >>> they lock for every variable update. >>> ave >>> CM3 last week, kernel threads, -unsafe 1460 1482 1437 1460 >>> CM3 last week, kernel threads, 2392 2402 2376 2390 >>> CM3 this week, kernel threads, -unsafe 1455 1458 1490 1468 (*) >>> CM3 this week, user threads, -unsafe 914 934 914 921 >>> CM3 this week, user threads, 967 965 986 973 >>> PM3 -unsafe 678 657 682 672 >>> PM3 709 714 700 708 >>> >>> (*) not entirely sure this got linked correctly. >>> >>> Mika >>> >>> >>> Jay writes: >>>> >>>> User threads seem to work on on FreeBSD/x86 7.0. >>>> Mika can you report back the perf cm3 vs. pm3? >>>> Still, kernel threads have been around a long time and imho should >>>> be strongly favored.. >>>> >>>> >>>> Kernel threads should be a /little/ faster than they were -- >>>> PushEFrame removed from successful heap allocations. And should be >>>> further improvable via __thread where it is supported -- probably >>>> not FreeBSD 4. >>>> x, sometimes older is not better. :) >>>> >>>> >>>> I've temporarily switched FreeBSD/x86 to userthreads by default but >>>> I think that's just an experiment and should be undone shortly, >>>> maybe work out some other story for easily switching between them, >>>> or just k >>>> eep the existing story of "you get to rebuild everything". >>>> >>>> >>>> Tony, can you look into GetGCRatio? I removed the call to it. The >>>> "fatal" pragma invokes PushEFrame apparently. >>>> >>>> >>>> We should now "fix" Win32 and pthreads to not have GetActivation >>>> initialize on-demand, just leave Init to initialize always. This >>>> should shave a few more cycles from PushEFrame. >>>> >>>> >>>> - Jay From jay.krell at cornell.edu Wed Apr 29 22:01:14 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 29 Apr 2009 20:01:14 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: References: <200904291832.n3TIWPNo038139@camembert.async.caltech.edu> Message-ID: Add this to your favorites or bookmarks or whatever: http://tinderbox.elegosoft.com/tinderbox/cm3/status.html It's not the most friendly but it is ok. Unfortunately the error is just: 12067 NEXT Bus Error - core dumped I'll undo stuff, like __thread mainly. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: mika at async.caltech.edu > Date: Thu, 30 Apr 2009 04:35:07 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Fwd: Output from "cron" command > > Tinderbox... > > On 30 Apr 2009, at 04:32, Mika Nystrom wrote: > >> >> I found I had made a typo in my m3tk check-in. Is there an easy >> way to see what the error is? >> >> Mika >> >> Tony Hosking writes: >>> >>> --Apple-Mail-6-728527402 >>> Content-Type: text/plain; >>> charset=US-ASCII; >>> format=flowed >>> Content-Transfer-Encoding: 7bit >>> >>> Now I am getting compile errors. Recent checkins are culpable. >>> >>> Begin forwarded message: >>> >>>> From: Tony Hosking >>>> Date: 29 April 2009 23:21:16 GMT+10:00 >>>> To: hosking at cs.purdue.edu >>>> Subject: Output from "cron" command >>>> >>>> Your "cron" job on niagara.cs.purdue.edu >>>> $HOME/cm3/scripts/regression/cron.sh >>>> >>>> produced the following output: >>>> >>>> TESTHOSTNAME=niagara >>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-10-30-05 >>>> LASTREL=5.4.0 >>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>> CM3_OSTYPE=POSIX >>>> CM3_TARGET=SOLgnu >>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> CM3CVSSERVER=birch.elegosoft.com >>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> CM3CVSUSER= >>>> testing ssh birch.elegosoft.com.. >>>> ssh birch.elegosoft.com ok >>>> Building cm3. >>>> Tinderbox Tree: "cm3" >>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>> >>>> creating log file /tmp/build-cm3-20090429-063007-_Laq8F/log.txt >>>> >>>> --- >>>> >>>> checkout, compile and test of cm3 ... >>>> 2009.04.29 06:30:07 -- checkout in progress. >>>> [start checkout 2009.04.29 06:30:09] >>>> cd /tmp/build-cm3-20090429-063007-_Laq8F/build >>>> cvs return value: 0 >>>> [end checkout 2009.04.29 06:49:37] >>>> CHECKOUT_RETURN = 0 >>>> -- >>>> 2009.04.29 06:49:41 -- compile in progress. >>>> [start compile 2009.04.29 06:49:41] >>>> compile return value: 0 >>>> [end compile 2009.04.29 08:10:32] >>>> COMPILE_RETURN = 1 >>>> *** COMPILE FAILED >>>> removing build tree /tmp/build-cm3-20090429-063007-_Laq8F ... >>>> cleaning CM3 workspaces... >>>> /homes/hosking/work/cm3-ws/niagara-* >>>> >>>> cleaning regression test log files... >>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>> >>>> cleaning m3test log files... >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>> >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>> >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>> >>>> cleaning snapshot files... >>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>> >>>> cleaning package reports... >>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>> >>>> TESTHOSTNAME=niagara >>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-12-12-22 >>>> LASTREL=5.4.0 >>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>> CM3_OSTYPE=POSIX >>>> CM3_TARGET=SOLgnu >>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> CM3CVSSERVER=birch.elegosoft.com >>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> CM3CVSUSER= >>>> testing ssh birch.elegosoft.com.. >>>> ssh birch.elegosoft.com ok >>>> Building cm3. >>>> Tinderbox Tree: "cm3" >>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>> >>>> creating log file /tmp/build-cm3-20090429-081224-i9aWYM/log.txt >>>> >>>> --- >>>> >>>> checkout, compile and test of cm3 ... >>>> 2009.04.29 08:12:24 -- checkout in progress. >>>> [start checkout 2009.04.29 08:12:26] >>>> cd /tmp/build-cm3-20090429-081224-i9aWYM/build >>>> cvs return value: 0 >>>> [end checkout 2009.04.29 08:32:34] >>>> CHECKOUT_RETURN = 0 >>>> -- >>>> 2009.04.29 08:32:38 -- compile in progress. >>>> [start compile 2009.04.29 08:32:38] >>>> compile return value: 0 >>>> [end compile 2009.04.29 09:19:20] >>>> COMPILE_RETURN = 0 >>>> 2009.04.29 09:19:24 -- tests in progress. >>>> [start run-tests 2009.04.29 09:19:24] >>>> cd /tmp/build-cm3-20090429-081224-i9aWYM/build >>>> [end run-tests 2009.04.29 09:19:24] >>>> TESTS_RETURN = 0 >>>> 2009.04.29 09:19:24 -- checkout, compile and test run done. >>>> >>>> --- >>>> >>>> removing build tree /tmp/build-cm3-20090429-081224-i9aWYM ... >>>> cleaning CM3 workspaces... >>>> /homes/hosking/work/cm3-ws/niagara-* >>>> >>>> cleaning regression test log files... >>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>> >>>> cleaning m3test log files... >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>> >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>> >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>> >>>> cleaning snapshot files... >>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>> >>>> cleaning package reports... >>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>> >>>> done. >>> >>> >>> --Apple-Mail-6-728527402 >>> Content-Type: text/html; >>> charset=US-ASCII >>> Content-Transfer-Encoding: quoted-printable >>> >>>>>> space; = >>> -webkit-line-break: after-white-space; "> >>> apple-content-edited=3D"true">>>> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >>> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >>> normal; font-variant: normal; font-weight: normal; letter-spacing: = >>> normal; line-height: normal; text-align: auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; "> >>> style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; = >>> -khtml-line-break: after-white-space; ">>>> span" = >>> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >>> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >>> normal; font-variant: normal; font-weight: normal; letter-spacing: = >>> normal; line-height: normal; text-align: auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>> Helvetica; = >>> font-size: 12px; font-style: normal; font-variant: normal; font- >>> weight: = >>> normal; letter-spacing: normal; line-height: normal; text-align: >>> auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>> Helvetica; = >>> font-size: 12px; font-style: normal; font-variant: normal; font- >>> weight: = >>> normal; letter-spacing: normal; line-height: normal; text-align: >>> auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>> Helvetica; = >>> font-size: 12px; font-style: normal; font-variant: normal; font- >>> weight: = >>> normal; letter-spacing: normal; line-height: normal; text-align: >>> auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>> Helvetica; = >>> font-size: 12px; font-style: normal; font-variant: normal; font- >>> weight: = >>> normal; letter-spacing: normal; line-height: normal; text-align: >>> auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>> Helvetica; = >>> font-size: 12px; font-style: normal; font-variant: normal; font- >>> weight: = >>> normal; letter-spacing: normal; line-height: normal; text-align: >>> auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>> Helvetica; = >>> font-size: 12px; font-style: normal; font-variant: normal; font- >>> weight: = >>> normal; letter-spacing: normal; line-height: normal; text-align: >>> auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>> Helvetica; = >>> font-size: 12px; font-style: normal; font-variant: normal; font- >>> weight: = >>> normal; letter-spacing: normal; line-height: normal; text-align: >>> auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; "> Now I am = >>> getting compile errors. Recent checkins are = >>> culpable.>>> span>>>> iv> Begin forwarded message: >>> class=3D"Apple-interchange-newline">>>> type=3D"cite"> >>> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >>> margin-left: 0px; ">>>> color=3D"#000000" = >>> style=3D"font: 12.0px Helvetica; color: #000000">From: = >>>>>> 12.0px = >>> Helvetica">Tony Hosking <>>> href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu>>>> font>>>> iv> >>> 0px; = >>> margin-left: 0px; ">>>> color=3D"#000000" = >>> style=3D"font: 12.0px Helvetica; color: #000000">Date: = >>>>>> 12.0px = >>> Helvetica">29 April 2009 23:21:16 GMT+10:00 >>> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >>> margin-left: 0px; ">>>> color=3D"#000000" = >>> style=3D"font: 12.0px Helvetica; color: #000000">To:>>> font>>>> face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">>>> href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu>>> font>>>> v> >>> 0px; = >>> margin-left: 0px; ">>>> color=3D"#000000" = >>> style=3D"font: 12.0px Helvetica; color: #000000">Subject: = >>>>>> 12.0px = >>> Helvetica">Output from "cron" command >>> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >>> margin-left: 0px; min-height: 14px; "> Your >>> "cron" = >>> job on = >>> niagara.cs.purdue.edu $HOME/cm3/scripts/regression/ >>> cron.sh produ= >>> ced the following = >>> output: TESTHOSTNAME=3Dniagara WS=3D/homes/hosking/work/ >>> cm3-ws/n= >>> iagara-2009-04-29-10-30-05 LASTREL=3D5.4.0 INSTROOT_REL=3D/ >>> homes/hos= >>> king/work/cm3-inst/niagara/rel-5.4.0 INSTROOT_POK=3D/homes/ >>> hosking/work= >>> /cm3-inst/niagara/prev-ok INSTROOT_LOK=3D/homes/hosking/work/cm3- >>> inst/n= >>> iagara/last-ok INSTROOT_CUR=3D/homes/hosking/work/cm3-inst/ >>> niagara/curr= >>> ent CM3_OSTYPE=3DPOSIX CM3_TARGET=3DSOLgnu BINDISTMIN=3D/ >>> homes/ho= >>> sking/work/cm3-min-POSIX- >>> SOLgnu-5.4.0.tgz CM3CVSSERVER=3Dbirch.elegosof= >>> t.com CM3CVSROOT=3Dbirch.elegosoft.com:/usr/ >>> cvs BINDISTMIN_NAME=3Dcm= >>> 3-min-POSIX-SOLgnu-5.4.0.tgz BINDISTMIN=3D/homes/hosking/work/ >>> cm3-min-P= >>> OSIX-SOLgnu-5.4.0.tgz CM3CVSUSER=3D testing ssh = >>> birch.elegosoft.com.. ssh birch.elegosoft.com ok Building = >>> cm3. Tinderbox Tree: "cm3" Buildname: = >>> "SOLgnu SunOS 5.10 >>> niagara = >>> release-build" creating log file = >>> /tmp/build-cm3-20090429-063007-_Laq8F/log.txt --- >>> checkout, = >>> compile and test of cm3 ... 2009.04.29 06:30:07 -- checkout in = >>> progress. [start checkout 2009.04.29 06:30:09] cd = >>> /tmp/build-cm3-20090429-063007-_Laq8F/build cvs return value: = >>> 0 [end checkout 2009.04.29 06:49:37] CHECKOUT_RETURN =3D = >> 0 -- 2009.04.29 06:49:41 -- compile in progress. [start >> compile = >>> 2009.04.29 06:49:41] compile return value: 0 [end compile = >>> 2009.04.29 08:10:32] COMPILE_RETURN =3D 1 *** COMPILE = >>> FAILED removing build tree /tmp/build-cm3-20090429-063007-_Laq8F = >>> ... cleaning CM3 = >>> workspaces... /homes/hosking/work/cm3-ws/niagara- >>> * cleaning = >>> regression test log = >>> files... /homes/hosking/tmp/cm3/niagara/cm3-rlog- >>> * cleaning = >>> m3test log = >>> files... /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout / >>> homes/= >>> hosking/tmp/cm3/niagara/m3tests-*.stderr /homes/hosking/tmp/ >>> cm3/nia= >>> gara/m3tests-*.stderr.extract cleaning snapshot = >>> files... /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >>> *.tgz>>>> cleaning package = >>> reports... /tmp/cm3-pkg-report-SOLgnu- >>> *.html TESTHOSTNAME=3Dniag= >>> ara WS=3D/homes/hosking/work/cm3-ws/ >>> niagara-2009-04-29-12-12-22 LAST= >>> REL=3D5.4.0 INSTROOT_REL=3D/homes/hosking/work/cm3-inst/niagara/ >>> rel-5.4= >>> .0 INSTROOT_POK=3D/homes/hosking/work/cm3-inst/niagara/prev- >>> ok INSTR= >>> OOT_LOK=3D/homes/hosking/work/cm3-inst/niagara/last- >>> ok INSTROOT_CUR=3D/= >>> homes/hosking/work/cm3-inst/niagara/ >>> current CM3_OSTYPE=3DPOSIX CM3_T= >>> ARGET=3DSOLgnu BINDISTMIN=3D/homes/hosking/work/cm3-min-POSIX- >>> SOLgnu-5.= >>> 4.0 >>> .tgz >>> CM3CVSSERVER=3Dbirch.elegosoft.com CM3CVSROOT=3Dbirch.elegos= >>> oft.com:/usr/cvs BINDISTMIN_NAME=3Dcm3-min-POSIX- >>> SOLgnu-5.4.0.tgz BI= >>> NDISTMIN=3D/homes/hosking/work/cm3-min-POSIX- >>> SOLgnu-5.4.0.tgz CM3CVSUSE= >>> R=3D testing ssh birch.elegosoft.com.. ssh >>> birch.elegosoft.com = >>> ok Building cm3. Tinderbox Tree: >>> "cm3" Buildname: = >>> "SOLgnu SunOS 5.10 >>> niagara = >>> lastok-build" creating log file = >>> /tmp/build-cm3-20090429-081224-i9aWYM/log.txt --- >>> checkout, = >>> compile and test of cm3 ... 2009.04.29 08:12:24 -- checkout in = >>> progress. [start checkout 2009.04.29 08:12:26] cd = >>> /tmp/build-cm3-20090429-081224-i9aWYM/build cvs return value: = >>> 0 [end checkout 2009.04.29 08:32:34] CHECKOUT_RETURN =3D = >>> 0 -- 2009.04.29 08:32:38 -- compile in progress. [start >>> compile = >>> 2009.04.29 08:32:38] compile return value: 0 [end compile = >>> 2009.04.29 09:19:20] COMPILE_RETURN =3D 0 2009.04.29 09:19:24 >>> -- = >>> tests in progress. [start run-tests 2009.04.29 09:19:24] cd = >>> /tmp/build-cm3-20090429-081224-i9aWYM/build [end run-tests >>> 2009.04.29 = >>> 09:19:24] TESTS_RETURN =3D 0 2009.04.29 09:19:24 -- checkout, = >> compile and test run done. --- removing build tree = >>> /tmp/build-cm3-20090429-081224-i9aWYM ... cleaning CM3 = >>> workspaces... /homes/hosking/work/cm3-ws/niagara- >>> * cleaning = >>> regression test log = >>> files... /homes/hosking/tmp/cm3/niagara/cm3-rlog- >>> * cleaning = >>> m3test log = >>> files... /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout / >>> homes/= >>> hosking/tmp/cm3/niagara/m3tests-*.stderr /homes/hosking/tmp/ >>> cm3/nia= >>> gara/m3tests-*.stderr.extract cleaning snapshot = >>> files... /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >>> *.tgz>>>> cleaning package = >>> reports... /tmp/cm3-pkg-report-SOLgnu-*.html done. >>> div>>>> ockquote> = >>> >>> --Apple-Mail-6-728527402-- > From jay.krell at cornell.edu Wed Apr 29 22:07:48 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 29 Apr 2009 20:07:48 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: References: <200904291832.n3TIWPNo038139@camembert.async.caltech.edu> Message-ID: Actually it looks like I missed I didn't change ThreadPThreadC.c to turn on __thread. Anyway I'll look a bit, did make other changes. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; mika at async.caltech.edu > Date: Wed, 29 Apr 2009 20:01:14 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Fwd: Output from "cron" command > > > Add this to your favorites or bookmarks or whatever: > > > http://tinderbox.elegosoft.com/tinderbox/cm3/status.html > > It's not the most friendly but it is ok. > > > Unfortunately the error is just: > > 12067 NEXT Bus Error - core dumped > > I'll undo stuff, like __thread mainly. > > - Jay > > > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: mika at async.caltech.edu >> Date: Thu, 30 Apr 2009 04:35:07 +1000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Fwd: Output from "cron" command >> >> Tinderbox... >> >> On 30 Apr 2009, at 04:32, Mika Nystrom wrote: >> >>> >>> I found I had made a typo in my m3tk check-in. Is there an easy >>> way to see what the error is? >>> >>> Mika >>> >>> Tony Hosking writes: >>>> >>>> --Apple-Mail-6-728527402 >>>> Content-Type: text/plain; >>>> charset=US-ASCII; >>>> format=flowed >>>> Content-Transfer-Encoding: 7bit >>>> >>>> Now I am getting compile errors. Recent checkins are culpable. >>>> >>>> Begin forwarded message: >>>> >>>>> From: Tony Hosking >>>>> Date: 29 April 2009 23:21:16 GMT+10:00 >>>>> To: hosking at cs.purdue.edu >>>>> Subject: Output from "cron" command >>>>> >>>>> Your "cron" job on niagara.cs.purdue.edu >>>>> $HOME/cm3/scripts/regression/cron.sh >>>>> >>>>> produced the following output: >>>>> >>>>> TESTHOSTNAME=niagara >>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-10-30-05 >>>>> LASTREL=5.4.0 >>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>> CM3_OSTYPE=POSIX >>>>> CM3_TARGET=SOLgnu >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSSERVER=birch.elegosoft.com >>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSUSER= >>>>> testing ssh birch.elegosoft.com.. >>>>> ssh birch.elegosoft.com ok >>>>> Building cm3. >>>>> Tinderbox Tree: "cm3" >>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>> >>>>> creating log file /tmp/build-cm3-20090429-063007-_Laq8F/log.txt >>>>> >>>>> --- >>>>> >>>>> checkout, compile and test of cm3 ... >>>>> 2009.04.29 06:30:07 -- checkout in progress. >>>>> [start checkout 2009.04.29 06:30:09] >>>>> cd /tmp/build-cm3-20090429-063007-_Laq8F/build >>>>> cvs return value: 0 >>>>> [end checkout 2009.04.29 06:49:37] >>>>> CHECKOUT_RETURN = 0 >>>>> -- >>>>> 2009.04.29 06:49:41 -- compile in progress. >>>>> [start compile 2009.04.29 06:49:41] >>>>> compile return value: 0 >>>>> [end compile 2009.04.29 08:10:32] >>>>> COMPILE_RETURN = 1 >>>>> *** COMPILE FAILED >>>>> removing build tree /tmp/build-cm3-20090429-063007-_Laq8F ... >>>>> cleaning CM3 workspaces... >>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>> >>>>> cleaning regression test log files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>> >>>>> cleaning m3test log files... >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>> >>>>> cleaning snapshot files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>> >>>>> cleaning package reports... >>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>> >>>>> TESTHOSTNAME=niagara >>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-12-12-22 >>>>> LASTREL=5.4.0 >>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>> CM3_OSTYPE=POSIX >>>>> CM3_TARGET=SOLgnu >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSSERVER=birch.elegosoft.com >>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSUSER= >>>>> testing ssh birch.elegosoft.com.. >>>>> ssh birch.elegosoft.com ok >>>>> Building cm3. >>>>> Tinderbox Tree: "cm3" >>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>> >>>>> creating log file /tmp/build-cm3-20090429-081224-i9aWYM/log.txt >>>>> >>>>> --- >>>>> >>>>> checkout, compile and test of cm3 ... >>>>> 2009.04.29 08:12:24 -- checkout in progress. >>>>> [start checkout 2009.04.29 08:12:26] >>>>> cd /tmp/build-cm3-20090429-081224-i9aWYM/build >>>>> cvs return value: 0 >>>>> [end checkout 2009.04.29 08:32:34] >>>>> CHECKOUT_RETURN = 0 >>>>> -- >>>>> 2009.04.29 08:32:38 -- compile in progress. >>>>> [start compile 2009.04.29 08:32:38] >>>>> compile return value: 0 >>>>> [end compile 2009.04.29 09:19:20] >>>>> COMPILE_RETURN = 0 >>>>> 2009.04.29 09:19:24 -- tests in progress. >>>>> [start run-tests 2009.04.29 09:19:24] >>>>> cd /tmp/build-cm3-20090429-081224-i9aWYM/build >>>>> [end run-tests 2009.04.29 09:19:24] >>>>> TESTS_RETURN = 0 >>>>> 2009.04.29 09:19:24 -- checkout, compile and test run done. >>>>> >>>>> --- >>>>> >>>>> removing build tree /tmp/build-cm3-20090429-081224-i9aWYM ... >>>>> cleaning CM3 workspaces... >>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>> >>>>> cleaning regression test log files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>> >>>>> cleaning m3test log files... >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>> >>>>> cleaning snapshot files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>> >>>>> cleaning package reports... >>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>> >>>>> done. >>>> >>>> >>>> --Apple-Mail-6-728527402 >>>> Content-Type: text/html; >>>> charset=US-ASCII >>>> Content-Transfer-Encoding: quoted-printable >>>> >>>>>>> space; = >>>> -webkit-line-break: after-white-space; "> >>>> apple-content-edited=3D"true">>>> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >>>> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >>>> normal; font-variant: normal; font-weight: normal; letter-spacing: = >>>> normal; line-height: normal; text-align: auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; "> >>>> style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; = >>>> -khtml-line-break: after-white-space; ">>>> span" = >>>> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >>>> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >>>> normal; font-variant: normal; font-weight: normal; letter-spacing: = >>>> normal; line-height: normal; text-align: auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; "> > Now I am = >>>> getting compile errors. Recent checkins are = >>>> culpable.>>> span>>>> iv> > > > Begin forwarded message: >>>> class=3D"Apple-interchange-newline">>>> type=3D"cite"> > >>>> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >>>> margin-left: 0px; ">>>> color=3D"#000000" = >>>> style=3D"font: 12.0px Helvetica; color: #000000">From: = >>>>>>> 12.0px = >>>> Helvetica">Tony Hosking <>>> href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu>>>> font>>>> iv> >>>> 0px; = >>>> margin-left: 0px; ">>>> color=3D"#000000" = >>>> style=3D"font: 12.0px Helvetica; color: #000000">Date: = >>>>>>> 12.0px = >>>> Helvetica">29 April 2009 23:21:16 GMT+10:00 >>>> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >>>> margin-left: 0px; ">>>> color=3D"#000000" = >>>> style=3D"font: 12.0px Helvetica; color: #000000">To:>>> font>>>> face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">>>> href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu>>> font>>>> v> >>>> 0px; = >>>> margin-left: 0px; ">>>> color=3D"#000000" = >>>> style=3D"font: 12.0px Helvetica; color: #000000">Subject: = >>>>>>> 12.0px = >>>> Helvetica">Output from "cron" command >>>> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >>>> margin-left: 0px; min-height: 14px; "> > > Your >>>> "cron" = >>>> job on = >>>> niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/ >>>> cron.sh > > produ= >>>> ced the following = >>>> output: > > TESTHOSTNAME=3Dniagara > WS=3D/homes/hosking/work/ >>>> cm3-ws/n= >>>> iagara-2009-04-29-10-30-05 > LASTREL=3D5.4.0 > INSTROOT_REL=3D/ >>>> homes/hos= >>>> king/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=3D/homes/ >>>> hosking/work= >>>> /cm3-inst/niagara/prev-ok > INSTROOT_LOK=3D/homes/hosking/work/cm3- >>>> inst/n= >>>> iagara/last-ok > INSTROOT_CUR=3D/homes/hosking/work/cm3-inst/ >>>> niagara/curr= >>>> ent > CM3_OSTYPE=3DPOSIX > CM3_TARGET=3DSOLgnu > BINDISTMIN=3D/ >>>> homes/ho= >>>> sking/work/cm3-min-POSIX- >>>> SOLgnu-5.4.0.tgz > CM3CVSSERVER=3Dbirch.elegosof= >>>> t.com > CM3CVSROOT=3Dbirch.elegosoft.com:/usr/ >>>> cvs > BINDISTMIN_NAME=3Dcm= >>>> 3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=3D/homes/hosking/work/ >>>> cm3-min-P= >>>> OSIX-SOLgnu-5.4.0.tgz > CM3CVSUSER=3D > testing ssh = >>>> birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building = >>>> cm3. > Tinderbox Tree: "cm3" > Buildname: = >>>> "SOLgnu SunOS 5.10 >>>> niagara = >>>> release-build" > > creating log file = >>>> /tmp/build-cm3-20090429-063007-_Laq8F/log.txt > > --- >>>> > > checkout, = >>>> compile and test of cm3 ... > 2009.04.29 06:30:07 -- checkout in = >>>> progress. > [start checkout 2009.04.29 06:30:09] > cd = >>>> /tmp/build-cm3-20090429-063007-_Laq8F/build > cvs return value: = >>>> 0 > [end checkout 2009.04.29 06:49:37] > CHECKOUT_RETURN =3D = >>> 0 > -- > 2009.04.29 06:49:41 -- compile in progress. > [start >>> compile = >>>> 2009.04.29 06:49:41] > compile return value: 0 > [end compile = >>>> 2009.04.29 08:10:32] > COMPILE_RETURN =3D 1 > *** COMPILE = >>>> FAILED > removing build tree /tmp/build-cm3-20090429-063007-_Laq8F = >>>> ... > cleaning CM3 = >>>> workspaces... > /homes/hosking/work/cm3-ws/niagara- >>>> * > > cleaning = >>>> regression test log = >>>> files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog- >>>> * > > cleaning = >>>> m3test log = >>>> files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > / >>>> homes/= >>>> hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/ >>>> cm3/nia= >>>> gara/m3tests-*.stderr.extract > > cleaning snapshot = >>>> files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >>>> *.tgz>>>> > cleaning package = >>>> reports... > /tmp/cm3-pkg-report-SOLgnu- >>>> *.html > > TESTHOSTNAME=3Dniag= >>>> ara > WS=3D/homes/hosking/work/cm3-ws/ >>>> niagara-2009-04-29-12-12-22 > LAST= >>>> REL=3D5.4.0 > INSTROOT_REL=3D/homes/hosking/work/cm3-inst/niagara/ >>>> rel-5.4= >>>> .0 > INSTROOT_POK=3D/homes/hosking/work/cm3-inst/niagara/prev- >>>> ok > INSTR= >>>> OOT_LOK=3D/homes/hosking/work/cm3-inst/niagara/last- >>>> ok > INSTROOT_CUR=3D/= >>>> homes/hosking/work/cm3-inst/niagara/ >>>> current > CM3_OSTYPE=3DPOSIX > CM3_T= >>>> ARGET=3DSOLgnu > BINDISTMIN=3D/homes/hosking/work/cm3-min-POSIX- >>>> SOLgnu-5.= >>>> 4.0 >>>> .tgz >>>> > CM3CVSSERVER=3Dbirch.elegosoft.com > CM3CVSROOT=3Dbirch.elegos= >>>> oft.com:/usr/cvs > BINDISTMIN_NAME=3Dcm3-min-POSIX- >>>> SOLgnu-5.4.0.tgz > BI= >>>> NDISTMIN=3D/homes/hosking/work/cm3-min-POSIX- >>>> SOLgnu-5.4.0.tgz > CM3CVSUSE= >>>> R=3D > testing ssh birch.elegosoft.com.. > ssh >>>> birch.elegosoft.com = >>>> ok > Building cm3. > Tinderbox Tree: >>>> "cm3" > Buildname: = >>>> "SOLgnu SunOS 5.10 >>>> niagara = >>>> lastok-build" > > creating log file = >>>> /tmp/build-cm3-20090429-081224-i9aWYM/log.txt > > --- >>>> > > checkout, = >>>> compile and test of cm3 ... > 2009.04.29 08:12:24 -- checkout in = >>>> progress. > [start checkout 2009.04.29 08:12:26] > cd = >>>> /tmp/build-cm3-20090429-081224-i9aWYM/build > cvs return value: = >>>> 0 > [end checkout 2009.04.29 08:32:34] > CHECKOUT_RETURN =3D = >>>> 0 > -- > 2009.04.29 08:32:38 -- compile in progress. > [start >>>> compile = >>>> 2009.04.29 08:32:38] > compile return value: 0 > [end compile = >>>> 2009.04.29 09:19:20] > COMPILE_RETURN =3D 0 > 2009.04.29 09:19:24 >>>> -- = >>>> tests in progress. > [start run-tests 2009.04.29 09:19:24] > cd = >>>> /tmp/build-cm3-20090429-081224-i9aWYM/build > [end run-tests >>>> 2009.04.29 = >>>> 09:19:24] > TESTS_RETURN =3D 0 > 2009.04.29 09:19:24 -- checkout, = >>> compile and test run done. > > --- > > removing build tree = >>>> /tmp/build-cm3-20090429-081224-i9aWYM ... > cleaning CM3 = >>>> workspaces... > /homes/hosking/work/cm3-ws/niagara- >>>> * > > cleaning = >>>> regression test log = >>>> files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog- >>>> * > > cleaning = >>>> m3test log = >>>> files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > / >>>> homes/= >>>> hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/ >>>> cm3/nia= >>>> gara/m3tests-*.stderr.extract > > cleaning snapshot = >>>> files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >>>> *.tgz>>>> > cleaning package = >>>> reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > done. >>>> div>>>> ockquote> > = >>>> >>>> --Apple-Mail-6-728527402-- >> From mika at async.caltech.edu Wed Apr 29 22:12:09 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 29 Apr 2009 13:12:09 -0700 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: Your message of "Wed, 29 Apr 2009 20:01:14 -0000." Message-ID: <200904292012.n3TKC93h043346@camembert.async.caltech.edu> This one is my fault: 27146 new source -> compiling Type.m3 27147 "../src/Type.m3", line 291: types are not assignable 27148 NEXT 1 error encountered I think I already fixed it, though. Mika Jay writes: > >Add this to your favorites or bookmarks or whatever: > > >http://tinderbox.elegosoft.com/tinderbox/cm3/status.html > >It's not the most friendly but it is ok. > > >Unfortunately the error is just: > >12067 NEXT Bus Error - core dumped > >I'll undo stuff, like __thread mainly. > > - Jay > > > > >---------------------------------------- >> From: hosking at cs.purdue.edu >> To: mika at async.caltech.edu >> Date: Thu, 30 Apr 2009 04:35:07 +1000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Fwd: Output from "cron" command >> >> Tinderbox... >> >> On 30 Apr 2009, at 04:32, Mika Nystrom wrote: >> >>> >>> I found I had made a typo in my m3tk check-in. Is there an easy >>> way to see what the error is? >>> >>> Mika >>> >>> Tony Hosking writes: >>>> >>>> --Apple-Mail-6-728527402 >>>> Content-Type: text/plain; >>>> charset=US-ASCII; >>>> format=flowed >>>> Content-Transfer-Encoding: 7bit >>>> >>>> Now I am getting compile errors. Recent checkins are culpable. >>>> >>>> Begin forwarded message: >>>> >>>>> From: Tony Hosking >>>>> Date: 29 April 2009 23:21:16 GMT+10:00 >>>>> To: hosking at cs.purdue.edu >>>>> Subject: Output from "cron" command >>>>> >>>>> Your "cron" job on niagara.cs.purdue.edu >>>>> $HOME/cm3/scripts/regression/cron.sh >>>>> >>>>> produced the following output: >>>>> >>>>> TESTHOSTNAME=niagara >>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-10-30-05 >>>>> LASTREL=5.4.0 >>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>> CM3_OSTYPE=POSIX >>>>> CM3_TARGET=SOLgnu >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSSERVER=birch.elegosoft.com >>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSUSER= >>>>> testing ssh birch.elegosoft.com.. >>>>> ssh birch.elegosoft.com ok >>>>> Building cm3. >>>>> Tinderbox Tree: "cm3" >>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>> >>>>> creating log file /tmp/build-cm3-20090429-063007-_Laq8F/log.txt >>>>> >>>>> --- >>>>> >>>>> checkout, compile and test of cm3 ... >>>>> 2009.04.29 06:30:07 -- checkout in progress. >>>>> [start checkout 2009.04.29 06:30:09] >>>>> cd /tmp/build-cm3-20090429-063007-_Laq8F/build >>>>> cvs return value: 0 >>>>> [end checkout 2009.04.29 06:49:37] >>>>> CHECKOUT_RETURN = 0 >>>>> -- >>>>> 2009.04.29 06:49:41 -- compile in progress. >>>>> [start compile 2009.04.29 06:49:41] >>>>> compile return value: 0 >>>>> [end compile 2009.04.29 08:10:32] >>>>> COMPILE_RETURN = 1 >>>>> *** COMPILE FAILED >>>>> removing build tree /tmp/build-cm3-20090429-063007-_Laq8F ... >>>>> cleaning CM3 workspaces... >>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>> >>>>> cleaning regression test log files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>> >>>>> cleaning m3test log files... >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>> >>>>> cleaning snapshot files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>> >>>>> cleaning package reports... >>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>> >>>>> TESTHOSTNAME=niagara >>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-12-12-22 >>>>> LASTREL=5.4.0 >>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>> CM3_OSTYPE=POSIX >>>>> CM3_TARGET=SOLgnu >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSSERVER=birch.elegosoft.com >>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSUSER= >>>>> testing ssh birch.elegosoft.com.. >>>>> ssh birch.elegosoft.com ok >>>>> Building cm3. >>>>> Tinderbox Tree: "cm3" >>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>> >>>>> creating log file /tmp/build-cm3-20090429-081224-i9aWYM/log.txt >>>>> >>>>> --- >>>>> >>>>> checkout, compile and test of cm3 ... >>>>> 2009.04.29 08:12:24 -- checkout in progress. >>>>> [start checkout 2009.04.29 08:12:26] >>>>> cd /tmp/build-cm3-20090429-081224-i9aWYM/build >>>>> cvs return value: 0 >>>>> [end checkout 2009.04.29 08:32:34] >>>>> CHECKOUT_RETURN = 0 >>>>> -- >>>>> 2009.04.29 08:32:38 -- compile in progress. >>>>> [start compile 2009.04.29 08:32:38] >>>>> compile return value: 0 >>>>> [end compile 2009.04.29 09:19:20] >>>>> COMPILE_RETURN = 0 >>>>> 2009.04.29 09:19:24 -- tests in progress. >>>>> [start run-tests 2009.04.29 09:19:24] >>>>> cd /tmp/build-cm3-20090429-081224-i9aWYM/build >>>>> [end run-tests 2009.04.29 09:19:24] >>>>> TESTS_RETURN = 0 >>>>> 2009.04.29 09:19:24 -- checkout, compile and test run done. >>>>> >>>>> --- >>>>> >>>>> removing build tree /tmp/build-cm3-20090429-081224-i9aWYM ... >>>>> cleaning CM3 workspaces... >>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>> >>>>> cleaning regression test log files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>> >>>>> cleaning m3test log files... >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>> >>>>> cleaning snapshot files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>> >>>>> cleaning package reports... >>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>> >>>>> done. >>>> >>>> >>>> --Apple-Mail-6-728527402 >>>> Content-Type: text/html; >>>> charset=US-ASCII >>>> Content-Transfer-Encoding: quoted-printable >>>> >>>>>>> space; = >>>> -webkit-line-break: after-white-space; "> >>>> apple-content-edited=3D"true">>>> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >>>> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >>>> normal; font-variant: normal; font-weight: normal; letter-spacing: = >>>> normal; line-height: normal; text-align: auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; "> >>>> style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; = >>>> -khtml-line-break: after-white-space; ">>>> span" = >>>> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >>>> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >>>> normal; font-variant: normal; font-weight: normal; letter-spacing: = >>>> normal; line-height: normal; text-align: auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; "> >Now I am = >>>> getting compile errors. Recent checkins are = >>>> culpable.>>> span>>>> iv> > > >Begin forwarded message: >>>> class=3D"Apple-interchange-newline">>>> type=3D"cite"> > >>>> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >>>> margin-left: 0px; ">>>> color=3D"#000000" = >>>> style=3D"font: 12.0px Helvetica; color: #000000">From: = >>>>>>> 12.0px = >>>> Helvetica">Tony Hosking <>>> href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu>>>> font>>>> iv> >>>> 0px; = >>>> margin-left: 0px; ">>>> color=3D"#000000" = >>>> style=3D"font: 12.0px Helvetica; color: #000000">Date: = >>>>>>> 12.0px = >>>> Helvetica">29 April 2009 23:21:16 GMT+10:00 >>>> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >>>> margin-left: 0px; ">>>> color=3D"#000000" = >>>> style=3D"font: 12.0px Helvetica; color: #000000">To:>>> font>>>> face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">>>> href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu>>> font>>>> >v> >>>> 0px; = >>>> margin-left: 0px; ">>>> color=3D"#000000" = >>>> style=3D"font: 12.0px Helvetica; color: #000000">Subject: = >>>>>>> 12.0px = >>>> Helvetica">Output from "cron" command >>>> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >>>> margin-left: 0px; min-height: 14px; "> > >Your >>>> "cron" = >>>> job on = >>>> niagara.cs.purdue.edu >$HOME/cm3/scripts/regression/ >>>> cron.sh > >produ= >>>> ced the following = >>>> output: > >TESTHOSTNAME=3Dniagara >WS=3D/homes/hosking/work/ >>>> cm3-ws/n= >>>> iagara-2009-04-29-10-30-05 >LASTREL=3D5.4.0 >INSTROOT_REL=3D/ >>>> homes/hos= >>>> king/work/cm3-inst/niagara/rel-5.4.0 >INSTROOT_POK=3D/homes/ >>>> hosking/work= >>>> /cm3-inst/niagara/prev-ok >INSTROOT_LOK=3D/homes/hosking/work/cm3- >>>> inst/n= >>>> iagara/last-ok >INSTROOT_CUR=3D/homes/hosking/work/cm3-inst/ >>>> niagara/curr= >>>> ent >CM3_OSTYPE=3DPOSIX >CM3_TARGET=3DSOLgnu >BINDISTMIN=3D/ >>>> homes/ho= >>>> sking/work/cm3-min-POSIX- >>>> SOLgnu-5.4.0.tgz >CM3CVSSERVER=3Dbirch.elegosof= >>>> t.com >CM3CVSROOT=3Dbirch.elegosoft.com:/usr/ >>>> cvs >BINDISTMIN_NAME=3Dcm= >>>> 3-min-POSIX-SOLgnu-5.4.0.tgz >BINDISTMIN=3D/homes/hosking/work/ >>>> cm3-min-P= >>>> OSIX-SOLgnu-5.4.0.tgz >CM3CVSUSER=3D >testing ssh = >>>> birch.elegosoft.com.. >ssh birch.elegosoft.com ok >Building = >>>> cm3. >Tinderbox Tree: "cm3" >Buildname: = >>>> "SOLgnu SunOS 5.10 >>>> niagara = >>>> release-build" > >creating log file = >>>> /tmp/build-cm3-20090429-063007-_Laq8F/log.txt > >--- >>>> > >checkout, = >>>> compile and test of cm3 ... >2009.04.29 06:30:07 -- checkout in = >>>> progress. >[start checkout 2009.04.29 06:30:09] >cd = >>>> /tmp/build-cm3-20090429-063007-_Laq8F/build >cvs return value: = >>>> 0 >[end checkout 2009.04.29 06:49:37] >CHECKOUT_RETURN =3D = >>> 0 >-- >2009.04.29 06:49:41 -- compile in progress. >[start >>> compile = >>>> 2009.04.29 06:49:41] >compile return value: 0 >[end compile = >>>> 2009.04.29 08:10:32] >COMPILE_RETURN =3D 1 >*** COMPILE = >>>> FAILED >removing build tree /tmp/build-cm3-20090429-063007-_Laq8F = >>>> ... >cleaning CM3 = >>>> workspaces... >/homes/hosking/work/cm3-ws/niagara- >>>> * > >cleaning = >>>> regression test log = >>>> files... >/homes/hosking/tmp/cm3/niagara/cm3-rlog- >>>> * > >cleaning = >>>> m3test log = >>>> files... >/homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > >/ >>>> homes/= >>>> hosking/tmp/cm3/niagara/m3tests-*.stderr > >/homes/hosking/tmp/ >>>> cm3/nia= >>>> gara/m3tests-*.stderr.extract > >cleaning snapshot = >>>> files... >/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >>>> *.tgz>>>> >cleaning package = >>>> reports... >/tmp/cm3-pkg-report-SOLgnu- >>>> *.html > >TESTHOSTNAME=3Dniag= >>>> ara >WS=3D/homes/hosking/work/cm3-ws/ >>>> niagara-2009-04-29-12-12-22 >LAST= >>>> REL=3D5.4.0 >INSTROOT_REL=3D/homes/hosking/work/cm3-inst/niagara/ >>>> rel-5.4= >>>> .0 >INSTROOT_POK=3D/homes/hosking/work/cm3-inst/niagara/prev- >>>> ok >INSTR= >>>> OOT_LOK=3D/homes/hosking/work/cm3-inst/niagara/last- >>>> ok >INSTROOT_CUR=3D/= >>>> homes/hosking/work/cm3-inst/niagara/ >>>> current >CM3_OSTYPE=3DPOSIX >CM3_T= >>>> ARGET=3DSOLgnu >BINDISTMIN=3D/homes/hosking/work/cm3-min-POSIX- >>>> SOLgnu-5.= >>>> 4.0 >>>> .tgz >>>> >CM3CVSSERVER=3Dbirch.elegosoft.com >CM3CVSROOT=3Dbirch.elegos= >>>> oft.com:/usr/cvs >BINDISTMIN_NAME=3Dcm3-min-POSIX- >>>> SOLgnu-5.4.0.tgz >BI= >>>> NDISTMIN=3D/homes/hosking/work/cm3-min-POSIX- >>>> SOLgnu-5.4.0.tgz >CM3CVSUSE= >>>> R=3D >testing ssh birch.elegosoft.com.. >ssh >>>> birch.elegosoft.com = >>>> ok >Building cm3. >Tinderbox Tree: >>>> "cm3" >Buildname: = >>>> "SOLgnu SunOS 5.10 >>>> niagara = >>>> lastok-build" > >creating log file = >>>> /tmp/build-cm3-20090429-081224-i9aWYM/log.txt > >--- >>>> > >checkout, = >>>> compile and test of cm3 ... >2009.04.29 08:12:24 -- checkout in = >>>> progress. >[start checkout 2009.04.29 08:12:26] >cd = >>>> /tmp/build-cm3-20090429-081224-i9aWYM/build >cvs return value: = >>>> 0 >[end checkout 2009.04.29 08:32:34] >CHECKOUT_RETURN =3D = >>>> 0 >-- >2009.04.29 08:32:38 -- compile in progress. >[start >>>> compile = >>>> 2009.04.29 08:32:38] >compile return value: 0 >[end compile = >>>> 2009.04.29 09:19:20] >COMPILE_RETURN =3D 0 >2009.04.29 09:19:24 >>>> -- = >>>> tests in progress. >[start run-tests 2009.04.29 09:19:24] >cd = >>>> /tmp/build-cm3-20090429-081224-i9aWYM/build >[end run-tests >>>> 2009.04.29 = >>>> 09:19:24] >TESTS_RETURN =3D 0 >2009.04.29 09:19:24 -- checkout, = >>> compile and test run done. > >--- > >removing build tree = >>>> /tmp/build-cm3-20090429-081224-i9aWYM ... >cleaning CM3 = >>>> workspaces... >/homes/hosking/work/cm3-ws/niagara- >>>> * > >cleaning = >>>> regression test log = >>>> files... >/homes/hosking/tmp/cm3/niagara/cm3-rlog- >>>> * > >cleaning = >>>> m3test log = >>>> files... >/homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > >/ >>>> homes/= >>>> hosking/tmp/cm3/niagara/m3tests-*.stderr > >/homes/hosking/tmp/ >>>> cm3/nia= >>>> gara/m3tests-*.stderr.extract > >cleaning snapshot = >>>> files... >/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >>>> *.tgz>>>> >cleaning package = >>>> reports... >/tmp/cm3-pkg-report-SOLgnu-*.html > >done. >>>> div>>>> ockquote> >= >>>> >>>> --Apple-Mail-6-728527402-- >> From jay.krell at cornell.edu Wed Apr 29 23:16:24 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 29 Apr 2009 21:16:24 +0000 Subject: [M3devel] [M3commit] how to switch userthreads on/off In-Reply-To: <69291A6D-E915-41C9-B4FB-AB7F5CF398EE@cs.purdue.edu> References: <200904290622.n3T6MZBR003219@camembert.async.caltech.edu> <69291A6D-E915-41C9-B4FB-AB7F5CF398EE@cs.purdue.edu> Message-ID: Really? I mean, partly, definitely. And I was looking at the "inflating" to see how they do conditionv variables. But, as I understand: The first time you enter a lock will be slow in that it will be heap allocate and pthread_mutex_init. (untraced; with implied use of a lock for the untraced heap). (plus pthread_mutex_lock(&init)). The subsequent times you enter a lock will be "slow" in that they will always call pthread_mutex_lock, but that might not be particularly slow, right? It is a function call, granted, but the implementation might/should be very quick in the case of no contention. Like, you know, presumably the pthread implementer, except on the case of FreeBSD 4.x :) is trying to do a pretty good job for everyone. "But I don't have numbers." - Jay ________________________________ > From: hosking at cs.purdue.edu > To: mika at async.caltech.edu > Date: Thu, 30 Apr 2009 04:33:01 +1000 > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] [M3commit] how to switch userthreads on/off > > Mika, > > With the current implementation of M3 MUTEX 1-1 as pthread mutex you are bound to have significant overhead for any locking code even in single-threaded apps. We need to move towards a thin-lock implementation for mutex (as used in modern Java implementations) to avoid overhead for uncontended locks. It's not too hard to implement. The idea is to represent a mutex as a tagged word. The word contains either NIL, the thread holding the lock, or a pointer to a full-blown (inflated) pthread mutex. We can use GC and other opportunities to deflate locks as needs. Checking the tag requires a CAS. There are other techniques that further eliminate the CAS for the uncontended case. But, generally, you should consider LOCK to be a fairly high-overhead operation for now. > > 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 29 Apr 2009, at 16:22, Mika Nystrom wrote: > > Jay writes: > ... > > Maybe just leave it as an option in m3core's m3makefile and people can twiddle it if they want and rebuild the entire system like it is today? > That is a bit onerous, but maybe it's all userthreads deserve? > ? > > > Anyone who actually wanted to switch back and forth (Mika) would just have two installs and two source trees? > > > - Jay > > I just want to clarify. I'm not really that interested in switching > back and forth. I'm just a little disturbed by the sometimes huge > performance loss due to the introduction of kernel threads. I knew > that this would happen in certain highly multithreaded applications, > but I'm surprised it happens in a more or less single-threaded > application. > > I think I've just been spoiled by 10 years of using SRCM3 and PM3 > for FreeBSD w/o kernel threads in the sense that I've learned that > using LOCK has essentially no cost. On a shared-memory multiprocessor, > I really don't expect that to remain the case... physics won't allow > it. So now I just have to go through my code and find all the places > where I lock too much and remove them. > > But the memory allocator and garbage collector do it too, no? > > I also think that this idea of being able to use either is great. > Mainly single-threaded programs should definitely not use kernel > threads! > > As for reaching the "thread locals", there is one slightly crazy > idea that one could borrow from Sussman and Steele: add another > implicit argument to every Modula-3 routine. In that argument, > pass a pointer to the thread locals. For EXTERNAL calls (in or > out), make it NIL (somehow, maybe involving pragmas), and in that > case (only), use the pthreads routines to access the thread locals. > Ok so it sounds kind of nuts, but with this approach you could avoid > locking or even calling into the pthreads libs almost entirely for > a single-threaded program. You could even have a thread-local > memory allocator that would only lock when it needs to request > memory from the "global allocator"... in fact there are lots of > things you can do with this sort of thing. Dynamically scoped > variables in Scheme (a la MacLisp?) is what they originally proposed > it for but then they suggested all kinds of tricks related to > continuations with it. > > Mika > From jay.krell at cornell.edu Wed Apr 29 23:26:42 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 29 Apr 2009 21:26:42 +0000 Subject: [M3devel] user threads In-Reply-To: <200904291846.n3TIk3F6038926@camembert.async.caltech.edu> References: Your message of "Thu, 30 Apr 2009 04:04:22 +1000." <736196D3-6AA1-49C4-80E8-4EEB05B38CFC@cs.purdue.edu> <200904291846.n3TIk3F6038926@camembert.async.caltech.edu> Message-ID: > I think if possible "M3 user threads" should definitely be the > default on FreeBSD4 and earlier, rather than "system user threads". I'm tempted to add FreeBSD5 and possibly 6,7,8. Or I386_FREEBSD to imply>=5 (though it'd also work, slowly, for 4) They would all use the same Unix/*.i3 files (not even copies), take the same code in Target.m3. The only difference would be the default threading model in thread.quake and probably a line in the config file to use -lpthread vs. -lc_r. And the default archive/distribution names, if nothing else is done about them. And MAYBE restore the global for pusheframe -- though that precludes I think leaving FreeBSD1-4 able to use their usermode pthreads. That's a microptimization though, for a dying system(s). On the other hand, there might not be more than one FreeBSD 4 user and he can just edit hits m3core/thread.quake?? Mika maybe you'll collect some pthread numbers on FreeBSD 5 soon and dump 4? - Jay From wagner at elegosoft.com Thu Apr 30 08:42:00 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Apr 2009 08:42:00 +0200 Subject: [M3devel] user threads In-Reply-To: References: <200904291846.n3TIk3F6038926@camembert.async.caltech.edu> Message-ID: <20090430084200.7e7jwrb9pck0wwsk@mail.elegosoft.com> Quoting Tony Hosking : > On 30 Apr 2009, at 04:46, Mika Nystrom wrote: > >> But what Jay has pointed out is that what I labeled as "kernel >> threads" in the attached table aren't kernel threads at all but >> libc_r threads, which provide the same facilities (as far as I know) >> as M3's "user threads". In this case M3's user threads are simply >> superior to what the system provides. Much superior. > > Ah, understood. Threading on FreeBSD has been a sad topic for many years. Actually I think I was among the first who ever got a threading library working on FreeBSD (was it still 1.5 or some 2.x?) for the company I worked for in the 1990s (Point-of-Sale applications). Unfortunately, that system was never sold nor could it be released as open source. There was no official FreeBSD thread support then. Later official solutions were always wanting in functionality or performance. I think in FreeBSD 6 there are not less than three different implementations, all of which have some advantages and disadvantages. But M3 threads were always much faster than any of the FreeBSD libraries. I think the situation may have got better in FreeBSD 7, but I haven't really tried that. >> I think if possible "M3 user threads" should definitely be the >> default on FreeBSD4 and earlier, rather than "system user threads". > > Fair enough. Old thread libraries were pretty substandard. Indeed. And that's exactly why I'm still a `fan' of the M3 threads and think they should not be abandoned and be available for certain applications. Sorry, I couldn't resist to comment on this again :-) I'll return to serious work now and will not feed the M3 mail flood (which is really a good thing as it shows the interest and activity) any more, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 30 10:58:58 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 30 Apr 2009 01:58:58 -0700 Subject: [M3devel] user threads In-Reply-To: Your message of "Wed, 29 Apr 2009 07:05:10 -0000." Message-ID: <200904300858.n3U8wwAM078186@camembert.async.caltech.edu> I have to re-build everything again? It segfaults on my 5.5 system with that change. Btw, here are timings on FreeBSD 5.5 libc_r 1642 ms pthread 1646 ms PM3 504 ms Roughly the same program as before. Slightly different hardware (AM2 I think). Mika Jay writes: >--_57af40c5-3867-4a47-915e-00f808c2e343_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Mika=2C thanks. Want to try the next variation? look at m3-libs/m3core/src/= >thread/PTHREAD/ThreadPThreadC.c. > >See THREAD_LOCAL=2C THREAD_LOCAL_SLOW=2C THREAD_LOCAL_FAST? Try switching T= >HREAD_LOCAL to use THREAD_LOCAL_FAST instead of _SLOW. On FreeBSD 5.x or ne= >wer. > >It won't compile for 4.x we know. > >=20 > >Thanks=2C > > - Jay > >=20 >> To: jay.krell at cornell.edu >> Date: Tue=2C 28 Apr 2009 23:53:32 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] user threads >>=20 >> Ok=2C it works! >>=20 >> Numbers: >>=20 >> Timings in milliseconds=2C three samples=2C filesystem "warmed up" by >> doing one dummy run before launching the real ones. >>=20 >> -unsafe means that I use non-locking Scheme environments=2C otherwise >> they lock for every variable update. >> ave=20 >> CM3 last week=2C kernel threads=2C -unsafe 1460 1482 1437 1460 >> CM3 last week=2C kernel threads=2C 2392 2402 2376 2390 >> CM3 this week=2C kernel threads=2C -unsafe 1455 1458 1490 1468 (*) >> CM3 this week=2C user threads=2C -unsafe 914 934 914 921 >> CM3 this week=2C user threads=2C 967 965 986 973 >> PM3 -unsafe 678 657 682 672 >> PM3 709 714 700 708 >>=20 >> (*) not entirely sure this got linked correctly. >>=20 >> Mika >>=20 >>=20 >> Jay writes: >> > >> >User threads seem to work on on FreeBSD/x86 7.0. >> >Mika can you report back the perf cm3 vs. pm3? >> >Still=2C kernel threads have been around a long time and imho should be = >strongly favored.. >> >=20 >> >=20 >> >Kernel threads should be a /little/ faster than they were -- PushEFrame = >removed from successful heap allocations. And should be further improvable = >via __thread where it is supported -- probably not FreeBSD 4. >> >x=2C sometimes older is not better. :) >> >=20 >> >=20 >> >I've temporarily switched FreeBSD/x86 to userthreads by default but I th= >ink that's just an experiment and should be undone shortly=2C maybe work ou= >t some other story for easily switching between them=2C or just k >> >eep the existing story of "you get to rebuild everything". >> >=20 >> >=20 >> >Tony=2C can you look into GetGCRatio? I removed the call to it. The "fat= >al" pragma invokes PushEFrame apparently. >> >=20 >> >=20 >> >We should now "fix" Win32 and pthreads to not have GetActivation initial= >ize on-demand=2C just leave Init to initialize always. This should shave a = >few more cycles from PushEFrame. >> >=20 >> >=20 >> > - Jay > >--_57af40c5-3867-4a47-915e-00f808c2e343_ >Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > > > > > >Mika=2C =3Bthanks. Want to try the next variation? look at m3-libs/m3co= >re/src/thread/PTHREAD/ThreadPThreadC.c.
>See THREAD_LOCAL=2C THREAD_LOCAL_SLOW=2C THREAD_LOCAL_FAST? Try switching T= >HREAD_LOCAL to use THREAD_LOCAL_FAST instead of _SLOW. On FreeBSD 5.x or&nb= >sp=3Bnewer.
>It won't compile for 4.x we know.
> =3B
>Thanks=2C
> =3B- Jay

 =3B
>=3B To: jay.krell at cornell.edu
>=3B= > Date: Tue=2C 28 Apr 2009 23:53:32 -0700
>=3B From: mika at async.caltech= >.edu
>=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] u= >ser threads
>=3B
>=3B Ok=2C it works!
>=3B
>=3B Numbe= >rs:
>=3B
>=3B Timings in milliseconds=2C three samples=2C filesy= >stem "warmed up" by
>=3B doing one dummy run before launching the real= > ones.
>=3B
>=3B -unsafe means that I use non-locking Scheme env= >ironments=2C otherwise
>=3B they lock for every variable update.
&g= >t=3B ave
>=3B CM3 last week=2C kernel threads=2C -unsafe 1460 1482 14= >37 1460
>=3B CM3 last week=2C kernel threads=2C 2392 2402 2376 2390>>=3B CM3 this week=2C kernel threads=2C -unsafe 1455 1458 1490 1468 (*)<= >BR>>=3B CM3 this week=2C user threads=2C -unsafe 914 934 914 921
>= >=3B CM3 this week=2C user threads=2C 967 965 986 973
>=3B PM3 -unsafe = >678 657 682 672
>=3B PM3 709 714 700 708
>=3B
>=3B (*) not = >entirely sure this got linked correctly.
>=3B
>=3B Mika
>= >=3B
>=3B
>=3B Jay writes:
>=3B >=3B
>=3B >=3BUser= > threads seem to work on on FreeBSD/x86 7.0.
>=3B >=3BMika can you r= >eport back the perf cm3 vs. pm3?
>=3B >=3BStill=2C kernel threads ha= >ve been around a long time and imho should be strongly favored..
>=3B = >>=3B
>=3B >=3B
>=3B >=3BKernel threads should be a /littl= >e/ faster than they were -- PushEFrame removed from successful heap allocat= >ions. And should be further improvable via __thread where it is supported -= >- probably not FreeBSD 4.
>=3B >=3Bx=2C sometimes older is not bette= >r. :)
>=3B >=3B
>=3B >=3B
>=3B >=3BI've temporarily = >switched FreeBSD/x86 to userthreads by default but I think that's just an e= >xperiment and should be undone shortly=2C maybe work out some other story f= >or easily switching between them=2C or just k
>=3B >=3Beep the exist= >ing story of "you get to rebuild everything".
>=3B >=3B
>=3B &= >gt=3B
>=3B >=3BTony=2C can you look into GetGCRatio? I removed the = >call to it. The "fatal" pragma invokes PushEFrame apparently.
>=3B >= >=3B
>=3B >=3B
>=3B >=3BWe should now "fix" Win32 and pthrea= >ds to not have GetActivation initialize on-demand=2C just leave Init to ini= >tialize always. This should shave a few more cycles from PushEFrame.
>= >=3B >=3B
>=3B >=3B
>=3B >=3B - Jay
>= > >--_57af40c5-3867-4a47-915e-00f808c2e343_-- From wagner at elegosoft.com Thu Apr 30 11:05:15 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Apr 2009 11:05:15 +0200 Subject: [M3devel] [M3commit] how to switch userthreads on/off In-Reply-To: References: Your message of "Wed, 29 Apr 2009 00:06:02 -0000." <200904290622.n3T6MZBR003219@camembert.async.caltech.edu> Message-ID: <20090430110515.lnlfuu02v4sso0wo@mail.elegosoft.com> Quoting Jay : > Olaf, your recall that FreeBSD userthreads were "fast"..is that > based on FreeBSD 4.x by chance? Maybe they don't have much advantage > on any other system? > > You know...FreeBSD 4.x pthreads are also userthreads, not really a > fair comparison maybe with other pthreads implementations and maybe > give pthreads a bad name? I'm afraid I cannot provide any exact numbers or test results any more, so the validity of all my comments must be treated very carefully. AFAIR M3 user threads on FreeBSD were fast compared to the system implementation of pthreads even in 4.x. FreeBSD system threads that are `real' kernel threads were introduced later, when the system was incrementally made ready for multi-CPU-support. I think this change has not been completed until 7.0. (All systems after 4.x were much less stable due to this transition.). One of the bottlenecks _may_ have been the malloc implementation. The FreeBSD pthreads implementation in 4.x were indeed user-level threads, but they were not very performant compared to what would have been possible IIRC. There was also an implementation which used process structures as threads ported from Linux (known as Linux-threads). Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 30 11:18:47 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Apr 2009 11:18:47 +0200 Subject: [M3devel] any limitations on __thread? In-Reply-To: References: Message-ID: <20090430111847.0vqnqf8yrs4gkkw4@mail.elegosoft.com> Quoting Jay : > > Anyone have expertise on __thread? > In particular, on Windows there is a close analog __declspec(thread) > that generally would seem to work and work well, except that, per > documentation, prior to Vista, it doesn't work if you are loaded > with LoadLibrary (dlopen), only if the main executable uses your > .so, directly or indirectly. To me that's a pretty big limitation so > I wouldn't use it. I haven't seen any documentation on __thread > giving this caveat though so it seems ok to use. > > I changed m3core to use it if sample code seems to compile, link, > and execute correctly with it. This is done at installation time, I assume? Where is this test located? > > > - 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 Thu Apr 30 12:14:47 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 30 Apr 2009 03:14:47 -0700 Subject: [M3devel] any limitations on __thread? In-Reply-To: <20090430111847.0vqnqf8yrs4gkkw4@mail.elegosoft.com> References: <20090430111847.0vqnqf8yrs4gkkw4@mail.elegosoft.com> Message-ID: <454BD710-4008-4045-B7EB-EF76D823BD49@hotmail.com> It was to be done every time building m3core. Fast enough. I removed it for now. Pic makes it a smaller win, I have no numbers, and broke Tony's build. It would also reduce but not eliminate leak upon dynamic unload, which we should consider anyway. It was in m3core/src/thread/pthread/m3makefile. - Jay (phone) On Apr 30, 2009, at 2:18 AM, Olaf Wagner wrote: > Quoting Jay : > >> >> Anyone have expertise on __thread? >> In particular, on Windows there is a close analog >> __declspec(thread) that generally would seem to work and work >> well, except that, per documentation, prior to Vista, it doesn't >> work if you are loaded with LoadLibrary (dlopen), only if the main >> executable uses your .so, directly or indirectly. To me that's a >> pretty big limitation so I wouldn't use it. I haven't seen any >> documentation on __thread giving this caveat though so it seems ok >> to use. >> >> I changed m3core to use it if sample code seems to compile, link, >> and execute correctly with it. > > This is done at installation time, I assume? > Where is this test located? > >> >> >> - 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 Thu Apr 30 12:17:58 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 30 Apr 2009 03:17:58 -0700 Subject: [M3devel] user threads In-Reply-To: <200904300858.n3U8wwAM078186@camembert.async.caltech.edu> References: <200904300858.n3U8wwAM078186@camembert.async.caltech.edu> Message-ID: <840816F3-68FF-4B8B-A52A-2B6ED8A8BBB1@hotmail.com> No need for clean here. Lets punt threads for now and look at typecase. - Jay (phone) On Apr 30, 2009, at 1:58 AM, Mika Nystrom wrote: > I have to re-build everything again? It segfaults on my 5.5 system > with that > change. > > Btw, here are timings on FreeBSD 5.5 > > libc_r 1642 ms > pthread 1646 ms > PM3 504 ms > > Roughly the same program as before. Slightly different hardware > (AM2 I think). > > Mika > > Jay writes: >> --_57af40c5-3867-4a47-915e-00f808c2e343_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> Mika=2C thanks. Want to try the next variation? look at m3-libs/ >> m3core/src/= >> thread/PTHREAD/ThreadPThreadC.c. >> >> See THREAD_LOCAL=2C THREAD_LOCAL_SLOW=2C THREAD_LOCAL_FAST? Try >> switching T= >> HREAD_LOCAL to use THREAD_LOCAL_FAST instead of _SLOW. On FreeBSD >> 5.x or ne= >> wer. >> >> It won't compile for 4.x we know. >> >> =20 >> >> Thanks=2C >> >> - Jay >> >> =20 >>> To: jay.krell at cornell.edu >>> Date: Tue=2C 28 Apr 2009 23:53:32 -0700 >>> From: mika at async.caltech.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] user threads >>> =20 >>> Ok=2C it works! >>> =20 >>> Numbers: >>> =20 >>> Timings in milliseconds=2C three samples=2C filesystem "warmed up" >>> by >>> doing one dummy run before launching the real ones. >>> =20 >>> -unsafe means that I use non-locking Scheme environments=2C >>> otherwise >>> they lock for every variable update. >>> ave=20 >>> CM3 last week=2C kernel threads=2C -unsafe 1460 1482 1437 1460 >>> CM3 last week=2C kernel threads=2C 2392 2402 2376 2390 >>> CM3 this week=2C kernel threads=2C -unsafe 1455 1458 1490 1468 (*) >>> CM3 this week=2C user threads=2C -unsafe 914 934 914 921 >>> CM3 this week=2C user threads=2C 967 965 986 973 >>> PM3 -unsafe 678 657 682 672 >>> PM3 709 714 700 708 >>> =20 >>> (*) not entirely sure this got linked correctly. >>> =20 >>> Mika >>> =20 >>> =20 >>> Jay writes: >>>> >>>> User threads seem to work on on FreeBSD/x86 7.0. >>>> Mika can you report back the perf cm3 vs. pm3? >>>> Still=2C kernel threads have been around a long time and imho >>>> should be = >> strongly favored.. >>>> =20 >>>> =20 >>>> Kernel threads should be a /little/ faster than they were -- >>>> PushEFrame = >> removed from successful heap allocations. And should be further >> improvable = >> via __thread where it is supported -- probably not FreeBSD 4. >>>> x=2C sometimes older is not better. :) >>>> =20 >>>> =20 >>>> I've temporarily switched FreeBSD/x86 to userthreads by default >>>> but I th= >> ink that's just an experiment and should be undone shortly=2C maybe >> work ou= >> t some other story for easily switching between them=2C or just k >>>> eep the existing story of "you get to rebuild everything". >>>> =20 >>>> =20 >>>> Tony=2C can you look into GetGCRatio? I removed the call to it. >>>> The "fat= >> al" pragma invokes PushEFrame apparently. >>>> =20 >>>> =20 >>>> We should now "fix" Win32 and pthreads to not have GetActivation >>>> initial= >> ize on-demand=2C just leave Init to initialize always. This should >> shave a = >> few more cycles from PushEFrame. >>>> =20 >>>> =20 >>>> - Jay >> >> --_57af40c5-3867-4a47-915e-00f808c2e343_ >> Content-Type: text/html; charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable >> >> >> >> >> >> >> Mika=2C =3Bthanks. Want to try the next variation? look at m3- >> libs/m3co= >> re/src/thread/PTHREAD/ThreadPThreadC.c.
>> See THREAD_LOCAL=2C THREAD_LOCAL_SLOW=2C THREAD_LOCAL_FAST? Try >> switching T= >> HREAD_LOCAL to use THREAD_LOCAL_FAST instead of _SLOW. On FreeBSD >> 5.x or&nb= >> sp=3Bnewer.
>> It won't compile for 4.x we know.
>>  =3B
>> Thanks=2C
>>  =3B- Jay

 =3B
>=3B To: >> jay.krell at cornell.edu
>=3B= >> Date: Tue=2C 28 Apr 2009 23:53:32 -0700
>=3B From: mika at async.caltech >> = >> .edu
>=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: >> [M3devel] u= >> ser threads
>=3B
>=3B Ok=2C it works!
>=3B >>
>=3B Numbe= >> rs:
>=3B
>=3B Timings in milliseconds=2C three >> samples=2C filesy= >> stem "warmed up" by
>=3B doing one dummy run before launching >> the real= >> ones.
>=3B
>=3B -unsafe means that I use non-locking >> Scheme env= >> ironments=2C otherwise
>=3B they lock for every variable >> update.
&g= >> t=3B ave
>=3B CM3 last week=2C kernel threads=2C -unsafe 1460 1482 14 >> = >> 37 1460
>=3B CM3 last week=2C kernel threads=2C 2392 2402 2376 >> 2390>> >=3B CM3 this week=2C kernel threads=2C -unsafe 1455 1458 1490 >>> 1468 (*)<= >> BR>>=3B CM3 this week=2C user threads=2C -unsafe 914 934 914 >> 921
>= >> =3B CM3 this week=2C user threads=2C 967 965 986 973
>=3B PM3 - >> unsafe = >> 678 657 682 672
>=3B PM3 709 714 700 708
>=3B
>=3B >> (*) not = >> entirely sure this got linked correctly.
>=3B
>=3B >> Mika
>= >> =3B
>=3B
>=3B Jay writes:
>=3B >=3B
>=3B >> >=3BUser= >> threads seem to work on on FreeBSD/x86 7.0.
>=3B >=3BMika >> can you r= >> eport back the perf cm3 vs. pm3?
>=3B >=3BStill=2C kernel >> threads ha= >> ve been around a long time and imho should be strongly >> favored..
>=3B = >> >=3B
>=3B >=3B
>=3B >=3BKernel threads should be >> a /littl= >> e/ faster than they were -- PushEFrame removed from successful heap >> allocat= >> ions. And should be further improvable via __thread where it is >> supported -= >> - probably not FreeBSD 4.
>=3B >=3Bx=2C sometimes older is >> not bette= >> r. :)
>=3B >=3B
>=3B >=3B
>=3B >=3BI've >> temporarily = >> switched FreeBSD/x86 to userthreads by default but I think that's >> just an e= >> xperiment and should be undone shortly=2C maybe work out some other >> story f= >> or easily switching between them=2C or just k
>=3B >=3Beep >> the exist= >> ing story of "you get to rebuild everything".
>=3B >=3B >>
>=3B &= >> gt=3B
>=3B >=3BTony=2C can you look into GetGCRatio? I >> removed the = >> call to it. The "fatal" pragma invokes PushEFrame >> apparently.
>=3B >= >> =3B
>=3B >=3B
>=3B >=3BWe should now "fix" Win32 >> and pthrea= >> ds to not have GetActivation initialize on-demand=2C just leave >> Init to ini= >> tialize always. This should shave a few more cycles from >> PushEFrame.
>= >> =3B >=3B
>=3B >=3B
>=3B >=3B - Jay
>> = >> >> --_57af40c5-3867-4a47-915e-00f808c2e343_-- > From hosking at cs.purdue.edu Thu Apr 30 19:35:23 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 1 May 2009 03:35:23 +1000 Subject: [M3devel] Fwd: Output from "cron" command References: <200904301321.n3UDL5s4029847@niagara.cs.purdue.edu> Message-ID: Something is still broken with builds on SOLgnu: Begin forwarded message: > From: Tony Hosking > Date: 30 April 2009 23:21:05 GMT+10:00 > To: hosking at cs.purdue.edu > Subject: Output from "cron" command > > Your "cron" job on niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/cron.sh > > produced the following output: > > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-04-30-10-30-04 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSUSER= > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara release-build" > > creating log file /tmp/build-cm3-20090430-063006-xlaG7T/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.04.30 06:30:06 -- checkout in progress. > [start checkout 2009.04.30 06:30:09] > cd /tmp/build-cm3-20090430-063006-xlaG7T/build > cvs return value: 0 > [end checkout 2009.04.30 06:49:48] > CHECKOUT_RETURN = 0 > -- > 2009.04.30 06:49:51 -- compile in progress. > [start compile 2009.04.30 06:49:51] > compile return value: 0 > [end compile 2009.04.30 08:10:52] > COMPILE_RETURN = 1 > *** COMPILE FAILED > removing build tree /tmp/build-cm3-20090430-063006-xlaG7T ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-04-30-12-12-43 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSUSER= > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" > > creating log file /tmp/build-cm3-20090430-081245-KRaGZ0/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.04.30 08:12:45 -- checkout in progress. > [start checkout 2009.04.30 08:12:47] > cd /tmp/build-cm3-20090430-081245-KRaGZ0/build > cvs return value: 0 > [end checkout 2009.04.30 08:32:38] > CHECKOUT_RETURN = 0 > -- > 2009.04.30 08:32:41 -- compile in progress. > [start compile 2009.04.30 08:32:41] > compile return value: 0 > [end compile 2009.04.30 09:19:11] > COMPILE_RETURN = 0 > 2009.04.30 09:19:15 -- tests in progress. > [start run-tests 2009.04.30 09:19:15] > cd /tmp/build-cm3-20090430-081245-KRaGZ0/build > [end run-tests 2009.04.30 09:19:15] > TESTS_RETURN = 0 > 2009.04.30 09:19:15 -- checkout, compile and test run done. > > --- > > removing build tree /tmp/build-cm3-20090430-081245-KRaGZ0 ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > done. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Apr 1 00:03:50 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 01 Apr 2009 00:03:50 +0200 Subject: [M3devel] m3 CVS? In-Reply-To: <47E57322-28FD-4C9E-B1FE-12761C6F32AB@cs.purdue.edu> References: <20090325135234.GA16351@topoi.pooq.com> <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> <20090325144505.GA16526@topoi.pooq.com> <20090325225421.GB17118@topoi.pooq.com> <20090330131918.GA6921@topoi.pooq.com> <20090331133910.flci659jockgo04c@mail.elegosoft.com> <20090331135610.GA9539@topoi.pooq.com> <20090331161908.3pferzf9c08oso40@mail.elegosoft.com> <20090331144252.GA9624@topoi.pooq.com> <20090331173542.60xixsbl4w4kcsgs@mail.elegosoft.com> <47E57322-28FD-4C9E-B1FE-12761C6F32AB@cs.purdue.edu> Message-ID: <20090401000350.9ulc6eobpk44coo0@mail.elegosoft.com> Quoting Tony Hosking : > Both PM3 and CM3 forked from SRC M3. Yes, the releases both built on the SRC source, but as far as I know there was never one repository where the history was combined. Olaf > On 1 Apr 2009, at 02:35, Olaf Wagner wrote: > >> Quoting hendrik at topoi.pooq.com: >> >>> Speaking of ancient history -- Are cm3 and pm3 both in one CVS so that >>> they share history? Or are they in separate CVS's? >> >> CM3 and PM3 are two separate repositories. SRC never used CVS for M3 >> version control (don't exactly know how they did managed the sources). >> PM3 was created by Michel Dagenais as an open source continuation of >> SRC M3, while CM3 started as a commercial product and was later open >> sourced. >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Wed Apr 1 00:38:59 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 31 Mar 2009 18:38:59 -0400 Subject: [M3devel] m3 CVS? In-Reply-To: <20090401000350.9ulc6eobpk44coo0@mail.elegosoft.com> References: <20090325225421.GB17118@topoi.pooq.com> <20090330131918.GA6921@topoi.pooq.com> <20090331133910.flci659jockgo04c@mail.elegosoft.com> <20090331135610.GA9539@topoi.pooq.com> <20090331161908.3pferzf9c08oso40@mail.elegosoft.com> <20090331144252.GA9624@topoi.pooq.com> <20090331173542.60xixsbl4w4kcsgs@mail.elegosoft.com> <47E57322-28FD-4C9E-B1FE-12761C6F32AB@cs.purdue.edu> <20090401000350.9ulc6eobpk44coo0@mail.elegosoft.com> Message-ID: <20090331223859.GC10145@topoi.pooq.com> On Wed, Apr 01, 2009 at 12:03:50AM +0200, Olaf Wagner wrote: > Quoting Tony Hosking : > > >Both PM3 and CM3 forked from SRC M3. > > Yes, the releases both built on the SRC source, but as far as I know > there was never one repository where the history was combined. > > Olaf I suspect combining them would be more work than it's worth. And only feasible if the SRC source both forked from is still in existence. But tempting. -- hendrik From jay.krell at cornell.edu Wed Apr 1 00:41:42 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 31 Mar 2009 22:41:42 +0000 Subject: [M3devel] m3 CVS? In-Reply-To: <20090331161908.3pferzf9c08oso40@mail.elegosoft.com> References: <20090325083158.hkinn8yjkksocw4c@mail.elegosoft.com> <20090325135234.GA16351@topoi.pooq.com> <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> <20090325144505.GA16526@topoi.pooq.com> <20090325225421.GB17118@topoi.pooq.com> <20090330131918.GA6921@topoi.pooq.com> <20090331133910.flci659jockgo04c@mail.elegosoft.com> <20090331135610.GA9539@topoi.pooq.com> <20090331161908.3pferzf9c08oso40@mail.elegosoft.com> Message-ID: Also, presumably you can copy the entire CVS repository with little CPU use and then do the monotone work locally. I doubt it is all that large, can tell you later.. (ssh in and du /usr/cvs) - Jay > Date: Tue, 31 Mar 2009 16:19:08 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > CC: manderson at elego.de > Subject: Re: [M3devel] m3 CVS? > > Quoting hendrik at topoi.pooq.com: > > > On Tue, Mar 31, 2009 at 01:39:10PM +0200, Olaf Wagner wrote: > >> Quoting hendrik at topoi.pooq.com: > >> > >> >Is CVS back up yet? Completely? I've been delaying trying the > >> >monotone conversion because it would be nice to have only one set > >> >of problems to look into. > >> > >> CVS is up and no history should be lost, but tinderbox is still not > >> working and several archives are missing. Michael is working on it > >> (but he's got some other tasks, too). > > > > So the current source is available, but not the tools to investigate > > their status on-line. And the other archives? What are they? Are they > > more source code? Should they be subject to revision control too? Are > > they ancient prehistory that should be grafted into the revision tree > > except that it may not be technically feasible? > > Mostly all the old installation archives and snapshots are still missing. > I'm not sure what's the status of the re-installation of tinderbox. > > > Ah. I have too many questions. > > > > By the way, rumours are that monotone's cvs pull command is quite > > demanding on the cvs server, but that sync operation isn't bad at all > > after that. Getting really old versions of files requires CVS to chain > > back through a lot of reverse differences. And I don't know if it > > caches any of that in case it is asked to cough up another really old > > version. > > > > If there are any scheduling considerations I'd like to hear them. I > > don't know if I'll flatten your system, but if I do there are probably > > better and worse times to do it. (I may saturate ny DSL link first, but > > you never know until you try it.) > > > > By the way, what's the total size of Modula 3's CVS archive? > > I've got no access from here (can only check later tonight); please > ask Michael Anderson directly for administrative topics. > > Olaf > > PS: I don't think you can bring the server down a one external CVS > client; the syncing will just take a long time. Unless lots of parallel > requests are started... > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 1 00:43:41 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 31 Mar 2009 22:43:41 +0000 Subject: [M3devel] m3 CVS? In-Reply-To: <20090331223859.GC10145@topoi.pooq.com> References: <20090325225421.GB17118@topoi.pooq.com> <20090330131918.GA6921@topoi.pooq.com> <20090331133910.flci659jockgo04c@mail.elegosoft.com> <20090331135610.GA9539@topoi.pooq.com> <20090331161908.3pferzf9c08oso40@mail.elegosoft.com> <20090331144252.GA9624@topoi.pooq.com> <20090331173542.60xixsbl4w4kcsgs@mail.elegosoft.com> <47E57322-28FD-4C9E-B1FE-12761C6F32AB@cs.purdue.edu> <20090401000350.9ulc6eobpk44coo0@mail.elegosoft.com> <20090331223859.GC10145@topoi.pooq.com> Message-ID: > And only feasible if the SRC source both forked from is still in existence. The SRC 3.6 release is certainly available, not sure if that is what they forked from. I do wonder: - Does PM3 have anything we should salvage? Unknown. - Does ezm3? - Is CM3 the one true Modula-3? I guess not. Or at least the "best" by far and the only one worth working on? I think so. - Jay > Date: Tue, 31 Mar 2009 18:38:59 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3 CVS? > > On Wed, Apr 01, 2009 at 12:03:50AM +0200, Olaf Wagner wrote: > > Quoting Tony Hosking : > > > > >Both PM3 and CM3 forked from SRC M3. > > > > Yes, the releases both built on the SRC source, but as far as I know > > there was never one repository where the history was combined. > > > > Olaf > > I suspect combining them would be more work than it's worth. And only > feasible if the SRC source both forked from is still in existence. > > But tempting. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 1 00:38:35 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 31 Mar 2009 22:38:35 +0000 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: <49D2807D.7010100@bellsouth.net> References: <200903311842.n2VIg6LS046075@camembert.async.caltech.edu> <49D2807D.7010100@bellsouth.net> Message-ID: http://modula3.elegosoft.com/cm3/uploaded-archives ? I can make another later this week. All you need is a working cm3 on any system. >From there you can build the whole system, targeting any system. As long as that cm3 understands LONGINT and your target system. And it is easier, but not necessary, if you have Python. :) - Jay > Date: Tue, 31 Mar 2009 15:43:41 -0500 > From: martinbishop at bellsouth.net > To: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Help finding CM3 compiler for Linux? > > Not sure if this helps, but on my linux system: > > Critical Mass Modula-3 version d5.7.0 > last updated: 2008-03-16 > compiled: 2008-08-14 00:56:14 > configuration: /usr/local/cm3/bin/cm3.cfg > > Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 > i686 GNU/Linux > > > I don't have the cm3 tarball, but I do have the sources in cm3/ still. > > Mika Nystrom wrote: > > Hello everyone, > > > > This is, for me, a most unfortunate time for the CM3 servers to > > have crashed. I'm teaching a class using Modula-3, and we need a > > compiler... here's the uname of the system I'm trying to use: > > > > Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Linux > > > > The most recent archives I have for Linux are: > > > > cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz > > > > And they don't seem to work on this system: I can compile a program > > but when I try to run it, it says "Segmentation fault". Can anyone > > help? (My understanding is that I need 5.5.1 or later...) > > > > Mika > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Apr 1 00:46:59 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 31 Mar 2009 15:46:59 -0700 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: Your message of "Tue, 31 Mar 2009 22:38:35 -0000." Message-ID: <200903312246.n2VMkxml055400@camembert.async.caltech.edu> Aaaah it works now.. or was I looking in the wrong place earlier? (I was getting only broken links.) Thanks to everyone who offered to help! Jay writes: >--_806446ae-8d10-4d74-8eea-51aa365e9204_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > http://modula3.elegosoft.com/cm3/uploaded-archives > >? > >=20 > >I can make another later this week. > >=20 > >All you need is a working cm3 on any system. > >>From there you can build the whole system=2C targeting any system. > >As long as that cm3 understands LONGINT and your target system. > >And it is easier=2C but not necessary=2C if you have Python. :) > >=20 > > - Jay > >=20 >> Date: Tue=2C 31 Mar 2009 15:43:41 -0500 >> From: martinbishop at bellsouth.net >> To: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >>=20 >> Not sure if this helps=2C but on my linux system: >>=20 >> Critical Mass Modula-3 version d5.7.0 >> last updated: 2008-03-16 >> compiled: 2008-08-14 00:56:14 >> configuration: /usr/local/cm3/bin/cm3.cfg >>=20 >> Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 >> i686 GNU/Linux >>=20 >>=20 >> I don't have the cm3 tarball=2C but I do have the sources in cm3/ still. >>=20 >> Mika Nystrom wrote: >> > Hello everyone=2C >> >=20 >> > This is=2C for me=2C a most unfortunate time for the CM3 servers to >> > have crashed. I'm teaching a class using Modula-3=2C and we need a >> > compiler... here's the uname of the system I'm trying to use: >> >=20 >> > Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Lin= >ux >> >=20 >> > The most recent archives I have for Linux are: >> >=20 >> > cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=20 >> >=20 >> > And they don't seem to work on this system: I can compile a program >> > but when I try to run it=2C it says "Segmentation fault". Can anyone >> > help? (My understanding is that I need 5.5.1 or later...) >> >=20 >> > Mika >> >=20 >>=20 > >--_806446ae-8d10-4d74-8eea-51aa365e9204_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > > =3Bet=3D_blank>http://modula3.elegosoft.com/cm3/uploaded= >-archives
>?
> =3B
>I can make another later this week.
> =3B
>All you need is a working cm3 on any system.
>>From there you can build the whole system=2C targeting any system.
>As long as that cm3 understands LONGINT and your target system.
>And it is easier=2C but not necessary=2C if you have Python. :)
> =3B
> =3B- Jay

 =3B
>=3B Date: Tue=2C 31 Mar 2009 15:43:41 -= >0500
>=3B From: martinbishop at bellsouth.net
>=3B To: mika at async.ca= >ltech.edu
>=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3dev= >el] Help finding CM3 compiler for Linux?
>=3B
>=3B Not sure if t= >his helps=2C but on my linux system:
>=3B
>=3B Critical Mass Mod= >ula-3 version d5.7.0
>=3B last updated: 2008-03-16
>=3B compiled:= > 2008-08-14 00:56:14
>=3B configuration: /usr/local/cm3/bin/cm3.cfg>>=3B
>=3B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24= >:39 UTC 2009
>=3B i686 GNU/Linux
>=3B
>=3B
>=3B I don= >'t have the cm3 tarball=2C but I do have the sources in cm3/ still.
>= >=3B
>=3B Mika Nystrom wrote:
>=3B >=3B Hello everyone=2C
&g= >t=3B >=3B
>=3B >=3B This is=2C for me=2C a most unfortunate time = >for the CM3 servers to
>=3B >=3B have crashed. I'm teaching a class = >using Modula-3=2C and we need a
>=3B >=3B compiler... here's the una= >me of the system I'm trying to use:
>=3B >=3B
>=3B >=3B Linu= >x lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Linux
&g= >t=3B >=3B
>=3B >=3B The most recent archives I have for Linux are= >:
>=3B >=3B
>=3B >=3B cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3= >-src-all-5.4.0.tgz
>=3B >=3B
>=3B >=3B And they don't seem = >to work on this system: I can compile a program
>=3B >=3B but when I= > try to run it=2C it says "Segmentation fault". Can anyone
>=3B >=3B= > help? (My understanding is that I need 5.5.1 or later...)
>=3B >=3B= >
>=3B >=3B Mika
>=3B >=3B
>=3B
>= > >--_806446ae-8d10-4d74-8eea-51aa365e9204_-- From hendrik at topoi.pooq.com Wed Apr 1 01:05:07 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 31 Mar 2009 19:05:07 -0400 Subject: [M3devel] m3 CVS? In-Reply-To: References: <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> <20090325144505.GA16526@topoi.pooq.com> <20090325225421.GB17118@topoi.pooq.com> <20090330131918.GA6921@topoi.pooq.com> <20090331133910.flci659jockgo04c@mail.elegosoft.com> <20090331135610.GA9539@topoi.pooq.com> <20090331161908.3pferzf9c08oso40@mail.elegosoft.com> Message-ID: <20090331230507.GA10261@topoi.pooq.com> On Tue, Mar 31, 2009 at 10:41:42PM +0000, Jay wrote: > > Also, presumably you can copy the entire CVS repository with little CPU use and then do the monotone work locally. I doubt it is all that large, can tell you later.. (ssh in and du /usr/cvs) That might be the way to go. My LAN is a hundred times faster than my connexion with the outside world. Not mention putting it on localhost or getting monotone to look at the cvs files directly (whichever it turns out to like). -- hendrik From hendrik at topoi.pooq.com Wed Apr 1 01:08:28 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 31 Mar 2009 19:08:28 -0400 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: <200903312259.n2VMxIQk055916@camembert.async.caltech.edu> References: <20090331214921.GA10145@topoi.pooq.com> <200903312259.n2VMxIQk055916@camembert.async.caltech.edu> Message-ID: <20090331230828.GB10261@topoi.pooq.com> On Tue, Mar 31, 2009 at 03:59:18PM -0700, Mika Nystrom wrote: > Yes you could try sending it to me somehow? Sorry.. I had an anon > ftp site but it seems to have succumbed to some sort of bit rot. > (If it's too big a hassle for you to send in an attachment or via > the web, let me know and I'll configure something...) > > You could also try uploading it to "rapidshare.com"? > > Any help is appreciated! > > Mika For the time being, there's a link to a copy of cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz near the bottonm of the web page http://hendrik.pooq.com/ -- hendrik From hosking at cs.purdue.edu Wed Apr 1 03:15:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 1 Apr 2009 12:15:29 +1100 Subject: [M3devel] m3 CVS? In-Reply-To: References: <20090325225421.GB17118@topoi.pooq.com> <20090330131918.GA6921@topoi.pooq.com> <20090331133910.flci659jockgo04c@mail.elegosoft.com> <20090331135610.GA9539@topoi.pooq.com> <20090331161908.3pferzf9c08oso40@mail.elegosoft.com> <20090331144252.GA9624@topoi.pooq.com> <20090331173542.60xixsbl4w4kcsgs@mail.elegosoft.com> <47E57322-28FD-4C9E-B1FE-12761C6F32AB@cs.purdue.edu> <20090401000350.9ulc6eobpk44coo0@mail.elegosoft.com> <20090331223859.GC10145@topoi.pooq.com> Message-ID: <51447406-6C71-4CC2-AEAB-EFFFAA139555@cs.purdue.edu> CM3 has evolved significantly beyond PM3. I switched over because PM3 was getting a little crusty. 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 1 Apr 2009, at 09:43, Jay wrote: > > And only feasible if the SRC source both forked from is still in > existence. > > The SRC 3.6 release is certainly available, not sure if that is what > they forked from. > > I do wonder: > - Does PM3 have anything we should salvage? Unknown. > - Does ezm3? > - Is CM3 the one true Modula-3? I guess not. > Or at least the "best" by far and the only one worth working > on? I think so. > > - Jay > > > > Date: Tue, 31 Mar 2009 18:38:59 -0400 > > From: hendrik at topoi.pooq.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] m3 CVS? > > > > On Wed, Apr 01, 2009 at 12:03:50AM +0200, Olaf Wagner wrote: > > > Quoting Tony Hosking : > > > > > > >Both PM3 and CM3 forked from SRC M3. > > > > > > Yes, the releases both built on the SRC source, but as far as I > know > > > there was never one repository where the history was combined. > > > > > > Olaf > > > > I suspect combining them would be more work than it's worth. And > only > > feasible if the SRC source both forked from is still in existence. > > > > But tempting. > > > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Apr 1 07:59:18 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 31 Mar 2009 22:59:18 -0700 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: Your message of "Wed, 01 Apr 2009 04:31:27 -0000." Message-ID: <200904010559.n315xIBx071256@camembert.async.caltech.edu> Is there any documentation for this format beyond what you just wrote? Where? terpsichore-14: cm3 --- building in ../LINUXLIBC6 --- new source -> compiling Main.m3 "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common", line 169: quake runtime error: undefined variable: ROOT --procedure-- -line- -file--- GetM3Back 169 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common _IsM3BackFlagSupported 181 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common IsM3BackFlagSupported 193 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common GetM3BackFlag 197 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common m3_backend 62 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common program -- 6 /afs/.ugcs.caltech.edu/user/mika/test/LINUXLIBC6/m3make.args Fatal Error: procedure "m3_backend" defined in "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3.cfg" failed. Jay writes: >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >These archives do have a different format=2C yes. > >But it isn't a bad format. > >cminstall is pretty worthless imho. > >Extract=2C rename=2C set PATH and LD_LIBRARY_PATH. > >=20 > > - Jay > >=20 >> To: jay.krell at cornell.edu >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux?=20 >> Date: Tue=2C 31 Mar 2009 15:56:11 -0700 >> From: mika at async.caltech.edu >>=20 >> No=2C I'm sorry... >>=20 >> the archives do not have the usual format. I'm expecting to unpack >> and run "cminstall" and then unpack the big source tar on top and=20 >> build that. But there's no cminstall in the archive on this page. >> This is "the normal procedure" for installing CM3=2C no? It's what >> the instructions say to do=2C as well... >>=20 >> And the link from the "Download" page is broken (to -d5.5.0.tgz). >>=20 >> Mika >>=20 >> Jay writes: >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> > http://modula3.elegosoft.com/cm3/uploaded-archives >> > >> >? >> > >> >=3D20 >> > >> >I can make another later this week. >> > >> >=3D20 >> > >> >All you need is a working cm3 on any system. >> > >> >>From there you can build the whole system=3D2C targeting any system. >> > >> >As long as that cm3 understands LONGINT and your target system. >> > >> >And it is easier=3D2C but not necessary=3D2C if you have Python. :) >> > >> >=3D20 >> > >> > - Jay >> > >> >=3D20 >> >> Date: Tue=3D2C 31 Mar 2009 15:43:41 -0500 >> >> From: martinbishop at bellsouth.net >> >> To: mika at async.caltech.edu >> >> CC: m3devel at elegosoft.com >> >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >> >>=3D20 >> >> Not sure if this helps=3D2C but on my linux system: >> >>=3D20 >> >> Critical Mass Modula-3 version d5.7.0 >> >> last updated: 2008-03-16 >> >> compiled: 2008-08-14 00:56:14 >> >> configuration: /usr/local/cm3/bin/cm3.cfg >> >>=3D20 >> >> Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 >> >> i686 GNU/Linux >> >>=3D20 >> >>=3D20 >> >> I don't have the cm3 tarball=3D2C but I do have the sources in cm3/ st= >ill. >> >>=3D20 >> >> Mika Nystrom wrote: >> >> > Hello everyone=3D2C >> >> >=3D20 >> >> > This is=3D2C for me=3D2C a most unfortunate time for the CM3 servers= > to >> >> > have crashed. I'm teaching a class using Modula-3=3D2C and we need a >> >> > compiler... here's the uname of the system I'm trying to use: >> >> >=3D20 >> >> > Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/= >Lin=3D >> >ux >> >> >=3D20 >> >> > The most recent archives I have for Linux are: >> >> >=3D20 >> >> > cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D20 >> >> >=3D20 >> >> > And they don't seem to work on this system: I can compile a program >> >> > but when I try to run it=3D2C it says "Segmentation fault". Can anyo= >ne >> >> > help? (My understanding is that I need 5.5.1 or later...) >> >> >=3D20 >> >> > Mika >> >> >=3D20 >> >>=3D20 >> > >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ >> >Content-Type: text/html=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> > >> > >> > >> > >> > =3D3Bs" targ=3D >> >et=3D3D_blank>http://modula3.elegosoft.com/cm3/u= >ploaded=3D >> >-archives
>> >?
>> > =3D3B
>> >I can make another later this week.
>> > =3D3B
>> >All you need is a working cm3 on any system.
>> >>From there you can build the whole system=3D2C targeting any system.> >> >As long as that cm3 understands LONGINT and your target system.
>> >And it is easier=3D2C but not necessary=3D2C if you have Python. :)
>> > =3D3B
>> > =3D3B- Jay

 =3D3B
>=3D3B Date: Tue=3D2C 31 Mar 2009= > 15:43:41 -=3D >> >0500
>=3D3B From: martinbishop at bellsouth.net
>=3D3B To: mika at a= >sync.ca=3D >> >ltech.edu
>=3D3B CC: m3devel at elegosoft.com
>=3D3B Subject: Re:= > [M3dev=3D >> >el] Help finding CM3 compiler for Linux?
>=3D3B
>=3D3B Not su= >re if t=3D >> >his helps=3D2C but on my linux system:
>=3D3B
>=3D3B Critical= > Mass Mod=3D >> >ula-3 version d5.7.0
>=3D3B last updated: 2008-03-16
>=3D3B co= >mpiled:=3D >> > 2008-08-14 00:56:14
>=3D3B configuration: /usr/local/cm3/bin/cm3.c= >fg> >>>=3D3B
>=3D3B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 2= >9 19:24=3D >> >:39 UTC 2009
>=3D3B i686 GNU/Linux
>=3D3B
>=3D3B
>= >=3D3B I don=3D >> >'t have the cm3 tarball=3D2C but I do have the sources in cm3/ still.>>=3D >> >=3D3B
>=3D3B Mika Nystrom wrote:
>=3D3B >=3D3B Hello everyo= >ne=3D2C
&g=3D >> >t=3D3B >=3D3B
>=3D3B >=3D3B This is=3D2C for me=3D2C a most un= >fortunate time =3D >> >for the CM3 servers to
>=3D3B >=3D3B have crashed. I'm teaching a= > class =3D >> >using Modula-3=3D2C and we need a
>=3D3B >=3D3B compiler... here'= >s the una=3D >> >me of the system I'm trying to use:
>=3D3B >=3D3B
>=3D3B &g= >t=3D3B Linu=3D >> >x lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Linux>&g=3D >> >t=3D3B >=3D3B
>=3D3B >=3D3B The most recent archives I have fo= >r Linux are=3D >> >:
>=3D3B >=3D3B
>=3D3B >=3D3B cm3-min-POSIX-LINUXLIBC6-5.= >4.0.tgz cm3=3D >> >-src-all-5.4.0.tgz
>=3D3B >=3D3B
>=3D3B >=3D3B And they = >don't seem =3D >> >to work on this system: I can compile a program
>=3D3B >=3D3B but= > when I=3D >> > try to run it=3D2C it says "Segmentation fault". Can anyone
>=3D3B= > >=3D3B=3D >> > help? (My understanding is that I need 5.5.1 or later...)
>=3D3B &= >gt=3D3B=3D >> >
>=3D3B >=3D3B Mika
>=3D3B >=3D3B
>=3D3B
> >> >=3D >> > >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_-- > >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >These archives do have a different format=2C yes.
>But it isn't a bad format.
>cminstall is pretty worthless imho.
>Extract=2C rename=2C set PATH and LD_LIBRARY_PATH.
> =3B
> =3B- Jay

 =3B
>=3B To: jay.krell at cornell.edu
>=3B= > Subject: Re: [M3devel] Help finding CM3 compiler for Linux?
>=3B Dat= >e: Tue=2C 31 Mar 2009 15:56:11 -0700
>=3B From: mika at async.caltech.edu= >
>=3B
>=3B No=2C I'm sorry...
>=3B
>=3B the archives = >do not have the usual format. I'm expecting to unpack
>=3B and run "cm= >install" and then unpack the big source tar on top and
>=3B build tha= >t. But there's no cminstall in the archive on this page.
>=3B This is = >"the normal procedure" for installing CM3=2C no? It's what
>=3B the in= >structions say to do=2C as well...
>=3B
>=3B And the link from t= >he "Download" page is broken (to -d5.5.0.tgz).
>=3B
>=3B Mika>>=3B
>=3B Jay writes:
>=3B >=3B--_806446ae-8d10-4d74-8eea-5= >1aa365e9204_
>=3B >=3BContent-Type: text/plain=3B charset=3D"iso-885= >9-1"
>=3B >=3BContent-Transfer-Encoding: quoted-printable
>=3B = >>=3B
>=3B >=3B
>=3B >=3B http://modula3.elegosoft.com/cm3/u= >ploaded-archives
>=3B >=3B
>=3B >=3B?
>=3B >=3B
>= >=3B >=3B=3D20
>=3B >=3B
>=3B >=3BI can make another later t= >his week.
>=3B >=3B
>=3B >=3B=3D20
>=3B >=3B
>=3B= > >=3BAll you need is a working cm3 on any system.
>=3B >=3B
>= >=3B >=3B>=3BFrom there you can build the whole system=3D2C targeting an= >y system.
>=3B >=3B
>=3B >=3BAs long as that cm3 understands = >LONGINT and your target system.
>=3B >=3B
>=3B >=3BAnd it is = >easier=3D2C but not necessary=3D2C if you have Python. :)
>=3B >=3B<= >BR>>=3B >=3B=3D20
>=3B >=3B
>=3B >=3B - Jay
>=3B >= >=3B
>=3B >=3B=3D20
>=3B >=3B>=3B Date: Tue=3D2C 31 Mar 2009= > 15:43:41 -0500
>=3B >=3B>=3B From: martinbishop at bellsouth.net
= >>=3B >=3B>=3B To: mika at async.caltech.edu
>=3B >=3B>=3B CC: m= >3devel at elegosoft.com
>=3B >=3B>=3B Subject: Re: [M3devel] Help fin= >ding CM3 compiler for Linux?
>=3B >=3B>=3B=3D20
>=3B >=3B&g= >t=3B Not sure if this helps=3D2C but on my linux system:
>=3B >=3B&g= >t=3B=3D20
>=3B >=3B>=3B Critical Mass Modula-3 version d5.7.0
&= >gt=3B >=3B>=3B last updated: 2008-03-16
>=3B >=3B>=3B compiled= >: 2008-08-14 00:56:14
>=3B >=3B>=3B configuration: /usr/local/cm3/= >bin/cm3.cfg
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B Linux thinkp= >ad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009
>=3B >=3B&g= >t=3B i686 GNU/Linux
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B=3D20= >
>=3B >=3B>=3B I don't have the cm3 tarball=3D2C but I do have the= > sources in cm3/ still.
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B = >Mika Nystrom wrote:
>=3B >=3B>=3B >=3B Hello everyone=3D2C
&g= >t=3B >=3B>=3B >=3B=3D20
>=3B >=3B>=3B >=3B This is=3D2C fo= >r me=3D2C a most unfortunate time for the CM3 servers to
>=3B >=3B&g= >t=3B >=3B have crashed. I'm teaching a class using Modula-3=3D2C and we n= >eed a
>=3B >=3B>=3B >=3B compiler... here's the uname of the sys= >tem I'm trying to use:
>=3B >=3B>=3B >=3B=3D20
>=3B >=3B&= >gt=3B >=3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i68= >6 GNU/Lin=3D
>=3B >=3Bux
>=3B >=3B>=3B >=3B=3D20
>= >=3B >=3B>=3B >=3B The most recent archives I have for Linux are:
&= >gt=3B >=3B>=3B >=3B=3D20
>=3B >=3B>=3B >=3B cm3-min-POSIX-= >LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D20
>=3B >=3B>=3B >= >=3B=3D20
>=3B >=3B>=3B >=3B And they don't seem to work on this = >system: I can compile a program
>=3B >=3B>=3B >=3B but when I tr= >y to run it=3D2C it says "Segmentation fault". Can anyone
>=3B >=3B&= >gt=3B >=3B help? (My understanding is that I need 5.5.1 or later...)
&= >gt=3B >=3B>=3B >=3B=3D20
>=3B >=3B>=3B >=3B Mika
>=3B= > >=3B>=3B >=3B=3D20
>=3B >=3B>=3B=3D20
>=3B >=3B
&= >gt=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>=3B >=3BConten= >t-Type: text/html=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfe= >r-Encoding: quoted-printable
>=3B >=3B
>=3B >=3B<=3Bhtml>= >=3B
>=3B >=3B<=3Bhead>=3B
>=3B >=3B<=3Bstyle>=3B
&= >gt=3B >=3B.hmmessage P
>=3B >=3B{
>=3B >=3Bmargin:0px=3D3B<= >BR>>=3B >=3Bpadding:0px
>=3B >=3B}
>=3B >=3Bbody.hmmessag= >e
>=3B >=3B{
>=3B >=3Bfont-size: 10pt=3D3B
>=3B >=3Bfo= >nt-family:Verdana
>=3B >=3B}
>=3B >=3B<=3B/style>=3B
&= >gt=3B >=3B<=3B/head>=3B
>=3B >=3B<=3Bbody class=3D3D'hmmessa= >ge'>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BA href=3D3D"http://modula3.= >elegosoft.com/cm3/uploaded-archives" targ=3D
>=3B >=3Bet=3D3D_blank&= >gt=3B<=3BFONT color=3D3D#0068cf>=3Bhttp://modula3.elegosoft.com/cm3/upl= >oaded=3D
>=3B >=3B-archives<=3B/FONT>=3B<=3B/A>=3B<=3BBR&g= >t=3B
>=3B >=3B?<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3B= >BR>=3B
>=3B >=3BI can make another later this week.<=3BBR>=3B<= >BR>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BAll you need= > is a working cm3 on any system.<=3BBR>=3B
>=3B >=3B>=3BFrom t= >here you can build the whole system=3D2C targeting any system.<=3BBR>= >=3B
>=3B >=3BAs long as that cm3 understands LONGINT and your target= > system.<=3BBR>=3B
>=3B >=3BAnd it is easier=3D2C but not necess= >ary=3D2C if you have Python. :)<=3BBR>=3B
>=3B >=3B&=3Bnbsp= >=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B- Jay<=3BBR>=3B<= >=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3B&=3Bgt=3D3B Date: Tue=3D2C 31 M= >ar 2009 15:43:41 -=3D
>=3B >=3B0500<=3BBR>=3B&=3Bgt=3D3B From= >: martinbishop at bellsouth.net<=3BBR>=3B&=3Bgt=3D3B To: mika at async.ca= >=3D
>=3B >=3Bltech.edu<=3BBR>=3B&=3Bgt=3D3B CC: m3devel at elego= >soft.com<=3BBR>=3B&=3Bgt=3D3B Subject: Re: [M3dev=3D
>=3B >= >=3Bel] Help finding CM3 compiler for Linux?<=3BBR>=3B&=3Bgt=3D3B <= >=3BBR>=3B&=3Bgt=3D3B Not sure if t=3D
>=3B >=3Bhis helps=3D2C b= >ut on my linux system:<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt= >=3D3B Critical Mass Mod=3D
>=3B >=3Bula-3 version d5.7.0<=3BBR>= >=3B&=3Bgt=3D3B last updated: 2008-03-16<=3BBR>=3B&=3Bgt=3D3B comp= >iled:=3D
>=3B >=3B 2008-08-14 00:56:14<=3BBR>=3B&=3Bgt=3D3B c= >onfiguration: /usr/local/cm3/bin/cm3.cfg<=3BBR=3D
>=3B >=3B>=3B&= >amp=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Linux thinkpad 2.6.27-11-generic= > #1 SMP Thu Jan 29 19:24=3D
>=3B >=3B:39 UTC 2009<=3BBR>=3B&= >=3Bgt=3D3B i686 GNU/Linux<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3B= >gt=3D3B <=3BBR>=3B&=3Bgt=3D3B I don=3D
>=3B >=3B't have the c= >m3 tarball=3D2C but I do have the sources in cm3/ still.<=3BBR>=3B&= >=3Bgt=3D
>=3B >=3B=3D3B <=3BBR>=3B&=3Bgt=3D3B Mika Nystrom wr= >ote:<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B Hello everyone=3D2C<=3BBR= >>=3B&=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B <=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B This is=3D2C for me=3D2C a most unfortunate time = >=3D
>=3B >=3Bfor the CM3 servers to<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B have crashed. I'm teaching a class =3D
>=3B >=3Busing Mod= >ula-3=3D2C and we need a<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B compile= >r... here's the una=3D
>=3B >=3Bme of the system I'm trying to use:&= >lt=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B &am= >p=3Bgt=3D3B Linu=3D
>=3B >=3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10= >:53:03 PST 2008 i686 GNU/Linux<=3BBR>=3B&=3Bg=3D
>=3B >=3Bt= >=3D3B &=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B The most r= >ecent archives I have for Linux are=3D
>=3B >=3B:<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B cm3-m= >in-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D
>=3B >=3B-src-all-5.4.0.tgz <= =3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B And they don't seem =3D
>=3B >=3Bto work on this system: = >I can compile a program<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B but when= > I=3D
>=3B >=3B try to run it=3D2C it says "Segmentation fault". Can= > anyone<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D
>=3B >=3B help= >? (My understanding is that I need 5.5.1 or later...)<=3BBR>=3B&=3Bg= >t=3D3B &=3Bgt=3D3B=3D
>=3B >=3B <=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B Mika<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B <=3BBR>=3B&a= >mp=3Bgt=3D3B <=3BBR>=3B<=3B/body>=3B
>=3B >=3B<=3B/html>= >=3B=3D
>=3B >=3B
>=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e= >9204_--
>= > >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_-- From jay.krell at cornell.edu Wed Apr 1 08:13:00 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Apr 2009 06:13:00 +0000 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: <200904010559.n315xIBx071256@camembert.async.caltech.edu> References: Your message of "Wed, 01 Apr 2009 04:31:27 -0000." <200904010559.n315xIBx071256@camembert.async.caltech.edu> Message-ID: Maybe not. Hm. That is bug. There is use with a cvs tree, and use without. I must have broken use without. Try this: export CM3_ROOT=root of cm3 cvs (for me this is /dev2/cm3, for you, maybe $HOME/cm3?) rm $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6 # *Common and *common in one command rm $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/*ommon cp root of cm3 cvs/m3-sys/cminstall/src/config/cm3.cfg $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin The .cfg will delegate out to the cvs tree. I don't like having two copies of files..having to keep them in sync.. Though the archives are meant to work standalone, without CVS. But I don't test that so much oops sorry. That /might/ not be the right file, but it is close. - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Help finding CM3 compiler for Linux? > Date: Tue, 31 Mar 2009 22:59:18 -0700 > From: mika at async.caltech.edu > > > Is there any documentation for this format beyond what you just > wrote? Where? > > terpsichore-14: cm3 > --- building in ../LINUXLIBC6 --- > > new source -> compiling Main.m3 > "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common", line 169: quake runtime error: undefined variable: ROOT > > --procedure-- -line- -file--- > GetM3Back 169 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common > _IsM3BackFlagSupported 181 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common > IsM3BackFlagSupported 193 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common > GetM3BackFlag 197 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common > m3_backend 62 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common > program -- > 6 /afs/.ugcs.caltech.edu/user/mika/test/LINUXLIBC6/m3make.args > > > Fatal Error: procedure "m3_backend" defined in "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3.cfg" failed. > > Jay writes: > >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >These archives do have a different format=2C yes. > > > >But it isn't a bad format. > > > >cminstall is pretty worthless imho. > > > >Extract=2C rename=2C set PATH and LD_LIBRARY_PATH. > > > >=20 > > > > - Jay > > > >=20 > >> To: jay.krell at cornell.edu > >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux?=20 > >> Date: Tue=2C 31 Mar 2009 15:56:11 -0700 > >> From: mika at async.caltech.edu > >>=20 > >> No=2C I'm sorry... > >>=20 > >> the archives do not have the usual format. I'm expecting to unpack > >> and run "cminstall" and then unpack the big source tar on top and=20 > >> build that. But there's no cminstall in the archive on this page. > >> This is "the normal procedure" for installing CM3=2C no? It's what > >> the instructions say to do=2C as well... > >>=20 > >> And the link from the "Download" page is broken (to -d5.5.0.tgz). > >>=20 > >> Mika > >>=20 > >> Jay writes: > >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ > >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> > http://modula3.elegosoft.com/cm3/uploaded-archives > >> > > >> >? > >> > > >> >=3D20 > >> > > >> >I can make another later this week. > >> > > >> >=3D20 > >> > > >> >All you need is a working cm3 on any system. > >> > > >> >>From there you can build the whole system=3D2C targeting any system. > >> > > >> >As long as that cm3 understands LONGINT and your target system. > >> > > >> >And it is easier=3D2C but not necessary=3D2C if you have Python. :) > >> > > >> >=3D20 > >> > > >> > - Jay > >> > > >> >=3D20 > >> >> Date: Tue=3D2C 31 Mar 2009 15:43:41 -0500 > >> >> From: martinbishop at bellsouth.net > >> >> To: mika at async.caltech.edu > >> >> CC: m3devel at elegosoft.com > >> >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? > >> >>=3D20 > >> >> Not sure if this helps=3D2C but on my linux system: > >> >>=3D20 > >> >> Critical Mass Modula-3 version d5.7.0 > >> >> last updated: 2008-03-16 > >> >> compiled: 2008-08-14 00:56:14 > >> >> configuration: /usr/local/cm3/bin/cm3.cfg > >> >>=3D20 > >> >> Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 > >> >> i686 GNU/Linux > >> >>=3D20 > >> >>=3D20 > >> >> I don't have the cm3 tarball=3D2C but I do have the sources in cm3/ st= > >ill. > >> >>=3D20 > >> >> Mika Nystrom wrote: > >> >> > Hello everyone=3D2C > >> >> >=3D20 > >> >> > This is=3D2C for me=3D2C a most unfortunate time for the CM3 servers= > > to > >> >> > have crashed. I'm teaching a class using Modula-3=3D2C and we need a > >> >> > compiler... here's the uname of the system I'm trying to use: > >> >> >=3D20 > >> >> > Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/= > >Lin=3D > >> >ux > >> >> >=3D20 > >> >> > The most recent archives I have for Linux are: > >> >> >=3D20 > >> >> > cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D20 > >> >> >=3D20 > >> >> > And they don't seem to work on this system: I can compile a program > >> >> > but when I try to run it=3D2C it says "Segmentation fault". Can anyo= > >ne > >> >> > help? (My understanding is that I need 5.5.1 or later...) > >> >> >=3D20 > >> >> > Mika > >> >> >=3D20 > >> >>=3D20 > >> > > >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ > >> >Content-Type: text/html=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> > > >> > > >> > > >> > > >> > =3D3B >s" targ=3D > >> >et=3D3D_blank>http://modula3.elegosoft.com/cm3/u= > >ploaded=3D > >> >-archives
> >> >?
> >> > =3D3B
> >> >I can make another later this week.
> >> > =3D3B
> >> >All you need is a working cm3 on any system.
> >> >>From there you can build the whole system=3D2C targeting any system. >> > >> >As long as that cm3 understands LONGINT and your target system.
> >> >And it is easier=3D2C but not necessary=3D2C if you have Python. :)
> >> > =3D3B
> >> > =3D3B- Jay

 =3D3B
>=3D3B Date: Tue=3D2C 31 Mar 2009= > > 15:43:41 -=3D > >> >0500
>=3D3B From: martinbishop at bellsouth.net
>=3D3B To: mika at a= > >sync.ca=3D > >> >ltech.edu
>=3D3B CC: m3devel at elegosoft.com
>=3D3B Subject: Re:= > > [M3dev=3D > >> >el] Help finding CM3 compiler for Linux?
>=3D3B
>=3D3B Not su= > >re if t=3D > >> >his helps=3D2C but on my linux system:
>=3D3B
>=3D3B Critical= > > Mass Mod=3D > >> >ula-3 version d5.7.0
>=3D3B last updated: 2008-03-16
>=3D3B co= > >mpiled:=3D > >> > 2008-08-14 00:56:14
>=3D3B configuration: /usr/local/cm3/bin/cm3.c= > >fg >> >>>=3D3B
>=3D3B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 2= > >9 19:24=3D > >> >:39 UTC 2009
>=3D3B i686 GNU/Linux
>=3D3B
>=3D3B
>= > >=3D3B I don=3D > >> >'t have the cm3 tarball=3D2C but I do have the sources in cm3/ still. >>>=3D > >> >=3D3B
>=3D3B Mika Nystrom wrote:
>=3D3B >=3D3B Hello everyo= > >ne=3D2C
&g=3D > >> >t=3D3B >=3D3B
>=3D3B >=3D3B This is=3D2C for me=3D2C a most un= > >fortunate time =3D > >> >for the CM3 servers to
>=3D3B >=3D3B have crashed. I'm teaching a= > > class =3D > >> >using Modula-3=3D2C and we need a
>=3D3B >=3D3B compiler... here'= > >s the una=3D > >> >me of the system I'm trying to use:
>=3D3B >=3D3B
>=3D3B &g= > >t=3D3B Linu=3D > >> >x lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Linux >>&g=3D > >> >t=3D3B >=3D3B
>=3D3B >=3D3B The most recent archives I have fo= > >r Linux are=3D > >> >:
>=3D3B >=3D3B
>=3D3B >=3D3B cm3-min-POSIX-LINUXLIBC6-5.= > >4.0.tgz cm3=3D > >> >-src-all-5.4.0.tgz
>=3D3B >=3D3B
>=3D3B >=3D3B And they = > >don't seem =3D > >> >to work on this system: I can compile a program
>=3D3B >=3D3B but= > > when I=3D > >> > try to run it=3D2C it says "Segmentation fault". Can anyone
>=3D3B= > > >=3D3B=3D > >> > help? (My understanding is that I need 5.5.1 or later...)
>=3D3B &= > >gt=3D3B=3D > >> >
>=3D3B >=3D3B Mika
>=3D3B >=3D3B
>=3D3B
>> > >> >=3D > >> > > >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_-- > > > >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >These archives do have a different format=2C yes.
> >But it isn't a bad format.
> >cminstall is pretty worthless imho.
> >Extract=2C rename=2C set PATH and LD_LIBRARY_PATH.
> > =3B
> > =3B- Jay

 =3B
>=3B To: jay.krell at cornell.edu
>=3B= > > Subject: Re: [M3devel] Help finding CM3 compiler for Linux?
>=3B Dat= > >e: Tue=2C 31 Mar 2009 15:56:11 -0700
>=3B From: mika at async.caltech.edu= > >
>=3B
>=3B No=2C I'm sorry...
>=3B
>=3B the archives = > >do not have the usual format. I'm expecting to unpack
>=3B and run "cm= > >install" and then unpack the big source tar on top and
>=3B build tha= > >t. But there's no cminstall in the archive on this page.
>=3B This is = > >"the normal procedure" for installing CM3=2C no? It's what
>=3B the in= > >structions say to do=2C as well...
>=3B
>=3B And the link from t= > >he "Download" page is broken (to -d5.5.0.tgz).
>=3B
>=3B Mika >>>=3B
>=3B Jay writes:
>=3B >=3B--_806446ae-8d10-4d74-8eea-5= > >1aa365e9204_
>=3B >=3BContent-Type: text/plain=3B charset=3D"iso-885= > >9-1"
>=3B >=3BContent-Transfer-Encoding: quoted-printable
>=3B = > >>=3B
>=3B >=3B
>=3B >=3B http://modula3.elegosoft.com/cm3/u= > >ploaded-archives
>=3B >=3B
>=3B >=3B?
>=3B >=3B
>= > >=3B >=3B=3D20
>=3B >=3B
>=3B >=3BI can make another later t= > >his week.
>=3B >=3B
>=3B >=3B=3D20
>=3B >=3B
>=3B= > > >=3BAll you need is a working cm3 on any system.
>=3B >=3B
>= > >=3B >=3B>=3BFrom there you can build the whole system=3D2C targeting an= > >y system.
>=3B >=3B
>=3B >=3BAs long as that cm3 understands = > >LONGINT and your target system.
>=3B >=3B
>=3B >=3BAnd it is = > >easier=3D2C but not necessary=3D2C if you have Python. :)
>=3B >=3B<= > >BR>>=3B >=3B=3D20
>=3B >=3B
>=3B >=3B - Jay
>=3B >= > >=3B
>=3B >=3B=3D20
>=3B >=3B>=3B Date: Tue=3D2C 31 Mar 2009= > > 15:43:41 -0500
>=3B >=3B>=3B From: martinbishop at bellsouth.net
= > >>=3B >=3B>=3B To: mika at async.caltech.edu
>=3B >=3B>=3B CC: m= > >3devel at elegosoft.com
>=3B >=3B>=3B Subject: Re: [M3devel] Help fin= > >ding CM3 compiler for Linux?
>=3B >=3B>=3B=3D20
>=3B >=3B&g= > >t=3B Not sure if this helps=3D2C but on my linux system:
>=3B >=3B&g= > >t=3B=3D20
>=3B >=3B>=3B Critical Mass Modula-3 version d5.7.0
&= > >gt=3B >=3B>=3B last updated: 2008-03-16
>=3B >=3B>=3B compiled= > >: 2008-08-14 00:56:14
>=3B >=3B>=3B configuration: /usr/local/cm3/= > >bin/cm3.cfg
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B Linux thinkp= > >ad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009
>=3B >=3B&g= > >t=3B i686 GNU/Linux
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B=3D20= > >
>=3B >=3B>=3B I don't have the cm3 tarball=3D2C but I do have the= > > sources in cm3/ still.
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B = > >Mika Nystrom wrote:
>=3B >=3B>=3B >=3B Hello everyone=3D2C
&g= > >t=3B >=3B>=3B >=3B=3D20
>=3B >=3B>=3B >=3B This is=3D2C fo= > >r me=3D2C a most unfortunate time for the CM3 servers to
>=3B >=3B&g= > >t=3B >=3B have crashed. I'm teaching a class using Modula-3=3D2C and we n= > >eed a
>=3B >=3B>=3B >=3B compiler... here's the uname of the sys= > >tem I'm trying to use:
>=3B >=3B>=3B >=3B=3D20
>=3B >=3B&= > >gt=3B >=3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i68= > >6 GNU/Lin=3D
>=3B >=3Bux
>=3B >=3B>=3B >=3B=3D20
>= > >=3B >=3B>=3B >=3B The most recent archives I have for Linux are:
&= > >gt=3B >=3B>=3B >=3B=3D20
>=3B >=3B>=3B >=3B cm3-min-POSIX-= > >LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D20
>=3B >=3B>=3B >= > >=3B=3D20
>=3B >=3B>=3B >=3B And they don't seem to work on this = > >system: I can compile a program
>=3B >=3B>=3B >=3B but when I tr= > >y to run it=3D2C it says "Segmentation fault". Can anyone
>=3B >=3B&= > >gt=3B >=3B help? (My understanding is that I need 5.5.1 or later...)
&= > >gt=3B >=3B>=3B >=3B=3D20
>=3B >=3B>=3B >=3B Mika
>=3B= > > >=3B>=3B >=3B=3D20
>=3B >=3B>=3B=3D20
>=3B >=3B
&= > >gt=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>=3B >=3BConten= > >t-Type: text/html=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfe= > >r-Encoding: quoted-printable
>=3B >=3B
>=3B >=3B<=3Bhtml>= > >=3B
>=3B >=3B<=3Bhead>=3B
>=3B >=3B<=3Bstyle>=3B
&= > >gt=3B >=3B.hmmessage P
>=3B >=3B{
>=3B >=3Bmargin:0px=3D3B<= > >BR>>=3B >=3Bpadding:0px
>=3B >=3B}
>=3B >=3Bbody.hmmessag= > >e
>=3B >=3B{
>=3B >=3Bfont-size: 10pt=3D3B
>=3B >=3Bfo= > >nt-family:Verdana
>=3B >=3B}
>=3B >=3B<=3B/style>=3B
&= > >gt=3B >=3B<=3B/head>=3B
>=3B >=3B<=3Bbody class=3D3D'hmmessa= > >ge'>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BA href=3D3D"http://modula3.= > >elegosoft.com/cm3/uploaded-archives" targ=3D
>=3B >=3Bet=3D3D_blank&= > >gt=3B<=3BFONT color=3D3D#0068cf>=3Bhttp://modula3.elegosoft.com/cm3/upl= > >oaded=3D
>=3B >=3B-archives<=3B/FONT>=3B<=3B/A>=3B<=3BBR&g= > >t=3B
>=3B >=3B?<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3B= > >BR>=3B
>=3B >=3BI can make another later this week.<=3BBR>=3B<= > >BR>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BAll you need= > > is a working cm3 on any system.<=3BBR>=3B
>=3B >=3B>=3BFrom t= > >here you can build the whole system=3D2C targeting any system.<=3BBR>= > >=3B
>=3B >=3BAs long as that cm3 understands LONGINT and your target= > > system.<=3BBR>=3B
>=3B >=3BAnd it is easier=3D2C but not necess= > >ary=3D2C if you have Python. :)<=3BBR>=3B
>=3B >=3B&=3Bnbsp= > >=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B- Jay<=3BBR>=3B<= > >=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3B&=3Bgt=3D3B Date: Tue=3D2C 31 M= > >ar 2009 15:43:41 -=3D
>=3B >=3B0500<=3BBR>=3B&=3Bgt=3D3B From= > >: martinbishop at bellsouth.net<=3BBR>=3B&=3Bgt=3D3B To: mika at async.ca= > >=3D
>=3B >=3Bltech.edu<=3BBR>=3B&=3Bgt=3D3B CC: m3devel at elego= > >soft.com<=3BBR>=3B&=3Bgt=3D3B Subject: Re: [M3dev=3D
>=3B >= > >=3Bel] Help finding CM3 compiler for Linux?<=3BBR>=3B&=3Bgt=3D3B <= > >=3BBR>=3B&=3Bgt=3D3B Not sure if t=3D
>=3B >=3Bhis helps=3D2C b= > >ut on my linux system:<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt= > >=3D3B Critical Mass Mod=3D
>=3B >=3Bula-3 version d5.7.0<=3BBR>= > >=3B&=3Bgt=3D3B last updated: 2008-03-16<=3BBR>=3B&=3Bgt=3D3B comp= > >iled:=3D
>=3B >=3B 2008-08-14 00:56:14<=3BBR>=3B&=3Bgt=3D3B c= > >onfiguration: /usr/local/cm3/bin/cm3.cfg<=3BBR=3D
>=3B >=3B>=3B&= > >amp=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Linux thinkpad 2.6.27-11-generic= > > #1 SMP Thu Jan 29 19:24=3D
>=3B >=3B:39 UTC 2009<=3BBR>=3B&= > >=3Bgt=3D3B i686 GNU/Linux<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3B= > >gt=3D3B <=3BBR>=3B&=3Bgt=3D3B I don=3D
>=3B >=3B't have the c= > >m3 tarball=3D2C but I do have the sources in cm3/ still.<=3BBR>=3B&= > >=3Bgt=3D
>=3B >=3B=3D3B <=3BBR>=3B&=3Bgt=3D3B Mika Nystrom wr= > >ote:<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B Hello everyone=3D2C<=3BBR= > >>=3B&=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B <=3BBR>=3B&= > >=3Bgt=3D3B &=3Bgt=3D3B This is=3D2C for me=3D2C a most unfortunate time = > >=3D
>=3B >=3Bfor the CM3 servers to<=3BBR>=3B&=3Bgt=3D3B &= > >=3Bgt=3D3B have crashed. I'm teaching a class =3D
>=3B >=3Busing Mod= > >ula-3=3D2C and we need a<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B compile= > >r... here's the una=3D
>=3B >=3Bme of the system I'm trying to use:&= > >lt=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B &am= > >p=3Bgt=3D3B Linu=3D
>=3B >=3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10= > >:53:03 PST 2008 i686 GNU/Linux<=3BBR>=3B&=3Bg=3D
>=3B >=3Bt= > >=3D3B &=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B The most r= > >ecent archives I have for Linux are=3D
>=3B >=3B:<=3BBR>=3B&= > >=3Bgt=3D3B &=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B cm3-m= > >in-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D
>=3B >=3B-src-all-5.4.0.tgz <= > =3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B &= > >=3Bgt=3D3B And they don't seem =3D
>=3B >=3Bto work on this system: = > >I can compile a program<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B but when= > > I=3D
>=3B >=3B try to run it=3D2C it says "Segmentation fault". Can= > > anyone<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D
>=3B >=3B help= > >? (My understanding is that I need 5.5.1 or later...)<=3BBR>=3B&=3Bg= > >t=3D3B &=3Bgt=3D3B=3D
>=3B >=3B <=3BBR>=3B&=3Bgt=3D3B &= > >=3Bgt=3D3B Mika<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B <=3BBR>=3B&a= > >mp=3Bgt=3D3B <=3BBR>=3B<=3B/body>=3B
>=3B >=3B<=3B/html>= > >=3B=3D
>=3B >=3B
>=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e= > >9204_--
> >= > > > >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Apr 1 08:27:22 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 31 Mar 2009 23:27:22 -0700 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: Your message of "Wed, 01 Apr 2009 06:13:00 -0000." Message-ID: <200904010627.n316RM55072294@camembert.async.caltech.edu> Hmm, I'm not sure what you mean? "root of cm3 cvs"? I have lots of Modula-3 installations on my own machines, but I'm just trying to get a system installed for student use on the student systems (which are different)... A working binary dist for Linux is exactly what I'm looking for and this is what you seem to have directed me to, but I don't have a CVS repository... I don't have "m3-sys/cminstall/" etc. Do I need to unpack both the min and std before doing these things? What I'm *used to* is that I unpack the binary distribution, then unpack the sources (or CVS if you like) on top of that, and then compile everything. Which works about 1 time in 3. I think Modula-3 is almost impossible to install if you don't know exactly what to do! (I'm sure I can figure this out with some work.. but is it really meant to be hard to do? I guess it keeps the riff-raff off the M3 mailing lists!) Mika Jay writes: >--_55339e45-8c85-4ab6-9440-0d2131bbad69_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Maybe not. > >Hm. That is bug. There is use with a cvs tree=2C and use without. > >I must have broken use without. > >=20 > >Try this: > >export CM3_ROOT=3Droot of cm3 cvs (for me this is /dev2/cm3=2C > >for you=2C maybe $HOME/cm3?) > >rm $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6 > ># *Common and *common in one command >rm $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/*ommon >cp root of cm3 cvs/m3-sys/cminstall/src/config/cm3.cfg $HOME/cm3/cm3-min-LI= >NUXLIBC6-d5.7.0/bin > >=20 > >The .cfg will delegate out to the cvs tree. > >I don't like having two copies of files..having to keep them in sync.. > > Though the archives are meant to work standalone=2C without CVS. > > But I don't test that so much oops sorry. > >That /might/ not be the right file=2C but it is close. > >=20 > > - Jay > >=20 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux?=20 >> Date: Tue=2C 31 Mar 2009 22:59:18 -0700 >> From: mika at async.caltech.edu >>=20 >>=20 >> Is there any documentation for this format beyond what you just >> wrote? Where? >>=20 >> terpsichore-14: cm3 >> --- building in ../LINUXLIBC6 --- >>=20 >> new source -> compiling Main.m3 >> "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common"=2C= > line 169: quake runtime error: undefined variable: ROOT >>=20 >> --procedure-- -line- -file--- >> GetM3Back 169 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3c= >fg.common >> _IsM3BackFlagSupported 181 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5= >.7.0/bin/Unix.common >> IsM3BackFlagSupported 193 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.= >7.0/bin/Unix.common >> GetM3BackFlag 197 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/= >Unix.common >> m3_backend 62 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix= >.common >> program -- >> 6 /afs/.ugcs.caltech.edu/user/mika/test/LINUXLIBC6/m3make.args >>=20 >>=20 >> Fatal Error: procedure "m3_backend" defined in "/afs/.ugcs/user/mika/cm3/= >cm3-min-LINUXLIBC6-d5.7.0/bin/cm3.cfg" failed. >>=20 >> Jay writes: >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> >These archives do have a different format=3D2C yes. >> > >> >But it isn't a bad format. >> > >> >cminstall is pretty worthless imho. >> > >> >Extract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH. >> > >> >=3D20 >> > >> > - Jay >> > >> >=3D20 >> >> To: jay.krell at cornell.edu >> >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux?=3D20 >> >> Date: Tue=3D2C 31 Mar 2009 15:56:11 -0700 >> >> From: mika at async.caltech.edu >> >>=3D20 >> >> No=3D2C I'm sorry... >> >>=3D20 >> >> the archives do not have the usual format. I'm expecting to unpack >> >> and run "cminstall" and then unpack the big source tar on top and=3D20 >> >> build that. But there's no cminstall in the archive on this page. >> >> This is "the normal procedure" for installing CM3=3D2C no? It's what >> >> the instructions say to do=3D2C as well... >> >>=3D20 >> >> And the link from the "Download" page is broken (to -d5.5.0.tgz). >> >>=3D20 >> >> Mika >> >>=3D20 >> >> Jay writes: >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ >> >> >Content-Type: text/plain=3D3B charset=3D3D"iso-8859-1" >> >> >Content-Transfer-Encoding: quoted-printable >> >> > >> >> > >> >> > http://modula3.elegosoft.com/cm3/uploaded-archives >> >> > >> >> >? >> >> > >> >> >=3D3D20 >> >> > >> >> >I can make another later this week. >> >> > >> >> >=3D3D20 >> >> > >> >> >All you need is a working cm3 on any system. >> >> > >> >> >>From there you can build the whole system=3D3D2C targeting any syste= >m. >> >> > >> >> >As long as that cm3 understands LONGINT and your target system. >> >> > >> >> >And it is easier=3D3D2C but not necessary=3D3D2C if you have Python. = >:) >> >> > >> >> >=3D3D20 >> >> > >> >> > - Jay >> >> > >> >> >=3D3D20 >> >> >> Date: Tue=3D3D2C 31 Mar 2009 15:43:41 -0500 >> >> >> From: martinbishop at bellsouth.net >> >> >> To: mika at async.caltech.edu >> >> >> CC: m3devel at elegosoft.com >> >> >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >> >> >>=3D3D20 >> >> >> Not sure if this helps=3D3D2C but on my linux system: >> >> >>=3D3D20 >> >> >> Critical Mass Modula-3 version d5.7.0 >> >> >> last updated: 2008-03-16 >> >> >> compiled: 2008-08-14 00:56:14 >> >> >> configuration: /usr/local/cm3/bin/cm3.cfg >> >> >>=3D3D20 >> >> >> Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 200= >9 >> >> >> i686 GNU/Linux >> >> >>=3D3D20 >> >> >>=3D3D20 >> >> >> I don't have the cm3 tarball=3D3D2C but I do have the sources in cm= >3/ st=3D >> >ill. >> >> >>=3D3D20 >> >> >> Mika Nystrom wrote: >> >> >> > Hello everyone=3D3D2C >> >> >> >=3D3D20 >> >> >> > This is=3D3D2C for me=3D3D2C a most unfortunate time for the CM3 = >servers=3D >> > to >> >> >> > have crashed. I'm teaching a class using Modula-3=3D3D2C and we n= >eed a >> >> >> > compiler... here's the uname of the system I'm trying to use: >> >> >> >=3D3D20 >> >> >> > Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 G= >NU/=3D >> >Lin=3D3D >> >> >ux >> >> >> >=3D3D20 >> >> >> > The most recent archives I have for Linux are: >> >> >> >=3D3D20 >> >> >> > cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D3D20 >> >> >> >=3D3D20 >> >> >> > And they don't seem to work on this system: I can compile a progr= >am >> >> >> > but when I try to run it=3D3D2C it says "Segmentation fault". Can= > anyo=3D >> >ne >> >> >> > help? (My understanding is that I need 5.5.1 or later...) >> >> >> >=3D3D20 >> >> >> > Mika >> >> >> >=3D3D20 >> >> >>=3D3D20 >> >> > >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ >> >> >Content-Type: text/html=3D3B charset=3D3D"iso-8859-1" >> >> >Content-Transfer-Encoding: quoted-printable >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > =3D3D3Barchive=3D >> >s" targ=3D3D >> >> >et=3D3D3D_blank>http://modula3.elegosoft.co= >m/cm3/u=3D >> >ploaded=3D3D >> >> >-archives
>> >> >?
>> >> > =3D3D3B
>> >> >I can make another later this week.
>> >> > =3D3D3B
>> >> >All you need is a working cm3 on any system.
>> >> >>From there you can build the whole system=3D3D2C targeting any syste= >m.> >> >> >> >As long as that cm3 understands LONGINT and your target system.
>> >> >And it is easier=3D3D2C but not necessary=3D3D2C if you have Python. = >:)
>> >> > =3D3D3B
>> >> > =3D3D3B- Jay

 =3D3D3B
>=3D3D3B Date: Tue=3D3D2C = >31 Mar 2009=3D >> > 15:43:41 -=3D3D >> >> >0500
>=3D3D3B From: martinbishop at bellsouth.net
>=3D3D3B To:= > mika at a=3D >> >sync.ca=3D3D >> >> >ltech.edu
>=3D3D3B CC: m3devel at elegosoft.com
>=3D3D3B Subje= >ct: Re:=3D >> > [M3dev=3D3D >> >> >el] Help finding CM3 compiler for Linux?
>=3D3D3B
>=3D3D3B= > Not su=3D >> >re if t=3D3D >> >> >his helps=3D3D2C but on my linux system:
>=3D3D3B
>=3D3D3B= > Critical=3D >> > Mass Mod=3D3D >> >> >ula-3 version d5.7.0
>=3D3D3B last updated: 2008-03-16
>=3D= >3D3B co=3D >> >mpiled:=3D3D >> >> > 2008-08-14 00:56:14
>=3D3D3B configuration: /usr/local/cm3/bin/= >cm3.c=3D >> >fg> >> >>>=3D3D3B
>=3D3D3B Linux thinkpad 2.6.27-11-generic #1 SMP Th= >u Jan 2=3D >> >9 19:24=3D3D >> >> >:39 UTC 2009
>=3D3D3B i686 GNU/Linux
>=3D3D3B
>=3D3D3= >B
>=3D >> >=3D3D3B I don=3D3D >> >> >'t have the cm3 tarball=3D3D2C but I do have the sources in cm3/ stil= >l.> >>>=3D3D >> >> >=3D3D3B
>=3D3D3B Mika Nystrom wrote:
>=3D3D3B >=3D3D3B H= >ello everyo=3D >> >ne=3D3D2C
&g=3D3D >> >> >t=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B This is=3D3D2C for me= >=3D3D2C a most un=3D >> >fortunate time =3D3D >> >> >for the CM3 servers to
>=3D3D3B >=3D3D3B have crashed. I'm tea= >ching a=3D >> > class =3D3D >> >> >using Modula-3=3D3D2C and we need a
>=3D3D3B >=3D3D3B compiler= >... here'=3D >> >s the una=3D3D >> >> >me of the system I'm trying to use:
>=3D3D3B >=3D3D3B
>= >=3D3D3B &g=3D >> >t=3D3D3B Linu=3D3D >> >> >x lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Linux= >> >>&g=3D3D >> >> >t=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B The most recent archive= >s I have fo=3D >> >r Linux are=3D3D >> >> >:
>=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B cm3-min-POSIX-LI= >NUXLIBC6-5.=3D >> >4.0.tgz cm3=3D3D >> >> >-src-all-5.4.0.tgz
>=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3= >B And they =3D >> >don't seem =3D3D >> >> >to work on this system: I can compile a program
>=3D3D3B >=3D3= >D3B but=3D >> > when I=3D3D >> >> > try to run it=3D3D2C it says "Segmentation fault". Can anyone
>= >=3D3D3B=3D >> > >=3D3D3B=3D3D >> >> > help? (My understanding is that I need 5.5.1 or later...)
>=3D3= >D3B &=3D >> >gt=3D3D3B=3D3D >> >> >
>=3D3D3B >=3D3D3B Mika
>=3D3D3B >=3D3D3B
>=3D3D= >3B
> >> >> >> >=3D3D >> >> > >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_-- >> > >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ >> >Content-Type: text/html=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> > >> > >> > >> > >> >These archives do have a different format=3D2C yes.
>> >But it isn't a bad format.
>> >cminstall is pretty worthless imho.
>> >Extract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.
>> > =3D3B
>> > =3D3B- Jay

 =3D3B
>=3D3B To: jay.krell at cornell.edu<= >BR>>=3D3B=3D >> > Subject: Re: [M3devel] Help finding CM3 compiler for Linux?
>=3D3= >B Dat=3D >> >e: Tue=3D2C 31 Mar 2009 15:56:11 -0700
>=3D3B From: mika at async.calt= >ech.edu=3D >> >
>=3D3B
>=3D3B No=3D2C I'm sorry...
>=3D3B
>=3D3B = >the archives =3D >> >do not have the usual format. I'm expecting to unpack
>=3D3B and ru= >n "cm=3D >> >install" and then unpack the big source tar on top and
>=3D3B buil= >d tha=3D >> >t. But there's no cminstall in the archive on this page.
>=3D3B Thi= >s is =3D >> >"the normal procedure" for installing CM3=3D2C no? It's what
>=3D3B= > the in=3D >> >structions say to do=3D2C as well...
>=3D3B
>=3D3B And the li= >nk from t=3D >> >he "Download" page is broken (to -d5.5.0.tgz).
>=3D3B
>=3D3B = >Mika> >>>=3D3B
>=3D3B Jay writes:
>=3D3B >=3D3B--_806446ae-8d10-= >4d74-8eea-5=3D >> >1aa365e9204_
>=3D3B >=3D3BContent-Type: text/plain=3D3B charset= >=3D3D"iso-885=3D >> >9-1"
>=3D3B >=3D3BContent-Transfer-Encoding: quoted-printable
= >>=3D3B =3D >> >>=3D3B
>=3D3B >=3D3B
>=3D3B >=3D3B http://modula3.elegos= >oft.com/cm3/u=3D >> >ploaded-archives
>=3D3B >=3D3B
>=3D3B >=3D3B?
>=3D3B = >>=3D3B
>=3D >> >=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B
>=3D3B >=3D3BI can mak= >e another later t=3D >> >his week.
>=3D3B >=3D3B
>=3D3B >=3D3B=3D3D20
>=3D3B &= >gt=3D3B
>=3D3B=3D >> > >=3D3BAll you need is a working cm3 on any system.
>=3D3B >=3D= >3B
>=3D >> >=3D3B >=3D3B>=3D3BFrom there you can build the whole system=3D3D2C t= >argeting an=3D >> >y system.
>=3D3B >=3D3B
>=3D3B >=3D3BAs long as that cm3 u= >nderstands =3D >> >LONGINT and your target system.
>=3D3B >=3D3B
>=3D3B >=3D3= >BAnd it is =3D >> >easier=3D3D2C but not necessary=3D3D2C if you have Python. :)
>=3D3= >B >=3D3B<=3D >> >BR>>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B
>=3D3B >=3D3B - = >Jay
>=3D3B >=3D >> >=3D3B
>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B Date: Tue= >=3D3D2C 31 Mar 2009=3D >> > 15:43:41 -0500
>=3D3B >=3D3B>=3D3B From: martinbishop at bellsout= >h.net
=3D >> >>=3D3B >=3D3B>=3D3B To: mika at async.caltech.edu
>=3D3B >=3D3= >B>=3D3B CC: m=3D >> >3devel at elegosoft.com
>=3D3B >=3D3B>=3D3B Subject: Re: [M3devel]= > Help fin=3D >> >ding CM3 compiler for Linux?
>=3D3B >=3D3B>=3D3B=3D3D20
>= >=3D3B >=3D3B&g=3D >> >t=3D3B Not sure if this helps=3D3D2C but on my linux system:
>=3D3B= > >=3D3B&g=3D >> >t=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B Critical Mass Modula-3 versio= >n d5.7.0
&=3D >> >gt=3D3B >=3D3B>=3D3B last updated: 2008-03-16
>=3D3B >=3D3B&g= >t=3D3B compiled=3D >> >: 2008-08-14 00:56:14
>=3D3B >=3D3B>=3D3B configuration: /usr/l= >ocal/cm3/=3D >> >bin/cm3.cfg
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B >=3D3B>= >=3D3B Linux thinkp=3D >> >ad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009
>=3D3B >= >=3D3B&g=3D >> >t=3D3B i686 GNU/Linux
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B &g= >t=3D3B>=3D3B=3D3D20=3D >> >
>=3D3B >=3D3B>=3D3B I don't have the cm3 tarball=3D3D2C but I = >do have the=3D >> > sources in cm3/ still.
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B = >>=3D3B>=3D3B =3D >> >Mika Nystrom wrote:
>=3D3B >=3D3B>=3D3B >=3D3B Hello everyone= >=3D3D2C
&g=3D >> >t=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B >= >=3D3B This is=3D3D2C fo=3D >> >r me=3D3D2C a most unfortunate time for the CM3 servers to
>=3D3B &= >gt=3D3B&g=3D >> >t=3D3B >=3D3B have crashed. I'm teaching a class using Modula-3=3D3D2C= > and we n=3D >> >eed a
>=3D3B >=3D3B>=3D3B >=3D3B compiler... here's the uname= > of the sys=3D >> >tem I'm trying to use:
>=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
&= >gt=3D3B >=3D3B&=3D >> >gt=3D3B >=3D3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2= >008 i68=3D >> >6 GNU/Lin=3D3D
>=3D3B >=3D3Bux
>=3D3B >=3D3B>=3D3B >= >=3D3B=3D3D20
>=3D >> >=3D3B >=3D3B>=3D3B >=3D3B The most recent archives I have for Linu= >x are:
&=3D >> >gt=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B &g= >t=3D3B cm3-min-POSIX-=3D >> >LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D3D20
>=3D3B >=3D3B&g= >t=3D3B >=3D >> >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B >=3D3B And they don't seem t= >o work on this =3D >> >system: I can compile a program
>=3D3B >=3D3B>=3D3B >=3D3B bu= >t when I tr=3D >> >y to run it=3D3D2C it says "Segmentation fault". Can anyone
>=3D3B = >>=3D3B&=3D >> >gt=3D3B >=3D3B help? (My understanding is that I need 5.5.1 or later..= >.)
&=3D >> >gt=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B &g= >t=3D3B Mika
>=3D3B=3D >> > >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B=3D3D20>>=3D3B >=3D3B
&=3D >> >gt=3D3B >=3D3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>=3D3B >= >=3D3BConten=3D >> >t-Type: text/html=3D3B charset=3D3D"iso-8859-1"
>=3D3B >=3D3BCont= >ent-Transfe=3D >> >r-Encoding: quoted-printable
>=3D3B >=3D3B
>=3D3B >=3D3B&l= >t=3D3Bhtml>=3D >> >=3D3B
>=3D3B >=3D3B<=3D3Bhead>=3D3B
>=3D3B >=3D3B<= >=3D3Bstyle>=3D3B
&=3D >> >gt=3D3B >=3D3B.hmmessage P
>=3D3B >=3D3B{
>=3D3B >=3D3Bm= >argin:0px=3D3D3B<=3D >> >BR>>=3D3B >=3D3Bpadding:0px
>=3D3B >=3D3B}
>=3D3B >=3D= >3Bbody.hmmessag=3D >> >e
>=3D3B >=3D3B{
>=3D3B >=3D3Bfont-size: 10pt=3D3D3B
&g= >t=3D3B >=3D3Bfo=3D >> >nt-family:Verdana
>=3D3B >=3D3B}
>=3D3B >=3D3B<=3D3B/sty= >le>=3D3B
&=3D >> >gt=3D3B >=3D3B<=3D3B/head>=3D3B
>=3D3B >=3D3B<=3D3Bbody c= >lass=3D3D3D'hmmessa=3D >> >ge'>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BA href=3D3D3= >D"http://modula3.=3D >> >elegosoft.com/cm3/uploaded-archives" targ=3D3D
>=3D3B >=3D3Bet=3D= >3D3D_blank&=3D >> >gt=3D3B<=3D3BFONT color=3D3D3D#0068cf>=3D3Bhttp://modula3.elegosoft.= >com/cm3/upl=3D >> >oaded=3D3D
>=3D3B >=3D3B-archives<=3D3B/FONT>=3D3B<=3D3B/A&= >gt=3D3B<=3D3BBR&g=3D >> >t=3D3B
>=3D3B >=3D3B?<=3D3BBR>=3D3B
>=3D3B >=3D3B&= >=3D3Bnbsp=3D3D3B<=3D3B=3D >> >BR>=3D3B
>=3D3B >=3D3BI can make another later this week.<=3D= >3BBR>=3D3B<=3D >> >BR>>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
>=3D3B &= >gt=3D3BAll you need=3D >> > is a working cm3 on any system.<=3D3BBR>=3D3B
>=3D3B >=3D3B&= >gt=3D3BFrom t=3D >> >here you can build the whole system=3D3D2C targeting any system.<=3D3B= >BR>=3D >> >=3D3B
>=3D3B >=3D3BAs long as that cm3 understands LONGINT and yo= >ur target=3D >> > system.<=3D3BBR>=3D3B
>=3D3B >=3D3BAnd it is easier=3D3D2C b= >ut not necess=3D >> >ary=3D3D2C if you have Python. :)<=3D3BBR>=3D3B
>=3D3B >=3D3B= >&=3D3Bnbsp=3D >> >=3D3D3B<=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B- Jay&= >lt=3D3BBR>=3D3B<=3D >> >=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B = >Date: Tue=3D3D2C 31 M=3D >> >ar 2009 15:43:41 -=3D3D
>=3D3B >=3D3B0500<=3D3BBR>=3D3B&= >=3D3Bgt=3D3D3B From=3D >> >: martinbishop at bellsouth.net<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B To: mik= >a at async.ca=3D >> >=3D3D
>=3D3B >=3D3Bltech.edu<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B = >CC: m3devel at elego=3D >> >soft.com<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Subject: Re: [M3dev=3D3D>>=3D3B >=3D >> >=3D3Bel] Help finding CM3 compiler for Linux?<=3D3BBR>=3D3B&=3D3B= >gt=3D3D3B <=3D >> >=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Not sure if t=3D3D
>=3D3B >=3D3= >Bhis helps=3D3D2C b=3D >> >ut on my linux system:<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B <=3D3BBR>= >=3D3B&=3D3Bgt=3D >> >=3D3D3B Critical Mass Mod=3D3D
>=3D3B >=3D3Bula-3 version d5.7.0&= >lt=3D3BBR>=3D >> >=3D3B&=3D3Bgt=3D3D3B last updated: 2008-03-16<=3D3BBR>=3D3B&= >=3D3Bgt=3D3D3B comp=3D >> >iled:=3D3D
>=3D3B >=3D3B 2008-08-14 00:56:14<=3D3BBR>=3D3B&am= >p=3D3Bgt=3D3D3B c=3D >> >onfiguration: /usr/local/cm3/bin/cm3.cfg<=3D3BBR=3D3D
>=3D3B >= >=3D3B>=3D3B&=3D >> >amp=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Linux thinkpad 2.= >6.27-11-generic=3D >> > #1 SMP Thu Jan 29 19:24=3D3D
>=3D3B >=3D3B:39 UTC 2009<=3D3BBR= >>=3D3B&=3D >> >=3D3Bgt=3D3D3B i686 GNU/Linux<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B <=3D= >3BBR>=3D3B&=3D3B=3D >> >gt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B I don=3D3D
>=3D3B &g= >t=3D3B't have the c=3D >> >m3 tarball=3D3D2C but I do have the sources in cm3/ still.<=3D3BBR>= >=3D3B&=3D >> >=3D3Bgt=3D3D
>=3D3B >=3D3B=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt= >=3D3D3B Mika Nystrom wr=3D >> >ote:<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B Hello everyo= >ne=3D3D2C<=3D3BBR=3D >> >>=3D3B&=3D3Bg=3D3D
>=3D3B >=3D3Bt=3D3D3B &=3D3Bgt=3D3D3B = ><=3D3BBR>=3D3B&=3D >> >=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B This is=3D3D2C for me=3D3D2C a most un= >fortunate time =3D >> >=3D3D
>=3D3B >=3D3Bfor the CM3 servers to<=3D3BBR>=3D3B&= >=3D3Bgt=3D3D3B &=3D >> >=3D3Bgt=3D3D3B have crashed. I'm teaching a class =3D3D
>=3D3B >= >=3D3Busing Mod=3D >> >ula-3=3D3D2C and we need a<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3B= >gt=3D3D3B compile=3D >> >r... here's the una=3D3D
>=3D3B >=3D3Bme of the system I'm trying= > to use:&=3D >> >lt=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3= >B&=3D3Bgt=3D3D3B &am=3D >> >p=3D3Bgt=3D3D3B Linu=3D3D
>=3D3B >=3D3Bx lara 2.6.24ugcs1 #4 SMP = >Mon Feb 11 10=3D >> >:53:03 PST 2008 i686 GNU/Linux<=3D3BBR>=3D3B&=3D3Bg=3D3D
>= >=3D3B >=3D3Bt=3D >> >=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3= >Bgt=3D3D3B The most r=3D >> >ecent archives I have for Linux are=3D3D
>=3D3B >=3D3B:<=3D3BBR= >>=3D3B&=3D >> >=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &= >amp=3D3Bgt=3D3D3B cm3-m=3D >> >in-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D3D
>=3D3B >=3D3B-src-all-5.4.= >0.tgz <=3D >> =3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&a= >mp=3D3Bgt=3D3D3B &=3D >> >=3D3Bgt=3D3D3B And they don't seem =3D3D
>=3D3B >=3D3Bto work on = >this system: =3D >> >I can compile a program<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt= >=3D3D3B but when=3D >> > I=3D3D
>=3D3B >=3D3B try to run it=3D3D2C it says "Segmentation = >fault". Can=3D >> > anyone<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B=3D3D
&= >gt=3D3B >=3D3B help=3D >> >? (My understanding is that I need 5.5.1 or later...)<=3D3BBR>=3D3B&= >amp=3D3Bg=3D >> >t=3D3D3B &=3D3Bgt=3D3D3B=3D3D
>=3D3B >=3D3B <=3D3BBR>=3D3B= >&=3D3Bgt=3D3D3B &=3D >> >=3D3Bgt=3D3D3B Mika<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D= >3B <=3D3BBR>=3D3B&a=3D >> >mp=3D3Bgt=3D3D3B <=3D3BBR>=3D3B<=3D3B/body>=3D3B
>=3D3B >= >=3D3B<=3D3B/html>=3D >> >=3D3B=3D3D
>=3D3B >=3D3B
>=3D3B >=3D3B--_806446ae-8d10-4d7= >4-8eea-51aa365e=3D >> >9204_--
>> >=3D >> > >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_-- > >--_55339e45-8c85-4ab6-9440-0d2131bbad69_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Maybe not.
>Hm. That is bug. There is use with a cvs tree=2C and use without.
>I must have broken use without.
> =3B
>Try this:
>export CM3_ROOT=3Droot of cm3 cvs (for me this is /dev2/cm3=2C
>for you=2C maybe $HOME/cm3?)
>rm =3B$HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6
># *Common and *common in one command
rm =3B$HOME/cm3/cm3-min-LINUXLI= >BC6-d5.7.0/bin/*ommon
cp root of cm3 cvs/m3-sys/cminstall/src/config/cm3= >.cfg $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin
> =3B
>The .cfg will delegate out to the cvs tree.
>I don't like having two copies of files..having to keep them in sync..
> =3BThough the archives are meant to work standalone=2C without CVS.> > =3B But I don't test that so much oops sorry.
>That /might/ not be the right file=2C but it is close.
> =3B
> =3B- Jay

 =3B
>=3B To: jay.krell at cornell.edu
>=3B= > CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] Help finding CM= >3 compiler for Linux?
>=3B Date: Tue=2C 31 Mar 2009 22:59:18 -0700>>=3B From: mika at async.caltech.edu
>=3B
>=3B
>=3B Is the= >re any documentation for this format beyond what you just
>=3B wrote? = >Where?
>=3B
>=3B terpsichore-14: cm3
>=3B --- building in .= >./LINUXLIBC6 ---
>=3B
>=3B new source ->=3B compiling Main.m3<= >BR>>=3B "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.co= >mmon"=2C line 169: quake runtime error: undefined variable: ROOT
>=3B = >
>=3B --procedure-- -line- -file---
>=3B GetM3Back 169 /afs/.ugcs= >/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common
>=3B _IsM3B= >ackFlagSupported 181 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin= >/Unix.common
>=3B IsM3BackFlagSupported 193 /afs/.ugcs/user/mika/cm3/c= >m3-min-LINUXLIBC6-d5.7.0/bin/Unix.common
>=3B GetM3BackFlag 197 /afs/.= >ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common
>=3B m3_b= >ackend 62 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.commo= >n
>=3B program -- <=3Bbuiltin>=3B
>=3B 6 /afs/.ugcs.caltech.e= >du/user/mika/test/LINUXLIBC6/m3make.args
>=3B
>=3B
>=3B Fa= >tal Error: procedure "m3_backend" defined in "/afs/.ugcs/user/mika/cm3/cm3-= >min-LINUXLIBC6-d5.7.0/bin/cm3.cfg" failed.
>=3B
>=3B Jay writes:= >
>=3B >=3B--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_
>=3B >=3BC= >ontent-Type: text/plain=3B charset=3D"iso-8859-1"
>=3B >=3BContent-T= >ransfer-Encoding: quoted-printable
>=3B >=3B
>=3B >=3B
>= >=3B >=3BThese archives do have a different format=3D2C yes.
>=3B >= >=3B
>=3B >=3BBut it isn't a bad format.
>=3B >=3B
>=3B &= >gt=3Bcminstall is pretty worthless imho.
>=3B >=3B
>=3B >=3BE= >xtract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.
>=3B >=3B
&= >gt=3B >=3B=3D20
>=3B >=3B
>=3B >=3B - Jay
>=3B >=3B<= >BR>>=3B >=3B=3D20
>=3B >=3B>=3B To: jay.krell at cornell.edu
&= >gt=3B >=3B>=3B Subject: Re: [M3devel] Help finding CM3 compiler for Lin= >ux?=3D20
>=3B >=3B>=3B Date: Tue=3D2C 31 Mar 2009 15:56:11 -0700R>>=3B >=3B>=3B From: mika at async.caltech.edu
>=3B >=3B>=3B= >=3D20
>=3B >=3B>=3B No=3D2C I'm sorry...
>=3B >=3B>=3B=3D= >20
>=3B >=3B>=3B the archives do not have the usual format. I'm ex= >pecting to unpack
>=3B >=3B>=3B and run "cminstall" and then unpac= >k the big source tar on top and=3D20
>=3B >=3B>=3B build that. But= > there's no cminstall in the archive on this page.
>=3B >=3B>=3B T= >his is "the normal procedure" for installing CM3=3D2C no? It's what
>= >=3B >=3B>=3B the instructions say to do=3D2C as well...
>=3B >= >=3B>=3B=3D20
>=3B >=3B>=3B And the link from the "Download" page= > is broken (to -d5.5.0.tgz).
>=3B >=3B>=3B=3D20
>=3B >=3B&g= >t=3B Mika
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B Jay writes:>>=3B >=3B>=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>= >=3B >=3B>=3B >=3BContent-Type: text/plain=3D3B charset=3D3D"iso-8859-= >1"
>=3B >=3B>=3B >=3BContent-Transfer-Encoding: quoted-printable= >
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B
>=3B >= >=3B>=3B >=3B http://modula3.elegosoft.com/cm3/uploaded-archives
>= >=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B?
>=3B >=3B>= >=3B >=3B
>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >= >=3B
>=3B >=3B>=3B >=3BI can make another later this week.
>= >=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B=3D3D20
>=3B >= >=3B>=3B >=3B
>=3B >=3B>=3B >=3BAll you need is a working cm3= > on any system.
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B= >>=3BFrom there you can build the whole system=3D3D2C targeting any system= >.
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3BAs long as tha= >t cm3 understands LONGINT and your target system.
>=3B >=3B>=3B &g= >t=3B
>=3B >=3B>=3B >=3BAnd it is easier=3D3D2C but not necessary= >=3D3D2C if you have Python. :)
>=3B >=3B>=3B >=3B
>=3B >= >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B
>=3B >=3B>= >=3B >=3B - Jay
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >= >=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Date: Tue=3D3D2C 31 Mar 2009= > 15:43:41 -0500
>=3B >=3B>=3B >=3B>=3B From: martinbishop at bell= >south.net
>=3B >=3B>=3B >=3B>=3B To: mika at async.caltech.edu>>=3B >=3B>=3B >=3B>=3B CC: m3devel at elegosoft.com
>=3B >= >=3B>=3B >=3B>=3B Subject: Re: [M3devel] Help finding CM3 compiler for= > Linux?
>=3B >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B &= >gt=3B>=3B Not sure if this helps=3D3D2C but on my linux system:
>=3B= > >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Criti= >cal Mass Modula-3 version d5.7.0
>=3B >=3B>=3B >=3B>=3B last u= >pdated: 2008-03-16
>=3B >=3B>=3B >=3B>=3B compiled: 2008-08-14= > 00:56:14
>=3B >=3B>=3B >=3B>=3B configuration: /usr/local/cm3= >/bin/cm3.cfg
>=3B >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>= >=3B >=3B>=3B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:3= >9 UTC 2009
>=3B >=3B>=3B >=3B>=3B i686 GNU/Linux
>=3B >= >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B=3D3D20>>=3B >=3B>=3B >=3B>=3B I don't have the cm3 tarball=3D3D2C but I= > do have the sources in cm3/ st=3D
>=3B >=3Bill.
>=3B >=3B>= >=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Mika Nystrom wr= >ote:
>=3B >=3B>=3B >=3B>=3B >=3B Hello everyone=3D3D2C
&g= >t=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B&= >gt=3B >=3B This is=3D3D2C for me=3D3D2C a most unfortunate time for the C= >M3 servers=3D
>=3B >=3B to
>=3B >=3B>=3B >=3B>=3B >= >=3B have crashed. I'm teaching a class using Modula-3=3D3D2C and we need a<= >BR>>=3B >=3B>=3B >=3B>=3B >=3B compiler... here's the uname of = >the system I'm trying to use:
>=3B >=3B>=3B >=3B>=3B >=3B=3D= >3D20
>=3B >=3B>=3B >=3B>=3B >=3B Linux lara 2.6.24ugcs1 #4 S= >MP Mon Feb 11 10:53:03 PST 2008 i686 GNU/=3D
>=3B >=3BLin=3D3D
&g= >t=3B >=3B>=3B >=3Bux
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D2= >0
>=3B >=3B>=3B >=3B>=3B >=3B The most recent archives I hav= >e for Linux are:
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>= >=3B >=3B>=3B >=3B>=3B >=3B cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3= >-src-all-5.4.0.tgz=3D3D20
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20= >
>=3B >=3B>=3B >=3B>=3B >=3B And they don't seem to work on = >this system: I can compile a program
>=3B >=3B>=3B >=3B>=3B &g= >t=3B but when I try to run it=3D3D2C it says "Segmentation fault". Can anyo= >=3D
>=3B >=3Bne
>=3B >=3B>=3B >=3B>=3B >=3B help? (My= > understanding is that I need 5.5.1 or later...)
>=3B >=3B>=3B >= >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B >=3B Mika
= >>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >= >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >= >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>=3B >=3B>=3B >=3BCo= >ntent-Type: text/html=3D3B charset=3D3D"iso-8859-1"
>=3B >=3B>=3B = >>=3BContent-Transfer-Encoding: quoted-printable
>=3B >=3B>=3B &g= >t=3B
>=3B >=3B>=3B >=3B<=3Bhtml>=3B
>=3B >=3B>=3B &= >gt=3B<=3Bhead>=3B
>=3B >=3B>=3B >=3B<=3Bstyle>=3B
>= >=3B >=3B>=3B >=3B.hmmessage P
>=3B >=3B>=3B >=3B{
>= >=3B >=3B>=3B >=3Bmargin:0px=3D3D3B
>=3B >=3B>=3B >=3Bpaddi= >ng:0px
>=3B >=3B>=3B >=3B}
>=3B >=3B>=3B >=3Bbody.hmm= >essage
>=3B >=3B>=3B >=3B{
>=3B >=3B>=3B >=3Bfont-siz= e: 10pt=3D3D3B
>=3B >=3B>=3B >=3Bfont-family:Verdana
>=3B &= >gt=3B>=3B >=3B}
>=3B >=3B>=3B >=3B<=3B/style>=3B
>= >=3B >=3B>=3B >=3B<=3B/head>=3B
>=3B >=3B>=3B >=3B<= >=3Bbody class=3D3D3D'hmmessage'>=3B
>=3B >=3B>=3B >=3B&=3Bn= >bsp=3D3D3B<=3BA href=3D3D3D"http://modula3.elegosoft.com/cm3/uploaded-arc= >hive=3D
>=3B >=3Bs" targ=3D3D
>=3B >=3B>=3B >=3Bet=3D3D3D= >_blank>=3B<=3BFONT color=3D3D3D#0068cf>=3Bhttp://modula3.elegosoft.co= >m/cm3/u=3D
>=3B >=3Bploaded=3D3D
>=3B >=3B>=3B >=3B-archi= >ves<=3B/FONT>=3B<=3B/A>=3B<=3BBR>=3B
>=3B >=3B>=3B >= >=3B?<=3BBR>=3B
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR&= >gt=3B
>=3B >=3B>=3B >=3BI can make another later this week.<= >=3BBR>=3B
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3BR>>=3B >=3B>=3B >=3BAll you need is a working cm3 on any system.<= >=3BBR>=3B
>=3B >=3B>=3B >=3B>=3BFrom there you can build the= > whole system=3D3D2C targeting any system.<=3BBR=3D
>=3B >=3B>= >=3B
>=3B >=3B>=3B >=3BAs long as that cm3 understands LONGINT an= >d your target system.<=3BBR>=3B
>=3B >=3B>=3B >=3BAnd it is = >easier=3D3D2C but not necessary=3D3D2C if you have Python. :)<=3BBR>=3B= >
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B
>=3B &g= >t=3B>=3B >=3B&=3Bnbsp=3D3D3B- Jay<=3BBR>=3B<=3BBR>=3B&=3B= >nbsp=3D3D3B<=3BBR>=3B&=3Bgt=3D3D3B Date: Tue=3D3D2C 31 Mar 2009=3DR>>=3B >=3B 15:43:41 -=3D3D
>=3B >=3B>=3B >=3B0500<=3BBR&g= >t=3B&=3Bgt=3D3D3B From: martinbishop at bellsouth.net<=3BBR>=3B&=3Bg= >t=3D3D3B To: mika at a=3D
>=3B >=3Bsync.ca=3D3D
>=3B >=3B>=3B = >>=3Bltech.edu<=3BBR>=3B&=3Bgt=3D3D3B CC: m3devel at elegosoft.com<= >=3BBR>=3B&=3Bgt=3D3D3B Subject: Re:=3D
>=3B >=3B [M3dev=3D3D>>=3B >=3B>=3B >=3Bel] Help finding CM3 compiler for Linux?<=3BBR= >>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B Not su=3D
>=3B &= >gt=3Bre if t=3D3D
>=3B >=3B>=3B >=3Bhis helps=3D3D2C but on my l= >inux system:<=3BBR>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B C= >ritical=3D
>=3B >=3B Mass Mod=3D3D
>=3B >=3B>=3B >=3Bula-= >3 version d5.7.0<=3BBR>=3B&=3Bgt=3D3D3B last updated: 2008-03-16<= >=3BBR>=3B&=3Bgt=3D3D3B co=3D
>=3B >=3Bmpiled:=3D3D
>=3B &g= >t=3B>=3B >=3B 2008-08-14 00:56:14<=3BBR>=3B&=3Bgt=3D3D3B configu= >ration: /usr/local/cm3/bin/cm3.c=3D
>=3B >=3Bfg<=3BBR=3D3D
>= >=3B >=3B>=3B >=3B>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3= >B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 2=3D
>=3B >=3B9 19= >:24=3D3D
>=3B >=3B>=3B >=3B:39 UTC 2009<=3BBR>=3B&=3Bgt= >=3D3D3B i686 GNU/Linux<=3BBR>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bg= >t=3D3D3B <=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3D3B I don=3D3D
&= >gt=3B >=3B>=3B >=3B't have the cm3 tarball=3D3D2C but I do have the s= >ources in cm3/ still.<=3BBR=3D
>=3B >=3B>=3B&=3Bgt=3D3D
&g= >t=3B >=3B>=3B >=3B=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B Mika Nystrom= > wrote:<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B Hello everyo=3D
&= >gt=3B >=3Bne=3D3D2C<=3BBR>=3B&=3Bg=3D3D
>=3B >=3B>=3B >= >=3Bt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3= >B This is=3D3D2C for me=3D3D2C a most un=3D
>=3B >=3Bfortunate time = >=3D3D
>=3B >=3B>=3B >=3Bfor the CM3 servers to<=3BBR>=3B&= >=3Bgt=3D3D3B &=3Bgt=3D3D3B have crashed. I'm teaching a=3D
>=3B >= >=3B class =3D3D
>=3B >=3B>=3B >=3Busing Modula-3=3D3D2C and we n= >eed a<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B compiler... here'=3DR>>=3B >=3Bs the una=3D3D
>=3B >=3B>=3B >=3Bme of the system= > I'm trying to use:<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B <=3BBR= >>=3B&=3Bgt=3D3D3B &=3Bg=3D
>=3B >=3Bt=3D3D3B Linu=3D3D
&g= >t=3B >=3B>=3B >=3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2= >008 i686 GNU/Linux<=3BBR=3D
>=3B >=3B>=3B&=3Bg=3D3D
>=3B= > >=3B>=3B >=3Bt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3= >B &=3Bgt=3D3D3B The most recent archives I have fo=3D
>=3B >=3Br = >Linux are=3D3D
>=3B >=3B>=3B >=3B:<=3BBR>=3B&=3Bgt=3D3D3B= > &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B cm3-min-P= OSIX-LINUXLIBC6-5.=3D
>=3B >=3B4.0.tgz cm3=3D3D
>=3B >=3B>= >=3B >=3B-src-all-5.4.0.tgz <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3= >B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B And they =3D
>=3B &g= >t=3Bdon't seem =3D3D
>=3B >=3B>=3B >=3Bto work on this system: I= > can compile a program<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B but= >=3D
>=3B >=3B when I=3D3D
>=3B >=3B>=3B >=3B try to run i= >t=3D3D2C it says "Segmentation fault". Can anyone<=3BBR>=3B&=3Bgt=3D= >3D3B=3D
>=3B >=3B &=3Bgt=3D3D3B=3D3D
>=3B >=3B>=3B >= >=3B help? (My understanding is that I need 5.5.1 or later...)<=3BBR>=3B= >&=3Bgt=3D3D3B &=3B=3D
>=3B >=3Bgt=3D3D3B=3D3D
>=3B >=3B= >>=3B >=3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B Mika<=3BBR&= >gt=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B <= >=3BBR>=3B<=3B/body=3D
>=3B >=3B>=3B
>=3B >=3B>=3B >= >=3B<=3B/html>=3B=3D3D
>=3B >=3B>=3B >=3B
>=3B >=3B>= >=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_--
>=3B >=3B
&g= >t=3B >=3B--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_
>=3B >=3BContent= >-Type: text/html=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer= >-Encoding: quoted-printable
>=3B >=3B
>=3B >=3B<=3Bhtml>= >=3B
>=3B >=3B<=3Bhead>=3B
>=3B >=3B<=3Bstyle>=3B
&= >gt=3B >=3B.hmmessage P
>=3B >=3B{
>=3B >=3Bmargin:0px=3D3B<= >BR>>=3B >=3Bpadding:0px
>=3B >=3B}
>=3B >=3Bbody.hmmessag= >e
>=3B >=3B{
>=3B >=3Bfont-size: 10pt=3D3B
>=3B >=3Bfo= >nt-family:Verdana
>=3B >=3B}
>=3B >=3B<=3B/style>=3B
&= >gt=3B >=3B<=3B/head>=3B
>=3B >=3B<=3Bbody class=3D3D'hmmessa= >ge'>=3B
>=3B >=3BThese archives do have a different format=3D2C ye= >s.<=3BBR>=3B
>=3B >=3BBut it isn't a bad format.<=3BBR>=3BR>>=3B >=3Bcminstall is pretty worthless imho.<=3BBR>=3B
>=3B = >>=3BExtract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.<=3BBR>=3B<= >BR>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp= >=3D3B- Jay<=3BBR>=3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3B&=3B= >gt=3D3B To: jay.krell at cornell.edu<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B = >>=3B Subject: Re: [M3devel] Help finding CM3 compiler for Linux? <=3BBR= >>=3B&=3Bgt=3D3B Dat=3D
>=3B >=3Be: Tue=3D2C 31 Mar 2009 15:56:1= >1 -0700<=3BBR>=3B&=3Bgt=3D3B From: mika at async.caltech.edu=3D
>= >=3B >=3B<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B No=3D2C= > I'm sorry...<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B the = >archives =3D
>=3B >=3Bdo not have the usual format. I'm expecting to= > unpack<=3BBR>=3B&=3Bgt=3D3B and run "cm=3D
>=3B >=3Binstall"= > and then unpack the big source tar on top and <=3BBR>=3B&=3Bgt=3D3B= > build tha=3D
>=3B >=3Bt. But there's no cminstall in the archive on= > this page.<=3BBR>=3B&=3Bgt=3D3B This is =3D
>=3B >=3B"the no= >rmal procedure" for installing CM3=3D2C no? It's what<=3BBR>=3B&=3Bg= >t=3D3B the in=3D
>=3B >=3Bstructions say to do=3D2C as well...<=3B= >BR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B And the link from t=3D<= >BR>>=3B >=3Bhe "Download" page is broken (to -d5.5.0.tgz).<=3BBR>= >=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Mika<=3BBR=3D
>=3B &g= >t=3B>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Jay writes:<=3BBR&g= >t=3B&=3Bgt=3D3B &=3Bgt=3D3B--_806446ae-8d10-4d74-8eea-5=3D
>=3B = >>=3B1aa365e9204_<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BContent-Type: = >text/plain=3D3B charset=3D3D"iso-885=3D
>=3B >=3B9-1"<=3BBR>=3B&= >amp=3Bgt=3D3B &=3Bgt=3D3BContent-Transfer-Encoding: quoted-printable<= >=3BBR>=3B&=3Bgt=3D3B =3D
>=3B >=3B&=3Bgt=3D3B<=3BBR>=3B&= >amp=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B htt= >p://modula3.elegosoft.com/cm3/u=3D
>=3B >=3Bploaded-archives<=3BBR= >>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3B?<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D= >
>=3B >=3B=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &a= >mp=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BI can make another l= >ater t=3D
>=3B >=3Bhis week.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >=3B &= >amp=3Bgt=3D3BAll you need is a working cm3 on any system.<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &= >amp=3Bgt=3D3B&=3Bgt=3D3BFrom there you can build the whole system=3D3D2C= > targeting an=3D
>=3B >=3By system.<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAs long as that cm3 un= >derstands =3D
>=3B >=3BLONGINT and your target system.<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAnd= > it is =3D
>=3B >=3Beasier=3D3D2C but not necessary=3D3D2C if you ha= >ve Python. :)<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3B=3D
>=3B= > >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt= >=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B - Jay<=3B= >BR>=3B&=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B= >&=3Bgt=3D3B Date: Tue=3D3D2C 31 Mar 2009=3D
>=3B >=3B 15:43:41 -0= >500<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B From: martinbi= >shop at bellsouth.net<=3BBR>=3B=3D
>=3B >=3B&=3Bgt=3D3B &=3Bg= >t=3D3B&=3Bgt=3D3B To: mika at async.caltech.edu<=3BBR>=3B&=3Bgt=3D3B= > &=3Bgt=3D3B&=3Bgt=3D3B CC: m=3D
>=3B >=3B3devel at elegosoft.com= ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B Subject: Re: [M3d= >evel] Help fin=3D
>=3B >=3Bding CM3 compiler for Linux?<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bg= >t=3D3B &=3Bgt=3D3B&=3Bg=3D
>=3B >=3Bt=3D3B Not sure if this he= >lps=3D3D2C but on my linux system:<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3B&=3Bg=3D
>=3B >=3Bt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &am= >p=3Bgt=3D3B&=3Bgt=3D3B Critical Mass Modula-3 version d5.7.0<=3BBR>= >=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B last upd= >ated: 2008-03-16<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B c= >ompiled=3D
>=3B >=3B: 2008-08-14 00:56:14<=3BBR>=3B&=3Bgt=3D3= >B &=3Bgt=3D3B&=3Bgt=3D3B configuration: /usr/local/cm3/=3D
>=3B = >>=3Bbin/cm3.cfg<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B= >=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B Linux thin= >kp=3D
>=3B >=3Bad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2= >009<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bg=3D
>=3B >=3Bt= >=3D3B i686 GNU/Linux<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D= >3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20= >=3D
>=3B >=3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D= >3B I don't have the cm3 tarball=3D3D2C but I do have the=3D
>=3B >= >=3B sources in cm3/ still.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B = >=3D
>=3B >=3BMika Nystrom wrote:<=3BBR>=3B&=3Bgt=3D3B &=3B= >gt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B Hello everyone=3D3D2C<=3BBR>=3B&am= >p=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B= >=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt= >=3D3B This is=3D3D2C fo=3D
>=3B >=3Br me=3D3D2C a most unfortunate t= >ime for the CM3 servers to<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B have crashed. I'm teaching a = >class using Modula-3=3D3D2C and we n=3D
>=3B >=3Beed a<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B compiler... here= >'s the uname of the sys=3D
>=3B >=3Btem I'm trying to use:<=3BBR&g= >t=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3B= >BR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3B=3D
>=3B >=3Bgt=3D3B &am= >p=3Bgt=3D3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i68= >=3D
>=3B >=3B6 GNU/Lin=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3Bux<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3= >B=3D3D20<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &=3Bgt=3D3B&= >=3Bgt=3D3B &=3Bgt=3D3B The most recent archives I have for Linux are:<= >=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B = >&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt= >=3D3B &=3Bgt=3D3B cm3-min-POSIX-=3D
>=3B >=3BLINUXLIBC6-5.4.0.tgz= > cm3-src-all-5.4.0.tgz=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&am= >p=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B=3D3D20<=3BBR>=3B&=3Bg= >t=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B And they don't seem to w= >ork on this =3D
>=3B >=3Bsystem: I can compile a program<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B but when I tr= >=3D
>=3B >=3By to run it=3D3D2C it says "Segmentation fault". Can an= >yone<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3B=3D
>=3B >=3Bg= >t=3D3B &=3Bgt=3D3B help? (My understanding is that I need 5.5.1 or later= >...)<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bg= >t=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Bgt=3D3B &=3Bgt=3D3B Mika<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >= >=3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3B= >gt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &am= >p=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B-= >-_806446ae-8d10-4d74-8eea-51aa365e9204_<=3BBR>=3B&=3Bgt=3D3B &=3B= >gt=3D3BConten=3D
>=3B >=3Bt-Type: text/html=3D3B charset=3D3D"iso-88= >59-1"<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BContent-Transfe=3D
>= >=3B >=3Br-Encoding: quoted-printable<=3BBR>=3B&=3Bgt=3D3B &=3Bg= >t=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3Bhtml&=3Bg= >t=3D
>=3B >=3B=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Blt=3D3Bhead&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Blt=3D3Bstyle&=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D= >3B &=3Bgt=3D3B.hmmessage P<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B{&l= >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bmargin:0px=3D3D3B<=3B=3D
>= >=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bpadding:0px<=3BBR>=3B&am= >p=3Bgt=3D3B &=3Bgt=3D3B}<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bbody.= >hmmessag=3D
>=3B >=3Be<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B{&l= >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfont-size: 10pt=3D3D3B<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3Bfo=3D
>=3B >=3Bnt-family:Verdana<= >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B}<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B&=3Blt=3D3B/style&=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>= >=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3B/head&=3Bgt=3D3B<=3BBR&g= >t=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3Bbody class=3D3D3D'hmmessa=3D= >
>=3B >=3Bge'&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BA href=3D3D3D"http://modula3.=3D<= >BR>>=3B >=3Belegosoft.com/cm3/uploaded-archives" targ=3D3D<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3Bet=3D3D3D_blank&=3B=3D
>=3B >=3Bg= >t=3D3B&=3Blt=3D3BFONT color=3D3D3D#0068cf&=3Bgt=3D3Bhttp://modula3.el= >egosoft.com/cm3/upl=3D
>=3B >=3Boaded=3D3D<=3BBR>=3B&=3Bgt=3D= >3B &=3Bgt=3D3B-archives&=3Blt=3D3B/FONT&=3Bgt=3D3B&=3Blt=3D3B/A= >&=3Bgt=3D3B&=3Blt=3D3BBR&=3Bg=3D
>=3B >=3Bt=3D3B<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3B?&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3B=3D= >
>=3B >=3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3= >BI can make another later this week.&=3Blt=3D3BBR&=3Bgt=3D3B<=3B=3D= >
>=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp= >=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3BAll you need=3D
>=3B >=3B is a working cm3 on any system.&= >=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Bgt=3D3BFrom t=3D
>=3B >=3Bhere you can build the whole system=3D3= >D2C targeting any system.&=3Blt=3D3BBR&=3Bgt=3D
>=3B >=3B=3D3B= ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAs long as that cm3 understands = >LONGINT and your target=3D
>=3B >=3B system.&=3Blt=3D3BBR&=3Bg= >t=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAnd it is easier=3D3D2C bu= >t not necess=3D
>=3B >=3Bary=3D3D2C if you have Python. :)&=3Blt= >=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp= >=3D3Bnbsp=3D
>=3B >=3B=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR&= >gt=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B- Jay&=3Blt= >=3D3BBR&=3Bgt=3D3B&=3Blt=3D
>=3B >=3B=3D3BBR&=3Bgt=3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3= >B Date: Tue=3D3D2C 31 M=3D
>=3B >=3Bar 2009 15:43:41 -=3D3D<=3BBR&= >gt=3B&=3Bgt=3D3B &=3Bgt=3D3B0500&=3Blt=3D3BBR&=3Bgt=3D3B&=3B= >amp=3D3Bgt=3D3D3B From=3D
>=3B >=3B: martinbishop at bellsouth.net&= >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B To: mika at async.ca=3D
= >>=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bltech.edu&= >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B CC: m3devel at elego=3D
= >>=3B >=3Bsoft.com&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B= > Subject: Re: [M3dev=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D
>= >=3B >=3B=3D3Bel] Help finding CM3 compiler for Linux?&=3Blt=3D3BBR&= >=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D
>=3B >=3B=3D3BBR&= >=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B Not sure if t=3D3D<=3BBR>=3B&=3Bg= >t=3D3B &=3Bgt=3D3Bhis helps=3D3D2C b=3D
>=3B >=3But on my linux s= >ystem:&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3B= >BR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D
>=3B >=3B=3D3D3B Critical Mass = >Mod=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bula-3 version d5.7.0&= >=3Blt=3D3BBR&=3Bgt=3D
>=3B >=3B=3D3B&=3Bamp=3D3Bgt=3D3D3B last= > updated: 2008-03-16&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B = >comp=3D
>=3B >=3Biled:=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3B 2008-08-14 00:56:14&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3= >B c=3D
>=3B >=3Bonfiguration: /usr/local/cm3/bin/cm3.cfg&=3Blt=3D= >3BBR=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B&=3B= >=3D
>=3B >=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3B= >amp=3D3Bgt=3D3D3B Linux thinkpad 2.6.27-11-generic=3D
>=3B >=3B #1 S= >MP Thu Jan 29 19:24=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B:39 UTC = >2009&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3= >D3B i686 GNU/Linux&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &a= >mp=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3B=3D
>=3B >=3Bgt=3D3D3B &a= >mp=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B I don=3D3D<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3B't have the c=3D
>=3B >=3Bm3 tarball= >=3D3D2C but I do have the sources in cm3/ still.&=3Blt=3D3BBR&=3Bgt= >=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D<=3BBR>=3B&=3Bgt=3D3B= > &=3Bgt=3D3B=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D= >3B Mika Nystrom wr=3D
>=3B >=3Bote:&=3Blt=3D3BBR&=3Bgt=3D3B&am= >p=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B Hello everyone=3D3D2C&=3B= >lt=3D3BBR=3D
>=3B >=3B&=3Bgt=3D3B&=3Bamp=3D3Bg=3D3D<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3Bt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt= >=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D3B &=3Bam= >p=3D3Bgt=3D3D3B This is=3D3D2C for me=3D3D2C a most unfortunate time =3D>>=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfor the CM3 s= >ervers to&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp= >=3D
>=3B >=3B=3D3Bgt=3D3D3B have crashed. I'm teaching a class =3D3D= ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Busing Mod=3D
>=3B >=3Bula= >-3=3D3D2C and we need a&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D= >3B &=3Bamp=3D3Bgt=3D3D3B compile=3D
>=3B >=3Br... here's the una= >=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bme of the system I'm trying= > to use:&=3B=3D
>=3B >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt= >=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp= >=3D3Bgt=3D3D3B &=3Bam=3D
>=3B >=3Bp=3D3Bgt=3D3D3B Linu=3D3D<=3B= >BR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 1= >0=3D
>=3B >=3B:53:03 PST 2008 i686 GNU/Linux&=3Blt=3D3BBR&=3Bg= >t=3D3B&=3Bamp=3D3Bg=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bt=3D<= >BR>>=3B >=3B=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt= >=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B The most r=3D
>= >=3B >=3Becent archives I have for Linux are=3D3D<=3BBR>=3B&=3Bgt= >=3D3B &=3Bgt=3D3B:&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B = >>=3B=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3= >B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B cm3-m=3D
>=3B >= >=3Bin-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D3D<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B-src-all-5.4.0.tgz &=3Blt=3D
>=3B =3D3BBR&=3Bgt=3D3B&a= >mp=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt= >=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D3B = >And they don't seem =3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bto work= > on this system: =3D
>=3B >=3BI can compile a program&=3Blt=3D3BB= >R&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B but when= >=3D
>=3B >=3B I=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B try = >to run it=3D3D2C it says "Segmentation fault". Can=3D
>=3B >=3B anyo= >ne&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt= >=3D3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B help=3D
>=3B &= >gt=3B? (My understanding is that I need 5.5.1 or later...)&=3Blt=3D3BBR&= >amp=3Bgt=3D3B&=3Bamp=3D3Bg=3D
>=3B >=3Bt=3D3D3B &=3Bamp=3D3Bgt= >=3D3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B &=3Blt=3D3BBR&am= >p=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D
>=3B >=3B=3D3Bgt= >=3D3D3B Mika&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Ba= >mp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Ba=3D
>=3B >=3B= >mp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Blt=3D3B/body&=3Bgt= >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3B/html&=3Bg= >t=3D
>=3B >=3B=3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >lt=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B--_806446ae-8d10-4d74-8eea-51aa36= >5e=3D
>=3B >=3B9204_--<=3BBR>=3B<=3B/body>=3B
>=3B >= >=3B<=3B/html>=3B=3D
>=3B >=3B
>=3B >=3B--_777fdc4e-3c29-4= >0b4-a3dd-e6243f796cee_--
>= > >--_55339e45-8c85-4ab6-9440-0d2131bbad69_-- From mika at async.caltech.edu Wed Apr 1 08:53:38 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 31 Mar 2009 23:53:38 -0700 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: Your message of "Wed, 01 Apr 2009 06:13:00 -0000." Message-ID: <200904010653.n316rcZs073236@camembert.async.caltech.edu> To be honest, I'm not so sure what's intended. I either get this: "/home/mika/cm3/cm3-std-LINUXLIBC6-d5.7.0/bin/cm3.cfg", line 125: quake runtime error: unable to find a configuration file for (/home/mika/cm3/cm3-std-LINUXLIBC6-d5.7.0/bin/.., /afs/.ugcs/user/mika/cm3/cm3-std-LINUXLIBC6-d5.7.0, LINUXLIBC6) or, if I put back the LINUXLIBC6 file you had me delete: "/home/mika/cm3/cm3-std-LINUXLIBC6-d5.7.0/bin/cm3.cfg", line 128: quake runtime error: /home/mika/cm3/cm3-std-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6, line 61: syntax error: missing: <*EOF*> (found: ) which refers to the following (which looks like cminstall stuff to me): INITIAL_REACTOR_EDITOR = BEGIN_CONFIG "What should be the default text editor for new Reactor users?" <--- this line 10 "EDITOR" 0 "emacsclient" 0 "emacs" 0 "vi" 0 "textedit" 0 "xedit" 6 "/usr/local/emacs/bin" "emacsclient" 6 "/usr/local/bin" "emacsclient" 6 "/usr/local/emacs/bin" "emacs" 6 "/usr/local/bin" "emacs" 6 "/usr/bin" "vi" 6 "/usr/local/X11R5/bin" "xedit" 6 "/usr/openwin/bin" "textedit" Jay writes: >--_55339e45-8c85-4ab6-9440-0d2131bbad69_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Maybe not. > >Hm. That is bug. There is use with a cvs tree=2C and use without. > >I must have broken use without. > >=20 > >Try this: > >export CM3_ROOT=3Droot of cm3 cvs (for me this is /dev2/cm3=2C > >for you=2C maybe $HOME/cm3?) > >rm $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6 > ># *Common and *common in one command >rm $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/*ommon >cp root of cm3 cvs/m3-sys/cminstall/src/config/cm3.cfg $HOME/cm3/cm3-min-LI= >NUXLIBC6-d5.7.0/bin > >=20 > >The .cfg will delegate out to the cvs tree. > >I don't like having two copies of files..having to keep them in sync.. > > Though the archives are meant to work standalone=2C without CVS. > > But I don't test that so much oops sorry. > >That /might/ not be the right file=2C but it is close. > >=20 > > - Jay > >=20 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux?=20 >> Date: Tue=2C 31 Mar 2009 22:59:18 -0700 >> From: mika at async.caltech.edu >>=20 >>=20 >> Is there any documentation for this format beyond what you just >> wrote? Where? >>=20 >> terpsichore-14: cm3 >> --- building in ../LINUXLIBC6 --- >>=20 >> new source -> compiling Main.m3 >> "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common"=2C= > line 169: quake runtime error: undefined variable: ROOT >>=20 >> --procedure-- -line- -file--- >> GetM3Back 169 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3c= >fg.common >> _IsM3BackFlagSupported 181 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5= >.7.0/bin/Unix.common >> IsM3BackFlagSupported 193 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.= >7.0/bin/Unix.common >> GetM3BackFlag 197 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/= >Unix.common >> m3_backend 62 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix= >.common >> program -- >> 6 /afs/.ugcs.caltech.edu/user/mika/test/LINUXLIBC6/m3make.args >>=20 >>=20 >> Fatal Error: procedure "m3_backend" defined in "/afs/.ugcs/user/mika/cm3/= >cm3-min-LINUXLIBC6-d5.7.0/bin/cm3.cfg" failed. >>=20 >> Jay writes: >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> >These archives do have a different format=3D2C yes. >> > >> >But it isn't a bad format. >> > >> >cminstall is pretty worthless imho. >> > >> >Extract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH. >> > >> >=3D20 >> > >> > - Jay >> > >> >=3D20 >> >> To: jay.krell at cornell.edu >> >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux?=3D20 >> >> Date: Tue=3D2C 31 Mar 2009 15:56:11 -0700 >> >> From: mika at async.caltech.edu >> >>=3D20 >> >> No=3D2C I'm sorry... >> >>=3D20 >> >> the archives do not have the usual format. I'm expecting to unpack >> >> and run "cminstall" and then unpack the big source tar on top and=3D20 >> >> build that. But there's no cminstall in the archive on this page. >> >> This is "the normal procedure" for installing CM3=3D2C no? It's what >> >> the instructions say to do=3D2C as well... >> >>=3D20 >> >> And the link from the "Download" page is broken (to -d5.5.0.tgz). >> >>=3D20 >> >> Mika >> >>=3D20 >> >> Jay writes: >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ >> >> >Content-Type: text/plain=3D3B charset=3D3D"iso-8859-1" >> >> >Content-Transfer-Encoding: quoted-printable >> >> > >> >> > >> >> > http://modula3.elegosoft.com/cm3/uploaded-archives >> >> > >> >> >? >> >> > >> >> >=3D3D20 >> >> > >> >> >I can make another later this week. >> >> > >> >> >=3D3D20 >> >> > >> >> >All you need is a working cm3 on any system. >> >> > >> >> >>From there you can build the whole system=3D3D2C targeting any syste= >m. >> >> > >> >> >As long as that cm3 understands LONGINT and your target system. >> >> > >> >> >And it is easier=3D3D2C but not necessary=3D3D2C if you have Python. = >:) >> >> > >> >> >=3D3D20 >> >> > >> >> > - Jay >> >> > >> >> >=3D3D20 >> >> >> Date: Tue=3D3D2C 31 Mar 2009 15:43:41 -0500 >> >> >> From: martinbishop at bellsouth.net >> >> >> To: mika at async.caltech.edu >> >> >> CC: m3devel at elegosoft.com >> >> >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >> >> >>=3D3D20 >> >> >> Not sure if this helps=3D3D2C but on my linux system: >> >> >>=3D3D20 >> >> >> Critical Mass Modula-3 version d5.7.0 >> >> >> last updated: 2008-03-16 >> >> >> compiled: 2008-08-14 00:56:14 >> >> >> configuration: /usr/local/cm3/bin/cm3.cfg >> >> >>=3D3D20 >> >> >> Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 200= >9 >> >> >> i686 GNU/Linux >> >> >>=3D3D20 >> >> >>=3D3D20 >> >> >> I don't have the cm3 tarball=3D3D2C but I do have the sources in cm= >3/ st=3D >> >ill. >> >> >>=3D3D20 >> >> >> Mika Nystrom wrote: >> >> >> > Hello everyone=3D3D2C >> >> >> >=3D3D20 >> >> >> > This is=3D3D2C for me=3D3D2C a most unfortunate time for the CM3 = >servers=3D >> > to >> >> >> > have crashed. I'm teaching a class using Modula-3=3D3D2C and we n= >eed a >> >> >> > compiler... here's the uname of the system I'm trying to use: >> >> >> >=3D3D20 >> >> >> > Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 G= >NU/=3D >> >Lin=3D3D >> >> >ux >> >> >> >=3D3D20 >> >> >> > The most recent archives I have for Linux are: >> >> >> >=3D3D20 >> >> >> > cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D3D20 >> >> >> >=3D3D20 >> >> >> > And they don't seem to work on this system: I can compile a progr= >am >> >> >> > but when I try to run it=3D3D2C it says "Segmentation fault". Can= > anyo=3D >> >ne >> >> >> > help? (My understanding is that I need 5.5.1 or later...) >> >> >> >=3D3D20 >> >> >> > Mika >> >> >> >=3D3D20 >> >> >>=3D3D20 >> >> > >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ >> >> >Content-Type: text/html=3D3B charset=3D3D"iso-8859-1" >> >> >Content-Transfer-Encoding: quoted-printable >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > =3D3D3Barchive=3D >> >s" targ=3D3D >> >> >et=3D3D3D_blank>http://modula3.elegosoft.co= >m/cm3/u=3D >> >ploaded=3D3D >> >> >-archives
>> >> >?
>> >> > =3D3D3B
>> >> >I can make another later this week.
>> >> > =3D3D3B
>> >> >All you need is a working cm3 on any system.
>> >> >>From there you can build the whole system=3D3D2C targeting any syste= >m.> >> >> >> >As long as that cm3 understands LONGINT and your target system.
>> >> >And it is easier=3D3D2C but not necessary=3D3D2C if you have Python. = >:)
>> >> > =3D3D3B
>> >> > =3D3D3B- Jay

 =3D3D3B
>=3D3D3B Date: Tue=3D3D2C = >31 Mar 2009=3D >> > 15:43:41 -=3D3D >> >> >0500
>=3D3D3B From: martinbishop at bellsouth.net
>=3D3D3B To:= > mika at a=3D >> >sync.ca=3D3D >> >> >ltech.edu
>=3D3D3B CC: m3devel at elegosoft.com
>=3D3D3B Subje= >ct: Re:=3D >> > [M3dev=3D3D >> >> >el] Help finding CM3 compiler for Linux?
>=3D3D3B
>=3D3D3B= > Not su=3D >> >re if t=3D3D >> >> >his helps=3D3D2C but on my linux system:
>=3D3D3B
>=3D3D3B= > Critical=3D >> > Mass Mod=3D3D >> >> >ula-3 version d5.7.0
>=3D3D3B last updated: 2008-03-16
>=3D= >3D3B co=3D >> >mpiled:=3D3D >> >> > 2008-08-14 00:56:14
>=3D3D3B configuration: /usr/local/cm3/bin/= >cm3.c=3D >> >fg> >> >>>=3D3D3B
>=3D3D3B Linux thinkpad 2.6.27-11-generic #1 SMP Th= >u Jan 2=3D >> >9 19:24=3D3D >> >> >:39 UTC 2009
>=3D3D3B i686 GNU/Linux
>=3D3D3B
>=3D3D3= >B
>=3D >> >=3D3D3B I don=3D3D >> >> >'t have the cm3 tarball=3D3D2C but I do have the sources in cm3/ stil= >l.> >>>=3D3D >> >> >=3D3D3B
>=3D3D3B Mika Nystrom wrote:
>=3D3D3B >=3D3D3B H= >ello everyo=3D >> >ne=3D3D2C
&g=3D3D >> >> >t=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B This is=3D3D2C for me= >=3D3D2C a most un=3D >> >fortunate time =3D3D >> >> >for the CM3 servers to
>=3D3D3B >=3D3D3B have crashed. I'm tea= >ching a=3D >> > class =3D3D >> >> >using Modula-3=3D3D2C and we need a
>=3D3D3B >=3D3D3B compiler= >... here'=3D >> >s the una=3D3D >> >> >me of the system I'm trying to use:
>=3D3D3B >=3D3D3B
>= >=3D3D3B &g=3D >> >t=3D3D3B Linu=3D3D >> >> >x lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Linux= >> >>&g=3D3D >> >> >t=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B The most recent archive= >s I have fo=3D >> >r Linux are=3D3D >> >> >:
>=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B cm3-min-POSIX-LI= >NUXLIBC6-5.=3D >> >4.0.tgz cm3=3D3D >> >> >-src-all-5.4.0.tgz
>=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3= >B And they =3D >> >don't seem =3D3D >> >> >to work on this system: I can compile a program
>=3D3D3B >=3D3= >D3B but=3D >> > when I=3D3D >> >> > try to run it=3D3D2C it says "Segmentation fault". Can anyone
>= >=3D3D3B=3D >> > >=3D3D3B=3D3D >> >> > help? (My understanding is that I need 5.5.1 or later...)
>=3D3= >D3B &=3D >> >gt=3D3D3B=3D3D >> >> >
>=3D3D3B >=3D3D3B Mika
>=3D3D3B >=3D3D3B
>=3D3D= >3B
> >> >> >> >=3D3D >> >> > >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_-- >> > >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ >> >Content-Type: text/html=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> > >> > >> > >> > >> >These archives do have a different format=3D2C yes.
>> >But it isn't a bad format.
>> >cminstall is pretty worthless imho.
>> >Extract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.
>> > =3D3B
>> > =3D3B- Jay

 =3D3B
>=3D3B To: jay.krell at cornell.edu<= >BR>>=3D3B=3D >> > Subject: Re: [M3devel] Help finding CM3 compiler for Linux?
>=3D3= >B Dat=3D >> >e: Tue=3D2C 31 Mar 2009 15:56:11 -0700
>=3D3B From: mika at async.calt= >ech.edu=3D >> >
>=3D3B
>=3D3B No=3D2C I'm sorry...
>=3D3B
>=3D3B = >the archives =3D >> >do not have the usual format. I'm expecting to unpack
>=3D3B and ru= >n "cm=3D >> >install" and then unpack the big source tar on top and
>=3D3B buil= >d tha=3D >> >t. But there's no cminstall in the archive on this page.
>=3D3B Thi= >s is =3D >> >"the normal procedure" for installing CM3=3D2C no? It's what
>=3D3B= > the in=3D >> >structions say to do=3D2C as well...
>=3D3B
>=3D3B And the li= >nk from t=3D >> >he "Download" page is broken (to -d5.5.0.tgz).
>=3D3B
>=3D3B = >Mika> >>>=3D3B
>=3D3B Jay writes:
>=3D3B >=3D3B--_806446ae-8d10-= >4d74-8eea-5=3D >> >1aa365e9204_
>=3D3B >=3D3BContent-Type: text/plain=3D3B charset= >=3D3D"iso-885=3D >> >9-1"
>=3D3B >=3D3BContent-Transfer-Encoding: quoted-printable
= >>=3D3B =3D >> >>=3D3B
>=3D3B >=3D3B
>=3D3B >=3D3B http://modula3.elegos= >oft.com/cm3/u=3D >> >ploaded-archives
>=3D3B >=3D3B
>=3D3B >=3D3B?
>=3D3B = >>=3D3B
>=3D >> >=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B
>=3D3B >=3D3BI can mak= >e another later t=3D >> >his week.
>=3D3B >=3D3B
>=3D3B >=3D3B=3D3D20
>=3D3B &= >gt=3D3B
>=3D3B=3D >> > >=3D3BAll you need is a working cm3 on any system.
>=3D3B >=3D= >3B
>=3D >> >=3D3B >=3D3B>=3D3BFrom there you can build the whole system=3D3D2C t= >argeting an=3D >> >y system.
>=3D3B >=3D3B
>=3D3B >=3D3BAs long as that cm3 u= >nderstands =3D >> >LONGINT and your target system.
>=3D3B >=3D3B
>=3D3B >=3D3= >BAnd it is =3D >> >easier=3D3D2C but not necessary=3D3D2C if you have Python. :)
>=3D3= >B >=3D3B<=3D >> >BR>>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B
>=3D3B >=3D3B - = >Jay
>=3D3B >=3D >> >=3D3B
>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B Date: Tue= >=3D3D2C 31 Mar 2009=3D >> > 15:43:41 -0500
>=3D3B >=3D3B>=3D3B From: martinbishop at bellsout= >h.net
=3D >> >>=3D3B >=3D3B>=3D3B To: mika at async.caltech.edu
>=3D3B >=3D3= >B>=3D3B CC: m=3D >> >3devel at elegosoft.com
>=3D3B >=3D3B>=3D3B Subject: Re: [M3devel]= > Help fin=3D >> >ding CM3 compiler for Linux?
>=3D3B >=3D3B>=3D3B=3D3D20
>= >=3D3B >=3D3B&g=3D >> >t=3D3B Not sure if this helps=3D3D2C but on my linux system:
>=3D3B= > >=3D3B&g=3D >> >t=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B Critical Mass Modula-3 versio= >n d5.7.0
&=3D >> >gt=3D3B >=3D3B>=3D3B last updated: 2008-03-16
>=3D3B >=3D3B&g= >t=3D3B compiled=3D >> >: 2008-08-14 00:56:14
>=3D3B >=3D3B>=3D3B configuration: /usr/l= >ocal/cm3/=3D >> >bin/cm3.cfg
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B >=3D3B>= >=3D3B Linux thinkp=3D >> >ad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009
>=3D3B >= >=3D3B&g=3D >> >t=3D3B i686 GNU/Linux
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B &g= >t=3D3B>=3D3B=3D3D20=3D >> >
>=3D3B >=3D3B>=3D3B I don't have the cm3 tarball=3D3D2C but I = >do have the=3D >> > sources in cm3/ still.
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B = >>=3D3B>=3D3B =3D >> >Mika Nystrom wrote:
>=3D3B >=3D3B>=3D3B >=3D3B Hello everyone= >=3D3D2C
&g=3D >> >t=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B >= >=3D3B This is=3D3D2C fo=3D >> >r me=3D3D2C a most unfortunate time for the CM3 servers to
>=3D3B &= >gt=3D3B&g=3D >> >t=3D3B >=3D3B have crashed. I'm teaching a class using Modula-3=3D3D2C= > and we n=3D >> >eed a
>=3D3B >=3D3B>=3D3B >=3D3B compiler... here's the uname= > of the sys=3D >> >tem I'm trying to use:
>=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
&= >gt=3D3B >=3D3B&=3D >> >gt=3D3B >=3D3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2= >008 i68=3D >> >6 GNU/Lin=3D3D
>=3D3B >=3D3Bux
>=3D3B >=3D3B>=3D3B >= >=3D3B=3D3D20
>=3D >> >=3D3B >=3D3B>=3D3B >=3D3B The most recent archives I have for Linu= >x are:
&=3D >> >gt=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B &g= >t=3D3B cm3-min-POSIX-=3D >> >LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D3D20
>=3D3B >=3D3B&g= >t=3D3B >=3D >> >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B >=3D3B And they don't seem t= >o work on this =3D >> >system: I can compile a program
>=3D3B >=3D3B>=3D3B >=3D3B bu= >t when I tr=3D >> >y to run it=3D3D2C it says "Segmentation fault". Can anyone
>=3D3B = >>=3D3B&=3D >> >gt=3D3B >=3D3B help? (My understanding is that I need 5.5.1 or later..= >.)
&=3D >> >gt=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B &g= >t=3D3B Mika
>=3D3B=3D >> > >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B=3D3D20>>=3D3B >=3D3B
&=3D >> >gt=3D3B >=3D3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>=3D3B >= >=3D3BConten=3D >> >t-Type: text/html=3D3B charset=3D3D"iso-8859-1"
>=3D3B >=3D3BCont= >ent-Transfe=3D >> >r-Encoding: quoted-printable
>=3D3B >=3D3B
>=3D3B >=3D3B&l= >t=3D3Bhtml>=3D >> >=3D3B
>=3D3B >=3D3B<=3D3Bhead>=3D3B
>=3D3B >=3D3B<= >=3D3Bstyle>=3D3B
&=3D >> >gt=3D3B >=3D3B.hmmessage P
>=3D3B >=3D3B{
>=3D3B >=3D3Bm= >argin:0px=3D3D3B<=3D >> >BR>>=3D3B >=3D3Bpadding:0px
>=3D3B >=3D3B}
>=3D3B >=3D= >3Bbody.hmmessag=3D >> >e
>=3D3B >=3D3B{
>=3D3B >=3D3Bfont-size: 10pt=3D3D3B
&g= >t=3D3B >=3D3Bfo=3D >> >nt-family:Verdana
>=3D3B >=3D3B}
>=3D3B >=3D3B<=3D3B/sty= >le>=3D3B
&=3D >> >gt=3D3B >=3D3B<=3D3B/head>=3D3B
>=3D3B >=3D3B<=3D3Bbody c= >lass=3D3D3D'hmmessa=3D >> >ge'>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BA href=3D3D3= >D"http://modula3.=3D >> >elegosoft.com/cm3/uploaded-archives" targ=3D3D
>=3D3B >=3D3Bet=3D= >3D3D_blank&=3D >> >gt=3D3B<=3D3BFONT color=3D3D3D#0068cf>=3D3Bhttp://modula3.elegosoft.= >com/cm3/upl=3D >> >oaded=3D3D
>=3D3B >=3D3B-archives<=3D3B/FONT>=3D3B<=3D3B/A&= >gt=3D3B<=3D3BBR&g=3D >> >t=3D3B
>=3D3B >=3D3B?<=3D3BBR>=3D3B
>=3D3B >=3D3B&= >=3D3Bnbsp=3D3D3B<=3D3B=3D >> >BR>=3D3B
>=3D3B >=3D3BI can make another later this week.<=3D= >3BBR>=3D3B<=3D >> >BR>>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
>=3D3B &= >gt=3D3BAll you need=3D >> > is a working cm3 on any system.<=3D3BBR>=3D3B
>=3D3B >=3D3B&= >gt=3D3BFrom t=3D >> >here you can build the whole system=3D3D2C targeting any system.<=3D3B= >BR>=3D >> >=3D3B
>=3D3B >=3D3BAs long as that cm3 understands LONGINT and yo= >ur target=3D >> > system.<=3D3BBR>=3D3B
>=3D3B >=3D3BAnd it is easier=3D3D2C b= >ut not necess=3D >> >ary=3D3D2C if you have Python. :)<=3D3BBR>=3D3B
>=3D3B >=3D3B= >&=3D3Bnbsp=3D >> >=3D3D3B<=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B- Jay&= >lt=3D3BBR>=3D3B<=3D >> >=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B = >Date: Tue=3D3D2C 31 M=3D >> >ar 2009 15:43:41 -=3D3D
>=3D3B >=3D3B0500<=3D3BBR>=3D3B&= >=3D3Bgt=3D3D3B From=3D >> >: martinbishop at bellsouth.net<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B To: mik= >a at async.ca=3D >> >=3D3D
>=3D3B >=3D3Bltech.edu<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B = >CC: m3devel at elego=3D >> >soft.com<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Subject: Re: [M3dev=3D3D>>=3D3B >=3D >> >=3D3Bel] Help finding CM3 compiler for Linux?<=3D3BBR>=3D3B&=3D3B= >gt=3D3D3B <=3D >> >=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Not sure if t=3D3D
>=3D3B >=3D3= >Bhis helps=3D3D2C b=3D >> >ut on my linux system:<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B <=3D3BBR>= >=3D3B&=3D3Bgt=3D >> >=3D3D3B Critical Mass Mod=3D3D
>=3D3B >=3D3Bula-3 version d5.7.0&= >lt=3D3BBR>=3D >> >=3D3B&=3D3Bgt=3D3D3B last updated: 2008-03-16<=3D3BBR>=3D3B&= >=3D3Bgt=3D3D3B comp=3D >> >iled:=3D3D
>=3D3B >=3D3B 2008-08-14 00:56:14<=3D3BBR>=3D3B&am= >p=3D3Bgt=3D3D3B c=3D >> >onfiguration: /usr/local/cm3/bin/cm3.cfg<=3D3BBR=3D3D
>=3D3B >= >=3D3B>=3D3B&=3D >> >amp=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Linux thinkpad 2.= >6.27-11-generic=3D >> > #1 SMP Thu Jan 29 19:24=3D3D
>=3D3B >=3D3B:39 UTC 2009<=3D3BBR= >>=3D3B&=3D >> >=3D3Bgt=3D3D3B i686 GNU/Linux<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B <=3D= >3BBR>=3D3B&=3D3B=3D >> >gt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B I don=3D3D
>=3D3B &g= >t=3D3B't have the c=3D >> >m3 tarball=3D3D2C but I do have the sources in cm3/ still.<=3D3BBR>= >=3D3B&=3D >> >=3D3Bgt=3D3D
>=3D3B >=3D3B=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt= >=3D3D3B Mika Nystrom wr=3D >> >ote:<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B Hello everyo= >ne=3D3D2C<=3D3BBR=3D >> >>=3D3B&=3D3Bg=3D3D
>=3D3B >=3D3Bt=3D3D3B &=3D3Bgt=3D3D3B = ><=3D3BBR>=3D3B&=3D >> >=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B This is=3D3D2C for me=3D3D2C a most un= >fortunate time =3D >> >=3D3D
>=3D3B >=3D3Bfor the CM3 servers to<=3D3BBR>=3D3B&= >=3D3Bgt=3D3D3B &=3D >> >=3D3Bgt=3D3D3B have crashed. I'm teaching a class =3D3D
>=3D3B >= >=3D3Busing Mod=3D >> >ula-3=3D3D2C and we need a<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3B= >gt=3D3D3B compile=3D >> >r... here's the una=3D3D
>=3D3B >=3D3Bme of the system I'm trying= > to use:&=3D >> >lt=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3= >B&=3D3Bgt=3D3D3B &am=3D >> >p=3D3Bgt=3D3D3B Linu=3D3D
>=3D3B >=3D3Bx lara 2.6.24ugcs1 #4 SMP = >Mon Feb 11 10=3D >> >:53:03 PST 2008 i686 GNU/Linux<=3D3BBR>=3D3B&=3D3Bg=3D3D
>= >=3D3B >=3D3Bt=3D >> >=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3= >Bgt=3D3D3B The most r=3D >> >ecent archives I have for Linux are=3D3D
>=3D3B >=3D3B:<=3D3BBR= >>=3D3B&=3D >> >=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &= >amp=3D3Bgt=3D3D3B cm3-m=3D >> >in-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D3D
>=3D3B >=3D3B-src-all-5.4.= >0.tgz <=3D >> =3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&a= >mp=3D3Bgt=3D3D3B &=3D >> >=3D3Bgt=3D3D3B And they don't seem =3D3D
>=3D3B >=3D3Bto work on = >this system: =3D >> >I can compile a program<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt= >=3D3D3B but when=3D >> > I=3D3D
>=3D3B >=3D3B try to run it=3D3D2C it says "Segmentation = >fault". Can=3D >> > anyone<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B=3D3D
&= >gt=3D3B >=3D3B help=3D >> >? (My understanding is that I need 5.5.1 or later...)<=3D3BBR>=3D3B&= >amp=3D3Bg=3D >> >t=3D3D3B &=3D3Bgt=3D3D3B=3D3D
>=3D3B >=3D3B <=3D3BBR>=3D3B= >&=3D3Bgt=3D3D3B &=3D >> >=3D3Bgt=3D3D3B Mika<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D= >3B <=3D3BBR>=3D3B&a=3D >> >mp=3D3Bgt=3D3D3B <=3D3BBR>=3D3B<=3D3B/body>=3D3B
>=3D3B >= >=3D3B<=3D3B/html>=3D >> >=3D3B=3D3D
>=3D3B >=3D3B
>=3D3B >=3D3B--_806446ae-8d10-4d7= >4-8eea-51aa365e=3D >> >9204_--
>> >=3D >> > >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_-- > >--_55339e45-8c85-4ab6-9440-0d2131bbad69_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Maybe not.
>Hm. That is bug. There is use with a cvs tree=2C and use without.
>I must have broken use without.
> =3B
>Try this:
>export CM3_ROOT=3Droot of cm3 cvs (for me this is /dev2/cm3=2C
>for you=2C maybe $HOME/cm3?)
>rm =3B$HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6
># *Common and *common in one command
rm =3B$HOME/cm3/cm3-min-LINUXLI= >BC6-d5.7.0/bin/*ommon
cp root of cm3 cvs/m3-sys/cminstall/src/config/cm3= >.cfg $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin
> =3B
>The .cfg will delegate out to the cvs tree.
>I don't like having two copies of files..having to keep them in sync..
> =3BThough the archives are meant to work standalone=2C without CVS.> > =3B But I don't test that so much oops sorry.
>That /might/ not be the right file=2C but it is close.
> =3B
> =3B- Jay

 =3B
>=3B To: jay.krell at cornell.edu
>=3B= > CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] Help finding CM= >3 compiler for Linux?
>=3B Date: Tue=2C 31 Mar 2009 22:59:18 -0700>>=3B From: mika at async.caltech.edu
>=3B
>=3B
>=3B Is the= >re any documentation for this format beyond what you just
>=3B wrote? = >Where?
>=3B
>=3B terpsichore-14: cm3
>=3B --- building in .= >./LINUXLIBC6 ---
>=3B
>=3B new source ->=3B compiling Main.m3<= >BR>>=3B "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.co= >mmon"=2C line 169: quake runtime error: undefined variable: ROOT
>=3B = >
>=3B --procedure-- -line- -file---
>=3B GetM3Back 169 /afs/.ugcs= >/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common
>=3B _IsM3B= >ackFlagSupported 181 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin= >/Unix.common
>=3B IsM3BackFlagSupported 193 /afs/.ugcs/user/mika/cm3/c= >m3-min-LINUXLIBC6-d5.7.0/bin/Unix.common
>=3B GetM3BackFlag 197 /afs/.= >ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common
>=3B m3_b= >ackend 62 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.commo= >n
>=3B program -- <=3Bbuiltin>=3B
>=3B 6 /afs/.ugcs.caltech.e= >du/user/mika/test/LINUXLIBC6/m3make.args
>=3B
>=3B
>=3B Fa= >tal Error: procedure "m3_backend" defined in "/afs/.ugcs/user/mika/cm3/cm3-= >min-LINUXLIBC6-d5.7.0/bin/cm3.cfg" failed.
>=3B
>=3B Jay writes:= >
>=3B >=3B--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_
>=3B >=3BC= >ontent-Type: text/plain=3B charset=3D"iso-8859-1"
>=3B >=3BContent-T= >ransfer-Encoding: quoted-printable
>=3B >=3B
>=3B >=3B
>= >=3B >=3BThese archives do have a different format=3D2C yes.
>=3B >= >=3B
>=3B >=3BBut it isn't a bad format.
>=3B >=3B
>=3B &= >gt=3Bcminstall is pretty worthless imho.
>=3B >=3B
>=3B >=3BE= >xtract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.
>=3B >=3B
&= >gt=3B >=3B=3D20
>=3B >=3B
>=3B >=3B - Jay
>=3B >=3B<= >BR>>=3B >=3B=3D20
>=3B >=3B>=3B To: jay.krell at cornell.edu
&= >gt=3B >=3B>=3B Subject: Re: [M3devel] Help finding CM3 compiler for Lin= >ux?=3D20
>=3B >=3B>=3B Date: Tue=3D2C 31 Mar 2009 15:56:11 -0700R>>=3B >=3B>=3B From: mika at async.caltech.edu
>=3B >=3B>=3B= >=3D20
>=3B >=3B>=3B No=3D2C I'm sorry...
>=3B >=3B>=3B=3D= >20
>=3B >=3B>=3B the archives do not have the usual format. I'm ex= >pecting to unpack
>=3B >=3B>=3B and run "cminstall" and then unpac= >k the big source tar on top and=3D20
>=3B >=3B>=3B build that. But= > there's no cminstall in the archive on this page.
>=3B >=3B>=3B T= >his is "the normal procedure" for installing CM3=3D2C no? It's what
>= >=3B >=3B>=3B the instructions say to do=3D2C as well...
>=3B >= >=3B>=3B=3D20
>=3B >=3B>=3B And the link from the "Download" page= > is broken (to -d5.5.0.tgz).
>=3B >=3B>=3B=3D20
>=3B >=3B&g= >t=3B Mika
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B Jay writes:>>=3B >=3B>=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>= >=3B >=3B>=3B >=3BContent-Type: text/plain=3D3B charset=3D3D"iso-8859-= >1"
>=3B >=3B>=3B >=3BContent-Transfer-Encoding: quoted-printable= >
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B
>=3B >= >=3B>=3B >=3B http://modula3.elegosoft.com/cm3/uploaded-archives
>= >=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B?
>=3B >=3B>= >=3B >=3B
>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >= >=3B
>=3B >=3B>=3B >=3BI can make another later this week.
>= >=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B=3D3D20
>=3B >= >=3B>=3B >=3B
>=3B >=3B>=3B >=3BAll you need is a working cm3= > on any system.
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B= >>=3BFrom there you can build the whole system=3D3D2C targeting any system= >.
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3BAs long as tha= >t cm3 understands LONGINT and your target system.
>=3B >=3B>=3B &g= >t=3B
>=3B >=3B>=3B >=3BAnd it is easier=3D3D2C but not necessary= >=3D3D2C if you have Python. :)
>=3B >=3B>=3B >=3B
>=3B >= >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B
>=3B >=3B>= >=3B >=3B - Jay
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >= >=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Date: Tue=3D3D2C 31 Mar 2009= > 15:43:41 -0500
>=3B >=3B>=3B >=3B>=3B From: martinbishop at bell= >south.net
>=3B >=3B>=3B >=3B>=3B To: mika at async.caltech.edu>>=3B >=3B>=3B >=3B>=3B CC: m3devel at elegosoft.com
>=3B >= >=3B>=3B >=3B>=3B Subject: Re: [M3devel] Help finding CM3 compiler for= > Linux?
>=3B >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B &= >gt=3B>=3B Not sure if this helps=3D3D2C but on my linux system:
>=3B= > >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Criti= >cal Mass Modula-3 version d5.7.0
>=3B >=3B>=3B >=3B>=3B last u= >pdated: 2008-03-16
>=3B >=3B>=3B >=3B>=3B compiled: 2008-08-14= > 00:56:14
>=3B >=3B>=3B >=3B>=3B configuration: /usr/local/cm3= >/bin/cm3.cfg
>=3B >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>= >=3B >=3B>=3B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:3= >9 UTC 2009
>=3B >=3B>=3B >=3B>=3B i686 GNU/Linux
>=3B >= >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B=3D3D20>>=3B >=3B>=3B >=3B>=3B I don't have the cm3 tarball=3D3D2C but I= > do have the sources in cm3/ st=3D
>=3B >=3Bill.
>=3B >=3B>= >=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Mika Nystrom wr= >ote:
>=3B >=3B>=3B >=3B>=3B >=3B Hello everyone=3D3D2C
&g= >t=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B&= >gt=3B >=3B This is=3D3D2C for me=3D3D2C a most unfortunate time for the C= >M3 servers=3D
>=3B >=3B to
>=3B >=3B>=3B >=3B>=3B >= >=3B have crashed. I'm teaching a class using Modula-3=3D3D2C and we need a<= >BR>>=3B >=3B>=3B >=3B>=3B >=3B compiler... here's the uname of = >the system I'm trying to use:
>=3B >=3B>=3B >=3B>=3B >=3B=3D= >3D20
>=3B >=3B>=3B >=3B>=3B >=3B Linux lara 2.6.24ugcs1 #4 S= >MP Mon Feb 11 10:53:03 PST 2008 i686 GNU/=3D
>=3B >=3BLin=3D3D
&g= >t=3B >=3B>=3B >=3Bux
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D2= >0
>=3B >=3B>=3B >=3B>=3B >=3B The most recent archives I hav= >e for Linux are:
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>= >=3B >=3B>=3B >=3B>=3B >=3B cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3= >-src-all-5.4.0.tgz=3D3D20
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20= >
>=3B >=3B>=3B >=3B>=3B >=3B And they don't seem to work on = >this system: I can compile a program
>=3B >=3B>=3B >=3B>=3B &g= >t=3B but when I try to run it=3D3D2C it says "Segmentation fault". Can anyo= >=3D
>=3B >=3Bne
>=3B >=3B>=3B >=3B>=3B >=3B help? (My= > understanding is that I need 5.5.1 or later...)
>=3B >=3B>=3B >= >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B >=3B Mika
= >>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >= >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >= >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>=3B >=3B>=3B >=3BCo= >ntent-Type: text/html=3D3B charset=3D3D"iso-8859-1"
>=3B >=3B>=3B = >>=3BContent-Transfer-Encoding: quoted-printable
>=3B >=3B>=3B &g= >t=3B
>=3B >=3B>=3B >=3B<=3Bhtml>=3B
>=3B >=3B>=3B &= >gt=3B<=3Bhead>=3B
>=3B >=3B>=3B >=3B<=3Bstyle>=3B
>= >=3B >=3B>=3B >=3B.hmmessage P
>=3B >=3B>=3B >=3B{
>= >=3B >=3B>=3B >=3Bmargin:0px=3D3D3B
>=3B >=3B>=3B >=3Bpaddi= >ng:0px
>=3B >=3B>=3B >=3B}
>=3B >=3B>=3B >=3Bbody.hmm= >essage
>=3B >=3B>=3B >=3B{
>=3B >=3B>=3B >=3Bfont-siz= e: 10pt=3D3D3B
>=3B >=3B>=3B >=3Bfont-family:Verdana
>=3B &= >gt=3B>=3B >=3B}
>=3B >=3B>=3B >=3B<=3B/style>=3B
>= >=3B >=3B>=3B >=3B<=3B/head>=3B
>=3B >=3B>=3B >=3B<= >=3Bbody class=3D3D3D'hmmessage'>=3B
>=3B >=3B>=3B >=3B&=3Bn= >bsp=3D3D3B<=3BA href=3D3D3D"http://modula3.elegosoft.com/cm3/uploaded-arc= >hive=3D
>=3B >=3Bs" targ=3D3D
>=3B >=3B>=3B >=3Bet=3D3D3D= >_blank>=3B<=3BFONT color=3D3D3D#0068cf>=3Bhttp://modula3.elegosoft.co= >m/cm3/u=3D
>=3B >=3Bploaded=3D3D
>=3B >=3B>=3B >=3B-archi= >ves<=3B/FONT>=3B<=3B/A>=3B<=3BBR>=3B
>=3B >=3B>=3B >= >=3B?<=3BBR>=3B
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR&= >gt=3B
>=3B >=3B>=3B >=3BI can make another later this week.<= >=3BBR>=3B
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3BR>>=3B >=3B>=3B >=3BAll you need is a working cm3 on any system.<= >=3BBR>=3B
>=3B >=3B>=3B >=3B>=3BFrom there you can build the= > whole system=3D3D2C targeting any system.<=3BBR=3D
>=3B >=3B>= >=3B
>=3B >=3B>=3B >=3BAs long as that cm3 understands LONGINT an= >d your target system.<=3BBR>=3B
>=3B >=3B>=3B >=3BAnd it is = >easier=3D3D2C but not necessary=3D3D2C if you have Python. :)<=3BBR>=3B= >
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B
>=3B &g= >t=3B>=3B >=3B&=3Bnbsp=3D3D3B- Jay<=3BBR>=3B<=3BBR>=3B&=3B= >nbsp=3D3D3B<=3BBR>=3B&=3Bgt=3D3D3B Date: Tue=3D3D2C 31 Mar 2009=3DR>>=3B >=3B 15:43:41 -=3D3D
>=3B >=3B>=3B >=3B0500<=3BBR&g= >t=3B&=3Bgt=3D3D3B From: martinbishop at bellsouth.net<=3BBR>=3B&=3Bg= >t=3D3D3B To: mika at a=3D
>=3B >=3Bsync.ca=3D3D
>=3B >=3B>=3B = >>=3Bltech.edu<=3BBR>=3B&=3Bgt=3D3D3B CC: m3devel at elegosoft.com<= >=3BBR>=3B&=3Bgt=3D3D3B Subject: Re:=3D
>=3B >=3B [M3dev=3D3D>>=3B >=3B>=3B >=3Bel] Help finding CM3 compiler for Linux?<=3BBR= >>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B Not su=3D
>=3B &= >gt=3Bre if t=3D3D
>=3B >=3B>=3B >=3Bhis helps=3D3D2C but on my l= >inux system:<=3BBR>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B C= >ritical=3D
>=3B >=3B Mass Mod=3D3D
>=3B >=3B>=3B >=3Bula-= >3 version d5.7.0<=3BBR>=3B&=3Bgt=3D3D3B last updated: 2008-03-16<= >=3BBR>=3B&=3Bgt=3D3D3B co=3D
>=3B >=3Bmpiled:=3D3D
>=3B &g= >t=3B>=3B >=3B 2008-08-14 00:56:14<=3BBR>=3B&=3Bgt=3D3D3B configu= >ration: /usr/local/cm3/bin/cm3.c=3D
>=3B >=3Bfg<=3BBR=3D3D
>= >=3B >=3B>=3B >=3B>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3= >B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 2=3D
>=3B >=3B9 19= >:24=3D3D
>=3B >=3B>=3B >=3B:39 UTC 2009<=3BBR>=3B&=3Bgt= >=3D3D3B i686 GNU/Linux<=3BBR>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bg= >t=3D3D3B <=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3D3B I don=3D3D
&= >gt=3B >=3B>=3B >=3B't have the cm3 tarball=3D3D2C but I do have the s= >ources in cm3/ still.<=3BBR=3D
>=3B >=3B>=3B&=3Bgt=3D3D
&g= >t=3B >=3B>=3B >=3B=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B Mika Nystrom= > wrote:<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B Hello everyo=3D
&= >gt=3B >=3Bne=3D3D2C<=3BBR>=3B&=3Bg=3D3D
>=3B >=3B>=3B >= >=3Bt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3= >B This is=3D3D2C for me=3D3D2C a most un=3D
>=3B >=3Bfortunate time = >=3D3D
>=3B >=3B>=3B >=3Bfor the CM3 servers to<=3BBR>=3B&= >=3Bgt=3D3D3B &=3Bgt=3D3D3B have crashed. I'm teaching a=3D
>=3B >= >=3B class =3D3D
>=3B >=3B>=3B >=3Busing Modula-3=3D3D2C and we n= >eed a<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B compiler... here'=3DR>>=3B >=3Bs the una=3D3D
>=3B >=3B>=3B >=3Bme of the system= > I'm trying to use:<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B <=3BBR= >>=3B&=3Bgt=3D3D3B &=3Bg=3D
>=3B >=3Bt=3D3D3B Linu=3D3D
&g= >t=3B >=3B>=3B >=3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2= >008 i686 GNU/Linux<=3BBR=3D
>=3B >=3B>=3B&=3Bg=3D3D
>=3B= > >=3B>=3B >=3Bt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3= >B &=3Bgt=3D3D3B The most recent archives I have fo=3D
>=3B >=3Br = >Linux are=3D3D
>=3B >=3B>=3B >=3B:<=3BBR>=3B&=3Bgt=3D3D3B= > &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B cm3-min-P= OSIX-LINUXLIBC6-5.=3D
>=3B >=3B4.0.tgz cm3=3D3D
>=3B >=3B>= >=3B >=3B-src-all-5.4.0.tgz <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3= >B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B And they =3D
>=3B &g= >t=3Bdon't seem =3D3D
>=3B >=3B>=3B >=3Bto work on this system: I= > can compile a program<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B but= >=3D
>=3B >=3B when I=3D3D
>=3B >=3B>=3B >=3B try to run i= >t=3D3D2C it says "Segmentation fault". Can anyone<=3BBR>=3B&=3Bgt=3D= >3D3B=3D
>=3B >=3B &=3Bgt=3D3D3B=3D3D
>=3B >=3B>=3B >= >=3B help? (My understanding is that I need 5.5.1 or later...)<=3BBR>=3B= >&=3Bgt=3D3D3B &=3B=3D
>=3B >=3Bgt=3D3D3B=3D3D
>=3B >=3B= >>=3B >=3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B Mika<=3BBR&= >gt=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B <= >=3BBR>=3B<=3B/body=3D
>=3B >=3B>=3B
>=3B >=3B>=3B >= >=3B<=3B/html>=3B=3D3D
>=3B >=3B>=3B >=3B
>=3B >=3B>= >=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_--
>=3B >=3B
&g= >t=3B >=3B--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_
>=3B >=3BContent= >-Type: text/html=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer= >-Encoding: quoted-printable
>=3B >=3B
>=3B >=3B<=3Bhtml>= >=3B
>=3B >=3B<=3Bhead>=3B
>=3B >=3B<=3Bstyle>=3B
&= >gt=3B >=3B.hmmessage P
>=3B >=3B{
>=3B >=3Bmargin:0px=3D3B<= >BR>>=3B >=3Bpadding:0px
>=3B >=3B}
>=3B >=3Bbody.hmmessag= >e
>=3B >=3B{
>=3B >=3Bfont-size: 10pt=3D3B
>=3B >=3Bfo= >nt-family:Verdana
>=3B >=3B}
>=3B >=3B<=3B/style>=3B
&= >gt=3B >=3B<=3B/head>=3B
>=3B >=3B<=3Bbody class=3D3D'hmmessa= >ge'>=3B
>=3B >=3BThese archives do have a different format=3D2C ye= >s.<=3BBR>=3B
>=3B >=3BBut it isn't a bad format.<=3BBR>=3BR>>=3B >=3Bcminstall is pretty worthless imho.<=3BBR>=3B
>=3B = >>=3BExtract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.<=3BBR>=3B<= >BR>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp= >=3D3B- Jay<=3BBR>=3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3B&=3B= >gt=3D3B To: jay.krell at cornell.edu<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B = >>=3B Subject: Re: [M3devel] Help finding CM3 compiler for Linux? <=3BBR= >>=3B&=3Bgt=3D3B Dat=3D
>=3B >=3Be: Tue=3D2C 31 Mar 2009 15:56:1= >1 -0700<=3BBR>=3B&=3Bgt=3D3B From: mika at async.caltech.edu=3D
>= >=3B >=3B<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B No=3D2C= > I'm sorry...<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B the = >archives =3D
>=3B >=3Bdo not have the usual format. I'm expecting to= > unpack<=3BBR>=3B&=3Bgt=3D3B and run "cm=3D
>=3B >=3Binstall"= > and then unpack the big source tar on top and <=3BBR>=3B&=3Bgt=3D3B= > build tha=3D
>=3B >=3Bt. But there's no cminstall in the archive on= > this page.<=3BBR>=3B&=3Bgt=3D3B This is =3D
>=3B >=3B"the no= >rmal procedure" for installing CM3=3D2C no? It's what<=3BBR>=3B&=3Bg= >t=3D3B the in=3D
>=3B >=3Bstructions say to do=3D2C as well...<=3B= >BR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B And the link from t=3D<= >BR>>=3B >=3Bhe "Download" page is broken (to -d5.5.0.tgz).<=3BBR>= >=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Mika<=3BBR=3D
>=3B &g= >t=3B>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Jay writes:<=3BBR&g= >t=3B&=3Bgt=3D3B &=3Bgt=3D3B--_806446ae-8d10-4d74-8eea-5=3D
>=3B = >>=3B1aa365e9204_<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BContent-Type: = >text/plain=3D3B charset=3D3D"iso-885=3D
>=3B >=3B9-1"<=3BBR>=3B&= >amp=3Bgt=3D3B &=3Bgt=3D3BContent-Transfer-Encoding: quoted-printable<= >=3BBR>=3B&=3Bgt=3D3B =3D
>=3B >=3B&=3Bgt=3D3B<=3BBR>=3B&= >amp=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B htt= >p://modula3.elegosoft.com/cm3/u=3D
>=3B >=3Bploaded-archives<=3BBR= >>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3B?<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D= >
>=3B >=3B=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &a= >mp=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BI can make another l= >ater t=3D
>=3B >=3Bhis week.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >=3B &= >amp=3Bgt=3D3BAll you need is a working cm3 on any system.<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &= >amp=3Bgt=3D3B&=3Bgt=3D3BFrom there you can build the whole system=3D3D2C= > targeting an=3D
>=3B >=3By system.<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAs long as that cm3 un= >derstands =3D
>=3B >=3BLONGINT and your target system.<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAnd= > it is =3D
>=3B >=3Beasier=3D3D2C but not necessary=3D3D2C if you ha= >ve Python. :)<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3B=3D
>=3B= > >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt= >=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B - Jay<=3B= >BR>=3B&=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B= >&=3Bgt=3D3B Date: Tue=3D3D2C 31 Mar 2009=3D
>=3B >=3B 15:43:41 -0= >500<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B From: martinbi= >shop at bellsouth.net<=3BBR>=3B=3D
>=3B >=3B&=3Bgt=3D3B &=3Bg= >t=3D3B&=3Bgt=3D3B To: mika at async.caltech.edu<=3BBR>=3B&=3Bgt=3D3B= > &=3Bgt=3D3B&=3Bgt=3D3B CC: m=3D
>=3B >=3B3devel at elegosoft.com= ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B Subject: Re: [M3d= >evel] Help fin=3D
>=3B >=3Bding CM3 compiler for Linux?<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bg= >t=3D3B &=3Bgt=3D3B&=3Bg=3D
>=3B >=3Bt=3D3B Not sure if this he= >lps=3D3D2C but on my linux system:<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3B&=3Bg=3D
>=3B >=3Bt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &am= >p=3Bgt=3D3B&=3Bgt=3D3B Critical Mass Modula-3 version d5.7.0<=3BBR>= >=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B last upd= >ated: 2008-03-16<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B c= >ompiled=3D
>=3B >=3B: 2008-08-14 00:56:14<=3BBR>=3B&=3Bgt=3D3= >B &=3Bgt=3D3B&=3Bgt=3D3B configuration: /usr/local/cm3/=3D
>=3B = >>=3Bbin/cm3.cfg<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B= >=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B Linux thin= >kp=3D
>=3B >=3Bad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2= >009<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bg=3D
>=3B >=3Bt= >=3D3B i686 GNU/Linux<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D= >3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20= >=3D
>=3B >=3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D= >3B I don't have the cm3 tarball=3D3D2C but I do have the=3D
>=3B >= >=3B sources in cm3/ still.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B = >=3D
>=3B >=3BMika Nystrom wrote:<=3BBR>=3B&=3Bgt=3D3B &=3B= >gt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B Hello everyone=3D3D2C<=3BBR>=3B&am= >p=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B= >=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt= >=3D3B This is=3D3D2C fo=3D
>=3B >=3Br me=3D3D2C a most unfortunate t= >ime for the CM3 servers to<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B have crashed. I'm teaching a = >class using Modula-3=3D3D2C and we n=3D
>=3B >=3Beed a<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B compiler... here= >'s the uname of the sys=3D
>=3B >=3Btem I'm trying to use:<=3BBR&g= >t=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3B= >BR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3B=3D
>=3B >=3Bgt=3D3B &am= >p=3Bgt=3D3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i68= >=3D
>=3B >=3B6 GNU/Lin=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3Bux<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3= >B=3D3D20<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &=3Bgt=3D3B&= >=3Bgt=3D3B &=3Bgt=3D3B The most recent archives I have for Linux are:<= >=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B = >&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt= >=3D3B &=3Bgt=3D3B cm3-min-POSIX-=3D
>=3B >=3BLINUXLIBC6-5.4.0.tgz= > cm3-src-all-5.4.0.tgz=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&am= >p=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B=3D3D20<=3BBR>=3B&=3Bg= >t=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B And they don't seem to w= >ork on this =3D
>=3B >=3Bsystem: I can compile a program<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B but when I tr= >=3D
>=3B >=3By to run it=3D3D2C it says "Segmentation fault". Can an= >yone<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3B=3D
>=3B >=3Bg= >t=3D3B &=3Bgt=3D3B help? (My understanding is that I need 5.5.1 or later= >...)<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bg= >t=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Bgt=3D3B &=3Bgt=3D3B Mika<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >= >=3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3B= >gt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &am= >p=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B-= >-_806446ae-8d10-4d74-8eea-51aa365e9204_<=3BBR>=3B&=3Bgt=3D3B &=3B= >gt=3D3BConten=3D
>=3B >=3Bt-Type: text/html=3D3B charset=3D3D"iso-88= >59-1"<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BContent-Transfe=3D
>= >=3B >=3Br-Encoding: quoted-printable<=3BBR>=3B&=3Bgt=3D3B &=3Bg= >t=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3Bhtml&=3Bg= >t=3D
>=3B >=3B=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Blt=3D3Bhead&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Blt=3D3Bstyle&=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D= >3B &=3Bgt=3D3B.hmmessage P<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B{&l= >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bmargin:0px=3D3D3B<=3B=3D
>= >=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bpadding:0px<=3BBR>=3B&am= >p=3Bgt=3D3B &=3Bgt=3D3B}<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bbody.= >hmmessag=3D
>=3B >=3Be<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B{&l= >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfont-size: 10pt=3D3D3B<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3Bfo=3D
>=3B >=3Bnt-family:Verdana<= >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B}<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B&=3Blt=3D3B/style&=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>= >=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3B/head&=3Bgt=3D3B<=3BBR&g= >t=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3Bbody class=3D3D3D'hmmessa=3D= >
>=3B >=3Bge'&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BA href=3D3D3D"http://modula3.=3D<= >BR>>=3B >=3Belegosoft.com/cm3/uploaded-archives" targ=3D3D<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3Bet=3D3D3D_blank&=3B=3D
>=3B >=3Bg= >t=3D3B&=3Blt=3D3BFONT color=3D3D3D#0068cf&=3Bgt=3D3Bhttp://modula3.el= >egosoft.com/cm3/upl=3D
>=3B >=3Boaded=3D3D<=3BBR>=3B&=3Bgt=3D= >3B &=3Bgt=3D3B-archives&=3Blt=3D3B/FONT&=3Bgt=3D3B&=3Blt=3D3B/A= >&=3Bgt=3D3B&=3Blt=3D3BBR&=3Bg=3D
>=3B >=3Bt=3D3B<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3B?&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3B=3D= >
>=3B >=3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3= >BI can make another later this week.&=3Blt=3D3BBR&=3Bgt=3D3B<=3B=3D= >
>=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp= >=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3BAll you need=3D
>=3B >=3B is a working cm3 on any system.&= >=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Bgt=3D3BFrom t=3D
>=3B >=3Bhere you can build the whole system=3D3= >D2C targeting any system.&=3Blt=3D3BBR&=3Bgt=3D
>=3B >=3B=3D3B= ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAs long as that cm3 understands = >LONGINT and your target=3D
>=3B >=3B system.&=3Blt=3D3BBR&=3Bg= >t=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAnd it is easier=3D3D2C bu= >t not necess=3D
>=3B >=3Bary=3D3D2C if you have Python. :)&=3Blt= >=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp= >=3D3Bnbsp=3D
>=3B >=3B=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR&= >gt=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B- Jay&=3Blt= >=3D3BBR&=3Bgt=3D3B&=3Blt=3D
>=3B >=3B=3D3BBR&=3Bgt=3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3= >B Date: Tue=3D3D2C 31 M=3D
>=3B >=3Bar 2009 15:43:41 -=3D3D<=3BBR&= >gt=3B&=3Bgt=3D3B &=3Bgt=3D3B0500&=3Blt=3D3BBR&=3Bgt=3D3B&=3B= >amp=3D3Bgt=3D3D3B From=3D
>=3B >=3B: martinbishop at bellsouth.net&= >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B To: mika at async.ca=3D
= >>=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bltech.edu&= >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B CC: m3devel at elego=3D
= >>=3B >=3Bsoft.com&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B= > Subject: Re: [M3dev=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D
>= >=3B >=3B=3D3Bel] Help finding CM3 compiler for Linux?&=3Blt=3D3BBR&= >=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D
>=3B >=3B=3D3BBR&= >=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B Not sure if t=3D3D<=3BBR>=3B&=3Bg= >t=3D3B &=3Bgt=3D3Bhis helps=3D3D2C b=3D
>=3B >=3But on my linux s= >ystem:&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3B= >BR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D
>=3B >=3B=3D3D3B Critical Mass = >Mod=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bula-3 version d5.7.0&= >=3Blt=3D3BBR&=3Bgt=3D
>=3B >=3B=3D3B&=3Bamp=3D3Bgt=3D3D3B last= > updated: 2008-03-16&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B = >comp=3D
>=3B >=3Biled:=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3B 2008-08-14 00:56:14&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3= >B c=3D
>=3B >=3Bonfiguration: /usr/local/cm3/bin/cm3.cfg&=3Blt=3D= >3BBR=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B&=3B= >=3D
>=3B >=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3B= >amp=3D3Bgt=3D3D3B Linux thinkpad 2.6.27-11-generic=3D
>=3B >=3B #1 S= >MP Thu Jan 29 19:24=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B:39 UTC = >2009&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3= >D3B i686 GNU/Linux&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &a= >mp=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3B=3D
>=3B >=3Bgt=3D3D3B &a= >mp=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B I don=3D3D<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3B't have the c=3D
>=3B >=3Bm3 tarball= >=3D3D2C but I do have the sources in cm3/ still.&=3Blt=3D3BBR&=3Bgt= >=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D<=3BBR>=3B&=3Bgt=3D3B= > &=3Bgt=3D3B=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D= >3B Mika Nystrom wr=3D
>=3B >=3Bote:&=3Blt=3D3BBR&=3Bgt=3D3B&am= >p=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B Hello everyone=3D3D2C&=3B= >lt=3D3BBR=3D
>=3B >=3B&=3Bgt=3D3B&=3Bamp=3D3Bg=3D3D<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3Bt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt= >=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D3B &=3Bam= >p=3D3Bgt=3D3D3B This is=3D3D2C for me=3D3D2C a most unfortunate time =3D>>=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfor the CM3 s= >ervers to&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp= >=3D
>=3B >=3B=3D3Bgt=3D3D3B have crashed. I'm teaching a class =3D3D= ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Busing Mod=3D
>=3B >=3Bula= >-3=3D3D2C and we need a&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D= >3B &=3Bamp=3D3Bgt=3D3D3B compile=3D
>=3B >=3Br... here's the una= >=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bme of the system I'm trying= > to use:&=3B=3D
>=3B >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt= >=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp= >=3D3Bgt=3D3D3B &=3Bam=3D
>=3B >=3Bp=3D3Bgt=3D3D3B Linu=3D3D<=3B= >BR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 1= >0=3D
>=3B >=3B:53:03 PST 2008 i686 GNU/Linux&=3Blt=3D3BBR&=3Bg= >t=3D3B&=3Bamp=3D3Bg=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bt=3D<= >BR>>=3B >=3B=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt= >=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B The most r=3D
>= >=3B >=3Becent archives I have for Linux are=3D3D<=3BBR>=3B&=3Bgt= >=3D3B &=3Bgt=3D3B:&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B = >>=3B=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3= >B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B cm3-m=3D
>=3B >= >=3Bin-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D3D<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B-src-all-5.4.0.tgz &=3Blt=3D
>=3B =3D3BBR&=3Bgt=3D3B&a= >mp=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt= >=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D3B = >And they don't seem =3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bto work= > on this system: =3D
>=3B >=3BI can compile a program&=3Blt=3D3BB= >R&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B but when= >=3D
>=3B >=3B I=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B try = >to run it=3D3D2C it says "Segmentation fault". Can=3D
>=3B >=3B anyo= >ne&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt= >=3D3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B help=3D
>=3B &= >gt=3B? (My understanding is that I need 5.5.1 or later...)&=3Blt=3D3BBR&= >amp=3Bgt=3D3B&=3Bamp=3D3Bg=3D
>=3B >=3Bt=3D3D3B &=3Bamp=3D3Bgt= >=3D3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B &=3Blt=3D3BBR&am= >p=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D
>=3B >=3B=3D3Bgt= >=3D3D3B Mika&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Ba= >mp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Ba=3D
>=3B >=3B= >mp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Blt=3D3B/body&=3Bgt= >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3B/html&=3Bg= >t=3D
>=3B >=3B=3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >lt=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B--_806446ae-8d10-4d74-8eea-51aa36= >5e=3D
>=3B >=3B9204_--<=3BBR>=3B<=3B/body>=3B
>=3B >= >=3B<=3B/html>=3B=3D
>=3B >=3B
>=3B >=3B--_777fdc4e-3c29-4= >0b4-a3dd-e6243f796cee_--
>= > >--_55339e45-8c85-4ab6-9440-0d2131bbad69_-- From jay.krell at cornell.edu Wed Apr 1 08:56:45 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Apr 2009 06:56:45 +0000 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: <200904010627.n316RM55072294@camembert.async.caltech.edu> References: Your message of "Wed, 01 Apr 2009 06:13:00 -0000." <200904010627.n316RM55072294@camembert.async.caltech.edu> Message-ID: Sorry it is meant to be a little easier. I'll see about putting an "install" or "readme" file in. "root of cm3 cvs" is the root of a cvs checkout, not a "repository". But it isn't meant to be required...it is just the way I always work.. Similar to your "extracting the source tarball", though that isn't supposed to be necessary either. Here is another avenue..roundabout, but.. You had a kind of working install from 5.4 and running its cminstall. cm3 ran but produced crashing binaries. Take the cm3.cfg file from it and put it at. $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3.cfg That might work. I'll test this out more later and maybe make an updated archive. "this" being "not having any source tree", just the extracted archive + set $PATH and $LD_LIBRARY_PATH. It should be a small fix, if it isn't fixed already, and easy to patch up existing extracted archives -- you might just try a current cm3cfg.common from the source tree, but..the "shoe" is kind of on my "foot" at this point. - Jay > To: jay.krell at cornell.edu > Date: Tue, 31 Mar 2009 23:27:22 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Help finding CM3 compiler for Linux? > > Hmm, I'm not sure what you mean? "root of cm3 cvs"? > > I have lots of Modula-3 installations on my own machines, but I'm > just trying to get a system installed for student use on the student > systems (which are different)... A working binary dist for Linux > is exactly what I'm looking for and this is what you seem to have > directed me to, but I don't have a CVS repository... > > I don't have "m3-sys/cminstall/" etc. Do I need to unpack both > the min and std before doing these things? > > What I'm *used to* is that I unpack the binary distribution, then > unpack the sources (or CVS if you like) on top of that, and > then compile everything. Which works about 1 time in 3. > > I think Modula-3 is almost impossible to install if you don't know > exactly what to do! (I'm sure I can figure this out with some > work.. but is it really meant to be hard to do? I guess it keeps > the riff-raff off the M3 mailing lists!) > > Mika > > Jay writes: > >--_55339e45-8c85-4ab6-9440-0d2131bbad69_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Maybe not. > > > >Hm. That is bug. There is use with a cvs tree=2C and use without. > > > >I must have broken use without. > > > >=20 > > > >Try this: > > > >export CM3_ROOT=3Droot of cm3 cvs (for me this is /dev2/cm3=2C > > > >for you=2C maybe $HOME/cm3?) > > > >rm $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6 > > > ># *Common and *common in one command > >rm $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/*ommon > >cp root of cm3 cvs/m3-sys/cminstall/src/config/cm3.cfg $HOME/cm3/cm3-min-LI= > >NUXLIBC6-d5.7.0/bin > > > >=20 > > > >The .cfg will delegate out to the cvs tree. > > > >I don't like having two copies of files..having to keep them in sync.. > > > > Though the archives are meant to work standalone=2C without CVS. > > > > But I don't test that so much oops sorry. > > > >That /might/ not be the right file=2C but it is close. > > > >=20 > > > > - Jay > > > >=20 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux?=20 > >> Date: Tue=2C 31 Mar 2009 22:59:18 -0700 > >> From: mika at async.caltech.edu > >>=20 > >>=20 > >> Is there any documentation for this format beyond what you just > >> wrote? Where? > >>=20 > >> terpsichore-14: cm3 > >> --- building in ../LINUXLIBC6 --- > >>=20 > >> new source -> compiling Main.m3 > >> "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common"=2C= > > line 169: quake runtime error: undefined variable: ROOT > >>=20 > >> --procedure-- -line- -file--- > >> GetM3Back 169 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3c= > >fg.common > >> _IsM3BackFlagSupported 181 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5= > >.7.0/bin/Unix.common > >> IsM3BackFlagSupported 193 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.= > >7.0/bin/Unix.common > >> GetM3BackFlag 197 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/= > >Unix.common > >> m3_backend 62 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix= > >.common > >> program -- > >> 6 /afs/.ugcs.caltech.edu/user/mika/test/LINUXLIBC6/m3make.args > >>=20 > >>=20 > >> Fatal Error: procedure "m3_backend" defined in "/afs/.ugcs/user/mika/cm3/= > >cm3-min-LINUXLIBC6-d5.7.0/bin/cm3.cfg" failed. > >>=20 > >> Jay writes: > >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ > >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> >These archives do have a different format=3D2C yes. > >> > > >> >But it isn't a bad format. > >> > > >> >cminstall is pretty worthless imho. > >> > > >> >Extract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH. > >> > > >> >=3D20 > >> > > >> > - Jay > >> > > >> >=3D20 > >> >> To: jay.krell at cornell.edu > >> >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux?=3D20 > >> >> Date: Tue=3D2C 31 Mar 2009 15:56:11 -0700 > >> >> From: mika at async.caltech.edu > >> >>=3D20 > >> >> No=3D2C I'm sorry... > >> >>=3D20 > >> >> the archives do not have the usual format. I'm expecting to unpack > >> >> and run "cminstall" and then unpack the big source tar on top and=3D20 > >> >> build that. But there's no cminstall in the archive on this page. > >> >> This is "the normal procedure" for installing CM3=3D2C no? It's what > >> >> the instructions say to do=3D2C as well... > >> >>=3D20 > >> >> And the link from the "Download" page is broken (to -d5.5.0.tgz). > >> >>=3D20 > >> >> Mika > >> >>=3D20 > >> >> Jay writes: > >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ > >> >> >Content-Type: text/plain=3D3B charset=3D3D"iso-8859-1" > >> >> >Content-Transfer-Encoding: quoted-printable > >> >> > > >> >> > > >> >> > http://modula3.elegosoft.com/cm3/uploaded-archives > >> >> > > >> >> >? > >> >> > > >> >> >=3D3D20 > >> >> > > >> >> >I can make another later this week. > >> >> > > >> >> >=3D3D20 > >> >> > > >> >> >All you need is a working cm3 on any system. > >> >> > > >> >> >>From there you can build the whole system=3D3D2C targeting any syste= > >m. > >> >> > > >> >> >As long as that cm3 understands LONGINT and your target system. > >> >> > > >> >> >And it is easier=3D3D2C but not necessary=3D3D2C if you have Python. = > >:) > >> >> > > >> >> >=3D3D20 > >> >> > > >> >> > - Jay > >> >> > > >> >> >=3D3D20 > >> >> >> Date: Tue=3D3D2C 31 Mar 2009 15:43:41 -0500 > >> >> >> From: martinbishop at bellsouth.net > >> >> >> To: mika at async.caltech.edu > >> >> >> CC: m3devel at elegosoft.com > >> >> >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? > >> >> >>=3D3D20 > >> >> >> Not sure if this helps=3D3D2C but on my linux system: > >> >> >>=3D3D20 > >> >> >> Critical Mass Modula-3 version d5.7.0 > >> >> >> last updated: 2008-03-16 > >> >> >> compiled: 2008-08-14 00:56:14 > >> >> >> configuration: /usr/local/cm3/bin/cm3.cfg > >> >> >>=3D3D20 > >> >> >> Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 200= > >9 > >> >> >> i686 GNU/Linux > >> >> >>=3D3D20 > >> >> >>=3D3D20 > >> >> >> I don't have the cm3 tarball=3D3D2C but I do have the sources in cm= > >3/ st=3D > >> >ill. > >> >> >>=3D3D20 > >> >> >> Mika Nystrom wrote: > >> >> >> > Hello everyone=3D3D2C > >> >> >> >=3D3D20 > >> >> >> > This is=3D3D2C for me=3D3D2C a most unfortunate time for the CM3 = > >servers=3D > >> > to > >> >> >> > have crashed. I'm teaching a class using Modula-3=3D3D2C and we n= > >eed a > >> >> >> > compiler... here's the uname of the system I'm trying to use: > >> >> >> >=3D3D20 > >> >> >> > Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 G= > >NU/=3D > >> >Lin=3D3D > >> >> >ux > >> >> >> >=3D3D20 > >> >> >> > The most recent archives I have for Linux are: > >> >> >> >=3D3D20 > >> >> >> > cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D3D20 > >> >> >> >=3D3D20 > >> >> >> > And they don't seem to work on this system: I can compile a progr= > >am > >> >> >> > but when I try to run it=3D3D2C it says "Segmentation fault". Can= > > anyo=3D > >> >ne > >> >> >> > help? (My understanding is that I need 5.5.1 or later...) > >> >> >> >=3D3D20 > >> >> >> > Mika > >> >> >> >=3D3D20 > >> >> >>=3D3D20 > >> >> > > >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ > >> >> >Content-Type: text/html=3D3B charset=3D3D"iso-8859-1" > >> >> >Content-Transfer-Encoding: quoted-printable > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > =3D3D3B >archive=3D > >> >s" targ=3D3D > >> >> >et=3D3D3D_blank>http://modula3.elegosoft.co= > >m/cm3/u=3D > >> >ploaded=3D3D > >> >> >-archives
> >> >> >?
> >> >> > =3D3D3B
> >> >> >I can make another later this week.
> >> >> > =3D3D3B
> >> >> >All you need is a working cm3 on any system.
> >> >> >>From there you can build the whole system=3D3D2C targeting any syste= > >m. >> >> > >> >> >As long as that cm3 understands LONGINT and your target system.
> >> >> >And it is easier=3D3D2C but not necessary=3D3D2C if you have Python. = > >:)
> >> >> > =3D3D3B
> >> >> > =3D3D3B- Jay

 =3D3D3B
>=3D3D3B Date: Tue=3D3D2C = > >31 Mar 2009=3D > >> > 15:43:41 -=3D3D > >> >> >0500
>=3D3D3B From: martinbishop at bellsouth.net
>=3D3D3B To:= > > mika at a=3D > >> >sync.ca=3D3D > >> >> >ltech.edu
>=3D3D3B CC: m3devel at elegosoft.com
>=3D3D3B Subje= > >ct: Re:=3D > >> > [M3dev=3D3D > >> >> >el] Help finding CM3 compiler for Linux?
>=3D3D3B
>=3D3D3B= > > Not su=3D > >> >re if t=3D3D > >> >> >his helps=3D3D2C but on my linux system:
>=3D3D3B
>=3D3D3B= > > Critical=3D > >> > Mass Mod=3D3D > >> >> >ula-3 version d5.7.0
>=3D3D3B last updated: 2008-03-16
>=3D= > >3D3B co=3D > >> >mpiled:=3D3D > >> >> > 2008-08-14 00:56:14
>=3D3D3B configuration: /usr/local/cm3/bin/= > >cm3.c=3D > >> >fg >> >> >>>=3D3D3B
>=3D3D3B Linux thinkpad 2.6.27-11-generic #1 SMP Th= > >u Jan 2=3D > >> >9 19:24=3D3D > >> >> >:39 UTC 2009
>=3D3D3B i686 GNU/Linux
>=3D3D3B
>=3D3D3= > >B
>=3D > >> >=3D3D3B I don=3D3D > >> >> >'t have the cm3 tarball=3D3D2C but I do have the sources in cm3/ stil= > >l. >> >>>=3D3D > >> >> >=3D3D3B
>=3D3D3B Mika Nystrom wrote:
>=3D3D3B >=3D3D3B H= > >ello everyo=3D > >> >ne=3D3D2C
&g=3D3D > >> >> >t=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B This is=3D3D2C for me= > >=3D3D2C a most un=3D > >> >fortunate time =3D3D > >> >> >for the CM3 servers to
>=3D3D3B >=3D3D3B have crashed. I'm tea= > >ching a=3D > >> > class =3D3D > >> >> >using Modula-3=3D3D2C and we need a
>=3D3D3B >=3D3D3B compiler= > >... here'=3D > >> >s the una=3D3D > >> >> >me of the system I'm trying to use:
>=3D3D3B >=3D3D3B
>= > >=3D3D3B &g=3D > >> >t=3D3D3B Linu=3D3D > >> >> >x lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Linux= > > >> >>&g=3D3D > >> >> >t=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B The most recent archive= > >s I have fo=3D > >> >r Linux are=3D3D > >> >> >:
>=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B cm3-min-POSIX-LI= > >NUXLIBC6-5.=3D > >> >4.0.tgz cm3=3D3D > >> >> >-src-all-5.4.0.tgz
>=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3= > >B And they =3D > >> >don't seem =3D3D > >> >> >to work on this system: I can compile a program
>=3D3D3B >=3D3= > >D3B but=3D > >> > when I=3D3D > >> >> > try to run it=3D3D2C it says "Segmentation fault". Can anyone
>= > >=3D3D3B=3D > >> > >=3D3D3B=3D3D > >> >> > help? (My understanding is that I need 5.5.1 or later...)
>=3D3= > >D3B &=3D > >> >gt=3D3D3B=3D3D > >> >> >
>=3D3D3B >=3D3D3B Mika
>=3D3D3B >=3D3D3B
>=3D3D= > >3B
>> >> > >> >> >=3D3D > >> >> > > >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_-- > >> > > >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ > >> >Content-Type: text/html=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> > > >> > > >> > > >> > > >> >These archives do have a different format=3D2C yes.
> >> >But it isn't a bad format.
> >> >cminstall is pretty worthless imho.
> >> >Extract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.
> >> > =3D3B
> >> > =3D3B- Jay

 =3D3B
>=3D3B To: jay.krell at cornell.edu<= > >BR>>=3D3B=3D > >> > Subject: Re: [M3devel] Help finding CM3 compiler for Linux?
>=3D3= > >B Dat=3D > >> >e: Tue=3D2C 31 Mar 2009 15:56:11 -0700
>=3D3B From: mika at async.calt= > >ech.edu=3D > >> >
>=3D3B
>=3D3B No=3D2C I'm sorry...
>=3D3B
>=3D3B = > >the archives =3D > >> >do not have the usual format. I'm expecting to unpack
>=3D3B and ru= > >n "cm=3D > >> >install" and then unpack the big source tar on top and
>=3D3B buil= > >d tha=3D > >> >t. But there's no cminstall in the archive on this page.
>=3D3B Thi= > >s is =3D > >> >"the normal procedure" for installing CM3=3D2C no? It's what
>=3D3B= > > the in=3D > >> >structions say to do=3D2C as well...
>=3D3B
>=3D3B And the li= > >nk from t=3D > >> >he "Download" page is broken (to -d5.5.0.tgz).
>=3D3B
>=3D3B = > >Mika >> >>>=3D3B
>=3D3B Jay writes:
>=3D3B >=3D3B--_806446ae-8d10-= > >4d74-8eea-5=3D > >> >1aa365e9204_
>=3D3B >=3D3BContent-Type: text/plain=3D3B charset= > >=3D3D"iso-885=3D > >> >9-1"
>=3D3B >=3D3BContent-Transfer-Encoding: quoted-printable
= > >>=3D3B =3D > >> >>=3D3B
>=3D3B >=3D3B
>=3D3B >=3D3B http://modula3.elegos= > >oft.com/cm3/u=3D > >> >ploaded-archives
>=3D3B >=3D3B
>=3D3B >=3D3B?
>=3D3B = > >>=3D3B
>=3D > >> >=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B
>=3D3B >=3D3BI can mak= > >e another later t=3D > >> >his week.
>=3D3B >=3D3B
>=3D3B >=3D3B=3D3D20
>=3D3B &= > >gt=3D3B
>=3D3B=3D > >> > >=3D3BAll you need is a working cm3 on any system.
>=3D3B >=3D= > >3B
>=3D > >> >=3D3B >=3D3B>=3D3BFrom there you can build the whole system=3D3D2C t= > >argeting an=3D > >> >y system.
>=3D3B >=3D3B
>=3D3B >=3D3BAs long as that cm3 u= > >nderstands =3D > >> >LONGINT and your target system.
>=3D3B >=3D3B
>=3D3B >=3D3= > >BAnd it is =3D > >> >easier=3D3D2C but not necessary=3D3D2C if you have Python. :)
>=3D3= > >B >=3D3B<=3D > >> >BR>>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B
>=3D3B >=3D3B - = > >Jay
>=3D3B >=3D > >> >=3D3B
>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B Date: Tue= > >=3D3D2C 31 Mar 2009=3D > >> > 15:43:41 -0500
>=3D3B >=3D3B>=3D3B From: martinbishop at bellsout= > >h.net
=3D > >> >>=3D3B >=3D3B>=3D3B To: mika at async.caltech.edu
>=3D3B >=3D3= > >B>=3D3B CC: m=3D > >> >3devel at elegosoft.com
>=3D3B >=3D3B>=3D3B Subject: Re: [M3devel]= > > Help fin=3D > >> >ding CM3 compiler for Linux?
>=3D3B >=3D3B>=3D3B=3D3D20
>= > >=3D3B >=3D3B&g=3D > >> >t=3D3B Not sure if this helps=3D3D2C but on my linux system:
>=3D3B= > > >=3D3B&g=3D > >> >t=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B Critical Mass Modula-3 versio= > >n d5.7.0
&=3D > >> >gt=3D3B >=3D3B>=3D3B last updated: 2008-03-16
>=3D3B >=3D3B&g= > >t=3D3B compiled=3D > >> >: 2008-08-14 00:56:14
>=3D3B >=3D3B>=3D3B configuration: /usr/l= > >ocal/cm3/=3D > >> >bin/cm3.cfg
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B >=3D3B>= > >=3D3B Linux thinkp=3D > >> >ad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009
>=3D3B >= > >=3D3B&g=3D > >> >t=3D3B i686 GNU/Linux
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B &g= > >t=3D3B>=3D3B=3D3D20=3D > >> >
>=3D3B >=3D3B>=3D3B I don't have the cm3 tarball=3D3D2C but I = > >do have the=3D > >> > sources in cm3/ still.
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B = > >>=3D3B>=3D3B =3D > >> >Mika Nystrom wrote:
>=3D3B >=3D3B>=3D3B >=3D3B Hello everyone= > >=3D3D2C
&g=3D > >> >t=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B >= > >=3D3B This is=3D3D2C fo=3D > >> >r me=3D3D2C a most unfortunate time for the CM3 servers to
>=3D3B &= > >gt=3D3B&g=3D > >> >t=3D3B >=3D3B have crashed. I'm teaching a class using Modula-3=3D3D2C= > > and we n=3D > >> >eed a
>=3D3B >=3D3B>=3D3B >=3D3B compiler... here's the uname= > > of the sys=3D > >> >tem I'm trying to use:
>=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
&= > >gt=3D3B >=3D3B&=3D > >> >gt=3D3B >=3D3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2= > >008 i68=3D > >> >6 GNU/Lin=3D3D
>=3D3B >=3D3Bux
>=3D3B >=3D3B>=3D3B >= > >=3D3B=3D3D20
>=3D > >> >=3D3B >=3D3B>=3D3B >=3D3B The most recent archives I have for Linu= > >x are:
&=3D > >> >gt=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B &g= > >t=3D3B cm3-min-POSIX-=3D > >> >LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D3D20
>=3D3B >=3D3B&g= > >t=3D3B >=3D > >> >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B >=3D3B And they don't seem t= > >o work on this =3D > >> >system: I can compile a program
>=3D3B >=3D3B>=3D3B >=3D3B bu= > >t when I tr=3D > >> >y to run it=3D3D2C it says "Segmentation fault". Can anyone
>=3D3B = > >>=3D3B&=3D > >> >gt=3D3B >=3D3B help? (My understanding is that I need 5.5.1 or later..= > >.)
&=3D > >> >gt=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B &g= > >t=3D3B Mika
>=3D3B=3D > >> > >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B=3D3D20 >>>=3D3B >=3D3B
&=3D > >> >gt=3D3B >=3D3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>=3D3B >= > >=3D3BConten=3D > >> >t-Type: text/html=3D3B charset=3D3D"iso-8859-1"
>=3D3B >=3D3BCont= > >ent-Transfe=3D > >> >r-Encoding: quoted-printable
>=3D3B >=3D3B
>=3D3B >=3D3B&l= > >t=3D3Bhtml>=3D > >> >=3D3B
>=3D3B >=3D3B<=3D3Bhead>=3D3B
>=3D3B >=3D3B<= > >=3D3Bstyle>=3D3B
&=3D > >> >gt=3D3B >=3D3B.hmmessage P
>=3D3B >=3D3B{
>=3D3B >=3D3Bm= > >argin:0px=3D3D3B<=3D > >> >BR>>=3D3B >=3D3Bpadding:0px
>=3D3B >=3D3B}
>=3D3B >=3D= > >3Bbody.hmmessag=3D > >> >e
>=3D3B >=3D3B{
>=3D3B >=3D3Bfont-size: 10pt=3D3D3B
&g= > >t=3D3B >=3D3Bfo=3D > >> >nt-family:Verdana
>=3D3B >=3D3B}
>=3D3B >=3D3B<=3D3B/sty= > >le>=3D3B
&=3D > >> >gt=3D3B >=3D3B<=3D3B/head>=3D3B
>=3D3B >=3D3B<=3D3Bbody c= > >lass=3D3D3D'hmmessa=3D > >> >ge'>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BA href=3D3D3= > >D"http://modula3.=3D > >> >elegosoft.com/cm3/uploaded-archives" targ=3D3D
>=3D3B >=3D3Bet=3D= > >3D3D_blank&=3D > >> >gt=3D3B<=3D3BFONT color=3D3D3D#0068cf>=3D3Bhttp://modula3.elegosoft.= > >com/cm3/upl=3D > >> >oaded=3D3D
>=3D3B >=3D3B-archives<=3D3B/FONT>=3D3B<=3D3B/A&= > >gt=3D3B<=3D3BBR&g=3D > >> >t=3D3B
>=3D3B >=3D3B?<=3D3BBR>=3D3B
>=3D3B >=3D3B&= > >=3D3Bnbsp=3D3D3B<=3D3B=3D > >> >BR>=3D3B
>=3D3B >=3D3BI can make another later this week.<=3D= > >3BBR>=3D3B<=3D > >> >BR>>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
>=3D3B &= > >gt=3D3BAll you need=3D > >> > is a working cm3 on any system.<=3D3BBR>=3D3B
>=3D3B >=3D3B&= > >gt=3D3BFrom t=3D > >> >here you can build the whole system=3D3D2C targeting any system.<=3D3B= > >BR>=3D > >> >=3D3B
>=3D3B >=3D3BAs long as that cm3 understands LONGINT and yo= > >ur target=3D > >> > system.<=3D3BBR>=3D3B
>=3D3B >=3D3BAnd it is easier=3D3D2C b= > >ut not necess=3D > >> >ary=3D3D2C if you have Python. :)<=3D3BBR>=3D3B
>=3D3B >=3D3B= > >&=3D3Bnbsp=3D > >> >=3D3D3B<=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B- Jay&= > >lt=3D3BBR>=3D3B<=3D > >> >=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B = > >Date: Tue=3D3D2C 31 M=3D > >> >ar 2009 15:43:41 -=3D3D
>=3D3B >=3D3B0500<=3D3BBR>=3D3B&= > >=3D3Bgt=3D3D3B From=3D > >> >: martinbishop at bellsouth.net<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B To: mik= > >a at async.ca=3D > >> >=3D3D
>=3D3B >=3D3Bltech.edu<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B = > >CC: m3devel at elego=3D > >> >soft.com<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Subject: Re: [M3dev=3D3D >>>=3D3B >=3D > >> >=3D3Bel] Help finding CM3 compiler for Linux?<=3D3BBR>=3D3B&=3D3B= > >gt=3D3D3B <=3D > >> >=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Not sure if t=3D3D
>=3D3B >=3D3= > >Bhis helps=3D3D2C b=3D > >> >ut on my linux system:<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B <=3D3BBR>= > >=3D3B&=3D3Bgt=3D > >> >=3D3D3B Critical Mass Mod=3D3D
>=3D3B >=3D3Bula-3 version d5.7.0&= > >lt=3D3BBR>=3D > >> >=3D3B&=3D3Bgt=3D3D3B last updated: 2008-03-16<=3D3BBR>=3D3B&= > >=3D3Bgt=3D3D3B comp=3D > >> >iled:=3D3D
>=3D3B >=3D3B 2008-08-14 00:56:14<=3D3BBR>=3D3B&am= > >p=3D3Bgt=3D3D3B c=3D > >> >onfiguration: /usr/local/cm3/bin/cm3.cfg<=3D3BBR=3D3D
>=3D3B >= > >=3D3B>=3D3B&=3D > >> >amp=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Linux thinkpad 2.= > >6.27-11-generic=3D > >> > #1 SMP Thu Jan 29 19:24=3D3D
>=3D3B >=3D3B:39 UTC 2009<=3D3BBR= > >>=3D3B&=3D > >> >=3D3Bgt=3D3D3B i686 GNU/Linux<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B <=3D= > >3BBR>=3D3B&=3D3B=3D > >> >gt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B I don=3D3D
>=3D3B &g= > >t=3D3B't have the c=3D > >> >m3 tarball=3D3D2C but I do have the sources in cm3/ still.<=3D3BBR>= > >=3D3B&=3D > >> >=3D3Bgt=3D3D
>=3D3B >=3D3B=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt= > >=3D3D3B Mika Nystrom wr=3D > >> >ote:<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B Hello everyo= > >ne=3D3D2C<=3D3BBR=3D > >> >>=3D3B&=3D3Bg=3D3D
>=3D3B >=3D3Bt=3D3D3B &=3D3Bgt=3D3D3B = > ><=3D3BBR>=3D3B&=3D > >> >=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B This is=3D3D2C for me=3D3D2C a most un= > >fortunate time =3D > >> >=3D3D
>=3D3B >=3D3Bfor the CM3 servers to<=3D3BBR>=3D3B&= > >=3D3Bgt=3D3D3B &=3D > >> >=3D3Bgt=3D3D3B have crashed. I'm teaching a class =3D3D
>=3D3B >= > >=3D3Busing Mod=3D > >> >ula-3=3D3D2C and we need a<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3B= > >gt=3D3D3B compile=3D > >> >r... here's the una=3D3D
>=3D3B >=3D3Bme of the system I'm trying= > > to use:&=3D > >> >lt=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3= > >B&=3D3Bgt=3D3D3B &am=3D > >> >p=3D3Bgt=3D3D3B Linu=3D3D
>=3D3B >=3D3Bx lara 2.6.24ugcs1 #4 SMP = > >Mon Feb 11 10=3D > >> >:53:03 PST 2008 i686 GNU/Linux<=3D3BBR>=3D3B&=3D3Bg=3D3D
>= > >=3D3B >=3D3Bt=3D > >> >=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3= > >Bgt=3D3D3B The most r=3D > >> >ecent archives I have for Linux are=3D3D
>=3D3B >=3D3B:<=3D3BBR= > >>=3D3B&=3D > >> >=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &= > >amp=3D3Bgt=3D3D3B cm3-m=3D > >> >in-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D3D
>=3D3B >=3D3B-src-all-5.4.= > >0.tgz <=3D > >> =3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&a= > >mp=3D3Bgt=3D3D3B &=3D > >> >=3D3Bgt=3D3D3B And they don't seem =3D3D
>=3D3B >=3D3Bto work on = > >this system: =3D > >> >I can compile a program<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt= > >=3D3D3B but when=3D > >> > I=3D3D
>=3D3B >=3D3B try to run it=3D3D2C it says "Segmentation = > >fault". Can=3D > >> > anyone<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B=3D3D
&= > >gt=3D3B >=3D3B help=3D > >> >? (My understanding is that I need 5.5.1 or later...)<=3D3BBR>=3D3B&= > >amp=3D3Bg=3D > >> >t=3D3D3B &=3D3Bgt=3D3D3B=3D3D
>=3D3B >=3D3B <=3D3BBR>=3D3B= > >&=3D3Bgt=3D3D3B &=3D > >> >=3D3Bgt=3D3D3B Mika<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D= > >3B <=3D3BBR>=3D3B&a=3D > >> >mp=3D3Bgt=3D3D3B <=3D3BBR>=3D3B<=3D3B/body>=3D3B
>=3D3B >= > >=3D3B<=3D3B/html>=3D > >> >=3D3B=3D3D
>=3D3B >=3D3B
>=3D3B >=3D3B--_806446ae-8d10-4d7= > >4-8eea-51aa365e=3D > >> >9204_--
> >> >=3D > >> > > >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_-- > > > >--_55339e45-8c85-4ab6-9440-0d2131bbad69_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >Maybe not.
> >Hm. That is bug. There is use with a cvs tree=2C and use without.
> >I must have broken use without.
> > =3B
> >Try this:
> >export CM3_ROOT=3Droot of cm3 cvs (for me this is /dev2/cm3=2C
> >for you=2C maybe $HOME/cm3?)
> >rm =3B$HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6
> ># *Common and *common in one command
rm =3B$HOME/cm3/cm3-min-LINUXLI= > >BC6-d5.7.0/bin/*ommon
cp root of cm3 cvs/m3-sys/cminstall/src/config/cm3= > >.cfg $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin
> > =3B
> >The .cfg will delegate out to the cvs tree.
> >I don't like having two copies of files..having to keep them in sync..
> > =3BThough the archives are meant to work standalone=2C without CVS. >> > > =3B But I don't test that so much oops sorry.
> >That /might/ not be the right file=2C but it is close.
> > =3B
> > =3B- Jay

 =3B
>=3B To: jay.krell at cornell.edu
>=3B= > > CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] Help finding CM= > >3 compiler for Linux?
>=3B Date: Tue=2C 31 Mar 2009 22:59:18 -0700 >>>=3B From: mika at async.caltech.edu
>=3B
>=3B
>=3B Is the= > >re any documentation for this format beyond what you just
>=3B wrote? = > >Where?
>=3B
>=3B terpsichore-14: cm3
>=3B --- building in .= > >./LINUXLIBC6 ---
>=3B
>=3B new source ->=3B compiling Main.m3<= > >BR>>=3B "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.co= > >mmon"=2C line 169: quake runtime error: undefined variable: ROOT
>=3B = > >
>=3B --procedure-- -line- -file---
>=3B GetM3Back 169 /afs/.ugcs= > >/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common
>=3B _IsM3B= > >ackFlagSupported 181 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin= > >/Unix.common
>=3B IsM3BackFlagSupported 193 /afs/.ugcs/user/mika/cm3/c= > >m3-min-LINUXLIBC6-d5.7.0/bin/Unix.common
>=3B GetM3BackFlag 197 /afs/.= > >ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common
>=3B m3_b= > >ackend 62 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.commo= > >n
>=3B program -- <=3Bbuiltin>=3B
>=3B 6 /afs/.ugcs.caltech.e= > >du/user/mika/test/LINUXLIBC6/m3make.args
>=3B
>=3B
>=3B Fa= > >tal Error: procedure "m3_backend" defined in "/afs/.ugcs/user/mika/cm3/cm3-= > >min-LINUXLIBC6-d5.7.0/bin/cm3.cfg" failed.
>=3B
>=3B Jay writes:= > >
>=3B >=3B--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_
>=3B >=3BC= > >ontent-Type: text/plain=3B charset=3D"iso-8859-1"
>=3B >=3BContent-T= > >ransfer-Encoding: quoted-printable
>=3B >=3B
>=3B >=3B
>= > >=3B >=3BThese archives do have a different format=3D2C yes.
>=3B >= > >=3B
>=3B >=3BBut it isn't a bad format.
>=3B >=3B
>=3B &= > >gt=3Bcminstall is pretty worthless imho.
>=3B >=3B
>=3B >=3BE= > >xtract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.
>=3B >=3B
&= > >gt=3B >=3B=3D20
>=3B >=3B
>=3B >=3B - Jay
>=3B >=3B<= > >BR>>=3B >=3B=3D20
>=3B >=3B>=3B To: jay.krell at cornell.edu
&= > >gt=3B >=3B>=3B Subject: Re: [M3devel] Help finding CM3 compiler for Lin= > >ux?=3D20
>=3B >=3B>=3B Date: Tue=3D2C 31 Mar 2009 15:56:11 -0700 >R>>=3B >=3B>=3B From: mika at async.caltech.edu
>=3B >=3B>=3B= > >=3D20
>=3B >=3B>=3B No=3D2C I'm sorry...
>=3B >=3B>=3B=3D= > >20
>=3B >=3B>=3B the archives do not have the usual format. I'm ex= > >pecting to unpack
>=3B >=3B>=3B and run "cminstall" and then unpac= > >k the big source tar on top and=3D20
>=3B >=3B>=3B build that. But= > > there's no cminstall in the archive on this page.
>=3B >=3B>=3B T= > >his is "the normal procedure" for installing CM3=3D2C no? It's what
>= > >=3B >=3B>=3B the instructions say to do=3D2C as well...
>=3B >= > >=3B>=3B=3D20
>=3B >=3B>=3B And the link from the "Download" page= > > is broken (to -d5.5.0.tgz).
>=3B >=3B>=3B=3D20
>=3B >=3B&g= > >t=3B Mika
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B Jay writes: >>>=3B >=3B>=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>= > >=3B >=3B>=3B >=3BContent-Type: text/plain=3D3B charset=3D3D"iso-8859-= > >1"
>=3B >=3B>=3B >=3BContent-Transfer-Encoding: quoted-printable= > >
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B
>=3B >= > >=3B>=3B >=3B http://modula3.elegosoft.com/cm3/uploaded-archives
>= > >=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B?
>=3B >=3B>= > >=3B >=3B
>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >= > >=3B
>=3B >=3B>=3B >=3BI can make another later this week.
>= > >=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B=3D3D20
>=3B >= > >=3B>=3B >=3B
>=3B >=3B>=3B >=3BAll you need is a working cm3= > > on any system.
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B= > >>=3BFrom there you can build the whole system=3D3D2C targeting any system= > >.
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3BAs long as tha= > >t cm3 understands LONGINT and your target system.
>=3B >=3B>=3B &g= > >t=3B
>=3B >=3B>=3B >=3BAnd it is easier=3D3D2C but not necessary= > >=3D3D2C if you have Python. :)
>=3B >=3B>=3B >=3B
>=3B >= > >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B
>=3B >=3B>= > >=3B >=3B - Jay
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >= > >=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Date: Tue=3D3D2C 31 Mar 2009= > > 15:43:41 -0500
>=3B >=3B>=3B >=3B>=3B From: martinbishop at bell= > >south.net
>=3B >=3B>=3B >=3B>=3B To: mika at async.caltech.edu >>>=3B >=3B>=3B >=3B>=3B CC: m3devel at elegosoft.com
>=3B >= > >=3B>=3B >=3B>=3B Subject: Re: [M3devel] Help finding CM3 compiler for= > > Linux?
>=3B >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B &= > >gt=3B>=3B Not sure if this helps=3D3D2C but on my linux system:
>=3B= > > >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Criti= > >cal Mass Modula-3 version d5.7.0
>=3B >=3B>=3B >=3B>=3B last u= > >pdated: 2008-03-16
>=3B >=3B>=3B >=3B>=3B compiled: 2008-08-14= > > 00:56:14
>=3B >=3B>=3B >=3B>=3B configuration: /usr/local/cm3= > >/bin/cm3.cfg
>=3B >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>= > >=3B >=3B>=3B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:3= > >9 UTC 2009
>=3B >=3B>=3B >=3B>=3B i686 GNU/Linux
>=3B >= > >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B=3D3D20 >>>=3B >=3B>=3B >=3B>=3B I don't have the cm3 tarball=3D3D2C but I= > > do have the sources in cm3/ st=3D
>=3B >=3Bill.
>=3B >=3B>= > >=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Mika Nystrom wr= > >ote:
>=3B >=3B>=3B >=3B>=3B >=3B Hello everyone=3D3D2C
&g= > >t=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B&= > >gt=3B >=3B This is=3D3D2C for me=3D3D2C a most unfortunate time for the C= > >M3 servers=3D
>=3B >=3B to
>=3B >=3B>=3B >=3B>=3B >= > >=3B have crashed. I'm teaching a class using Modula-3=3D3D2C and we need a<= > >BR>>=3B >=3B>=3B >=3B>=3B >=3B compiler... here's the uname of = > >the system I'm trying to use:
>=3B >=3B>=3B >=3B>=3B >=3B=3D= > >3D20
>=3B >=3B>=3B >=3B>=3B >=3B Linux lara 2.6.24ugcs1 #4 S= > >MP Mon Feb 11 10:53:03 PST 2008 i686 GNU/=3D
>=3B >=3BLin=3D3D
&g= > >t=3B >=3B>=3B >=3Bux
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D2= > >0
>=3B >=3B>=3B >=3B>=3B >=3B The most recent archives I hav= > >e for Linux are:
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>= > >=3B >=3B>=3B >=3B>=3B >=3B cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3= > >-src-all-5.4.0.tgz=3D3D20
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20= > >
>=3B >=3B>=3B >=3B>=3B >=3B And they don't seem to work on = > >this system: I can compile a program
>=3B >=3B>=3B >=3B>=3B &g= > >t=3B but when I try to run it=3D3D2C it says "Segmentation fault". Can anyo= > >=3D
>=3B >=3Bne
>=3B >=3B>=3B >=3B>=3B >=3B help? (My= > > understanding is that I need 5.5.1 or later...)
>=3B >=3B>=3B >= > >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B >=3B Mika
= > >>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >= > >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >= > >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>=3B >=3B>=3B >=3BCo= > >ntent-Type: text/html=3D3B charset=3D3D"iso-8859-1"
>=3B >=3B>=3B = > >>=3BContent-Transfer-Encoding: quoted-printable
>=3B >=3B>=3B &g= > >t=3B
>=3B >=3B>=3B >=3B<=3Bhtml>=3B
>=3B >=3B>=3B &= > >gt=3B<=3Bhead>=3B
>=3B >=3B>=3B >=3B<=3Bstyle>=3B
>= > >=3B >=3B>=3B >=3B.hmmessage P
>=3B >=3B>=3B >=3B{
>= > >=3B >=3B>=3B >=3Bmargin:0px=3D3D3B
>=3B >=3B>=3B >=3Bpaddi= > >ng:0px
>=3B >=3B>=3B >=3B}
>=3B >=3B>=3B >=3Bbody.hmm= > >essage
>=3B >=3B>=3B >=3B{
>=3B >=3B>=3B >=3Bfont-siz= > e: 10pt=3D3D3B
>=3B >=3B>=3B >=3Bfont-family:Verdana
>=3B &= > >gt=3B>=3B >=3B}
>=3B >=3B>=3B >=3B<=3B/style>=3B
>= > >=3B >=3B>=3B >=3B<=3B/head>=3B
>=3B >=3B>=3B >=3B<= > >=3Bbody class=3D3D3D'hmmessage'>=3B
>=3B >=3B>=3B >=3B&=3Bn= > >bsp=3D3D3B<=3BA href=3D3D3D"http://modula3.elegosoft.com/cm3/uploaded-arc= > >hive=3D
>=3B >=3Bs" targ=3D3D
>=3B >=3B>=3B >=3Bet=3D3D3D= > >_blank>=3B<=3BFONT color=3D3D3D#0068cf>=3Bhttp://modula3.elegosoft.co= > >m/cm3/u=3D
>=3B >=3Bploaded=3D3D
>=3B >=3B>=3B >=3B-archi= > >ves<=3B/FONT>=3B<=3B/A>=3B<=3BBR>=3B
>=3B >=3B>=3B >= > >=3B?<=3BBR>=3B
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR&= > >gt=3B
>=3B >=3B>=3B >=3BI can make another later this week.<= > >=3BBR>=3B
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B >R>>=3B >=3B>=3B >=3BAll you need is a working cm3 on any system.<= > >=3BBR>=3B
>=3B >=3B>=3B >=3B>=3BFrom there you can build the= > > whole system=3D3D2C targeting any system.<=3BBR=3D
>=3B >=3B>= > >=3B
>=3B >=3B>=3B >=3BAs long as that cm3 understands LONGINT an= > >d your target system.<=3BBR>=3B
>=3B >=3B>=3B >=3BAnd it is = > >easier=3D3D2C but not necessary=3D3D2C if you have Python. :)<=3BBR>=3B= > >
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B
>=3B &g= > >t=3B>=3B >=3B&=3Bnbsp=3D3D3B- Jay<=3BBR>=3B<=3BBR>=3B&=3B= > >nbsp=3D3D3B<=3BBR>=3B&=3Bgt=3D3D3B Date: Tue=3D3D2C 31 Mar 2009=3D >R>>=3B >=3B 15:43:41 -=3D3D
>=3B >=3B>=3B >=3B0500<=3BBR&g= > >t=3B&=3Bgt=3D3D3B From: martinbishop at bellsouth.net<=3BBR>=3B&=3Bg= > >t=3D3D3B To: mika at a=3D
>=3B >=3Bsync.ca=3D3D
>=3B >=3B>=3B = > >>=3Bltech.edu<=3BBR>=3B&=3Bgt=3D3D3B CC: m3devel at elegosoft.com<= > >=3BBR>=3B&=3Bgt=3D3D3B Subject: Re:=3D
>=3B >=3B [M3dev=3D3D >>>=3B >=3B>=3B >=3Bel] Help finding CM3 compiler for Linux?<=3BBR= > >>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B Not su=3D
>=3B &= > >gt=3Bre if t=3D3D
>=3B >=3B>=3B >=3Bhis helps=3D3D2C but on my l= > >inux system:<=3BBR>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B C= > >ritical=3D
>=3B >=3B Mass Mod=3D3D
>=3B >=3B>=3B >=3Bula-= > >3 version d5.7.0<=3BBR>=3B&=3Bgt=3D3D3B last updated: 2008-03-16<= > >=3BBR>=3B&=3Bgt=3D3D3B co=3D
>=3B >=3Bmpiled:=3D3D
>=3B &g= > >t=3B>=3B >=3B 2008-08-14 00:56:14<=3BBR>=3B&=3Bgt=3D3D3B configu= > >ration: /usr/local/cm3/bin/cm3.c=3D
>=3B >=3Bfg<=3BBR=3D3D
>= > >=3B >=3B>=3B >=3B>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3= > >B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 2=3D
>=3B >=3B9 19= > >:24=3D3D
>=3B >=3B>=3B >=3B:39 UTC 2009<=3BBR>=3B&=3Bgt= > >=3D3D3B i686 GNU/Linux<=3BBR>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bg= > >t=3D3D3B <=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3D3B I don=3D3D
&= > >gt=3B >=3B>=3B >=3B't have the cm3 tarball=3D3D2C but I do have the s= > >ources in cm3/ still.<=3BBR=3D
>=3B >=3B>=3B&=3Bgt=3D3D
&g= > >t=3B >=3B>=3B >=3B=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B Mika Nystrom= > > wrote:<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B Hello everyo=3D
&= > >gt=3B >=3Bne=3D3D2C<=3BBR>=3B&=3Bg=3D3D
>=3B >=3B>=3B >= > >=3Bt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3= > >B This is=3D3D2C for me=3D3D2C a most un=3D
>=3B >=3Bfortunate time = > >=3D3D
>=3B >=3B>=3B >=3Bfor the CM3 servers to<=3BBR>=3B&= > >=3Bgt=3D3D3B &=3Bgt=3D3D3B have crashed. I'm teaching a=3D
>=3B >= > >=3B class =3D3D
>=3B >=3B>=3B >=3Busing Modula-3=3D3D2C and we n= > >eed a<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B compiler... here'=3D >R>>=3B >=3Bs the una=3D3D
>=3B >=3B>=3B >=3Bme of the system= > > I'm trying to use:<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B <=3BBR= > >>=3B&=3Bgt=3D3D3B &=3Bg=3D
>=3B >=3Bt=3D3D3B Linu=3D3D
&g= > >t=3B >=3B>=3B >=3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2= > >008 i686 GNU/Linux<=3BBR=3D
>=3B >=3B>=3B&=3Bg=3D3D
>=3B= > > >=3B>=3B >=3Bt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3= > >B &=3Bgt=3D3D3B The most recent archives I have fo=3D
>=3B >=3Br = > >Linux are=3D3D
>=3B >=3B>=3B >=3B:<=3BBR>=3B&=3Bgt=3D3D3B= > > &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B cm3-min-P= > OSIX-LINUXLIBC6-5.=3D
>=3B >=3B4.0.tgz cm3=3D3D
>=3B >=3B>= > >=3B >=3B-src-all-5.4.0.tgz <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3= > >B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B And they =3D
>=3B &g= > >t=3Bdon't seem =3D3D
>=3B >=3B>=3B >=3Bto work on this system: I= > > can compile a program<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B but= > >=3D
>=3B >=3B when I=3D3D
>=3B >=3B>=3B >=3B try to run i= > >t=3D3D2C it says "Segmentation fault". Can anyone<=3BBR>=3B&=3Bgt=3D= > >3D3B=3D
>=3B >=3B &=3Bgt=3D3D3B=3D3D
>=3B >=3B>=3B >= > >=3B help? (My understanding is that I need 5.5.1 or later...)<=3BBR>=3B= > >&=3Bgt=3D3D3B &=3B=3D
>=3B >=3Bgt=3D3D3B=3D3D
>=3B >=3B= > >>=3B >=3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B Mika<=3BBR&= > >gt=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B <= > >=3BBR>=3B<=3B/body=3D
>=3B >=3B>=3B
>=3B >=3B>=3B >= > >=3B<=3B/html>=3B=3D3D
>=3B >=3B>=3B >=3B
>=3B >=3B>= > >=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_--
>=3B >=3B
&g= > >t=3B >=3B--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_
>=3B >=3BContent= > >-Type: text/html=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer= > >-Encoding: quoted-printable
>=3B >=3B
>=3B >=3B<=3Bhtml>= > >=3B
>=3B >=3B<=3Bhead>=3B
>=3B >=3B<=3Bstyle>=3B
&= > >gt=3B >=3B.hmmessage P
>=3B >=3B{
>=3B >=3Bmargin:0px=3D3B<= > >BR>>=3B >=3Bpadding:0px
>=3B >=3B}
>=3B >=3Bbody.hmmessag= > >e
>=3B >=3B{
>=3B >=3Bfont-size: 10pt=3D3B
>=3B >=3Bfo= > >nt-family:Verdana
>=3B >=3B}
>=3B >=3B<=3B/style>=3B
&= > >gt=3B >=3B<=3B/head>=3B
>=3B >=3B<=3Bbody class=3D3D'hmmessa= > >ge'>=3B
>=3B >=3BThese archives do have a different format=3D2C ye= > >s.<=3BBR>=3B
>=3B >=3BBut it isn't a bad format.<=3BBR>=3B >R>>=3B >=3Bcminstall is pretty worthless imho.<=3BBR>=3B
>=3B = > >>=3BExtract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.<=3BBR>=3B<= > >BR>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp= > >=3D3B- Jay<=3BBR>=3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3B&=3B= > >gt=3D3B To: jay.krell at cornell.edu<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B = > >>=3B Subject: Re: [M3devel] Help finding CM3 compiler for Linux? <=3BBR= > >>=3B&=3Bgt=3D3B Dat=3D
>=3B >=3Be: Tue=3D2C 31 Mar 2009 15:56:1= > >1 -0700<=3BBR>=3B&=3Bgt=3D3B From: mika at async.caltech.edu=3D
>= > >=3B >=3B<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B No=3D2C= > > I'm sorry...<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B the = > >archives =3D
>=3B >=3Bdo not have the usual format. I'm expecting to= > > unpack<=3BBR>=3B&=3Bgt=3D3B and run "cm=3D
>=3B >=3Binstall"= > > and then unpack the big source tar on top and <=3BBR>=3B&=3Bgt=3D3B= > > build tha=3D
>=3B >=3Bt. But there's no cminstall in the archive on= > > this page.<=3BBR>=3B&=3Bgt=3D3B This is =3D
>=3B >=3B"the no= > >rmal procedure" for installing CM3=3D2C no? It's what<=3BBR>=3B&=3Bg= > >t=3D3B the in=3D
>=3B >=3Bstructions say to do=3D2C as well...<=3B= > >BR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B And the link from t=3D<= > >BR>>=3B >=3Bhe "Download" page is broken (to -d5.5.0.tgz).<=3BBR>= > >=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Mika<=3BBR=3D
>=3B &g= > >t=3B>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Jay writes:<=3BBR&g= > >t=3B&=3Bgt=3D3B &=3Bgt=3D3B--_806446ae-8d10-4d74-8eea-5=3D
>=3B = > >>=3B1aa365e9204_<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BContent-Type: = > >text/plain=3D3B charset=3D3D"iso-885=3D
>=3B >=3B9-1"<=3BBR>=3B&= > >amp=3Bgt=3D3B &=3Bgt=3D3BContent-Transfer-Encoding: quoted-printable<= > >=3BBR>=3B&=3Bgt=3D3B =3D
>=3B >=3B&=3Bgt=3D3B<=3BBR>=3B&= > >amp=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B htt= > >p://modula3.elegosoft.com/cm3/u=3D
>=3B >=3Bploaded-archives<=3BBR= > >>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= > >=3D3B?<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D= > >
>=3B >=3B=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &a= > >mp=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BI can make another l= > >ater t=3D
>=3B >=3Bhis week.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= > >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&= > >=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >=3B &= > >amp=3Bgt=3D3BAll you need is a working cm3 on any system.<=3BBR>=3B&= > >=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &= > >amp=3Bgt=3D3B&=3Bgt=3D3BFrom there you can build the whole system=3D3D2C= > > targeting an=3D
>=3B >=3By system.<=3BBR>=3B&=3Bgt=3D3B &= > >=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAs long as that cm3 un= > >derstands =3D
>=3B >=3BLONGINT and your target system.<=3BBR>=3B= > >&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAnd= > > it is =3D
>=3B >=3Beasier=3D3D2C but not necessary=3D3D2C if you ha= > >ve Python. :)<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3B=3D
>=3B= > > >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt= > >=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B - Jay<=3B= > >BR>=3B&=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B<=3BBR>=3B&= > >=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B= > >&=3Bgt=3D3B Date: Tue=3D3D2C 31 Mar 2009=3D
>=3B >=3B 15:43:41 -0= > >500<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B From: martinbi= > >shop at bellsouth.net<=3BBR>=3B=3D
>=3B >=3B&=3Bgt=3D3B &=3Bg= > >t=3D3B&=3Bgt=3D3B To: mika at async.caltech.edu<=3BBR>=3B&=3Bgt=3D3B= > > &=3Bgt=3D3B&=3Bgt=3D3B CC: m=3D
>=3B >=3B3devel at elegosoft.com= > ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B Subject: Re: [M3d= > >evel] Help fin=3D
>=3B >=3Bding CM3 compiler for Linux?<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bg= > >t=3D3B &=3Bgt=3D3B&=3Bg=3D
>=3B >=3Bt=3D3B Not sure if this he= > >lps=3D3D2C but on my linux system:<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= > >3B&=3Bg=3D
>=3B >=3Bt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &am= > >p=3Bgt=3D3B&=3Bgt=3D3B Critical Mass Modula-3 version d5.7.0<=3BBR>= > >=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B last upd= > >ated: 2008-03-16<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B c= > >ompiled=3D
>=3B >=3B: 2008-08-14 00:56:14<=3BBR>=3B&=3Bgt=3D3= > >B &=3Bgt=3D3B&=3Bgt=3D3B configuration: /usr/local/cm3/=3D
>=3B = > >>=3Bbin/cm3.cfg<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B= > >=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B Linux thin= > >kp=3D
>=3B >=3Bad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2= > >009<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bg=3D
>=3B >=3Bt= > >=3D3B i686 GNU/Linux<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D= > >3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20= > >=3D
>=3B >=3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D= > >3B I don't have the cm3 tarball=3D3D2C but I do have the=3D
>=3B >= > >=3B sources in cm3/ still.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B = > >=3D
>=3B >=3BMika Nystrom wrote:<=3BBR>=3B&=3Bgt=3D3B &=3B= > >gt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B Hello everyone=3D3D2C<=3BBR>=3B&am= > >p=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B= > >=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt= > >=3D3B This is=3D3D2C fo=3D
>=3B >=3Br me=3D3D2C a most unfortunate t= > >ime for the CM3 servers to<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B have crashed. I'm teaching a = > >class using Modula-3=3D3D2C and we n=3D
>=3B >=3Beed a<=3BBR>=3B= > >&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B compiler... here= > >'s the uname of the sys=3D
>=3B >=3Btem I'm trying to use:<=3BBR&g= > >t=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3B= > >BR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3B=3D
>=3B >=3Bgt=3D3B &am= > >p=3Bgt=3D3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i68= > >=3D
>=3B >=3B6 GNU/Lin=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= > >3Bux<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3= > >B=3D3D20<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &=3Bgt=3D3B&= > >=3Bgt=3D3B &=3Bgt=3D3B The most recent archives I have for Linux are:<= > >=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B = > >&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt= > >=3D3B &=3Bgt=3D3B cm3-min-POSIX-=3D
>=3B >=3BLINUXLIBC6-5.4.0.tgz= > > cm3-src-all-5.4.0.tgz=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&am= > >p=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B=3D3D20<=3BBR>=3B&=3Bg= > >t=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B And they don't seem to w= > >ork on this =3D
>=3B >=3Bsystem: I can compile a program<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B but when I tr= > >=3D
>=3B >=3By to run it=3D3D2C it says "Segmentation fault". Can an= > >yone<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3B=3D
>=3B >=3Bg= > >t=3D3B &=3Bgt=3D3B help? (My understanding is that I need 5.5.1 or later= > >...)<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bg= > >t=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Bgt=3D3B &=3Bgt=3D3B Mika<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >= > >=3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3B= > >gt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &am= > >p=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B-= > >-_806446ae-8d10-4d74-8eea-51aa365e9204_<=3BBR>=3B&=3Bgt=3D3B &=3B= > >gt=3D3BConten=3D
>=3B >=3Bt-Type: text/html=3D3B charset=3D3D"iso-88= > >59-1"<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BContent-Transfe=3D
>= > >=3B >=3Br-Encoding: quoted-printable<=3BBR>=3B&=3Bgt=3D3B &=3Bg= > >t=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3Bhtml&=3Bg= > >t=3D
>=3B >=3B=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Blt=3D3Bhead&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Blt=3D3Bstyle&=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D= > >3B &=3Bgt=3D3B.hmmessage P<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B{&l= > >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bmargin:0px=3D3D3B<=3B=3D
>= > >=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bpadding:0px<=3BBR>=3B&am= > >p=3Bgt=3D3B &=3Bgt=3D3B}<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bbody.= > >hmmessag=3D
>=3B >=3Be<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B{&l= > >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfont-size: 10pt=3D3D3B<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3Bfo=3D
>=3B >=3Bnt-family:Verdana<= > >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B}<=3BBR>=3B&=3Bgt=3D3B &= > >=3Bgt=3D3B&=3Blt=3D3B/style&=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>= > >=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3B/head&=3Bgt=3D3B<=3BBR&g= > >t=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3Bbody class=3D3D3D'hmmessa=3D= > >
>=3B >=3Bge'&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= > >3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BA href=3D3D3D"http://modula3.=3D<= > >BR>>=3B >=3Belegosoft.com/cm3/uploaded-archives" targ=3D3D<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3Bet=3D3D3D_blank&=3B=3D
>=3B >=3Bg= > >t=3D3B&=3Blt=3D3BFONT color=3D3D3D#0068cf&=3Bgt=3D3Bhttp://modula3.el= > >egosoft.com/cm3/upl=3D
>=3B >=3Boaded=3D3D<=3BBR>=3B&=3Bgt=3D= > >3B &=3Bgt=3D3B-archives&=3Blt=3D3B/FONT&=3Bgt=3D3B&=3Blt=3D3B/A= > >&=3Bgt=3D3B&=3Blt=3D3BBR&=3Bg=3D
>=3B >=3Bt=3D3B<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3B?&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3B=3D= > >
>=3B >=3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3= > >BI can make another later this week.&=3Blt=3D3BBR&=3Bgt=3D3B<=3B=3D= > >
>=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp= > >=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= > >=3D3BAll you need=3D
>=3B >=3B is a working cm3 on any system.&= > >=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Bgt=3D3BFrom t=3D
>=3B >=3Bhere you can build the whole system=3D3= > >D2C targeting any system.&=3Blt=3D3BBR&=3Bgt=3D
>=3B >=3B=3D3B= > ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAs long as that cm3 understands = > >LONGINT and your target=3D
>=3B >=3B system.&=3Blt=3D3BBR&=3Bg= > >t=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAnd it is easier=3D3D2C bu= > >t not necess=3D
>=3B >=3Bary=3D3D2C if you have Python. :)&=3Blt= > >=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp= > >=3D3Bnbsp=3D
>=3B >=3B=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR&= > >gt=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B- Jay&=3Blt= > >=3D3BBR&=3Bgt=3D3B&=3Blt=3D
>=3B >=3B=3D3BBR&=3Bgt=3D3B&= > >=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3= > >B Date: Tue=3D3D2C 31 M=3D
>=3B >=3Bar 2009 15:43:41 -=3D3D<=3BBR&= > >gt=3B&=3Bgt=3D3B &=3Bgt=3D3B0500&=3Blt=3D3BBR&=3Bgt=3D3B&=3B= > >amp=3D3Bgt=3D3D3B From=3D
>=3B >=3B: martinbishop at bellsouth.net&= > >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B To: mika at async.ca=3D
= > >>=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bltech.edu&= > >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B CC: m3devel at elego=3D
= > >>=3B >=3Bsoft.com&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B= > > Subject: Re: [M3dev=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D
>= > >=3B >=3B=3D3Bel] Help finding CM3 compiler for Linux?&=3Blt=3D3BBR&= > >=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D
>=3B >=3B=3D3BBR&= > >=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B Not sure if t=3D3D<=3BBR>=3B&=3Bg= > >t=3D3B &=3Bgt=3D3Bhis helps=3D3D2C b=3D
>=3B >=3But on my linux s= > >ystem:&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3B= > >BR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D
>=3B >=3B=3D3D3B Critical Mass = > >Mod=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bula-3 version d5.7.0&= > >=3Blt=3D3BBR&=3Bgt=3D
>=3B >=3B=3D3B&=3Bamp=3D3Bgt=3D3D3B last= > > updated: 2008-03-16&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B = > >comp=3D
>=3B >=3Biled:=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= > >3B 2008-08-14 00:56:14&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3= > >B c=3D
>=3B >=3Bonfiguration: /usr/local/cm3/bin/cm3.cfg&=3Blt=3D= > >3BBR=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B&=3B= > >=3D
>=3B >=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3B= > >amp=3D3Bgt=3D3D3B Linux thinkpad 2.6.27-11-generic=3D
>=3B >=3B #1 S= > >MP Thu Jan 29 19:24=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B:39 UTC = > >2009&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3= > >D3B i686 GNU/Linux&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &a= > >mp=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3B=3D
>=3B >=3Bgt=3D3D3B &a= > >mp=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B I don=3D3D<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3B't have the c=3D
>=3B >=3Bm3 tarball= > >=3D3D2C but I do have the sources in cm3/ still.&=3Blt=3D3BBR&=3Bgt= > >=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D<=3BBR>=3B&=3Bgt=3D3B= > > &=3Bgt=3D3B=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D= > >3B Mika Nystrom wr=3D
>=3B >=3Bote:&=3Blt=3D3BBR&=3Bgt=3D3B&am= > >p=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B Hello everyone=3D3D2C&=3B= > >lt=3D3BBR=3D
>=3B >=3B&=3Bgt=3D3B&=3Bamp=3D3Bg=3D3D<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3Bt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt= > >=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D3B &=3Bam= > >p=3D3Bgt=3D3D3B This is=3D3D2C for me=3D3D2C a most unfortunate time =3D >>>=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfor the CM3 s= > >ervers to&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp= > >=3D
>=3B >=3B=3D3Bgt=3D3D3B have crashed. I'm teaching a class =3D3D= > ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Busing Mod=3D
>=3B >=3Bula= > >-3=3D3D2C and we need a&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D= > >3B &=3Bamp=3D3Bgt=3D3D3B compile=3D
>=3B >=3Br... here's the una= > >=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bme of the system I'm trying= > > to use:&=3B=3D
>=3B >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt= > >=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp= > >=3D3Bgt=3D3D3B &=3Bam=3D
>=3B >=3Bp=3D3Bgt=3D3D3B Linu=3D3D<=3B= > >BR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 1= > >0=3D
>=3B >=3B:53:03 PST 2008 i686 GNU/Linux&=3Blt=3D3BBR&=3Bg= > >t=3D3B&=3Bamp=3D3Bg=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bt=3D<= > >BR>>=3B >=3B=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt= > >=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B The most r=3D
>= > >=3B >=3Becent archives I have for Linux are=3D3D<=3BBR>=3B&=3Bgt= > >=3D3B &=3Bgt=3D3B:&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B = > >>=3B=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3= > >B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B cm3-m=3D
>=3B >= > >=3Bin-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D3D<=3BBR>=3B&=3Bgt=3D3B &= > >=3Bgt=3D3B-src-all-5.4.0.tgz &=3Blt=3D
>=3B =3D3BBR&=3Bgt=3D3B&a= > >mp=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt= > >=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D3B = > >And they don't seem =3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bto work= > > on this system: =3D
>=3B >=3BI can compile a program&=3Blt=3D3BB= > >R&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B but when= > >=3D
>=3B >=3B I=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B try = > >to run it=3D3D2C it says "Segmentation fault". Can=3D
>=3B >=3B anyo= > >ne&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt= > >=3D3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B help=3D
>=3B &= > >gt=3B? (My understanding is that I need 5.5.1 or later...)&=3Blt=3D3BBR&= > >amp=3Bgt=3D3B&=3Bamp=3D3Bg=3D
>=3B >=3Bt=3D3D3B &=3Bamp=3D3Bgt= > >=3D3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B &=3Blt=3D3BBR&am= > >p=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D
>=3B >=3B=3D3Bgt= > >=3D3D3B Mika&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Ba= > >mp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Ba=3D
>=3B >=3B= > >mp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Blt=3D3B/body&=3Bgt= > >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3B/html&=3Bg= > >t=3D
>=3B >=3B=3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >lt=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B--_806446ae-8d10-4d74-8eea-51aa36= > >5e=3D
>=3B >=3B9204_--<=3BBR>=3B<=3B/body>=3B
>=3B >= > >=3B<=3B/html>=3B=3D
>=3B >=3B
>=3B >=3B--_777fdc4e-3c29-4= > >0b4-a3dd-e6243f796cee_--
> >= > > > >--_55339e45-8c85-4ab6-9440-0d2131bbad69_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 1 08:58:19 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Apr 2009 06:58:19 +0000 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: <200904010653.n316rcZs073236@camembert.async.caltech.edu> References: Your message of "Wed, 01 Apr 2009 06:13:00 -0000." <200904010653.n316rcZs073236@camembert.async.caltech.edu> Message-ID: For the first part, do you have CM3_ROOT set to the root of your cvs checkout? It should use that to find a current set of config files. For the second part, wrong file, my fault. That is an "unconfigured" file -- one that cminstall hasn't munged. How about m3-sys/cminstall/src/config-no-install/cm3.cfg? - Jay > To: jay.krell at cornell.edu > Date: Tue, 31 Mar 2009 23:53:38 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Help finding CM3 compiler for Linux? > > To be honest, I'm not so sure what's intended. > > I either get this: > > "/home/mika/cm3/cm3-std-LINUXLIBC6-d5.7.0/bin/cm3.cfg", line 125: quake runtime error: unable to find a configuration file for (/home/mika/cm3/cm3-std-LINUXLIBC6-d5.7.0/bin/.., /afs/.ugcs/user/mika/cm3/cm3-std-LINUXLIBC6-d5.7.0, LINUXLIBC6) > > or, if I put back the LINUXLIBC6 file you had me delete: > > "/home/mika/cm3/cm3-std-LINUXLIBC6-d5.7.0/bin/cm3.cfg", line 128: quake runtime error: /home/mika/cm3/cm3-std-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6, line 61: syntax error: missing: <*EOF*> (found: ) > > which refers to the following (which looks like cminstall stuff to me): > > INITIAL_REACTOR_EDITOR = BEGIN_CONFIG > "What should be the default text editor for new Reactor users?" <--- this line > 10 "EDITOR" > 0 "emacsclient" > 0 "emacs" > 0 "vi" > 0 "textedit" > 0 "xedit" > 6 "/usr/local/emacs/bin" "emacsclient" > 6 "/usr/local/bin" "emacsclient" > 6 "/usr/local/emacs/bin" "emacs" > 6 "/usr/local/bin" "emacs" > 6 "/usr/bin" "vi" > 6 "/usr/local/X11R5/bin" "xedit" > 6 "/usr/openwin/bin" "textedit" > > Jay writes: > >--_55339e45-8c85-4ab6-9440-0d2131bbad69_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Maybe not. > > > >Hm. That is bug. There is use with a cvs tree=2C and use without. > > > >I must have broken use without. > > > >=20 > > > >Try this: > > > >export CM3_ROOT=3Droot of cm3 cvs (for me this is /dev2/cm3=2C > > > >for you=2C maybe $HOME/cm3?) > > > >rm $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6 > > > ># *Common and *common in one command > >rm $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/*ommon > >cp root of cm3 cvs/m3-sys/cminstall/src/config/cm3.cfg $HOME/cm3/cm3-min-LI= > >NUXLIBC6-d5.7.0/bin > > > >=20 > > > >The .cfg will delegate out to the cvs tree. > > > >I don't like having two copies of files..having to keep them in sync.. > > > > Though the archives are meant to work standalone=2C without CVS. > > > > But I don't test that so much oops sorry. > > > >That /might/ not be the right file=2C but it is close. > > > >=20 > > > > - Jay > > > >=20 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux?=20 > >> Date: Tue=2C 31 Mar 2009 22:59:18 -0700 > >> From: mika at async.caltech.edu > >>=20 > >>=20 > >> Is there any documentation for this format beyond what you just > >> wrote? Where? > >>=20 > >> terpsichore-14: cm3 > >> --- building in ../LINUXLIBC6 --- > >>=20 > >> new source -> compiling Main.m3 > >> "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common"=2C= > > line 169: quake runtime error: undefined variable: ROOT > >>=20 > >> --procedure-- -line- -file--- > >> GetM3Back 169 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3c= > >fg.common > >> _IsM3BackFlagSupported 181 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5= > >.7.0/bin/Unix.common > >> IsM3BackFlagSupported 193 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.= > >7.0/bin/Unix.common > >> GetM3BackFlag 197 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/= > >Unix.common > >> m3_backend 62 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix= > >.common > >> program -- > >> 6 /afs/.ugcs.caltech.edu/user/mika/test/LINUXLIBC6/m3make.args > >>=20 > >>=20 > >> Fatal Error: procedure "m3_backend" defined in "/afs/.ugcs/user/mika/cm3/= > >cm3-min-LINUXLIBC6-d5.7.0/bin/cm3.cfg" failed. > >>=20 > >> Jay writes: > >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ > >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> >These archives do have a different format=3D2C yes. > >> > > >> >But it isn't a bad format. > >> > > >> >cminstall is pretty worthless imho. > >> > > >> >Extract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH. > >> > > >> >=3D20 > >> > > >> > - Jay > >> > > >> >=3D20 > >> >> To: jay.krell at cornell.edu > >> >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux?=3D20 > >> >> Date: Tue=3D2C 31 Mar 2009 15:56:11 -0700 > >> >> From: mika at async.caltech.edu > >> >>=3D20 > >> >> No=3D2C I'm sorry... > >> >>=3D20 > >> >> the archives do not have the usual format. I'm expecting to unpack > >> >> and run "cminstall" and then unpack the big source tar on top and=3D20 > >> >> build that. But there's no cminstall in the archive on this page. > >> >> This is "the normal procedure" for installing CM3=3D2C no? It's what > >> >> the instructions say to do=3D2C as well... > >> >>=3D20 > >> >> And the link from the "Download" page is broken (to -d5.5.0.tgz). > >> >>=3D20 > >> >> Mika > >> >>=3D20 > >> >> Jay writes: > >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ > >> >> >Content-Type: text/plain=3D3B charset=3D3D"iso-8859-1" > >> >> >Content-Transfer-Encoding: quoted-printable > >> >> > > >> >> > > >> >> > http://modula3.elegosoft.com/cm3/uploaded-archives > >> >> > > >> >> >? > >> >> > > >> >> >=3D3D20 > >> >> > > >> >> >I can make another later this week. > >> >> > > >> >> >=3D3D20 > >> >> > > >> >> >All you need is a working cm3 on any system. > >> >> > > >> >> >>From there you can build the whole system=3D3D2C targeting any syste= > >m. > >> >> > > >> >> >As long as that cm3 understands LONGINT and your target system. > >> >> > > >> >> >And it is easier=3D3D2C but not necessary=3D3D2C if you have Python. = > >:) > >> >> > > >> >> >=3D3D20 > >> >> > > >> >> > - Jay > >> >> > > >> >> >=3D3D20 > >> >> >> Date: Tue=3D3D2C 31 Mar 2009 15:43:41 -0500 > >> >> >> From: martinbishop at bellsouth.net > >> >> >> To: mika at async.caltech.edu > >> >> >> CC: m3devel at elegosoft.com > >> >> >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? > >> >> >>=3D3D20 > >> >> >> Not sure if this helps=3D3D2C but on my linux system: > >> >> >>=3D3D20 > >> >> >> Critical Mass Modula-3 version d5.7.0 > >> >> >> last updated: 2008-03-16 > >> >> >> compiled: 2008-08-14 00:56:14 > >> >> >> configuration: /usr/local/cm3/bin/cm3.cfg > >> >> >>=3D3D20 > >> >> >> Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 200= > >9 > >> >> >> i686 GNU/Linux > >> >> >>=3D3D20 > >> >> >>=3D3D20 > >> >> >> I don't have the cm3 tarball=3D3D2C but I do have the sources in cm= > >3/ st=3D > >> >ill. > >> >> >>=3D3D20 > >> >> >> Mika Nystrom wrote: > >> >> >> > Hello everyone=3D3D2C > >> >> >> >=3D3D20 > >> >> >> > This is=3D3D2C for me=3D3D2C a most unfortunate time for the CM3 = > >servers=3D > >> > to > >> >> >> > have crashed. I'm teaching a class using Modula-3=3D3D2C and we n= > >eed a > >> >> >> > compiler... here's the uname of the system I'm trying to use: > >> >> >> >=3D3D20 > >> >> >> > Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 G= > >NU/=3D > >> >Lin=3D3D > >> >> >ux > >> >> >> >=3D3D20 > >> >> >> > The most recent archives I have for Linux are: > >> >> >> >=3D3D20 > >> >> >> > cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D3D20 > >> >> >> >=3D3D20 > >> >> >> > And they don't seem to work on this system: I can compile a progr= > >am > >> >> >> > but when I try to run it=3D3D2C it says "Segmentation fault". Can= > > anyo=3D > >> >ne > >> >> >> > help? (My understanding is that I need 5.5.1 or later...) > >> >> >> >=3D3D20 > >> >> >> > Mika > >> >> >> >=3D3D20 > >> >> >>=3D3D20 > >> >> > > >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ > >> >> >Content-Type: text/html=3D3B charset=3D3D"iso-8859-1" > >> >> >Content-Transfer-Encoding: quoted-printable > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > =3D3D3B >archive=3D > >> >s" targ=3D3D > >> >> >et=3D3D3D_blank>http://modula3.elegosoft.co= > >m/cm3/u=3D > >> >ploaded=3D3D > >> >> >-archives
> >> >> >?
> >> >> > =3D3D3B
> >> >> >I can make another later this week.
> >> >> > =3D3D3B
> >> >> >All you need is a working cm3 on any system.
> >> >> >>From there you can build the whole system=3D3D2C targeting any syste= > >m. >> >> > >> >> >As long as that cm3 understands LONGINT and your target system.
> >> >> >And it is easier=3D3D2C but not necessary=3D3D2C if you have Python. = > >:)
> >> >> > =3D3D3B
> >> >> > =3D3D3B- Jay

 =3D3D3B
>=3D3D3B Date: Tue=3D3D2C = > >31 Mar 2009=3D > >> > 15:43:41 -=3D3D > >> >> >0500
>=3D3D3B From: martinbishop at bellsouth.net
>=3D3D3B To:= > > mika at a=3D > >> >sync.ca=3D3D > >> >> >ltech.edu
>=3D3D3B CC: m3devel at elegosoft.com
>=3D3D3B Subje= > >ct: Re:=3D > >> > [M3dev=3D3D > >> >> >el] Help finding CM3 compiler for Linux?
>=3D3D3B
>=3D3D3B= > > Not su=3D > >> >re if t=3D3D > >> >> >his helps=3D3D2C but on my linux system:
>=3D3D3B
>=3D3D3B= > > Critical=3D > >> > Mass Mod=3D3D > >> >> >ula-3 version d5.7.0
>=3D3D3B last updated: 2008-03-16
>=3D= > >3D3B co=3D > >> >mpiled:=3D3D > >> >> > 2008-08-14 00:56:14
>=3D3D3B configuration: /usr/local/cm3/bin/= > >cm3.c=3D > >> >fg >> >> >>>=3D3D3B
>=3D3D3B Linux thinkpad 2.6.27-11-generic #1 SMP Th= > >u Jan 2=3D > >> >9 19:24=3D3D > >> >> >:39 UTC 2009
>=3D3D3B i686 GNU/Linux
>=3D3D3B
>=3D3D3= > >B
>=3D > >> >=3D3D3B I don=3D3D > >> >> >'t have the cm3 tarball=3D3D2C but I do have the sources in cm3/ stil= > >l. >> >>>=3D3D > >> >> >=3D3D3B
>=3D3D3B Mika Nystrom wrote:
>=3D3D3B >=3D3D3B H= > >ello everyo=3D > >> >ne=3D3D2C
&g=3D3D > >> >> >t=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B This is=3D3D2C for me= > >=3D3D2C a most un=3D > >> >fortunate time =3D3D > >> >> >for the CM3 servers to
>=3D3D3B >=3D3D3B have crashed. I'm tea= > >ching a=3D > >> > class =3D3D > >> >> >using Modula-3=3D3D2C and we need a
>=3D3D3B >=3D3D3B compiler= > >... here'=3D > >> >s the una=3D3D > >> >> >me of the system I'm trying to use:
>=3D3D3B >=3D3D3B
>= > >=3D3D3B &g=3D > >> >t=3D3D3B Linu=3D3D > >> >> >x lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Linux= > > >> >>&g=3D3D > >> >> >t=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B The most recent archive= > >s I have fo=3D > >> >r Linux are=3D3D > >> >> >:
>=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B cm3-min-POSIX-LI= > >NUXLIBC6-5.=3D > >> >4.0.tgz cm3=3D3D > >> >> >-src-all-5.4.0.tgz
>=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3= > >B And they =3D > >> >don't seem =3D3D > >> >> >to work on this system: I can compile a program
>=3D3D3B >=3D3= > >D3B but=3D > >> > when I=3D3D > >> >> > try to run it=3D3D2C it says "Segmentation fault". Can anyone
>= > >=3D3D3B=3D > >> > >=3D3D3B=3D3D > >> >> > help? (My understanding is that I need 5.5.1 or later...)
>=3D3= > >D3B &=3D > >> >gt=3D3D3B=3D3D > >> >> >
>=3D3D3B >=3D3D3B Mika
>=3D3D3B >=3D3D3B
>=3D3D= > >3B
>> >> > >> >> >=3D3D > >> >> > > >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_-- > >> > > >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ > >> >Content-Type: text/html=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> > > >> > > >> > > >> > > >> >These archives do have a different format=3D2C yes.
> >> >But it isn't a bad format.
> >> >cminstall is pretty worthless imho.
> >> >Extract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.
> >> > =3D3B
> >> > =3D3B- Jay

 =3D3B
>=3D3B To: jay.krell at cornell.edu<= > >BR>>=3D3B=3D > >> > Subject: Re: [M3devel] Help finding CM3 compiler for Linux?
>=3D3= > >B Dat=3D > >> >e: Tue=3D2C 31 Mar 2009 15:56:11 -0700
>=3D3B From: mika at async.calt= > >ech.edu=3D > >> >
>=3D3B
>=3D3B No=3D2C I'm sorry...
>=3D3B
>=3D3B = > >the archives =3D > >> >do not have the usual format. I'm expecting to unpack
>=3D3B and ru= > >n "cm=3D > >> >install" and then unpack the big source tar on top and
>=3D3B buil= > >d tha=3D > >> >t. But there's no cminstall in the archive on this page.
>=3D3B Thi= > >s is =3D > >> >"the normal procedure" for installing CM3=3D2C no? It's what
>=3D3B= > > the in=3D > >> >structions say to do=3D2C as well...
>=3D3B
>=3D3B And the li= > >nk from t=3D > >> >he "Download" page is broken (to -d5.5.0.tgz).
>=3D3B
>=3D3B = > >Mika >> >>>=3D3B
>=3D3B Jay writes:
>=3D3B >=3D3B--_806446ae-8d10-= > >4d74-8eea-5=3D > >> >1aa365e9204_
>=3D3B >=3D3BContent-Type: text/plain=3D3B charset= > >=3D3D"iso-885=3D > >> >9-1"
>=3D3B >=3D3BContent-Transfer-Encoding: quoted-printable
= > >>=3D3B =3D > >> >>=3D3B
>=3D3B >=3D3B
>=3D3B >=3D3B http://modula3.elegos= > >oft.com/cm3/u=3D > >> >ploaded-archives
>=3D3B >=3D3B
>=3D3B >=3D3B?
>=3D3B = > >>=3D3B
>=3D > >> >=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B
>=3D3B >=3D3BI can mak= > >e another later t=3D > >> >his week.
>=3D3B >=3D3B
>=3D3B >=3D3B=3D3D20
>=3D3B &= > >gt=3D3B
>=3D3B=3D > >> > >=3D3BAll you need is a working cm3 on any system.
>=3D3B >=3D= > >3B
>=3D > >> >=3D3B >=3D3B>=3D3BFrom there you can build the whole system=3D3D2C t= > >argeting an=3D > >> >y system.
>=3D3B >=3D3B
>=3D3B >=3D3BAs long as that cm3 u= > >nderstands =3D > >> >LONGINT and your target system.
>=3D3B >=3D3B
>=3D3B >=3D3= > >BAnd it is =3D > >> >easier=3D3D2C but not necessary=3D3D2C if you have Python. :)
>=3D3= > >B >=3D3B<=3D > >> >BR>>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B
>=3D3B >=3D3B - = > >Jay
>=3D3B >=3D > >> >=3D3B
>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B Date: Tue= > >=3D3D2C 31 Mar 2009=3D > >> > 15:43:41 -0500
>=3D3B >=3D3B>=3D3B From: martinbishop at bellsout= > >h.net
=3D > >> >>=3D3B >=3D3B>=3D3B To: mika at async.caltech.edu
>=3D3B >=3D3= > >B>=3D3B CC: m=3D > >> >3devel at elegosoft.com
>=3D3B >=3D3B>=3D3B Subject: Re: [M3devel]= > > Help fin=3D > >> >ding CM3 compiler for Linux?
>=3D3B >=3D3B>=3D3B=3D3D20
>= > >=3D3B >=3D3B&g=3D > >> >t=3D3B Not sure if this helps=3D3D2C but on my linux system:
>=3D3B= > > >=3D3B&g=3D > >> >t=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B Critical Mass Modula-3 versio= > >n d5.7.0
&=3D > >> >gt=3D3B >=3D3B>=3D3B last updated: 2008-03-16
>=3D3B >=3D3B&g= > >t=3D3B compiled=3D > >> >: 2008-08-14 00:56:14
>=3D3B >=3D3B>=3D3B configuration: /usr/l= > >ocal/cm3/=3D > >> >bin/cm3.cfg
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B >=3D3B>= > >=3D3B Linux thinkp=3D > >> >ad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009
>=3D3B >= > >=3D3B&g=3D > >> >t=3D3B i686 GNU/Linux
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B &g= > >t=3D3B>=3D3B=3D3D20=3D > >> >
>=3D3B >=3D3B>=3D3B I don't have the cm3 tarball=3D3D2C but I = > >do have the=3D > >> > sources in cm3/ still.
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B = > >>=3D3B>=3D3B =3D > >> >Mika Nystrom wrote:
>=3D3B >=3D3B>=3D3B >=3D3B Hello everyone= > >=3D3D2C
&g=3D > >> >t=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B >= > >=3D3B This is=3D3D2C fo=3D > >> >r me=3D3D2C a most unfortunate time for the CM3 servers to
>=3D3B &= > >gt=3D3B&g=3D > >> >t=3D3B >=3D3B have crashed. I'm teaching a class using Modula-3=3D3D2C= > > and we n=3D > >> >eed a
>=3D3B >=3D3B>=3D3B >=3D3B compiler... here's the uname= > > of the sys=3D > >> >tem I'm trying to use:
>=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
&= > >gt=3D3B >=3D3B&=3D > >> >gt=3D3B >=3D3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2= > >008 i68=3D > >> >6 GNU/Lin=3D3D
>=3D3B >=3D3Bux
>=3D3B >=3D3B>=3D3B >= > >=3D3B=3D3D20
>=3D > >> >=3D3B >=3D3B>=3D3B >=3D3B The most recent archives I have for Linu= > >x are:
&=3D > >> >gt=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B &g= > >t=3D3B cm3-min-POSIX-=3D > >> >LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D3D20
>=3D3B >=3D3B&g= > >t=3D3B >=3D > >> >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B >=3D3B And they don't seem t= > >o work on this =3D > >> >system: I can compile a program
>=3D3B >=3D3B>=3D3B >=3D3B bu= > >t when I tr=3D > >> >y to run it=3D3D2C it says "Segmentation fault". Can anyone
>=3D3B = > >>=3D3B&=3D > >> >gt=3D3B >=3D3B help? (My understanding is that I need 5.5.1 or later..= > >.)
&=3D > >> >gt=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B &g= > >t=3D3B Mika
>=3D3B=3D > >> > >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B=3D3D20 >>>=3D3B >=3D3B
&=3D > >> >gt=3D3B >=3D3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>=3D3B >= > >=3D3BConten=3D > >> >t-Type: text/html=3D3B charset=3D3D"iso-8859-1"
>=3D3B >=3D3BCont= > >ent-Transfe=3D > >> >r-Encoding: quoted-printable
>=3D3B >=3D3B
>=3D3B >=3D3B&l= > >t=3D3Bhtml>=3D > >> >=3D3B
>=3D3B >=3D3B<=3D3Bhead>=3D3B
>=3D3B >=3D3B<= > >=3D3Bstyle>=3D3B
&=3D > >> >gt=3D3B >=3D3B.hmmessage P
>=3D3B >=3D3B{
>=3D3B >=3D3Bm= > >argin:0px=3D3D3B<=3D > >> >BR>>=3D3B >=3D3Bpadding:0px
>=3D3B >=3D3B}
>=3D3B >=3D= > >3Bbody.hmmessag=3D > >> >e
>=3D3B >=3D3B{
>=3D3B >=3D3Bfont-size: 10pt=3D3D3B
&g= > >t=3D3B >=3D3Bfo=3D > >> >nt-family:Verdana
>=3D3B >=3D3B}
>=3D3B >=3D3B<=3D3B/sty= > >le>=3D3B
&=3D > >> >gt=3D3B >=3D3B<=3D3B/head>=3D3B
>=3D3B >=3D3B<=3D3Bbody c= > >lass=3D3D3D'hmmessa=3D > >> >ge'>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BA href=3D3D3= > >D"http://modula3.=3D > >> >elegosoft.com/cm3/uploaded-archives" targ=3D3D
>=3D3B >=3D3Bet=3D= > >3D3D_blank&=3D > >> >gt=3D3B<=3D3BFONT color=3D3D3D#0068cf>=3D3Bhttp://modula3.elegosoft.= > >com/cm3/upl=3D > >> >oaded=3D3D
>=3D3B >=3D3B-archives<=3D3B/FONT>=3D3B<=3D3B/A&= > >gt=3D3B<=3D3BBR&g=3D > >> >t=3D3B
>=3D3B >=3D3B?<=3D3BBR>=3D3B
>=3D3B >=3D3B&= > >=3D3Bnbsp=3D3D3B<=3D3B=3D > >> >BR>=3D3B
>=3D3B >=3D3BI can make another later this week.<=3D= > >3BBR>=3D3B<=3D > >> >BR>>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
>=3D3B &= > >gt=3D3BAll you need=3D > >> > is a working cm3 on any system.<=3D3BBR>=3D3B
>=3D3B >=3D3B&= > >gt=3D3BFrom t=3D > >> >here you can build the whole system=3D3D2C targeting any system.<=3D3B= > >BR>=3D > >> >=3D3B
>=3D3B >=3D3BAs long as that cm3 understands LONGINT and yo= > >ur target=3D > >> > system.<=3D3BBR>=3D3B
>=3D3B >=3D3BAnd it is easier=3D3D2C b= > >ut not necess=3D > >> >ary=3D3D2C if you have Python. :)<=3D3BBR>=3D3B
>=3D3B >=3D3B= > >&=3D3Bnbsp=3D > >> >=3D3D3B<=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B- Jay&= > >lt=3D3BBR>=3D3B<=3D > >> >=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B = > >Date: Tue=3D3D2C 31 M=3D > >> >ar 2009 15:43:41 -=3D3D
>=3D3B >=3D3B0500<=3D3BBR>=3D3B&= > >=3D3Bgt=3D3D3B From=3D > >> >: martinbishop at bellsouth.net<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B To: mik= > >a at async.ca=3D > >> >=3D3D
>=3D3B >=3D3Bltech.edu<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B = > >CC: m3devel at elego=3D > >> >soft.com<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Subject: Re: [M3dev=3D3D >>>=3D3B >=3D > >> >=3D3Bel] Help finding CM3 compiler for Linux?<=3D3BBR>=3D3B&=3D3B= > >gt=3D3D3B <=3D > >> >=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Not sure if t=3D3D
>=3D3B >=3D3= > >Bhis helps=3D3D2C b=3D > >> >ut on my linux system:<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B <=3D3BBR>= > >=3D3B&=3D3Bgt=3D > >> >=3D3D3B Critical Mass Mod=3D3D
>=3D3B >=3D3Bula-3 version d5.7.0&= > >lt=3D3BBR>=3D > >> >=3D3B&=3D3Bgt=3D3D3B last updated: 2008-03-16<=3D3BBR>=3D3B&= > >=3D3Bgt=3D3D3B comp=3D > >> >iled:=3D3D
>=3D3B >=3D3B 2008-08-14 00:56:14<=3D3BBR>=3D3B&am= > >p=3D3Bgt=3D3D3B c=3D > >> >onfiguration: /usr/local/cm3/bin/cm3.cfg<=3D3BBR=3D3D
>=3D3B >= > >=3D3B>=3D3B&=3D > >> >amp=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Linux thinkpad 2.= > >6.27-11-generic=3D > >> > #1 SMP Thu Jan 29 19:24=3D3D
>=3D3B >=3D3B:39 UTC 2009<=3D3BBR= > >>=3D3B&=3D > >> >=3D3Bgt=3D3D3B i686 GNU/Linux<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B <=3D= > >3BBR>=3D3B&=3D3B=3D > >> >gt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B I don=3D3D
>=3D3B &g= > >t=3D3B't have the c=3D > >> >m3 tarball=3D3D2C but I do have the sources in cm3/ still.<=3D3BBR>= > >=3D3B&=3D > >> >=3D3Bgt=3D3D
>=3D3B >=3D3B=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt= > >=3D3D3B Mika Nystrom wr=3D > >> >ote:<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B Hello everyo= > >ne=3D3D2C<=3D3BBR=3D > >> >>=3D3B&=3D3Bg=3D3D
>=3D3B >=3D3Bt=3D3D3B &=3D3Bgt=3D3D3B = > ><=3D3BBR>=3D3B&=3D > >> >=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B This is=3D3D2C for me=3D3D2C a most un= > >fortunate time =3D > >> >=3D3D
>=3D3B >=3D3Bfor the CM3 servers to<=3D3BBR>=3D3B&= > >=3D3Bgt=3D3D3B &=3D > >> >=3D3Bgt=3D3D3B have crashed. I'm teaching a class =3D3D
>=3D3B >= > >=3D3Busing Mod=3D > >> >ula-3=3D3D2C and we need a<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3B= > >gt=3D3D3B compile=3D > >> >r... here's the una=3D3D
>=3D3B >=3D3Bme of the system I'm trying= > > to use:&=3D > >> >lt=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3= > >B&=3D3Bgt=3D3D3B &am=3D > >> >p=3D3Bgt=3D3D3B Linu=3D3D
>=3D3B >=3D3Bx lara 2.6.24ugcs1 #4 SMP = > >Mon Feb 11 10=3D > >> >:53:03 PST 2008 i686 GNU/Linux<=3D3BBR>=3D3B&=3D3Bg=3D3D
>= > >=3D3B >=3D3Bt=3D > >> >=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3= > >Bgt=3D3D3B The most r=3D > >> >ecent archives I have for Linux are=3D3D
>=3D3B >=3D3B:<=3D3BBR= > >>=3D3B&=3D > >> >=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &= > >amp=3D3Bgt=3D3D3B cm3-m=3D > >> >in-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D3D
>=3D3B >=3D3B-src-all-5.4.= > >0.tgz <=3D > >> =3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&a= > >mp=3D3Bgt=3D3D3B &=3D > >> >=3D3Bgt=3D3D3B And they don't seem =3D3D
>=3D3B >=3D3Bto work on = > >this system: =3D > >> >I can compile a program<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt= > >=3D3D3B but when=3D > >> > I=3D3D
>=3D3B >=3D3B try to run it=3D3D2C it says "Segmentation = > >fault". Can=3D > >> > anyone<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B=3D3D
&= > >gt=3D3B >=3D3B help=3D > >> >? (My understanding is that I need 5.5.1 or later...)<=3D3BBR>=3D3B&= > >amp=3D3Bg=3D > >> >t=3D3D3B &=3D3Bgt=3D3D3B=3D3D
>=3D3B >=3D3B <=3D3BBR>=3D3B= > >&=3D3Bgt=3D3D3B &=3D > >> >=3D3Bgt=3D3D3B Mika<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D= > >3B <=3D3BBR>=3D3B&a=3D > >> >mp=3D3Bgt=3D3D3B <=3D3BBR>=3D3B<=3D3B/body>=3D3B
>=3D3B >= > >=3D3B<=3D3B/html>=3D > >> >=3D3B=3D3D
>=3D3B >=3D3B
>=3D3B >=3D3B--_806446ae-8d10-4d7= > >4-8eea-51aa365e=3D > >> >9204_--
> >> >=3D > >> > > >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_-- > > > >--_55339e45-8c85-4ab6-9440-0d2131bbad69_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >Maybe not.
> >Hm. That is bug. There is use with a cvs tree=2C and use without.
> >I must have broken use without.
> > =3B
> >Try this:
> >export CM3_ROOT=3Droot of cm3 cvs (for me this is /dev2/cm3=2C
> >for you=2C maybe $HOME/cm3?)
> >rm =3B$HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6
> ># *Common and *common in one command
rm =3B$HOME/cm3/cm3-min-LINUXLI= > >BC6-d5.7.0/bin/*ommon
cp root of cm3 cvs/m3-sys/cminstall/src/config/cm3= > >.cfg $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin
> > =3B
> >The .cfg will delegate out to the cvs tree.
> >I don't like having two copies of files..having to keep them in sync..
> > =3BThough the archives are meant to work standalone=2C without CVS. >> > > =3B But I don't test that so much oops sorry.
> >That /might/ not be the right file=2C but it is close.
> > =3B
> > =3B- Jay

 =3B
>=3B To: jay.krell at cornell.edu
>=3B= > > CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] Help finding CM= > >3 compiler for Linux?
>=3B Date: Tue=2C 31 Mar 2009 22:59:18 -0700 >>>=3B From: mika at async.caltech.edu
>=3B
>=3B
>=3B Is the= > >re any documentation for this format beyond what you just
>=3B wrote? = > >Where?
>=3B
>=3B terpsichore-14: cm3
>=3B --- building in .= > >./LINUXLIBC6 ---
>=3B
>=3B new source ->=3B compiling Main.m3<= > >BR>>=3B "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.co= > >mmon"=2C line 169: quake runtime error: undefined variable: ROOT
>=3B = > >
>=3B --procedure-- -line- -file---
>=3B GetM3Back 169 /afs/.ugcs= > >/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common
>=3B _IsM3B= > >ackFlagSupported 181 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin= > >/Unix.common
>=3B IsM3BackFlagSupported 193 /afs/.ugcs/user/mika/cm3/c= > >m3-min-LINUXLIBC6-d5.7.0/bin/Unix.common
>=3B GetM3BackFlag 197 /afs/.= > >ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common
>=3B m3_b= > >ackend 62 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.commo= > >n
>=3B program -- <=3Bbuiltin>=3B
>=3B 6 /afs/.ugcs.caltech.e= > >du/user/mika/test/LINUXLIBC6/m3make.args
>=3B
>=3B
>=3B Fa= > >tal Error: procedure "m3_backend" defined in "/afs/.ugcs/user/mika/cm3/cm3-= > >min-LINUXLIBC6-d5.7.0/bin/cm3.cfg" failed.
>=3B
>=3B Jay writes:= > >
>=3B >=3B--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_
>=3B >=3BC= > >ontent-Type: text/plain=3B charset=3D"iso-8859-1"
>=3B >=3BContent-T= > >ransfer-Encoding: quoted-printable
>=3B >=3B
>=3B >=3B
>= > >=3B >=3BThese archives do have a different format=3D2C yes.
>=3B >= > >=3B
>=3B >=3BBut it isn't a bad format.
>=3B >=3B
>=3B &= > >gt=3Bcminstall is pretty worthless imho.
>=3B >=3B
>=3B >=3BE= > >xtract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.
>=3B >=3B
&= > >gt=3B >=3B=3D20
>=3B >=3B
>=3B >=3B - Jay
>=3B >=3B<= > >BR>>=3B >=3B=3D20
>=3B >=3B>=3B To: jay.krell at cornell.edu
&= > >gt=3B >=3B>=3B Subject: Re: [M3devel] Help finding CM3 compiler for Lin= > >ux?=3D20
>=3B >=3B>=3B Date: Tue=3D2C 31 Mar 2009 15:56:11 -0700 >R>>=3B >=3B>=3B From: mika at async.caltech.edu
>=3B >=3B>=3B= > >=3D20
>=3B >=3B>=3B No=3D2C I'm sorry...
>=3B >=3B>=3B=3D= > >20
>=3B >=3B>=3B the archives do not have the usual format. I'm ex= > >pecting to unpack
>=3B >=3B>=3B and run "cminstall" and then unpac= > >k the big source tar on top and=3D20
>=3B >=3B>=3B build that. But= > > there's no cminstall in the archive on this page.
>=3B >=3B>=3B T= > >his is "the normal procedure" for installing CM3=3D2C no? It's what
>= > >=3B >=3B>=3B the instructions say to do=3D2C as well...
>=3B >= > >=3B>=3B=3D20
>=3B >=3B>=3B And the link from the "Download" page= > > is broken (to -d5.5.0.tgz).
>=3B >=3B>=3B=3D20
>=3B >=3B&g= > >t=3B Mika
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B Jay writes: >>>=3B >=3B>=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>= > >=3B >=3B>=3B >=3BContent-Type: text/plain=3D3B charset=3D3D"iso-8859-= > >1"
>=3B >=3B>=3B >=3BContent-Transfer-Encoding: quoted-printable= > >
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B
>=3B >= > >=3B>=3B >=3B http://modula3.elegosoft.com/cm3/uploaded-archives
>= > >=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B?
>=3B >=3B>= > >=3B >=3B
>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >= > >=3B
>=3B >=3B>=3B >=3BI can make another later this week.
>= > >=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B=3D3D20
>=3B >= > >=3B>=3B >=3B
>=3B >=3B>=3B >=3BAll you need is a working cm3= > > on any system.
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B= > >>=3BFrom there you can build the whole system=3D3D2C targeting any system= > >.
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3BAs long as tha= > >t cm3 understands LONGINT and your target system.
>=3B >=3B>=3B &g= > >t=3B
>=3B >=3B>=3B >=3BAnd it is easier=3D3D2C but not necessary= > >=3D3D2C if you have Python. :)
>=3B >=3B>=3B >=3B
>=3B >= > >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B
>=3B >=3B>= > >=3B >=3B - Jay
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >= > >=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Date: Tue=3D3D2C 31 Mar 2009= > > 15:43:41 -0500
>=3B >=3B>=3B >=3B>=3B From: martinbishop at bell= > >south.net
>=3B >=3B>=3B >=3B>=3B To: mika at async.caltech.edu >>>=3B >=3B>=3B >=3B>=3B CC: m3devel at elegosoft.com
>=3B >= > >=3B>=3B >=3B>=3B Subject: Re: [M3devel] Help finding CM3 compiler for= > > Linux?
>=3B >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B &= > >gt=3B>=3B Not sure if this helps=3D3D2C but on my linux system:
>=3B= > > >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Criti= > >cal Mass Modula-3 version d5.7.0
>=3B >=3B>=3B >=3B>=3B last u= > >pdated: 2008-03-16
>=3B >=3B>=3B >=3B>=3B compiled: 2008-08-14= > > 00:56:14
>=3B >=3B>=3B >=3B>=3B configuration: /usr/local/cm3= > >/bin/cm3.cfg
>=3B >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>= > >=3B >=3B>=3B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:3= > >9 UTC 2009
>=3B >=3B>=3B >=3B>=3B i686 GNU/Linux
>=3B >= > >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B=3D3D20 >>>=3B >=3B>=3B >=3B>=3B I don't have the cm3 tarball=3D3D2C but I= > > do have the sources in cm3/ st=3D
>=3B >=3Bill.
>=3B >=3B>= > >=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Mika Nystrom wr= > >ote:
>=3B >=3B>=3B >=3B>=3B >=3B Hello everyone=3D3D2C
&g= > >t=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B&= > >gt=3B >=3B This is=3D3D2C for me=3D3D2C a most unfortunate time for the C= > >M3 servers=3D
>=3B >=3B to
>=3B >=3B>=3B >=3B>=3B >= > >=3B have crashed. I'm teaching a class using Modula-3=3D3D2C and we need a<= > >BR>>=3B >=3B>=3B >=3B>=3B >=3B compiler... here's the uname of = > >the system I'm trying to use:
>=3B >=3B>=3B >=3B>=3B >=3B=3D= > >3D20
>=3B >=3B>=3B >=3B>=3B >=3B Linux lara 2.6.24ugcs1 #4 S= > >MP Mon Feb 11 10:53:03 PST 2008 i686 GNU/=3D
>=3B >=3BLin=3D3D
&g= > >t=3B >=3B>=3B >=3Bux
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D2= > >0
>=3B >=3B>=3B >=3B>=3B >=3B The most recent archives I hav= > >e for Linux are:
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>= > >=3B >=3B>=3B >=3B>=3B >=3B cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3= > >-src-all-5.4.0.tgz=3D3D20
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20= > >
>=3B >=3B>=3B >=3B>=3B >=3B And they don't seem to work on = > >this system: I can compile a program
>=3B >=3B>=3B >=3B>=3B &g= > >t=3B but when I try to run it=3D3D2C it says "Segmentation fault". Can anyo= > >=3D
>=3B >=3Bne
>=3B >=3B>=3B >=3B>=3B >=3B help? (My= > > understanding is that I need 5.5.1 or later...)
>=3B >=3B>=3B >= > >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B >=3B Mika
= > >>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >= > >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >= > >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>=3B >=3B>=3B >=3BCo= > >ntent-Type: text/html=3D3B charset=3D3D"iso-8859-1"
>=3B >=3B>=3B = > >>=3BContent-Transfer-Encoding: quoted-printable
>=3B >=3B>=3B &g= > >t=3B
>=3B >=3B>=3B >=3B<=3Bhtml>=3B
>=3B >=3B>=3B &= > >gt=3B<=3Bhead>=3B
>=3B >=3B>=3B >=3B<=3Bstyle>=3B
>= > >=3B >=3B>=3B >=3B.hmmessage P
>=3B >=3B>=3B >=3B{
>= > >=3B >=3B>=3B >=3Bmargin:0px=3D3D3B
>=3B >=3B>=3B >=3Bpaddi= > >ng:0px
>=3B >=3B>=3B >=3B}
>=3B >=3B>=3B >=3Bbody.hmm= > >essage
>=3B >=3B>=3B >=3B{
>=3B >=3B>=3B >=3Bfont-siz= > e: 10pt=3D3D3B
>=3B >=3B>=3B >=3Bfont-family:Verdana
>=3B &= > >gt=3B>=3B >=3B}
>=3B >=3B>=3B >=3B<=3B/style>=3B
>= > >=3B >=3B>=3B >=3B<=3B/head>=3B
>=3B >=3B>=3B >=3B<= > >=3Bbody class=3D3D3D'hmmessage'>=3B
>=3B >=3B>=3B >=3B&=3Bn= > >bsp=3D3D3B<=3BA href=3D3D3D"http://modula3.elegosoft.com/cm3/uploaded-arc= > >hive=3D
>=3B >=3Bs" targ=3D3D
>=3B >=3B>=3B >=3Bet=3D3D3D= > >_blank>=3B<=3BFONT color=3D3D3D#0068cf>=3Bhttp://modula3.elegosoft.co= > >m/cm3/u=3D
>=3B >=3Bploaded=3D3D
>=3B >=3B>=3B >=3B-archi= > >ves<=3B/FONT>=3B<=3B/A>=3B<=3BBR>=3B
>=3B >=3B>=3B >= > >=3B?<=3BBR>=3B
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR&= > >gt=3B
>=3B >=3B>=3B >=3BI can make another later this week.<= > >=3BBR>=3B
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B >R>>=3B >=3B>=3B >=3BAll you need is a working cm3 on any system.<= > >=3BBR>=3B
>=3B >=3B>=3B >=3B>=3BFrom there you can build the= > > whole system=3D3D2C targeting any system.<=3BBR=3D
>=3B >=3B>= > >=3B
>=3B >=3B>=3B >=3BAs long as that cm3 understands LONGINT an= > >d your target system.<=3BBR>=3B
>=3B >=3B>=3B >=3BAnd it is = > >easier=3D3D2C but not necessary=3D3D2C if you have Python. :)<=3BBR>=3B= > >
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B
>=3B &g= > >t=3B>=3B >=3B&=3Bnbsp=3D3D3B- Jay<=3BBR>=3B<=3BBR>=3B&=3B= > >nbsp=3D3D3B<=3BBR>=3B&=3Bgt=3D3D3B Date: Tue=3D3D2C 31 Mar 2009=3D >R>>=3B >=3B 15:43:41 -=3D3D
>=3B >=3B>=3B >=3B0500<=3BBR&g= > >t=3B&=3Bgt=3D3D3B From: martinbishop at bellsouth.net<=3BBR>=3B&=3Bg= > >t=3D3D3B To: mika at a=3D
>=3B >=3Bsync.ca=3D3D
>=3B >=3B>=3B = > >>=3Bltech.edu<=3BBR>=3B&=3Bgt=3D3D3B CC: m3devel at elegosoft.com<= > >=3BBR>=3B&=3Bgt=3D3D3B Subject: Re:=3D
>=3B >=3B [M3dev=3D3D >>>=3B >=3B>=3B >=3Bel] Help finding CM3 compiler for Linux?<=3BBR= > >>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B Not su=3D
>=3B &= > >gt=3Bre if t=3D3D
>=3B >=3B>=3B >=3Bhis helps=3D3D2C but on my l= > >inux system:<=3BBR>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B C= > >ritical=3D
>=3B >=3B Mass Mod=3D3D
>=3B >=3B>=3B >=3Bula-= > >3 version d5.7.0<=3BBR>=3B&=3Bgt=3D3D3B last updated: 2008-03-16<= > >=3BBR>=3B&=3Bgt=3D3D3B co=3D
>=3B >=3Bmpiled:=3D3D
>=3B &g= > >t=3B>=3B >=3B 2008-08-14 00:56:14<=3BBR>=3B&=3Bgt=3D3D3B configu= > >ration: /usr/local/cm3/bin/cm3.c=3D
>=3B >=3Bfg<=3BBR=3D3D
>= > >=3B >=3B>=3B >=3B>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3= > >B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 2=3D
>=3B >=3B9 19= > >:24=3D3D
>=3B >=3B>=3B >=3B:39 UTC 2009<=3BBR>=3B&=3Bgt= > >=3D3D3B i686 GNU/Linux<=3BBR>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bg= > >t=3D3D3B <=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3D3B I don=3D3D
&= > >gt=3B >=3B>=3B >=3B't have the cm3 tarball=3D3D2C but I do have the s= > >ources in cm3/ still.<=3BBR=3D
>=3B >=3B>=3B&=3Bgt=3D3D
&g= > >t=3B >=3B>=3B >=3B=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B Mika Nystrom= > > wrote:<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B Hello everyo=3D
&= > >gt=3B >=3Bne=3D3D2C<=3BBR>=3B&=3Bg=3D3D
>=3B >=3B>=3B >= > >=3Bt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3= > >B This is=3D3D2C for me=3D3D2C a most un=3D
>=3B >=3Bfortunate time = > >=3D3D
>=3B >=3B>=3B >=3Bfor the CM3 servers to<=3BBR>=3B&= > >=3Bgt=3D3D3B &=3Bgt=3D3D3B have crashed. I'm teaching a=3D
>=3B >= > >=3B class =3D3D
>=3B >=3B>=3B >=3Busing Modula-3=3D3D2C and we n= > >eed a<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B compiler... here'=3D >R>>=3B >=3Bs the una=3D3D
>=3B >=3B>=3B >=3Bme of the system= > > I'm trying to use:<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B <=3BBR= > >>=3B&=3Bgt=3D3D3B &=3Bg=3D
>=3B >=3Bt=3D3D3B Linu=3D3D
&g= > >t=3B >=3B>=3B >=3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2= > >008 i686 GNU/Linux<=3BBR=3D
>=3B >=3B>=3B&=3Bg=3D3D
>=3B= > > >=3B>=3B >=3Bt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3= > >B &=3Bgt=3D3D3B The most recent archives I have fo=3D
>=3B >=3Br = > >Linux are=3D3D
>=3B >=3B>=3B >=3B:<=3BBR>=3B&=3Bgt=3D3D3B= > > &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B cm3-min-P= > OSIX-LINUXLIBC6-5.=3D
>=3B >=3B4.0.tgz cm3=3D3D
>=3B >=3B>= > >=3B >=3B-src-all-5.4.0.tgz <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3= > >B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B And they =3D
>=3B &g= > >t=3Bdon't seem =3D3D
>=3B >=3B>=3B >=3Bto work on this system: I= > > can compile a program<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B but= > >=3D
>=3B >=3B when I=3D3D
>=3B >=3B>=3B >=3B try to run i= > >t=3D3D2C it says "Segmentation fault". Can anyone<=3BBR>=3B&=3Bgt=3D= > >3D3B=3D
>=3B >=3B &=3Bgt=3D3D3B=3D3D
>=3B >=3B>=3B >= > >=3B help? (My understanding is that I need 5.5.1 or later...)<=3BBR>=3B= > >&=3Bgt=3D3D3B &=3B=3D
>=3B >=3Bgt=3D3D3B=3D3D
>=3B >=3B= > >>=3B >=3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B Mika<=3BBR&= > >gt=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B <= > >=3BBR>=3B<=3B/body=3D
>=3B >=3B>=3B
>=3B >=3B>=3B >= > >=3B<=3B/html>=3B=3D3D
>=3B >=3B>=3B >=3B
>=3B >=3B>= > >=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_--
>=3B >=3B
&g= > >t=3B >=3B--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_
>=3B >=3BContent= > >-Type: text/html=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer= > >-Encoding: quoted-printable
>=3B >=3B
>=3B >=3B<=3Bhtml>= > >=3B
>=3B >=3B<=3Bhead>=3B
>=3B >=3B<=3Bstyle>=3B
&= > >gt=3B >=3B.hmmessage P
>=3B >=3B{
>=3B >=3Bmargin:0px=3D3B<= > >BR>>=3B >=3Bpadding:0px
>=3B >=3B}
>=3B >=3Bbody.hmmessag= > >e
>=3B >=3B{
>=3B >=3Bfont-size: 10pt=3D3B
>=3B >=3Bfo= > >nt-family:Verdana
>=3B >=3B}
>=3B >=3B<=3B/style>=3B
&= > >gt=3B >=3B<=3B/head>=3B
>=3B >=3B<=3Bbody class=3D3D'hmmessa= > >ge'>=3B
>=3B >=3BThese archives do have a different format=3D2C ye= > >s.<=3BBR>=3B
>=3B >=3BBut it isn't a bad format.<=3BBR>=3B >R>>=3B >=3Bcminstall is pretty worthless imho.<=3BBR>=3B
>=3B = > >>=3BExtract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.<=3BBR>=3B<= > >BR>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp= > >=3D3B- Jay<=3BBR>=3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3B&=3B= > >gt=3D3B To: jay.krell at cornell.edu<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B = > >>=3B Subject: Re: [M3devel] Help finding CM3 compiler for Linux? <=3BBR= > >>=3B&=3Bgt=3D3B Dat=3D
>=3B >=3Be: Tue=3D2C 31 Mar 2009 15:56:1= > >1 -0700<=3BBR>=3B&=3Bgt=3D3B From: mika at async.caltech.edu=3D
>= > >=3B >=3B<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B No=3D2C= > > I'm sorry...<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B the = > >archives =3D
>=3B >=3Bdo not have the usual format. I'm expecting to= > > unpack<=3BBR>=3B&=3Bgt=3D3B and run "cm=3D
>=3B >=3Binstall"= > > and then unpack the big source tar on top and <=3BBR>=3B&=3Bgt=3D3B= > > build tha=3D
>=3B >=3Bt. But there's no cminstall in the archive on= > > this page.<=3BBR>=3B&=3Bgt=3D3B This is =3D
>=3B >=3B"the no= > >rmal procedure" for installing CM3=3D2C no? It's what<=3BBR>=3B&=3Bg= > >t=3D3B the in=3D
>=3B >=3Bstructions say to do=3D2C as well...<=3B= > >BR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B And the link from t=3D<= > >BR>>=3B >=3Bhe "Download" page is broken (to -d5.5.0.tgz).<=3BBR>= > >=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Mika<=3BBR=3D
>=3B &g= > >t=3B>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Jay writes:<=3BBR&g= > >t=3B&=3Bgt=3D3B &=3Bgt=3D3B--_806446ae-8d10-4d74-8eea-5=3D
>=3B = > >>=3B1aa365e9204_<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BContent-Type: = > >text/plain=3D3B charset=3D3D"iso-885=3D
>=3B >=3B9-1"<=3BBR>=3B&= > >amp=3Bgt=3D3B &=3Bgt=3D3BContent-Transfer-Encoding: quoted-printable<= > >=3BBR>=3B&=3Bgt=3D3B =3D
>=3B >=3B&=3Bgt=3D3B<=3BBR>=3B&= > >amp=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B htt= > >p://modula3.elegosoft.com/cm3/u=3D
>=3B >=3Bploaded-archives<=3BBR= > >>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= > >=3D3B?<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D= > >
>=3B >=3B=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &a= > >mp=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BI can make another l= > >ater t=3D
>=3B >=3Bhis week.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= > >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&= > >=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >=3B &= > >amp=3Bgt=3D3BAll you need is a working cm3 on any system.<=3BBR>=3B&= > >=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &= > >amp=3Bgt=3D3B&=3Bgt=3D3BFrom there you can build the whole system=3D3D2C= > > targeting an=3D
>=3B >=3By system.<=3BBR>=3B&=3Bgt=3D3B &= > >=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAs long as that cm3 un= > >derstands =3D
>=3B >=3BLONGINT and your target system.<=3BBR>=3B= > >&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAnd= > > it is =3D
>=3B >=3Beasier=3D3D2C but not necessary=3D3D2C if you ha= > >ve Python. :)<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3B=3D
>=3B= > > >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt= > >=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B - Jay<=3B= > >BR>=3B&=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B<=3BBR>=3B&= > >=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B= > >&=3Bgt=3D3B Date: Tue=3D3D2C 31 Mar 2009=3D
>=3B >=3B 15:43:41 -0= > >500<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B From: martinbi= > >shop at bellsouth.net<=3BBR>=3B=3D
>=3B >=3B&=3Bgt=3D3B &=3Bg= > >t=3D3B&=3Bgt=3D3B To: mika at async.caltech.edu<=3BBR>=3B&=3Bgt=3D3B= > > &=3Bgt=3D3B&=3Bgt=3D3B CC: m=3D
>=3B >=3B3devel at elegosoft.com= > ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B Subject: Re: [M3d= > >evel] Help fin=3D
>=3B >=3Bding CM3 compiler for Linux?<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bg= > >t=3D3B &=3Bgt=3D3B&=3Bg=3D
>=3B >=3Bt=3D3B Not sure if this he= > >lps=3D3D2C but on my linux system:<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= > >3B&=3Bg=3D
>=3B >=3Bt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &am= > >p=3Bgt=3D3B&=3Bgt=3D3B Critical Mass Modula-3 version d5.7.0<=3BBR>= > >=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B last upd= > >ated: 2008-03-16<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B c= > >ompiled=3D
>=3B >=3B: 2008-08-14 00:56:14<=3BBR>=3B&=3Bgt=3D3= > >B &=3Bgt=3D3B&=3Bgt=3D3B configuration: /usr/local/cm3/=3D
>=3B = > >>=3Bbin/cm3.cfg<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B= > >=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B Linux thin= > >kp=3D
>=3B >=3Bad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2= > >009<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bg=3D
>=3B >=3Bt= > >=3D3B i686 GNU/Linux<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D= > >3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20= > >=3D
>=3B >=3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D= > >3B I don't have the cm3 tarball=3D3D2C but I do have the=3D
>=3B >= > >=3B sources in cm3/ still.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B = > >=3D
>=3B >=3BMika Nystrom wrote:<=3BBR>=3B&=3Bgt=3D3B &=3B= > >gt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B Hello everyone=3D3D2C<=3BBR>=3B&am= > >p=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B= > >=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt= > >=3D3B This is=3D3D2C fo=3D
>=3B >=3Br me=3D3D2C a most unfortunate t= > >ime for the CM3 servers to<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B have crashed. I'm teaching a = > >class using Modula-3=3D3D2C and we n=3D
>=3B >=3Beed a<=3BBR>=3B= > >&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B compiler... here= > >'s the uname of the sys=3D
>=3B >=3Btem I'm trying to use:<=3BBR&g= > >t=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3B= > >BR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3B=3D
>=3B >=3Bgt=3D3B &am= > >p=3Bgt=3D3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i68= > >=3D
>=3B >=3B6 GNU/Lin=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= > >3Bux<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3= > >B=3D3D20<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &=3Bgt=3D3B&= > >=3Bgt=3D3B &=3Bgt=3D3B The most recent archives I have for Linux are:<= > >=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B = > >&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt= > >=3D3B &=3Bgt=3D3B cm3-min-POSIX-=3D
>=3B >=3BLINUXLIBC6-5.4.0.tgz= > > cm3-src-all-5.4.0.tgz=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&am= > >p=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B=3D3D20<=3BBR>=3B&=3Bg= > >t=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B And they don't seem to w= > >ork on this =3D
>=3B >=3Bsystem: I can compile a program<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B but when I tr= > >=3D
>=3B >=3By to run it=3D3D2C it says "Segmentation fault". Can an= > >yone<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3B=3D
>=3B >=3Bg= > >t=3D3B &=3Bgt=3D3B help? (My understanding is that I need 5.5.1 or later= > >...)<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bg= > >t=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Bgt=3D3B &=3Bgt=3D3B Mika<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >= > >=3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3B= > >gt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &am= > >p=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B-= > >-_806446ae-8d10-4d74-8eea-51aa365e9204_<=3BBR>=3B&=3Bgt=3D3B &=3B= > >gt=3D3BConten=3D
>=3B >=3Bt-Type: text/html=3D3B charset=3D3D"iso-88= > >59-1"<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BContent-Transfe=3D
>= > >=3B >=3Br-Encoding: quoted-printable<=3BBR>=3B&=3Bgt=3D3B &=3Bg= > >t=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3Bhtml&=3Bg= > >t=3D
>=3B >=3B=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Blt=3D3Bhead&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Blt=3D3Bstyle&=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D= > >3B &=3Bgt=3D3B.hmmessage P<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B{&l= > >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bmargin:0px=3D3D3B<=3B=3D
>= > >=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bpadding:0px<=3BBR>=3B&am= > >p=3Bgt=3D3B &=3Bgt=3D3B}<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bbody.= > >hmmessag=3D
>=3B >=3Be<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B{&l= > >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfont-size: 10pt=3D3D3B<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3Bfo=3D
>=3B >=3Bnt-family:Verdana<= > >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B}<=3BBR>=3B&=3Bgt=3D3B &= > >=3Bgt=3D3B&=3Blt=3D3B/style&=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>= > >=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3B/head&=3Bgt=3D3B<=3BBR&g= > >t=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3Bbody class=3D3D3D'hmmessa=3D= > >
>=3B >=3Bge'&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= > >3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BA href=3D3D3D"http://modula3.=3D<= > >BR>>=3B >=3Belegosoft.com/cm3/uploaded-archives" targ=3D3D<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3Bet=3D3D3D_blank&=3B=3D
>=3B >=3Bg= > >t=3D3B&=3Blt=3D3BFONT color=3D3D3D#0068cf&=3Bgt=3D3Bhttp://modula3.el= > >egosoft.com/cm3/upl=3D
>=3B >=3Boaded=3D3D<=3BBR>=3B&=3Bgt=3D= > >3B &=3Bgt=3D3B-archives&=3Blt=3D3B/FONT&=3Bgt=3D3B&=3Blt=3D3B/A= > >&=3Bgt=3D3B&=3Blt=3D3BBR&=3Bg=3D
>=3B >=3Bt=3D3B<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3B?&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3B=3D= > >
>=3B >=3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3= > >BI can make another later this week.&=3Blt=3D3BBR&=3Bgt=3D3B<=3B=3D= > >
>=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp= > >=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= > >=3D3BAll you need=3D
>=3B >=3B is a working cm3 on any system.&= > >=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Bgt=3D3BFrom t=3D
>=3B >=3Bhere you can build the whole system=3D3= > >D2C targeting any system.&=3Blt=3D3BBR&=3Bgt=3D
>=3B >=3B=3D3B= > ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAs long as that cm3 understands = > >LONGINT and your target=3D
>=3B >=3B system.&=3Blt=3D3BBR&=3Bg= > >t=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAnd it is easier=3D3D2C bu= > >t not necess=3D
>=3B >=3Bary=3D3D2C if you have Python. :)&=3Blt= > >=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp= > >=3D3Bnbsp=3D
>=3B >=3B=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR&= > >gt=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B- Jay&=3Blt= > >=3D3BBR&=3Bgt=3D3B&=3Blt=3D
>=3B >=3B=3D3BBR&=3Bgt=3D3B&= > >=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3= > >B Date: Tue=3D3D2C 31 M=3D
>=3B >=3Bar 2009 15:43:41 -=3D3D<=3BBR&= > >gt=3B&=3Bgt=3D3B &=3Bgt=3D3B0500&=3Blt=3D3BBR&=3Bgt=3D3B&=3B= > >amp=3D3Bgt=3D3D3B From=3D
>=3B >=3B: martinbishop at bellsouth.net&= > >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B To: mika at async.ca=3D
= > >>=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bltech.edu&= > >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B CC: m3devel at elego=3D
= > >>=3B >=3Bsoft.com&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B= > > Subject: Re: [M3dev=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D
>= > >=3B >=3B=3D3Bel] Help finding CM3 compiler for Linux?&=3Blt=3D3BBR&= > >=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D
>=3B >=3B=3D3BBR&= > >=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B Not sure if t=3D3D<=3BBR>=3B&=3Bg= > >t=3D3B &=3Bgt=3D3Bhis helps=3D3D2C b=3D
>=3B >=3But on my linux s= > >ystem:&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3B= > >BR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D
>=3B >=3B=3D3D3B Critical Mass = > >Mod=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bula-3 version d5.7.0&= > >=3Blt=3D3BBR&=3Bgt=3D
>=3B >=3B=3D3B&=3Bamp=3D3Bgt=3D3D3B last= > > updated: 2008-03-16&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B = > >comp=3D
>=3B >=3Biled:=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= > >3B 2008-08-14 00:56:14&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3= > >B c=3D
>=3B >=3Bonfiguration: /usr/local/cm3/bin/cm3.cfg&=3Blt=3D= > >3BBR=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B&=3B= > >=3D
>=3B >=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3B= > >amp=3D3Bgt=3D3D3B Linux thinkpad 2.6.27-11-generic=3D
>=3B >=3B #1 S= > >MP Thu Jan 29 19:24=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B:39 UTC = > >2009&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3= > >D3B i686 GNU/Linux&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &a= > >mp=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3B=3D
>=3B >=3Bgt=3D3D3B &a= > >mp=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B I don=3D3D<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3B't have the c=3D
>=3B >=3Bm3 tarball= > >=3D3D2C but I do have the sources in cm3/ still.&=3Blt=3D3BBR&=3Bgt= > >=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D<=3BBR>=3B&=3Bgt=3D3B= > > &=3Bgt=3D3B=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D= > >3B Mika Nystrom wr=3D
>=3B >=3Bote:&=3Blt=3D3BBR&=3Bgt=3D3B&am= > >p=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B Hello everyone=3D3D2C&=3B= > >lt=3D3BBR=3D
>=3B >=3B&=3Bgt=3D3B&=3Bamp=3D3Bg=3D3D<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3Bt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt= > >=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D3B &=3Bam= > >p=3D3Bgt=3D3D3B This is=3D3D2C for me=3D3D2C a most unfortunate time =3D >>>=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfor the CM3 s= > >ervers to&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp= > >=3D
>=3B >=3B=3D3Bgt=3D3D3B have crashed. I'm teaching a class =3D3D= > ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Busing Mod=3D
>=3B >=3Bula= > >-3=3D3D2C and we need a&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D= > >3B &=3Bamp=3D3Bgt=3D3D3B compile=3D
>=3B >=3Br... here's the una= > >=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bme of the system I'm trying= > > to use:&=3B=3D
>=3B >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt= > >=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp= > >=3D3Bgt=3D3D3B &=3Bam=3D
>=3B >=3Bp=3D3Bgt=3D3D3B Linu=3D3D<=3B= > >BR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 1= > >0=3D
>=3B >=3B:53:03 PST 2008 i686 GNU/Linux&=3Blt=3D3BBR&=3Bg= > >t=3D3B&=3Bamp=3D3Bg=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bt=3D<= > >BR>>=3B >=3B=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt= > >=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B The most r=3D
>= > >=3B >=3Becent archives I have for Linux are=3D3D<=3BBR>=3B&=3Bgt= > >=3D3B &=3Bgt=3D3B:&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B = > >>=3B=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3= > >B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B cm3-m=3D
>=3B >= > >=3Bin-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D3D<=3BBR>=3B&=3Bgt=3D3B &= > >=3Bgt=3D3B-src-all-5.4.0.tgz &=3Blt=3D
>=3B =3D3BBR&=3Bgt=3D3B&a= > >mp=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt= > >=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D3B = > >And they don't seem =3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bto work= > > on this system: =3D
>=3B >=3BI can compile a program&=3Blt=3D3BB= > >R&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B but when= > >=3D
>=3B >=3B I=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B try = > >to run it=3D3D2C it says "Segmentation fault". Can=3D
>=3B >=3B anyo= > >ne&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt= > >=3D3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B help=3D
>=3B &= > >gt=3B? (My understanding is that I need 5.5.1 or later...)&=3Blt=3D3BBR&= > >amp=3Bgt=3D3B&=3Bamp=3D3Bg=3D
>=3B >=3Bt=3D3D3B &=3Bamp=3D3Bgt= > >=3D3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B &=3Blt=3D3BBR&am= > >p=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D
>=3B >=3B=3D3Bgt= > >=3D3D3B Mika&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Ba= > >mp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Ba=3D
>=3B >=3B= > >mp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Blt=3D3B/body&=3Bgt= > >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3B/html&=3Bg= > >t=3D
>=3B >=3B=3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >lt=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B--_806446ae-8d10-4d74-8eea-51aa36= > >5e=3D
>=3B >=3B9204_--<=3BBR>=3B<=3B/body>=3B
>=3B >= > >=3B<=3B/html>=3B=3D
>=3B >=3B
>=3B >=3B--_777fdc4e-3c29-4= > >0b4-a3dd-e6243f796cee_--
> >= > > > >--_55339e45-8c85-4ab6-9440-0d2131bbad69_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Apr 1 09:08:41 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 01 Apr 2009 00:08:41 -0700 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: Your message of "Wed, 01 Apr 2009 06:56:45 -0000." Message-ID: <200904010708.n3178fm8073790@camembert.async.caltech.edu> Crazily enough, this seems to have worked.... just had to add "-lpthread" to the LIBC libraries in the file. Oh and I had to make some libXaw symlinks to get your mentor binary to work---they seem to be on libXaw.so.7 now. (Yes I know new major #s shouldn't work, but it does seem to...) Thanks for tonight :-) Jay writes: >--_6a7b1519-a5fa-4142-b418-a208dc02c427_ ... > >You had a kind of working install from 5.4 and running its cminstall. > > cm3 ran but produced crashing binaries. > >=20 > >Take the cm3.cfg file from it and put it at. > ... From wagner at elegosoft.com Wed Apr 1 11:11:53 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 01 Apr 2009 11:11:53 +0200 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: <200904010559.n315xIBx071256@camembert.async.caltech.edu> References: <200904010559.n315xIBx071256@camembert.async.caltech.edu> Message-ID: <20090401111153.ul0hzu7nokc808sg@mail.elegosoft.com> Quoting Mika Nystrom : > > Is there any documentation for this format beyond what you just > wrote? Where? Well, yes, that's the problem with these kinds of archives: (1) they're not well tested and (2) there's no documentation user's can rely on This doesn't mean that I disapprove or want to criticise the contributors, but an official well-documented release with installation notes etc. has some advantages. Unfortunately, the official releases are really outdated now. I succeeded in building current AMD64_LINUX and FreeBSD4 installations on our servers for d5.7.1 tonight and was able to build archives for FreeBSD binaries and sources, but the tooling failed for AMD64_KINUX due to changed and missing configuration files. I'll need to have a closer look at that, some extensions seem to be needed. Anybody who feels he can do that faster than me is of course encouraged (I'll have little time as usual :-/). It may also turn out to be difficult to produce LINUXLIBC6 binaries, as birch and other Elego servers are now 64 bit machines, and trying to use current CM3 with --32 produced lots of assembler errors about unsupported instructions on this architecture. As the old installation on birch seems to be gone without a chance of being restored, it will probably be easiest to use a real 32 bit system and start from 5.4.0 again. Anybody who wants to help should be able to build the binary archives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh easily and upload them to birch at /var/www/modula3.elegosoft.com/cm3/uploaded-archives My guess is that tinderbox will take some time to run smoothly again, as it was highly customized, and I'm not sure if these customizations survied the crash. Please stay tuned and thanks for all your patience, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 1 11:22:58 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Apr 2009 09:22:58 +0000 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: <20090401111153.ul0hzu7nokc808sg@mail.elegosoft.com> References: <200904010559.n315xIBx071256@camembert.async.caltech.edu> <20090401111153.ul0hzu7nokc808sg@mail.elegosoft.com> Message-ID: Olaf, in the LINUXLIBC6 configuration, try putting --32 on the as/gas invocations. You mentioned --32 on cm3, but I wonder if you meant -m32 on cm3. cm3 -m32 as --32 or check the man pages or help. They aren't consistent, for more reasons than shown here (e.g. MIPS has -mabi64, and I think AIX has something else, and HP-UX gcc supports none of these -- no bi-arch support). > probably be easiest to use a real 32 bit system and start from 5.4.0 > again. Using any current system should be plenty easy too. e.g. the distributions I put up. :) AMD64_LINUX should be a good starting point, but I haven't tried it in a bit. I should be able to build a current LINUXLIBC6 very very soon. I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test a switch to the "new" Unix *.i3 files. I'll be using python/make-dist.py though. I do need to get more packages into it though, e.g. cm3ide and m3gdb. - Jay > Date: Wed, 1 Apr 2009 11:11:53 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > CC: mand at elego.de; m3-support at elego.de > Subject: Re: [M3devel] Help finding CM3 compiler for Linux? > > Quoting Mika Nystrom : > > > > > Is there any documentation for this format beyond what you just > > wrote? Where? > > Well, yes, that's the problem with these kinds of archives: > > (1) they're not well tested and > (2) there's no documentation user's can rely on > > This doesn't mean that I disapprove or want to criticise the contributors, > but an official well-documented release with installation notes etc. > has some advantages. Unfortunately, the official releases are really > outdated now. > > I succeeded in building current AMD64_LINUX and FreeBSD4 installations > on our servers for d5.7.1 tonight and was able to build archives for > FreeBSD binaries and sources, but the tooling failed for AMD64_KINUX > due to changed and missing configuration files. I'll need to have a > closer look at that, some extensions seem to be needed. Anybody who > feels he can do that faster than me is of course encouraged (I'll have > little time as usual :-/). > > It may also turn out to be difficult to produce LINUXLIBC6 binaries, > as birch and other Elego servers are now 64 bit machines, and trying > to use current CM3 with --32 produced lots of assembler errors about > unsupported instructions on this architecture. As the old installation > on birch seems to be gone without a chance of being restored, it will > probably be easiest to use a real 32 bit system and start from 5.4.0 > again. > > Anybody who wants to help should be able to build the binary > archives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh > easily and upload them to birch at > > /var/www/modula3.elegosoft.com/cm3/uploaded-archives > > My guess is that tinderbox will take some time to run smoothly again, > as it was highly customized, and I'm not sure if these customizations > survied the crash. > > Please stay tuned and thanks for all your patience, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Wed Apr 1 12:03:47 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 01 Apr 2009 12:03:47 +0200 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090331145127.GB9624@topoi.pooq.com> References: <20090331145127.GB9624@topoi.pooq.com> Message-ID: <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > The BottonVBT contains an action, which is a procedure rather than a > method. b This makes it awkward to subclass ButtonVBT becaue the action > will still expect its first parameter to be a ButtonVBT instead of > belonging to the subclass, and an explicit downcast of some sort will be > needed to acess the subclass's members. > > The Trestle manual says this was a deliberate decision: > > : The action procedure is a field rather than a method in order to allow > : buttons with different action procedures to share their method suites. > > I, however, find it massively inconvenient because it mans I have to > resort to downcasting or the very kludgey VBT.GetProp to access what > should be just there. I'd rather the action procedure was a method. > > But it should be possible to have the best of both worlds. Have an > action2 (better name wanted here) method that is available for > overriding, and by default calls the procedure in the existing action. > field. That action2 method wounl then be called by Trestle wherever > action is now called. > > Does anyone see problems with this? Sounds fine to me offhand. You should test your extensions with some of the existing larger applications, like mentor and Juno-2, of course. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 1 16:25:13 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Apr 2009 14:25:13 +0000 Subject: [M3devel] new Linux/x86 archives Message-ID: new Linux/x86 archives, the ones are version 5.7.1: http://modula3.elegosoft.com/cm3/uploaded-archives => http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-LINUXLIBC6-d5.7.1.tar.gz http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-LINUXLIBC6-d5.7.1.tar.lzma http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-LINUXLIBC6-d5.7.1.tar.gz http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-LINUXLIBC6-d5.7.1.tar.lzma The last one is still compressing/uploading (lzma compresses very slow, but compresses smallest and uncompressed fast or fastest.) notes: Mika's problem is fixed. (Jan 12: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cminstall/src/config-no-install/cm3cfg.common) Be sure to export PATH=installroot/bin:$PATH and LD_LIBRARY_PATH=installroot/lib or LD_LIBRARY_PATH=installroot/lib:$LD_LIBRARY_PATH Don't have Modula-3 .so files in /tmp/tmpdtNszn/... (objdump -x installroot/bin/mentor | grep PATH to see what I mean) A near future build should: not require setting either environment variable, nor look in /tmp. setting $PATH will be optional for convenience to find cm3, but cm3 won't use it to find cm3cg. Shared libs will be found via rpath=$ORIGIN/../lib. (Consensus that that is a good idea? Seems clear to me. $LD_LIBRARY_PATH should still either override or provide fallback, for uninstalled binaries or binaries installed elsewhere.) - Jay From hendrik at topoi.pooq.com Wed Apr 1 16:59:45 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 1 Apr 2009 10:59:45 -0400 Subject: [M3devel] new Linux/x86 archives In-Reply-To: References: Message-ID: <20090401145945.GA12017@topoi.pooq.com> On Wed, Apr 01, 2009 at 02:25:13PM +0000, Jay wrote: > > A near future build should: > not require setting either environment variable, nor look in /tmp. > setting $PATH will be optional for convenience to find cm3, > but cm3 won't use it to find cm3cg. > Shared libs will be found via rpath=$ORIGIN/../lib. Would this be problematic it $ORIGIN is a symbolic link? -- hendrik From vapier at gentoo.org Wed Apr 1 17:23:55 2009 From: vapier at gentoo.org (Mike Frysinger) Date: Wed, 1 Apr 2009 11:23:55 -0400 Subject: [M3devel] new Linux/x86 archives In-Reply-To: <20090401145945.GA12017@topoi.pooq.com> References: <20090401145945.GA12017@topoi.pooq.com> Message-ID: <200904011123.56014.vapier@gentoo.org> On Wednesday 01 April 2009 10:59:45 hendrik at topoi.pooq.com wrote: > On Wed, Apr 01, 2009 at 02:25:13PM +0000, Jay wrote: > > A near future build should: > > not require setting either environment variable, nor look in /tmp. > > setting $PATH will be optional for convenience to find cm3, > > but cm3 won't use it to find cm3cg. > > Shared libs will be found via rpath=$ORIGIN/../lib. > > Would this be problematic it $ORIGIN is a symbolic link? is that realistic ? you'd have to unpack the archive, move only ./bin/ somewhere, and then symlink it back in. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mika at async.caltech.edu Wed Apr 1 18:59:45 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 01 Apr 2009 09:59:45 -0700 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: Your message of "Wed, 01 Apr 2009 09:22:58 -0000." Message-ID: <200904011659.n31GxkMW094881@camembert.async.caltech.edu> I have to say that once I figured out what I needed to do, using Jay's distributions was easy---easier than I'm used to with CM3. All I had to do was: untar the -std dist (forget the min one). Set PATH and LD_LIBRARY_PATH And then---the mysterious part, which takes more than passing knowledge of how CM3 works---providing a cm3.cfg file, which doesn't seem to be provided at all by Jay's archive. It seems to me it would be quite easy to package this up, maybe even with cminstall? That would be easiest I think, to cminstall the whole dist rather than cminstalling just the -min and then making people build their own compiler, libraries, and demo apps... Mika Jay writes: >--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Olaf=2C in the LINUXLIBC6 configuration=2C try putting --32 on the as/gas i= >nvocations. > >You mentioned --32 on cm3=2C but I wonder if you meant -m32 on cm3. > > cm3 -m32=20 > > as --32=20 > >=20 > >or check the man pages or help. They aren't consistent=2C for more reasons = >than shown here (e.g. MIPS has -mabi64=2C and I think AIX has something els= >e=2C and HP-UX gcc supports none of these -- no bi-arch support). > >=20 > > > probably be easiest to use a real 32 bit system and start from 5.4.0 > > again. > > >Using any current system should be plenty easy too. > >e.g. the distributions I put up. :) > >=20 > >AMD64_LINUX should be a good starting point=2C but I haven't tried it in a = >bit. > >=20 > >I should be able to build a current LINUXLIBC6 very very soon. > >I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test= > a switch to the "new" Unix *.i3 files. > >=20 > >I'll be using python/make-dist.py though. > >I do need to get more packages into it though=2C e.g. cm3ide and m3gdb. > >=20 > > - Jay >=20 >> Date: Wed=2C 1 Apr 2009 11:11:53 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> CC: mand at elego.de=3B m3-support at elego.de >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >>=20 >> Quoting Mika Nystrom : >>=20 >> > >> > Is there any documentation for this format beyond what you just >> > wrote? Where? >>=20 >> Well=2C yes=2C that's the problem with these kinds of archives: >>=20 >> (1) they're not well tested and >> (2) there's no documentation user's can rely on >>=20 >> This doesn't mean that I disapprove or want to criticise the contributors= >=2C >> but an official well-documented release with installation notes etc. >> has some advantages. Unfortunately=2C the official releases are really >> outdated now. >>=20 >> I succeeded in building current AMD64_LINUX and FreeBSD4 installations >> on our servers for d5.7.1 tonight and was able to build archives for >> FreeBSD binaries and sources=2C but the tooling failed for AMD64_KINUX >> due to changed and missing configuration files. I'll need to have a >> closer look at that=2C some extensions seem to be needed. Anybody who >> feels he can do that faster than me is of course encouraged (I'll have >> little time as usual :-/). >>=20 >> It may also turn out to be difficult to produce LINUXLIBC6 binaries=2C >> as birch and other Elego servers are now 64 bit machines=2C and trying >> to use current CM3 with --32 produced lots of assembler errors about >> unsupported instructions on this architecture. As the old installation >> on birch seems to be gone without a chance of being restored=2C it will >> probably be easiest to use a real 32 bit system and start from 5.4.0 >> again. >>=20 >> Anybody who wants to help should be able to build the binary >> archives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh >> easily and upload them to birch at >>=20 >> /var/www/modula3.elegosoft.com/cm3/uploaded-archives >>=20 >> My guess is that tinderbox will take some time to run smoothly again=2C >> as it was highly customized=2C and I'm not sure if these customizations >> survied the crash. >>=20 >> Please stay tuned and thanks for all your patience=2C >>=20 >> Olaf >> --=20 >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 9= >5 >> http://www.elegosoft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berli= >n >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214= >194 >>=20 > >--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Olaf=2C in the LINUXLIBC6 configuration=2C try putting --32 on the as/gas i= >nvocations.
>You mentioned --32 on cm3=2C but I wonder if you meant -m32 on cm3.
> =3Bcm3 -m32
> =3Bas --32
> =3B
>or check the man pages or help. They aren't consistent=2C for more reasons = >than shown here (e.g. MIPS has -mabi64=2C and I think AIX has something els= >e=2C and HP-UX gcc supports none of these -- no bi-arch support).
> =3B
> =3B>=3B probably be easiest to use a real 32 bit system and start fr= >om 5.4.0
 =3B>=3B again.

>Using any current system should be plenty easy too.
>e.g. the distributions I put up. :)
> =3B
>AMD64_LINUX should be a good starting point=2C but I haven't tried it in a = >bit.
> =3B
>I should be able to build a current LINUXLIBC6 very very soon.
>I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test= > a switch to the "new" Unix *.i3 files.
> =3B
>I'll be using python/make-dist.py though.
>I do need to get more packages into it though=2C e.g. cm3ide and m3gdb.
> =3B
> =3B- Jay
 =3B
>=3B Date: Wed=2C 1 Apr 2009 11:11:53 +0200<= >BR>>=3B From: wagner at elegosoft.com
>=3B To: m3devel at elegosoft.com>>=3B CC: mand at elego.de=3B m3-support at elego.de
>=3B Subject: Re: [M3= >devel] Help finding CM3 compiler for Linux?
>=3B
>=3B Quoting Mi= >ka Nystrom <=3Bmika at async.caltech.edu>=3B:
>=3B
>=3B >=3B<= >BR>>=3B >=3B Is there any documentation for this format beyond what you= > just
>=3B >=3B wrote? Where?
>=3B
>=3B Well=2C yes=2C th= >at's the problem with these kinds of archives:
>=3B
>=3B (1) the= >y're not well tested and
>=3B (2) there's no documentation user's can = >rely on
>=3B
>=3B This doesn't mean that I disapprove or want to= > criticise the contributors=2C
>=3B but an official well-documented re= >lease with installation notes etc.
>=3B has some advantages. Unfortuna= >tely=2C the official releases are really
>=3B outdated now.
>=3B = >
>=3B I succeeded in building current AMD64_LINUX and FreeBSD4 install= >ations
>=3B on our servers for d5.7.1 tonight and was able to build ar= >chives for
>=3B FreeBSD binaries and sources=2C but the tooling failed= > for AMD64_KINUX
>=3B due to changed and missing configuration files. = I'll need to have a
>=3B closer look at that=2C some extensions seem t= >o be needed. Anybody who
>=3B feels he can do that faster than me is o= >f course encouraged (I'll have
>=3B little time as usual :-/).
>= >=3B
>=3B It may also turn out to be difficult to produce LINUXLIBC6 b= >inaries=2C
>=3B as birch and other Elego servers are now 64 bit machin= >es=2C and trying
>=3B to use current CM3 with --32 produced lots of as= >sembler errors about
>=3B unsupported instructions on this architectur= >e. As the old installation
>=3B on birch seems to be gone without a ch= >ance of being restored=2C it will
>=3B probably be easiest to use a re= >al 32 bit system and start from 5.4.0
>=3B again.
>=3B
>=3B= > Anybody who wants to help should be able to build the binary
>=3B arc= >hives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh
>=3B easily = >and upload them to birch at
>=3B
>=3B /var/www/modula3.elegosoft= >.com/cm3/uploaded-archives
>=3B
>=3B My guess is that tinderbox = >will take some time to run smoothly again=2C
>=3B as it was highly cus= >tomized=2C and I'm not sure if these customizations
>=3B survied the c= >rash.
>=3B
>=3B Please stay tuned and thanks for all your patien= >ce=2C
>=3B
>=3B Olaf
>=3B --
>=3B Olaf Wagner -- eleg= >o Software Solutions GmbH
>=3B Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C= > 13355 Berlin=2C Germany
>=3B phone: +49 30 23 45 86 96 mobile: +49 17= >7 2345 869 fax: +49 30 23 45 86 95
>=3B http://www.elegosoft.com | Ges= >ch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berlin
>=3B Handelregister: Amts= >gericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>=3B
dy> >= > >--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_-- From rodney.bates at wichita.edu Wed Apr 1 19:24:58 2009 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 01 Apr 2009 12:24:58 -0500 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090331145127.GB9624@topoi.pooq.com> References: <20090331145127.GB9624@topoi.pooq.com> Message-ID: <49D3A36A.1030501@wichita.edu> hendrik at topoi.pooq.com wrote: > The BottonVBT contains an action, which is a procedure rather than a > method. b This makes it awkward to subclass ButtonVBT becaue the action > will still expect its first parameter to be a ButtonVBT instead of > belonging to the subclass, and an explicit downcast of some sort will be > needed to acess the subclass's members. > > The Trestle manual says this was a deliberate decision: > > : The action procedure is a field rather than a method in order to allow > : buttons with different action procedures to share their method suites. I don't understand the original reasoning. If 'action' were a method, you could create different buttons with overrides for 'action' but not override any other method and get exactly the same set of shared methods among the buttons as in the original design. What have I missed? > > I, however, find it massively inconvenient because it mans I have to > resort to downcasting or the very kludgey VBT.GetProp to access what > should be just there. I'd rather the action procedure was a method. > > But it should be possible to have the best of both worlds. Have an > action2 (better name wanted here) method that is available for > overriding, and by default calls the procedure in the existing action. > field. That action2 method wounl then be called by Trestle wherever > action is now called. > > Does anyone see problems with this? > > -- hendrik > Rodney Bates From mika at async.caltech.edu Wed Apr 1 19:33:01 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 01 Apr 2009 10:33:01 -0700 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: Your message of "Wed, 01 Apr 2009 12:24:58 CDT." <49D3A36A.1030501@wichita.edu> Message-ID: <200904011733.n31HX1mO096260@camembert.async.caltech.edu> Seems a bit mysterious to me too but I wonder if it's not a way of getting the benefits of multiple inheritance. If you want method m1 from one set of VBTs V and method m2 from another set W, you can't inherit from both. But if the methods are instead procedure fields with the common supertype as the first argument, you can set the fields of X, m1 := V.M1, m2 := W.m2, even though X is a subtype of neither V nor W... You can probably use a design pattern to get something similar without using procedure fields, but that would involve introducing new types. Mika "Rodney M. Bates" writes: >hendrik at topoi.pooq.com wrote: >> The BottonVBT contains an action, which is a procedure rather than a >> method. b This makes it awkward to subclass ButtonVBT becaue the action >> will still expect its first parameter to be a ButtonVBT instead of >> belonging to the subclass, and an explicit downcast of some sort will be >> needed to acess the subclass's members. >> >> The Trestle manual says this was a deliberate decision: >> >> : The action procedure is a field rather than a method in order to allow >> : buttons with different action procedures to share their method suites. > >I don't understand the original reasoning. If 'action' were a method, you >could create different buttons with overrides for 'action' but not override >any other method and get exactly the same set of shared methods among the >buttons as in the original design. What have I missed? > >> >> I, however, find it massively inconvenient because it mans I have to >> resort to downcasting or the very kludgey VBT.GetProp to access what >> should be just there. I'd rather the action procedure was a method. >> >> But it should be possible to have the best of both worlds. Have an >> action2 (better name wanted here) method that is available for >> overriding, and by default calls the procedure in the existing action. >> field. That action2 method wounl then be called by Trestle wherever >> action is now called. >> >> Does anyone see problems with this? >> >> -- hendrik >> > >Rodney Bates From hendrik at topoi.pooq.com Wed Apr 1 22:34:32 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 1 Apr 2009 16:34:32 -0400 Subject: [M3devel] new Linux/x86 archives In-Reply-To: <200904011123.56014.vapier@gentoo.org> References: <20090401145945.GA12017@topoi.pooq.com> <200904011123.56014.vapier@gentoo.org> Message-ID: <20090401203432.GA12427@topoi.pooq.com> On Wed, Apr 01, 2009 at 11:23:55AM -0400, Mike Frysinger wrote: > On Wednesday 01 April 2009 10:59:45 hendrik at topoi.pooq.com wrote: > > On Wed, Apr 01, 2009 at 02:25:13PM +0000, Jay wrote: > > > A near future build should: > > > not require setting either environment variable, nor look in /tmp. > > > setting $PATH will be optional for convenience to find cm3, > > > but cm3 won't use it to find cm3cg. > > > Shared libs will be found via rpath=$ORIGIN/../lib. > > > > Would this be problematic it $ORIGIN is a symbolic link? > > is that realistic ? you'd have to unpack the archive, move only ./bin/ > somewhere, and then symlink it back in. I guess not. > -mike From jay.krell at cornell.edu Wed Apr 1 22:51:22 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Apr 2009 20:51:22 +0000 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: <200904011659.n31GxkMW094881@camembert.async.caltech.edu> References: Your message of "Wed, 01 Apr 2009 09:22:58 -0000." <200904011659.n31GxkMW094881@camembert.async.caltech.edu> Message-ID: Thank you Mika. There is a cm3.cfg file, but it had a small bug. Actually if you look the cm3.cfg file was probably a mere one line that includes LINUXLIBC6. That is probably overly confusing for anyone trying to understand how it works. If you repeat the experiment with the 5.7.1 archives you should find it easier. The not easy cheat is to take cm3cfg.common from current source tree. If you repeat it with a NOT yet existing archive that I have in mind, even easier, however not for all platforms -- i.e. no need to set LD_LIBRARY_PATH, on platforms that support $ORIGIN, but again, not yet. NT386 is already easy this way, since the .dlls are in the bin directory and that is searched; that is NT386-specific. I also need to get m3gdb and cm3ide into it. > It seems to me it would be quite easy to package this up, maybe even > with cminstall? That would be easiest I think, to cminstall the whole I deliberately don't. I find cminstall not very worthwhile. Try the 5.7.1 archive and see what you think? What you are saying I guess is you like the "one level archive" instead of the usual "two level". Agreed. One level can be easily achieved and have cminstall do a copy instead of untargz. But I also find cminstall not all that worthwhile (as I've said..). - Jay ---------------------------------------- > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Help finding CM3 compiler for Linux? > Date: Wed, 1 Apr 2009 09:59:45 -0700 > From: mika at async.caltech.edu > > > I have to say that once I figured out what I needed to do, using > Jay's distributions was easy---easier than I'm used to with CM3. > > All I had to do was: untar the -std dist (forget the min one). > > Set PATH and LD_LIBRARY_PATH > > And then---the mysterious part, which takes more than passing knowledge > of how CM3 works---providing a cm3.cfg file, which doesn't seem to be > provided at all by Jay's archive. > > It seems to me it would be quite easy to package this up, maybe even > with cminstall? That would be easiest I think, to cminstall the whole > dist rather than cminstalling just the -min and then making people build > their own compiler, libraries, and demo apps... > > Mika > > Jay writes: >>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_ >>Content-Type: text/plain; charset="iso-8859-1" >>Content-Transfer-Encoding: quoted-printable >> >> >>Olaf=2C in the LINUXLIBC6 configuration=2C try putting --32 on the as/gas i= >>nvocations. >> >>You mentioned --32 on cm3=2C but I wonder if you meant -m32 on cm3. >> >> cm3 -m32=20 >> >> as --32=20 >> >>=20 >> >>or check the man pages or help. They aren't consistent=2C for more reasons = >>than shown here (e.g. MIPS has -mabi64=2C and I think AIX has something els= >>e=2C and HP-UX gcc supports none of these -- no bi-arch support). >> >>=20 >> >>> probably be easiest to use a real 32 bit system and start from 5.4.0 >>> again. >> >> >>Using any current system should be plenty easy too. >> >>e.g. the distributions I put up. :) >> >>=20 >> >>AMD64_LINUX should be a good starting point=2C but I haven't tried it in a = >>bit. >> >>=20 >> >>I should be able to build a current LINUXLIBC6 very very soon. >> >>I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test= >> a switch to the "new" Unix *.i3 files. >> >>=20 >> >>I'll be using python/make-dist.py though. >> >>I do need to get more packages into it though=2C e.g. cm3ide and m3gdb. >> >>=20 >> >> - Jay >>=20 >>> Date: Wed=2C 1 Apr 2009 11:11:53 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> CC: mand at elego.de=3B m3-support at elego.de >>> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >>>=20 >>> Quoting Mika Nystrom : >>>=20 >>>> >>>> Is there any documentation for this format beyond what you just >>>> wrote? Where? >>>=20 >>> Well=2C yes=2C that's the problem with these kinds of archives: >>>=20 >>> (1) they're not well tested and >>> (2) there's no documentation user's can rely on >>>=20 >>> This doesn't mean that I disapprove or want to criticise the contributors= >>=2C >>> but an official well-documented release with installation notes etc. >>> has some advantages. Unfortunately=2C the official releases are really >>> outdated now. >>>=20 >>> I succeeded in building current AMD64_LINUX and FreeBSD4 installations >>> on our servers for d5.7.1 tonight and was able to build archives for >>> FreeBSD binaries and sources=2C but the tooling failed for AMD64_KINUX >>> due to changed and missing configuration files. I'll need to have a >>> closer look at that=2C some extensions seem to be needed. Anybody who >>> feels he can do that faster than me is of course encouraged (I'll have >>> little time as usual :-/). >>>=20 >>> It may also turn out to be difficult to produce LINUXLIBC6 binaries=2C >>> as birch and other Elego servers are now 64 bit machines=2C and trying >>> to use current CM3 with --32 produced lots of assembler errors about >>> unsupported instructions on this architecture. As the old installation >>> on birch seems to be gone without a chance of being restored=2C it will >>> probably be easiest to use a real 32 bit system and start from 5.4.0 >>> again. >>>=20 >>> Anybody who wants to help should be able to build the binary >>> archives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh >>> easily and upload them to birch at >>>=20 >>> /var/www/modula3.elegosoft.com/cm3/uploaded-archives >>>=20 >>> My guess is that tinderbox will take some time to run smoothly again=2C >>> as it was highly customized=2C and I'm not sure if these customizations >>> survied the crash. >>>=20 >>> Please stay tuned and thanks for all your patience=2C >>>=20 >>> Olaf >>> --=20 >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 9= >>5 >>> http://www.elegosoft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berli= >>n >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214= >>194 >>>=20 >> >>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_ >>Content-Type: text/html; charset="iso-8859-1" >>Content-Transfer-Encoding: quoted-printable >> >> >> >> >> >> >>Olaf=2C in the LINUXLIBC6 configuration=2C try putting --32 on the as/gas i= >>nvocations. >>You mentioned --32 on cm3=2C but I wonder if you meant -m32 on cm3. >> =3Bcm3 -m32 >> =3Bas --32 >> =3B >>or check the man pages or help. They aren't consistent=2C for more reasons = >>than shown here (e.g. MIPS has -mabi64=2C and I think AIX has something els= >>e=2C and HP-UX gcc supports none of these -- no bi-arch support). >> =3B >> =3B>=3B probably be easiest to use a real 32 bit system and start fr= >>om 5.4.0 =3B>=3B again. >>Using any current system should be plenty easy too. >>e.g. the distributions I put up. :) >> =3B >>AMD64_LINUX should be a good starting point=2C but I haven't tried it in a = >>bit. >> =3B >>I should be able to build a current LINUXLIBC6 very very soon. >>I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test= >> a switch to the "new" Unix *.i3 files. >> =3B >>I'll be using python/make-dist.py though. >>I do need to get more packages into it though=2C e.g. cm3ide and m3gdb. >> =3B >> =3B- Jay =3B >=3B Date: Wed=2C 1 Apr 2009 11:11:53 +0200<= >>BR>>=3B From: wagner at elegosoft.com >=3B To: m3devel at elegosoft.com>>>>=3B CC: mand at elego.de=3B m3-support at elego.de >=3B Subject: Re: [M3= >>devel] Help finding CM3 compiler for Linux? >=3B >=3B Quoting Mi= >>ka Nystrom <=3Bmika at async.caltech.edu>=3B: >=3B >=3B>=3B<= >>BR>>=3B>=3B Is there any documentation for this format beyond what you= >> just >=3B>=3B wrote? Where? >=3B >=3B Well=2C yes=2C th= >>at's the problem with these kinds of archives: >=3B >=3B (1) the= >>y're not well tested and >=3B (2) there's no documentation user's can = >>rely on >=3B >=3B This doesn't mean that I disapprove or want to= >> criticise the contributors=2C >=3B but an official well-documented re= >>lease with installation notes etc. >=3B has some advantages. Unfortuna= >>tely=2C the official releases are really >=3B outdated now. >=3B = >> >=3B I succeeded in building current AMD64_LINUX and FreeBSD4 install= >>ations >=3B on our servers for d5.7.1 tonight and was able to build ar= >>chives for >=3B FreeBSD binaries and sources=2C but the tooling failed= >> for AMD64_KINUX >=3B due to changed and missing configuration files. = > I'll need to have a >=3B closer look at that=2C some extensions seem t= >>o be needed. Anybody who >=3B feels he can do that faster than me is o= >>f course encouraged (I'll have >=3B little time as usual :-/). >= >>=3B >=3B It may also turn out to be difficult to produce LINUXLIBC6 b= >>inaries=2C >=3B as birch and other Elego servers are now 64 bit machin= >>es=2C and trying >=3B to use current CM3 with --32 produced lots of as= >>sembler errors about >=3B unsupported instructions on this architectur= >>e. As the old installation >=3B on birch seems to be gone without a ch= >>ance of being restored=2C it will >=3B probably be easiest to use a re= >>al 32 bit system and start from 5.4.0 >=3B again. >=3B >=3B= >> Anybody who wants to help should be able to build the binary >=3B arc= >>hives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh >=3B easily = >>and upload them to birch at >=3B >=3B /var/www/modula3.elegosoft= >>.com/cm3/uploaded-archives >=3B >=3B My guess is that tinderbox = >>will take some time to run smoothly again=2C >=3B as it was highly cus= >>tomized=2C and I'm not sure if these customizations >=3B survied the c= >>rash. >=3B >=3B Please stay tuned and thanks for all your patien= >>ce=2C >=3B >=3B Olaf >=3B -- >=3B Olaf Wagner -- eleg= >>o Software Solutions GmbH >=3B Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C= >> 13355 Berlin=2C Germany >=3B phone: +49 30 23 45 86 96 mobile: +49 17= >>7 2345 869 fax: +49 30 23 45 86 95 >=3B http://www.elegosoft.com | Ges= >>ch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berlin >=3B Handelregister: Amts= >>gericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >=3B >>dy> >>= >> >>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_-- From jay.krell at cornell.edu Wed Apr 1 22:55:46 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Apr 2009 20:55:46 +0000 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: <200904011659.n31GxkMW094881@camembert.async.caltech.edu> References: Your message of "Wed, 01 Apr 2009 09:22:58 -0000." <200904011659.n31GxkMW094881@camembert.async.caltech.edu> Message-ID: er, actually, the two level shouldn't be too bad, given that cminstall extracts the second level..so I don't know. "Usual two level" as in "usual Modula-3 two level", not usual outside Modula-3. But again, your experience was much worse than intended. There is a cm3.cfg file but it had a small but fatal bug. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Help finding CM3 compiler for Linux? > Date: Wed, 1 Apr 2009 20:51:22 +0000 > > > Thank you Mika. There is a cm3.cfg file, but it had a small bug. > Actually if you look the cm3.cfg file was probably a mere one line that includes LINUXLIBC6. That is probably overly confusing for anyone trying to understand how it works. > > If you repeat the experiment with the 5.7.1 archives you should find it easier. > The not easy cheat is to take cm3cfg.common from current source tree. > > If you repeat it with a NOT yet existing archive that I have in mind, even easier, however not for all platforms -- i.e. no need to set LD_LIBRARY_PATH, on platforms that support $ORIGIN, but again, not yet. NT386 is already easy this way, since the .dlls are in the bin directory and that is searched; that is NT386-specific. > > I also need to get m3gdb and cm3ide into it. > >> It seems to me it would be quite easy to package this up, maybe even >> with cminstall? That would be easiest I think, to cminstall the whole > > I deliberately don't. > I find cminstall not very worthwhile. > Try the 5.7.1 archive and see what you think? > > What you are saying I guess is you like the "one level archive" instead of the usual "two level". Agreed. One level can be easily achieved and have cminstall do a copy instead of untargz. But I also find cminstall not all that worthwhile (as I've said..). > > > - Jay > > ---------------------------------------- >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >> Date: Wed, 1 Apr 2009 09:59:45 -0700 >> From: mika at async.caltech.edu >> >> >> I have to say that once I figured out what I needed to do, using >> Jay's distributions was easy---easier than I'm used to with CM3. >> >> All I had to do was: untar the -std dist (forget the min one). >> >> Set PATH and LD_LIBRARY_PATH >> >> And then---the mysterious part, which takes more than passing knowledge >> of how CM3 works---providing a cm3.cfg file, which doesn't seem to be >> provided at all by Jay's archive. >> >> It seems to me it would be quite easy to package this up, maybe even >> with cminstall? That would be easiest I think, to cminstall the whole >> dist rather than cminstalling just the -min and then making people build >> their own compiler, libraries, and demo apps... >> >> Mika >> >> Jay writes: >>>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_ >>>Content-Type: text/plain; charset="iso-8859-1" >>>Content-Transfer-Encoding: quoted-printable >>> >>> >>>Olaf=2C in the LINUXLIBC6 configuration=2C try putting --32 on the as/gas i= >>>nvocations. >>> >>>You mentioned --32 on cm3=2C but I wonder if you meant -m32 on cm3. >>> >>> cm3 -m32=20 >>> >>> as --32=20 >>> >>>=20 >>> >>>or check the man pages or help. They aren't consistent=2C for more reasons = >>>than shown here (e.g. MIPS has -mabi64=2C and I think AIX has something els= >>>e=2C and HP-UX gcc supports none of these -- no bi-arch support). >>> >>>=20 >>> >>>> probably be easiest to use a real 32 bit system and start from 5.4.0 >>>> again. >>> >>> >>>Using any current system should be plenty easy too. >>> >>>e.g. the distributions I put up. :) >>> >>>=20 >>> >>>AMD64_LINUX should be a good starting point=2C but I haven't tried it in a = >>>bit. >>> >>>=20 >>> >>>I should be able to build a current LINUXLIBC6 very very soon. >>> >>>I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test= >>> a switch to the "new" Unix *.i3 files. >>> >>>=20 >>> >>>I'll be using python/make-dist.py though. >>> >>>I do need to get more packages into it though=2C e.g. cm3ide and m3gdb. >>> >>>=20 >>> >>> - Jay >>>=20 >>>> Date: Wed=2C 1 Apr 2009 11:11:53 +0200 >>>> From: wagner at elegosoft.com >>>> To: m3devel at elegosoft.com >>>> CC: mand at elego.de=3B m3-support at elego.de >>>> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >>>>=20 >>>> Quoting Mika Nystrom : >>>>=20 >>>>> >>>>> Is there any documentation for this format beyond what you just >>>>> wrote? Where? >>>>=20 >>>> Well=2C yes=2C that's the problem with these kinds of archives: >>>>=20 >>>> (1) they're not well tested and >>>> (2) there's no documentation user's can rely on >>>>=20 >>>> This doesn't mean that I disapprove or want to criticise the contributors= >>>=2C >>>> but an official well-documented release with installation notes etc. >>>> has some advantages. Unfortunately=2C the official releases are really >>>> outdated now. >>>>=20 >>>> I succeeded in building current AMD64_LINUX and FreeBSD4 installations >>>> on our servers for d5.7.1 tonight and was able to build archives for >>>> FreeBSD binaries and sources=2C but the tooling failed for AMD64_KINUX >>>> due to changed and missing configuration files. I'll need to have a >>>> closer look at that=2C some extensions seem to be needed. Anybody who >>>> feels he can do that faster than me is of course encouraged (I'll have >>>> little time as usual :-/). >>>>=20 >>>> It may also turn out to be difficult to produce LINUXLIBC6 binaries=2C >>>> as birch and other Elego servers are now 64 bit machines=2C and trying >>>> to use current CM3 with --32 produced lots of assembler errors about >>>> unsupported instructions on this architecture. As the old installation >>>> on birch seems to be gone without a chance of being restored=2C it will >>>> probably be easiest to use a real 32 bit system and start from 5.4.0 >>>> again. >>>>=20 >>>> Anybody who wants to help should be able to build the binary >>>> archives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh >>>> easily and upload them to birch at >>>>=20 >>>> /var/www/modula3.elegosoft.com/cm3/uploaded-archives >>>>=20 >>>> My guess is that tinderbox will take some time to run smoothly again=2C >>>> as it was highly customized=2C and I'm not sure if these customizations >>>> survied the crash. >>>>=20 >>>> Please stay tuned and thanks for all your patience=2C >>>>=20 >>>> Olaf >>>> --=20 >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 9= >>>5 >>>> http://www.elegosoft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berli= >>>n >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214= >>>194 >>>>=20 >>> >>>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_ >>>Content-Type: text/html; charset="iso-8859-1" >>>Content-Transfer-Encoding: quoted-printable >>> >>> >>> >>> > > >>> >>> >>>Olaf=2C in the LINUXLIBC6 configuration=2C try putting --32 on the as/gas i= >>>nvocations. > >>>You mentioned --32 on cm3=2C but I wonder if you meant -m32 on cm3. > >>> =3Bcm3 -m32 > >>> =3Bas --32 > >>> =3B > >>>or check the man pages or help. They aren't consistent=2C for more reasons = >>>than shown here (e.g. MIPS has -mabi64=2C and I think AIX has something els= >>>e=2C and HP-UX gcc supports none of these -- no bi-arch support). > >>> =3B > >>> =3B>=3B probably be easiest to use a real 32 bit system and start fr= >>>om 5.4.0 > =3B>=3B again. > > >>>Using any current system should be plenty easy too. > >>>e.g. the distributions I put up. :) > >>> =3B > >>>AMD64_LINUX should be a good starting point=2C but I haven't tried it in a = >>>bit. > >>> =3B > >>>I should be able to build a current LINUXLIBC6 very very soon. > >>>I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test= >>> a switch to the "new" Unix *.i3 files. > >>> =3B > >>>I'll be using python/make-dist.py though. > >>>I do need to get more packages into it though=2C e.g. cm3ide and m3gdb. > >>> =3B > >>> =3B- Jay > =3B >>=3B Date: Wed=2C 1 Apr 2009 11:11:53 +0200<= >>>BR>>=3B From: wagner at elegosoft.com >>=3B To: m3devel at elegosoft.com>>>>=3B CC: mand at elego.de=3B m3-support at elego.de >>=3B Subject: Re: [M3= >>>devel] Help finding CM3 compiler for Linux? >>=3B >>=3B Quoting Mi= >>>ka Nystrom <=3Bmika at async.caltech.edu>=3B: >>=3B >>=3B>=3B<= >>>BR>>=3B>=3B Is there any documentation for this format beyond what you= >>> just >>=3B>=3B wrote? Where? >>=3B >>=3B Well=2C yes=2C th= >>>at's the problem with these kinds of archives: >>=3B >>=3B (1) the= >>>y're not well tested and >>=3B (2) there's no documentation user's can = >>>rely on >>=3B >>=3B This doesn't mean that I disapprove or want to= >>> criticise the contributors=2C >>=3B but an official well-documented re= >>>lease with installation notes etc. >>=3B has some advantages. Unfortuna= >>>tely=2C the official releases are really >>=3B outdated now. >>=3B = >>> >>=3B I succeeded in building current AMD64_LINUX and FreeBSD4 install= >>>ations >>=3B on our servers for d5.7.1 tonight and was able to build ar= >>>chives for >>=3B FreeBSD binaries and sources=2C but the tooling failed= >>> for AMD64_KINUX >>=3B due to changed and missing configuration files. = >> I'll need to have a >>=3B closer look at that=2C some extensions seem t= >>>o be needed. Anybody who >>=3B feels he can do that faster than me is o= >>>f course encouraged (I'll have >>=3B little time as usual :-/). >>= >>>=3B >>=3B It may also turn out to be difficult to produce LINUXLIBC6 b= >>>inaries=2C >>=3B as birch and other Elego servers are now 64 bit machin= >>>es=2C and trying >>=3B to use current CM3 with --32 produced lots of as= >>>sembler errors about >>=3B unsupported instructions on this architectur= >>>e. As the old installation >>=3B on birch seems to be gone without a ch= >>>ance of being restored=2C it will >>=3B probably be easiest to use a re= >>>al 32 bit system and start from 5.4.0 >>=3B again. >>=3B >>=3B= >>> Anybody who wants to help should be able to build the binary >>=3B arc= >>>hives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh >>=3B easily = >>>and upload them to birch at >>=3B >>=3B /var/www/modula3.elegosoft= >>>.com/cm3/uploaded-archives >>=3B >>=3B My guess is that tinderbox = >>>will take some time to run smoothly again=2C >>=3B as it was highly cus= >>>tomized=2C and I'm not sure if these customizations >>=3B survied the c= >>>rash. >>=3B >>=3B Please stay tuned and thanks for all your patien= >>>ce=2C >>=3B >>=3B Olaf >>=3B -- >>=3B Olaf Wagner -- eleg= >>>o Software Solutions GmbH >>=3B Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C= >>> 13355 Berlin=2C Germany >>=3B phone: +49 30 23 45 86 96 mobile: +49 17= >>>7 2345 869 fax: +49 30 23 45 86 95 >>=3B http://www.elegosoft.com | Ges= >>>ch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berlin >>=3B Handelregister: Amts= >>>gericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>=3B >>>dy> >>>= >>> >>>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_-- From mika at async.caltech.edu Thu Apr 2 00:25:25 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 01 Apr 2009 15:25:25 -0700 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: Your message of "Wed, 01 Apr 2009 20:51:22 -0000." Message-ID: <200904012225.n31MPPDd007216@camembert.async.caltech.edu> Actually I think that the thing that has caused me the most problems in the past is that the -min and the -src-all get out of sync, since the binary bootstrapping dists are often not distributed (for size reasons?) with full source archives from exactly the same date. So when you try to build src-all with the binary bootstrap, something goes wrong. It's the whole... ok I need a binary install (since it's a real compiler), but now I have to bootstrap everything. And then the bootstrap turns out not to be 100% compatible with the compiler sources, libraries, some little detail in m3tk, ... Another way of saying this is "Isn't CM3 way overdue for a 'release'?" Mika Jay writes: > >Thank you Mika. There is a cm3.cfg file, but it had a small bug. > Actually if you look the cm3.cfg file was probably a mere one line that includes LINUXLIBC6. That is probably overly confusing for anyone trying to understand how it works. > >If you repeat the experiment with the 5.7.1 archives you should find it easier. > The not easy cheat is to take cm3cfg.common from current source tree. > >If you repeat it with a NOT yet existing archive that I have in mind, even easier, however not for all platforms -- i.e. no need to set LD_LIBRARY_PATH, on platforms that support $ORIGIN, but again, not yet. >NT386 is already easy this way, since the .dlls are in the bin directory and that is searched; that is NT386-specific. > >I also need to get m3gdb and cm3ide into it. > >> It seems to me it would be quite easy to package this up, maybe even >> with cminstall? That would be easiest I think, to cminstall the whole > >I deliberately don't. >I find cminstall not very worthwhile. >Try the 5.7.1 archive and see what you think? > >What you are saying I guess is you like the "one level archive" instead of the usual "two level". Agreed. One level can be easily achieved and have cminstall do a copy instead of untargz. But I also find cmin >stall not all that worthwhile (as I've said..). > > > - Jay > >---------------------------------------- >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >> Date: Wed, 1 Apr 2009 09:59:45 -0700 >> From: mika at async.caltech.edu >> >> >> I have to say that once I figured out what I needed to do, using >> Jay's distributions was easy---easier than I'm used to with CM3. >> >> All I had to do was: untar the -std dist (forget the min one). >> >> Set PATH and LD_LIBRARY_PATH >> >> And then---the mysterious part, which takes more than passing knowledge >> of how CM3 works---providing a cm3.cfg file, which doesn't seem to be >> provided at all by Jay's archive. >> >> It seems to me it would be quite easy to package this up, maybe even >> with cminstall? That would be easiest I think, to cminstall the whole >> dist rather than cminstalling just the -min and then making people build >> their own compiler, libraries, and demo apps... >> >> Mika >> >> Jay writes: >>>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_ >>>Content-Type: text/plain; charset="iso-8859-1" >>>Content-Transfer-Encoding: quoted-printable >>> >>> >>>Olaf=2C in the LINUXLIBC6 configuration=2C try putting --32 on the as/gas i= >>>nvocations. >>> >>>You mentioned --32 on cm3=2C but I wonder if you meant -m32 on cm3. >>> >>> cm3 -m32=20 >>> >>> as --32=20 >>> >>>=20 >>> >>>or check the man pages or help. They aren't consistent=2C for more reasons = >>>than shown here (e.g. MIPS has -mabi64=2C and I think AIX has something els= >>>e=2C and HP-UX gcc supports none of these -- no bi-arch support). >>> >>>=20 >>> >>>> probably be easiest to use a real 32 bit system and start from 5.4.0 >>>> again. >>> >>> >>>Using any current system should be plenty easy too. >>> >>>e.g. the distributions I put up. :) >>> >>>=20 >>> >>>AMD64_LINUX should be a good starting point=2C but I haven't tried it in a = >>>bit. >>> >>>=20 >>> >>>I should be able to build a current LINUXLIBC6 very very soon. >>> >>>I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test= >>> a switch to the "new" Unix *.i3 files. >>> >>>=20 >>> >>>I'll be using python/make-dist.py though. >>> >>>I do need to get more packages into it though=2C e.g. cm3ide and m3gdb. >>> >>>=20 >>> >>> - Jay >>>=20 >>>> Date: Wed=2C 1 Apr 2009 11:11:53 +0200 >>>> From: wagner at elegosoft.com >>>> To: m3devel at elegosoft.com >>>> CC: mand at elego.de=3B m3-support at elego.de >>>> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >>>>=20 >>>> Quoting Mika Nystrom : >>>>=20 >>>>> >>>>> Is there any documentation for this format beyond what you just >>>>> wrote? Where? >>>>=20 >>>> Well=2C yes=2C that's the problem with these kinds of archives: >>>>=20 >>>> (1) they're not well tested and >>>> (2) there's no documentation user's can rely on >>>>=20 >>>> This doesn't mean that I disapprove or want to criticise the contributors= >>>=2C >>>> but an official well-documented release with installation notes etc. >>>> has some advantages. Unfortunately=2C the official releases are really >>>> outdated now. >>>>=20 >>>> I succeeded in building current AMD64_LINUX and FreeBSD4 installations >>>> on our servers for d5.7.1 tonight and was able to build archives for >>>> FreeBSD binaries and sources=2C but the tooling failed for AMD64_KINUX >>>> due to changed and missing configuration files. I'll need to have a >>>> closer look at that=2C some extensions seem to be needed. Anybody who >>>> feels he can do that faster than me is of course encouraged (I'll have >>>> little time as usual :-/). >>>>=20 >>>> It may also turn out to be difficult to produce LINUXLIBC6 binaries=2C >>>> as birch and other Elego servers are now 64 bit machines=2C and trying >>>> to use current CM3 with --32 produced lots of assembler errors about >>>> unsupported instructions on this architecture. As the old installation >>>> on birch seems to be gone without a chance of being restored=2C it will >>>> probably be easiest to use a real 32 bit system and start from 5.4.0 >>>> again. >>>>=20 >>>> Anybody who wants to help should be able to build the binary >>>> archives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh >>>> easily and upload them to birch at >>>>=20 >>>> /var/www/modula3.elegosoft.com/cm3/uploaded-archives >>>>=20 >>>> My guess is that tinderbox will take some time to run smoothly again=2C >>>> as it was highly customized=2C and I'm not sure if these customizations >>>> survied the crash. >>>>=20 >>>> Please stay tuned and thanks for all your patience=2C >>>>=20 >>>> Olaf >>>> --=20 >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 9= >>>5 >>>> http://www.elegosoft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berli= >>>n >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214= >>>194 >>>>=20 >>> >>>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_ >>>Content-Type: text/html; charset="iso-8859-1" >>>Content-Transfer-Encoding: quoted-printable >>> >>> >>> >>> > > >>> >>> >>>Olaf=2C in the LINUXLIBC6 configuration=2C try putting --32 on the as/gas i= >>>nvocations. > >>>You mentioned --32 on cm3=2C but I wonder if you meant -m32 on cm3. > >>> =3Bcm3 -m32 > >>> =3Bas --32 > >>> =3B > >>>or check the man pages or help. They aren't consistent=2C for more reasons = >>>than shown here (e.g. MIPS has -mabi64=2C and I think AIX has something els= >>>e=2C and HP-UX gcc supports none of these -- no bi-arch support). > >>> =3B > >>> =3B>=3B probably be easiest to use a real 32 bit system and start fr= >>>om 5.4.0 > =3B>=3B again. > > >>>Using any current system should be plenty easy too. > >>>e.g. the distributions I put up. :) > >>> =3B > >>>AMD64_LINUX should be a good starting point=2C but I haven't tried it in a = >>>bit. > >>> =3B > >>>I should be able to build a current LINUXLIBC6 very very soon. > >>>I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test= >>> a switch to the "new" Unix *.i3 files. > >>> =3B > >>>I'll be using python/make-dist.py though. > >>>I do need to get more packages into it though=2C e.g. cm3ide and m3gdb. > >>> =3B > >>> =3B- Jay > =3B >>=3B Date: Wed=2C 1 Apr 2009 11:11:53 +0200<= >>>BR>>=3B From: wagner at elegosoft.com >>=3B To: m3devel at elegosoft.com>>>>=3B CC: mand at elego.de=3B m3-support at elego.de >>=3B Subject: Re: [M3= >>>devel] Help finding CM3 compiler for Linux? >>=3B >>=3B Quoting Mi= >>>ka Nystrom <=3Bmika at async.caltech.edu>=3B: >>=3B >>=3B>=3B<= >>>BR>>=3B>=3B Is there any documentation for this format beyond what you= >>> just >>=3B>=3B wrote? Where? >>=3B >>=3B Well=2C yes=2C th= >>>at's the problem with these kinds of archives: >>=3B >>=3B (1) the= >>>y're not well tested and >>=3B (2) there's no documentation user's can = >>>rely on >>=3B >>=3B This doesn't mean that I disapprove or want to= >>> criticise the contributors=2C >>=3B but an official well-documented re= >>>lease with installation notes etc. >>=3B has some advantages. Unfortuna= >>>tely=2C the official releases are really >>=3B outdated now. >>=3B = >>> >>=3B I succeeded in building current AMD64_LINUX and FreeBSD4 install= >>>ations >>=3B on our servers for d5.7.1 tonight and was able to build ar= >>>chives for >>=3B FreeBSD binaries and sources=2C but the tooling failed= >>> for AMD64_KINUX >>=3B due to changed and missing configuration files. = >> I'll need to have a >>=3B closer look at that=2C some extensions seem t= >>>o be needed. Anybody who >>=3B feels he can do that faster than me is o= >>>f course encouraged (I'll have >>=3B little time as usual :-/). >>= >>>=3B >>=3B It may also turn out to be difficult to produce LINUXLIBC6 b= >>>inaries=2C >>=3B as birch and other Elego servers are now 64 bit machin= >>>es=2C and trying >>=3B to use current CM3 with --32 produced lots of as= >>>sembler errors about >>=3B unsupported instructions on this architectur= >>>e. As the old installation >>=3B on birch seems to be gone without a ch= >>>ance of being restored=2C it will >>=3B probably be easiest to use a re= >>>al 32 bit system and start from 5.4.0 >>=3B again. >>=3B >>=3B= >>> Anybody who wants to help should be able to build the binary >>=3B arc= >>>hives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh >>=3B easily = >>>and upload them to birch at >>=3B >>=3B /var/www/modula3.elegosoft= >>>.com/cm3/uploaded-archives >>=3B >>=3B My guess is that tinderbox = >>>will take some time to run smoothly again=2C >>=3B as it was highly cus= >>>tomized=2C and I'm not sure if these customizations >>=3B survied the c= >>>rash. >>=3B >>=3B Please stay tuned and thanks for all your patien= >>>ce=2C >>=3B >>=3B Olaf >>=3B -- >>=3B Olaf Wagner -- eleg= >>>o Software Solutions GmbH >>=3B Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C= >>> 13355 Berlin=2C Germany >>=3B phone: +49 30 23 45 86 96 mobile: +49 17= >>>7 2345 869 fax: +49 30 23 45 86 95 >>=3B http://www.elegosoft.com | Ges= >>>ch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berlin >>=3B Handelregister: Amts= >>>gericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>=3B >>>dy> >>>= >>> >>>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_-- From rcoleburn at scires.com Thu Apr 2 01:05:16 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 01 Apr 2009 19:05:16 -0400 Subject: [M3devel] new cm3 release (was: Help finding CM3 compiler for Linux?) In-Reply-To: <200904012225.n31MPPDd007216@camembert.async.caltech.edu> References: Your message of "Wed, 01 Apr 2009 20:51:22 -0000." <200904012225.n31MPPDd007216@camembert.async.caltech.edu> Message-ID: <49D3BAD7.1E75.00D7.1@scires.com> I agree about needing a new release. I suppose there is some value in maintaining a MINimal size binary distribution, but I think it would also nice to also provide a FULL distribution with everything pre-built. (Of course, this will eat up more space on elego machines.) I have ready access to Windows XP (32-bit and 64-bit) and Vista platforms. I would be glad to build and supply the distros for these platforms. Suggest we agree upon a plan and a timeframe. a. make a tag or something in CVS that marks what will comprise the official sources for the release b. agree upon distribution format (platform naming conventions, compressed archive format for MIN and FULL variants) c. get a list of who is going to supply distros for which platforms d. establish procedure for how the distros will be uploaded to elego e. set a date for contributors to have the distros uploaded f. have someone put together the web page showing links to all the distros along with updated installation instructions One sticky issue in the past has been target location. If we unpack a distro and put it in a different place in the filesystem tree, we don't want it to break. I know that cminstall attempted to adjust the cm3.cfg file to deal with location differences. Do we need/want to build an installer program or script to deal with this issue, perhaps even adjusting cminstall will suffice? Or, do we give a set of instructions on which file(s) to edit when moving the install location? For Windows, I don't mind building an installer. Perhaps the installer could let you choose whether to install the MIN or the FULL version. Also, I think the Tinderbox has been great, but perhaps it can be improved. I know I would like to see testing for Windows platforms added. I have an XP computer I can pretty much dedicate to this task. The problem is that I tried with Olaf's help to get it working, but there were too many dependencies on unix-type shell/script environment, and trying to force fit into cygwin didn't work well for the native Win32 implementation. Thoughts? Regards, Randy >>> Mika Nystrom 4/1/2009 6:25 PM >>> Actually I think that the thing that has caused me the most problems in the past is that the -min and the -src-all get out of sync, since the binary bootstrapping dists are often not distributed (for size reasons?) with full source archives from exactly the same date. So when you try to build src-all with the binary bootstrap, something goes wrong. It's the whole... ok I need a binary install (since it's a real compiler), but now I have to bootstrap everything. And then the bootstrap turns out not to be 100% compatible with the compiler sources, libraries, some little detail in m3tk, ... Another way of saying this is "Isn't CM3 way overdue for a 'release'?" Mika CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 2 01:28:01 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Apr 2009 23:28:01 +0000 Subject: [M3devel] new cm3 release (was: Help finding CM3 compiler for Linux?) In-Reply-To: <49D3BAD7.1E75.00D7.1@scires.com> References: Your message of "Wed, 01 Apr 2009 20:51:22 -0000." <200904012225.n31MPPDd007216@camembert.async.caltech.edu> <49D3BAD7.1E75.00D7.1@scires.com> Message-ID: "std" is already essentially "full", or meant to be at least. Granted my "std" is missing m3gdb and cm3ide, at least. But it isn't small. "std" isn't new or specific to my releases. It has been in all the "open" cm3 releases, and probably the Critical Mass ones too. I've been meaning to put together "boot" releases that are perhaps smaller than "min", though that isn't perhaps their defining characteristic. They would consist of assembly code for the Modula-3 and uncompiled C code. Very similar to the old Digital SRC releases, and I think the ezm3 releases. The Digital SRC boot format no longer works, because it depended on quake/m3build/m3ship being written in C. A defining characteristic probably of "boot" is that it is safe against API and ABI changes. Another one perhaps though is having to spend the time to build cm3cg. My current "boot" archives build only cm3, but extending them to build m3core and libm3 would be trivial, extending them to build all of "std", not too difficult. I gather one of the nice things PM3 had was they shipped IL instead of assembly. That can be a a lot more portable, or extremely portable. "more portable" -- varying mainly only in wordsize and endian, /maybe/ smaller issues like alignment (almost always the same anyway), page size (not really) "extremely portable" -- factor even those out Though you'd also have to factor out the Time/Date stuff. And if you had user thread support in there, portability gains would be lost. This approach, in fact, can lead to "universal posix" distributions, at the cost of user having to build cm3cg. In fact you could build the Win32 code and have the last-on-the-target stage pick the appropriate files, leading to really "universal" distributions. > One sticky issue in the past has been target location This is not an issue with my config files, hasn't been for a long time. Kind of bothersome..you know..I solved this years ago..to still be discussing it as an issue.. Yeah, I realize my ChangeLog is not readable but... Quake code can query for its own location. At least as of a while ago. Maybe not in much old versions. (I didn't add the feature, I merely discovered it was there.) My cm3.cfg file does that. And then build the rest of the paths from there -- at least for cm3/cm3cg/pkg/lib. The location of cl.exe and link.exe aren't solved by path. For those, I just run "cl" and "link" and depend on $PATH. That's how people often deal with gcc/ld, though I realize there is no unversality here. Some people use full paths to gcc/ld, some rely on $PATH, ditto for cl/link (actually for cl/link, most "people" use an interactive GUI that hides tons of stuff, but there are still "automated builds" that have to do something.) I did some experimentation with building a GUI NT install, using "InnoSetup". It was just a glorified untargz, which does have some value. A little fancier than just distributing a .zip file. I didn't get to the point of (offering to) altering $PATH, ensuring cl.exe/link.exe were available. But this perhaps be adequately handled by one line documentation telling people to run the "shortcut" that Visual C++ installs, that runs an appropriately setup command line (the platform SDK and DDK do the same). I dread the "freeze" state approaching releases. Please hopefully there is a "tag" or "branch" for the release, and I can continue working "my way" (churn too high for near release). - Jay Date: Wed, 1 Apr 2009 19:05:16 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] new cm3 release (was: Help finding CM3 compiler for Linux?) I agree about needing a new release. I suppose there is some value in maintaining a MINimal size binary distribution, but I think it would also nice to also provide a FULL distribution with everything pre-built. (Of course, this will eat up more space on elego machines.) I have ready access to Windows XP (32-bit and 64-bit) and Vista platforms. I would be glad to build and supply the distros for these platforms. Suggest we agree upon a plan and a timeframe. a. make a tag or something in CVS that marks what will comprise the official sources for the release b. agree upon distribution format (platform naming conventions, compressed archive format for MIN and FULL variants) c. get a list of who is going to supply distros for which platforms d. establish procedure for how the distros will be uploaded to elego e. set a date for contributors to have the distros uploaded f. have someone put together the web page showing links to all the distros along with updated installation instructions One sticky issue in the past has been target location. If we unpack a distro and put it in a different place in the filesystem tree, we don't want it to break. I know that cminstall attempted to adjust the cm3.cfg file to deal with location differences. Do we need/want to build an installer program or script to deal with this issue, perhaps even adjusting cminstall will suffice? Or, do we give a set of instructions on which file(s) to edit when moving the install location? For Windows, I don't mind building an installer. Perhaps the installer could let you choose whether to install the MIN or the FULL version. Also, I think the Tinderbox has been great, but perhaps it can be improved. I know I would like to see testing for Windows platforms added. I have an XP computer I can pretty much dedicate to this task. The problem is that I tried with Olaf's help to get it working, but there were too many dependencies on unix-type shell/script environment, and trying to force fit into cygwin didn't work well for the native Win32 implementation. Thoughts? Regards, Randy >>> Mika Nystrom 4/1/2009 6:25 PM >>> Actually I think that the thing that has caused me the most problems in the past is that the -min and the -src-all get out of sync, since the binary bootstrapping dists are often not distributed (for size reasons?) with full source archives from exactly the same date. So when you try to build src-all with the binary bootstrap, something goes wrong. It's the whole... ok I need a binary install (since it's a real compiler), but now I have to bootstrap everything. And then the bootstrap turns out not to be 100% compatible with the compiler sources, libraries, some little detail in m3tk, ... Another way of saying this is "Isn't CM3 way overdue for a 'release'?" Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Thu Apr 2 02:03:47 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 1 Apr 2009 17:03:47 -0700 (PDT) Subject: [M3devel] new cm3 release (was: Help finding CM3 compiler for Linux?) In-Reply-To: <49D3BAD7.1E75.00D7.1@scires.com> Message-ID: <903288.9641.qm@web24714.mail.ird.yahoo.com> Hey what a port of the tinderbox to Obliq, in that way, we could allow the system to test and report hosted on itself and get a hand from the M3 runtime capabilities, network objects and pretty staff (GUIs included, it could allow even to test directly from the Obliq interpreter without recompiling nothing, just using M3 runtime), however depending on M3 runtime I don't know is that is the idea, I think it makes sense since it's supposed to be a M3 system in the platform to be tested and reported. If the test failed there should be a lastok obliq script and runtime that worked so it can be in any case reported on the status web page. With CM3-IDE we could also create a Link from the Initial web page to see the status locally and get or send reported status more easily integrated? Oh, I would like to help but still I haven't checked the latest versions of the complete system, I still want to wait to have all server services running on Elego.de (thanks all there cvs is running) but we can think meanwhile on it. Thanks in advance --- El mi?, 1/4/09, Randy Coleburn escribi?: De: Randy Coleburn Asunto: [M3devel] new cm3 release (was: Help finding CM3 compiler for Linux?) Para: m3devel at elegosoft.com Fecha: mi?rcoles, 1 abril, 2009 6:05 I agree about needing a new release. ? I suppose there is some value in maintaining a MINimal size binary distribution, but I think it would also nice to also provide a FULL distribution with everything pre-built.? (Of course, this will eat up more space on elego machines.) ? I have ready access to Windows XP (32-bit and 64-bit) and Vista platforms.? I would be glad to build and supply the distros for these platforms. ? Suggest we agree upon a plan and a timeframe. a.? make a tag or something in CVS that marks what will comprise the official sources for the release b.? agree upon distribution format (platform naming conventions, compressed archive format for MIN and FULL variants) c.? get a list of who is going to supply distros for which platforms d.? establish procedure for how the distros will be uploaded to elego e.? set a date for contributors to have the distros uploaded f.? have someone put together the web page showing links to all the distros along with updated installation instructions ? One sticky issue in the past has been target location.? If we unpack a distro and put it in a different place in the filesystem tree, we don't want it to break.? I know that cminstall attempted to adjust the cm3.cfg file to deal with location differences.? Do we need/want to build an installer program or script to deal with this issue, perhaps even adjusting cminstall will suffice?? Or, do we give a set of instructions on which file(s) to edit when moving the install location? ? For Windows, I don't mind building an installer.? Perhaps the installer could let you choose whether to install the MIN or the FULL version. ? Also, I think the Tinderbox has been great, but perhaps it can be improved.? I know I would like to see testing for Windows platforms added.? I have an XP computer I can pretty much dedicate to this task.? The problem is that I tried with Olaf's help to get it working, but there were too many dependencies on unix-type shell/script environment, and trying to force fit into cygwin didn't work well for the native Win32 implementation.? Thoughts? ? Regards, Randy >>> Mika Nystrom 4/1/2009 6:25 PM >>> Actually I think that the thing that has caused me the most problems in the past is that the -min and the -src-all get out of sync, since the binary bootstrapping dists are often not distributed (for size reasons?) with full source archives from exactly the same date.? So when you try to build src-all with the binary bootstrap, something goes wrong.? It's the whole... ok I need a binary install (since it's a real compiler), but now I have to bootstrap everything.? And then the bootstrap turns out not to be 100% compatible with the compiler sources, libraries, some little detail in m3tk, ... Another way of saying this is "Isn't CM3 way overdue for a 'release'?" ??? Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Apr 2 08:57:54 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 02 Apr 2009 08:57:54 +0200 Subject: [M3devel] new cm3 release (was: Help finding CM3 compiler for Linux?) In-Reply-To: <49D3BAD7.1E75.00D7.1@scires.com> References: Your message of "Wed, 01 Apr 2009 20:51:22 -0000." <200904012225.n31MPPDd007216@camembert.async.caltech.edu> <49D3BAD7.1E75.00D7.1@scires.com> Message-ID: <20090402085754.wpgiv2sgg800c0c4@mail.elegosoft.com> Quoting Randy Coleburn : > I agree about needing a new release. I suggested a new release twice within the recent two years, but nobody seemed to really support that idea. I never got round to do the work myself. > I suppose there is some value in maintaining a MINimal size binary > distribution, but I think it would also nice to also provide a FULL > distribution with everything pre-built. (Of course, this will eat > up more space on elego machines.) That should be no problem. As for archive size, I think disk sizes and transfer rates have changed much in recent years. We could easily provide full distribution archives in binary form. For those who just want the compiler, I'd suggest something of the size of the core set as defined in the script. > I have ready access to Windows XP (32-bit and 64-bit) and Vista > platforms. I would be glad to build and supply the distros for > these platforms. Great. > Suggest we agree upon a plan and a timeframe. > a. make a tag or something in CVS that marks what will comprise the > official sources for the release I can take over the CVS and pinging work, if everybody agrees. I won't have time to actually build and test all distributions. > b. agree upon distribution format (platform naming conventions, > compressed archive format for MIN and FULL variants) I'd suggest a switch to the complete binary archive format; but we need to automate and document the process. probably Jay has already done most of it, but I haven't tested it. > c. get a list of who is going to supply distros for which platforms Elego can provide FreeBSD 6.X and Linux on AMD64 easily. > d. establish procedure for how the distros will be uploaded to elego We should simply start by collecting release candidates in the uploaded-archives section of the server. We can use a naming scheme to separate these from other archives (cm3-*-*5.7.1-rc[1-9]?). > e. set a date for contributors to have the distros uploaded > f. have someone put together the web page showing links to all the > distros along with updated installation instructions I can do that, too, if you like. > One sticky issue in the past has been target location. If we unpack > a distro and put it in a different place in the filesystem tree, we > don't want it to break. I know that cminstall attempted to adjust > the cm3.cfg file to deal with location differences. Do we need/want > to build an installer program or script to deal with this issue, > perhaps even adjusting cminstall will suffice? Or, do we give a set > of instructions on which file(s) to edit when moving the install > location? I think Jay's archives can be easily relocated. > For Windows, I don't mind building an installer. Perhaps the > installer could let you choose whether to install the MIN or the > FULL version. > > Also, I think the Tinderbox has been great, but perhaps it can be > improved. I know I would like to see testing for Windows platforms > added. I have an XP computer I can pretty much dedicate to this > task. The problem is that I tried with Olaf's help to get it > working, but there were too many dependencies on unix-type > shell/script environment, and trying to force fit into cygwin didn't > work well for the native Win32 implementation. Thoughts? I had working most of it, but then got lost in other work again, and the virtual machine I used was so slow (and tended to crash :-/) We need to start again from where I stopped. > Regards, > Randy > >>>> Mika Nystrom 4/1/2009 6:25 PM >>> > > Actually I think that the thing that has caused me the most problems > in the past is that the -min and the -src-all get out of sync, since > the binary bootstrapping dists are often not distributed (for size > reasons?) with full source archives from exactly the same date. So > when you try to build src-all with the binary bootstrap, something > goes wrong. It's the whole... ok I need a binary install (since > it's a real compiler), but now I have to bootstrap everything. And > then the bootstrap turns out not to be 100% compatible with the > compiler sources, libraries, some little detail in m3tk, ... If you are happy with just overwriting everything existing, it should be no problem to switch to full binary archives. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 3 13:03:56 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 3 Apr 2009 11:03:56 +0000 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: <200904012225.n31MPPDd007216@camembert.async.caltech.edu> References: Your message of "Wed, 01 Apr 2009 20:51:22 -0000." <200904012225.n31MPPDd007216@camembert.async.caltech.edu> Message-ID: "Good oops", I only just noticed that the older releases only had "min binary" and "std src". I thought they had both min and std binary for users to chose from, and I was following suit. (noticed this 'cause I want to try old Solaris/PPC_DARWIN see when the formsedit crash came in; it's still there) - Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Wed, 1 Apr 2009 15:25:25 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Help finding CM3 compiler for Linux? > > > Actually I think that the thing that has caused me the most problems > in the past is that the -min and the -src-all get out of sync, since > the binary bootstrapping dists are often not distributed (for size > reasons?) with full source archives from exactly the same date. So > when you try to build src-all with the binary bootstrap, something > goes wrong. It's the whole... ok I need a binary install (since > it's a real compiler), but now I have to bootstrap everything. And > then the bootstrap turns out not to be 100% compatible with the > compiler sources, libraries, some little detail in m3tk, ... > > Another way of saying this is "Isn't CM3 way overdue for a 'release'?" > > Mika > > Jay writes: >> >>Thank you Mika. There is a cm3.cfg file, but it had a small bug. >> Actually if you look the cm3.cfg file was probably a mere one line that includes LINUXLIBC6. That is probably overly confusing for anyone trying to understand how it works. >> >>If you repeat the experiment with the 5.7.1 archives you should find it easier. >> The not easy cheat is to take cm3cfg.common from current source tree. >> >>If you repeat it with a NOT yet existing archive that I have in mind, even easier, however not for all platforms -- i.e. no need to set LD_LIBRARY_PATH, on platforms that support $ORIGIN, but again, not yet. >>NT386 is already easy this way, since the .dlls are in the bin directory and that is searched; that is NT386-specific. >> >>I also need to get m3gdb and cm3ide into it. >> >>> It seems to me it would be quite easy to package this up, maybe even >>> with cminstall? That would be easiest I think, to cminstall the whole >> >>I deliberately don't. >>I find cminstall not very worthwhile. >>Try the 5.7.1 archive and see what you think? >> >>What you are saying I guess is you like the "one level archive" instead of the usual "two level". Agreed. One level can be easily achieved and have cminstall do a copy instead of untargz. But I also find cmin >>stall not all that worthwhile (as I've said..). >> >> >> - Jay >> >>---------------------------------------- >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >>> Date: Wed, 1 Apr 2009 09:59:45 -0700 >>> From: mika at async.caltech.edu >>> >>> >>> I have to say that once I figured out what I needed to do, using >>> Jay's distributions was easy---easier than I'm used to with CM3. >>> >>> All I had to do was: untar the -std dist (forget the min one). >>> >>> Set PATH and LD_LIBRARY_PATH >>> >>> And then---the mysterious part, which takes more than passing knowledge >>> of how CM3 works---providing a cm3.cfg file, which doesn't seem to be >>> provided at all by Jay's archive. >>> >>> It seems to me it would be quite easy to package this up, maybe even >>> with cminstall? That would be easiest I think, to cminstall the whole >>> dist rather than cminstalling just the -min and then making people build >>> their own compiler, libraries, and demo apps... >>> >>> Mika >>> >>> Jay writes: >>>>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_ >>>>Content-Type: text/plain; charset="iso-8859-1" >>>>Content-Transfer-Encoding: quoted-printable >>>> >>>> >>>>Olaf=2C in the LINUXLIBC6 configuration=2C try putting --32 on the as/gas i= >>>>nvocations. >>>> >>>>You mentioned --32 on cm3=2C but I wonder if you meant -m32 on cm3. >>>> >>>> cm3 -m32=20 >>>> >>>> as --32=20 >>>> >>>>=20 >>>> >>>>or check the man pages or help. They aren't consistent=2C for more reasons = >>>>than shown here (e.g. MIPS has -mabi64=2C and I think AIX has something els= >>>>e=2C and HP-UX gcc supports none of these -- no bi-arch support). >>>> >>>>=20 >>>> >>>>> probably be easiest to use a real 32 bit system and start from 5.4.0 >>>>> again. >>>> >>>> >>>>Using any current system should be plenty easy too. >>>> >>>>e.g. the distributions I put up. :) >>>> >>>>=20 >>>> >>>>AMD64_LINUX should be a good starting point=2C but I haven't tried it in a = >>>>bit. >>>> >>>>=20 >>>> >>>>I should be able to build a current LINUXLIBC6 very very soon. >>>> >>>>I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test= >>>> a switch to the "new" Unix *.i3 files. >>>> >>>>=20 >>>> >>>>I'll be using python/make-dist.py though. >>>> >>>>I do need to get more packages into it though=2C e.g. cm3ide and m3gdb. >>>> >>>>=20 >>>> >>>> - Jay >>>>=20 >>>>> Date: Wed=2C 1 Apr 2009 11:11:53 +0200 >>>>> From: wagner at elegosoft.com >>>>> To: m3devel at elegosoft.com >>>>> CC: mand at elego.de=3B m3-support at elego.de >>>>> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >>>>>=20 >>>>> Quoting Mika Nystrom : >>>>>=20 >>>>>> >>>>>> Is there any documentation for this format beyond what you just >>>>>> wrote? Where? >>>>>=20 >>>>> Well=2C yes=2C that's the problem with these kinds of archives: >>>>>=20 >>>>> (1) they're not well tested and >>>>> (2) there's no documentation user's can rely on >>>>>=20 >>>>> This doesn't mean that I disapprove or want to criticise the contributors= >>>>=2C >>>>> but an official well-documented release with installation notes etc. >>>>> has some advantages. Unfortunately=2C the official releases are really >>>>> outdated now. >>>>>=20 >>>>> I succeeded in building current AMD64_LINUX and FreeBSD4 installations >>>>> on our servers for d5.7.1 tonight and was able to build archives for >>>>> FreeBSD binaries and sources=2C but the tooling failed for AMD64_KINUX >>>>> due to changed and missing configuration files. I'll need to have a >>>>> closer look at that=2C some extensions seem to be needed. Anybody who >>>>> feels he can do that faster than me is of course encouraged (I'll have >>>>> little time as usual :-/). >>>>>=20 >>>>> It may also turn out to be difficult to produce LINUXLIBC6 binaries=2C >>>>> as birch and other Elego servers are now 64 bit machines=2C and trying >>>>> to use current CM3 with --32 produced lots of assembler errors about >>>>> unsupported instructions on this architecture. As the old installation >>>>> on birch seems to be gone without a chance of being restored=2C it will >>>>> probably be easiest to use a real 32 bit system and start from 5.4.0 >>>>> again. >>>>>=20 >>>>> Anybody who wants to help should be able to build the binary >>>>> archives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh >>>>> easily and upload them to birch at >>>>>=20 >>>>> /var/www/modula3.elegosoft.com/cm3/uploaded-archives >>>>>=20 >>>>> My guess is that tinderbox will take some time to run smoothly again=2C >>>>> as it was highly customized=2C and I'm not sure if these customizations >>>>> survied the crash. >>>>>=20 >>>>> Please stay tuned and thanks for all your patience=2C >>>>>=20 >>>>> Olaf >>>>> --=20 >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 9= >>>>5 >>>>> http://www.elegosoft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berli= >>>>n >>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214= >>>>194 >>>>>=20 >>>> >>>>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_ >>>>Content-Type: text/html; charset="iso-8859-1" >>>>Content-Transfer-Encoding: quoted-printable >>>> >>>> >>>> >>>> >> >> >>>> >>>> >>>>Olaf=2C in the LINUXLIBC6 configuration=2C try putting --32 on the as/gas i= >>>>nvocations. >> >>>>You mentioned --32 on cm3=2C but I wonder if you meant -m32 on cm3. >> >>>> =3Bcm3 -m32 >> >>>> =3Bas --32 >> >>>> =3B >> >>>>or check the man pages or help. They aren't consistent=2C for more reasons = >>>>than shown here (e.g. MIPS has -mabi64=2C and I think AIX has something els= >>>>e=2C and HP-UX gcc supports none of these -- no bi-arch support). >> >>>> =3B >> >>>> =3B>=3B probably be easiest to use a real 32 bit system and start fr= >>>>om 5.4.0 >> =3B>=3B again. >> >> >>>>Using any current system should be plenty easy too. >> >>>>e.g. the distributions I put up. :) >> >>>> =3B >> >>>>AMD64_LINUX should be a good starting point=2C but I haven't tried it in a = >>>>bit. >> >>>> =3B >> >>>>I should be able to build a current LINUXLIBC6 very very soon. >> >>>>I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test= >>>> a switch to the "new" Unix *.i3 files. >> >>>> =3B >> >>>>I'll be using python/make-dist.py though. >> >>>>I do need to get more packages into it though=2C e.g. cm3ide and m3gdb. >> >>>> =3B >> >>>> =3B- Jay >> =3B >>>=3B Date: Wed=2C 1 Apr 2009 11:11:53 +0200<= >>>>BR>>=3B From: wagner at elegosoft.com >>>=3B To: m3devel at elegosoft.com>>>>=3B CC: mand at elego.de=3B m3-support at elego.de >>>=3B Subject: Re: [M3= >>>>devel] Help finding CM3 compiler for Linux? >>>=3B >>>=3B Quoting Mi= >>>>ka Nystrom <=3Bmika at async.caltech.edu>=3B: >>>=3B >>>=3B>=3B<= >>>>BR>>=3B>=3B Is there any documentation for this format beyond what you= >>>> just >>>=3B>=3B wrote? Where? >>>=3B >>>=3B Well=2C yes=2C th= >>>>at's the problem with these kinds of archives: >>>=3B >>>=3B (1) the= >>>>y're not well tested and >>>=3B (2) there's no documentation user's can = >>>>rely on >>>=3B >>>=3B This doesn't mean that I disapprove or want to= >>>> criticise the contributors=2C >>>=3B but an official well-documented re= >>>>lease with installation notes etc. >>>=3B has some advantages. Unfortuna= >>>>tely=2C the official releases are really >>>=3B outdated now. >>>=3B = >>>> >>>=3B I succeeded in building current AMD64_LINUX and FreeBSD4 install= >>>>ations >>>=3B on our servers for d5.7.1 tonight and was able to build ar= >>>>chives for >>>=3B FreeBSD binaries and sources=2C but the tooling failed= >>>> for AMD64_KINUX >>>=3B due to changed and missing configuration files. = >>> I'll need to have a >>>=3B closer look at that=2C some extensions seem t= >>>>o be needed. Anybody who >>>=3B feels he can do that faster than me is o= >>>>f course encouraged (I'll have >>>=3B little time as usual :-/). >>>= >>>>=3B >>>=3B It may also turn out to be difficult to produce LINUXLIBC6 b= >>>>inaries=2C >>>=3B as birch and other Elego servers are now 64 bit machin= >>>>es=2C and trying >>>=3B to use current CM3 with --32 produced lots of as= >>>>sembler errors about >>>=3B unsupported instructions on this architectur= >>>>e. As the old installation >>>=3B on birch seems to be gone without a ch= >>>>ance of being restored=2C it will >>>=3B probably be easiest to use a re= >>>>al 32 bit system and start from 5.4.0 >>>=3B again. >>>=3B >>>=3B= >>>> Anybody who wants to help should be able to build the binary >>>=3B arc= >>>>hives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh >>>=3B easily = >>>>and upload them to birch at >>>=3B >>>=3B /var/www/modula3.elegosoft= >>>>.com/cm3/uploaded-archives >>>=3B >>>=3B My guess is that tinderbox = >>>>will take some time to run smoothly again=2C >>>=3B as it was highly cus= >>>>tomized=2C and I'm not sure if these customizations >>>=3B survied the c= >>>>rash. >>>=3B >>>=3B Please stay tuned and thanks for all your patien= >>>>ce=2C >>>=3B >>>=3B Olaf >>>=3B -- >>>=3B Olaf Wagner -- eleg= >>>>o Software Solutions GmbH >>>=3B Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C= >>>> 13355 Berlin=2C Germany >>>=3B phone: +49 30 23 45 86 96 mobile: +49 17= >>>>7 2345 869 fax: +49 30 23 45 86 95 >>>=3B http://www.elegosoft.com | Ges= >>>>ch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berlin >>>=3B Handelregister: Amts= >>>>gericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>>=3B >>>>dy> >>>>= >>>> >>>>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_-- From jay.krell at cornell.edu Sun Apr 5 14:56:07 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 5 Apr 2009 12:56:07 +0000 Subject: [M3devel] runpath/unshipped vs. shipped binaries Message-ID: Hey..I have a crazy notion that maybe "ship" should first "relink". I've seen this thing..when I watch thw grass grow..I mean autoconf output run.. "how to embed full paths upon install"..."relink"... on some systems.. and I think..geez..what a waste, instead of just copying files, first they get relinked. Now..I find myself wanting something this and it seems maybe only this can provide. Let's limit discusion to Linux for now. These issues are not unique to it. But the area is full of confusing variables enough. When I build a "regular" build, historically, on Linux, binaries have a big bunch of paths run together in them, like: /cm3/pkg/m3core/AMD64_LINUX:/cm3/pkg/libm3/AMD64_LINUX:etc. Maybe maybe each one directory is associated with each one library, though I don't think so. This is called the "run path" and is where dependent shared libraries are sought, among other places. $LD_LIBRARY_PATH is another place but there is some general vague intent that "real" binaries shouldn't depend on that, that it is only for "ad hoc development mode". These full paths are specific to my machine. Other people might have /usr/local/cm3/pkg. Or whatever. Now, today I have made things a bit better. The first path is $ORIGIN/../lib. $ORIGIN is a special syntax for "The directory with the executable". That really is not a sufficient mechanism, but it is a small step forwarder. YOu want relativity from the referencing file, not just the executable. Or something more abstract not dealing with paths at all.. Now, when I make a distribution, I build everything in /tmp/tmprandom. These paths are in the binaries produce. Possibly preceded by $ORIGIN/../lib, but still, I'd rather not "infect" the binaries with these paths. Now, we also run binaries before they are installed -- PklFonts in particular. And user should be expected to be able to run uninstalled binaries. SO long story long... I suggest relink immediately prior to "ship". But this link will omit the bulk of -Wl,-rpath chunks, leaving only the -Wl,-rpath $ORIGIN/../lib. Thoughts? My "research" so far only applies to Linux. Maybe the prepending of $ORIGIN/../lib is enough mitigation. It does bug me though that if you move the binaries around such that ../lib is not correct, and you happen to have the same /tmp/tmprandom/... on your system that I had..very unlikely I realize.. that you will "unintentionally" load the "wrong" file. I'm not super keen on making these changes either..actually digging through and changing all the relevant Modula-3.... Other options include something like the M3_NEED_STANDALONE_LINKS option. Or maybe this is kind of novel/clever/reasonable, always building standalone and shared, standlone named plain "foo", shared/dynamic named "foo.dynamic", and have ship install the dynamic one, built with just -Wl,-rpath,$ORIGIN? This would waste a lot of time and diskspace for rarely used files though. Well, duh, a little less wasteful, when building dynamic, build two versions, both dynamic, one with the one small rpath, one with the usual larger one? This is easier. However if you assume a high build/run/debug to it works/install ratio, this is also wasteful. I come back to the original -- relink upon ship. Again, I'm not super excited to do this work, but it really does seem like the right thing. More generally, if you think about systems that don't support $ORIGIN and you think about some of the Modula-3 distribution formats, relinkin during setup/install of a "distribution" is also a good albeit onerous idea. There's this general theme around "how much of the build occurs on one machine vs. the machine the binaries will run on" and "stopping the build near the end, and finishing it later on another machine". - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 5 14:59:24 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 5 Apr 2009 12:59:24 +0000 Subject: [M3devel] some new archives -- AMD64_LINUX and PPC_DARWIN Message-ID: some new archives I put up PPC_DARWIN and AMD64_LINUX binaries on http://modula3.elegosoft.com/cm3/uploaded-archives. PPC_DARWIN still has the usually crashing formsvbt. I've started building Solaris 5.4 locally to see if it has the bug and then will proceed from there... AMD64_LINUX has paths like /tmp/tmprandom, and $ORIGIN/../lib in it, as mentioned in my other mail. AMD64_LINUX built easily starting with the earlier archives there. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.m.bates at cox.net Mon Apr 6 03:45:15 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Sun, 05 Apr 2009 20:45:15 -0500 Subject: [M3devel] small objects In-Reply-To: References: <200903300333.n2U3XBME062502@camembert.async.caltech.edu> Message-ID: <49D95EAB.8020802@cox.net> I spent quite a bit of time playing with a more general system where there is a set of "tagged" types, with (an implementation-defined subrange of) INTEGER and a reference type both being a subtype of a tagged type. It might have been tolerable, if it weren't for the interaction with object subtypes and opaque types, which quickly gets deep into a deep linguistic tar pit. Tony's approach is much simpler and would serve what I see as the need. It does sacrifice any static checking of what reference type is being tagged, and will also require an extra runtime ISTYPE/TYPECASE. Would INTEGER and REFANY be assignable to TAGGED, or would there also need to be an explicit conversion in that direction too, say VAL(x, TAGGED)? I think I favor the explicit conversion here. It is a bit inconsistent with the usual Modula-3 assignability philosophy, but not requiring the explicit conversion already gets your toes into tar. We would have to have something more like ISTYPE, though, which will tell which type the value belongs to without risking a runtime error, which VAL would do. An intermediate approach might be to have a set of tagged types constructed by, say, TAGGED T, where I is a reference type, but with no subtype relations on them at all, thus still requiring the explicit conversions and checks. I do want to say, I _really_ want this capability somehow. I have an ADT module whose internal data structure, for full generality, needs to have two heap objects (the second because it has nonstatic size) and 11 total words counting the orginal pointer, in the case of values that would fit directly into the "pointer" word. Moreover, these small cases are in the great majority. Besides the 11-to-one increase in actual occupied space, there is extra time for allocation, periodic tracing, and collection, space loss due to heap fragmentation, and time/space tradeoff loss due to reduced locality of reference. So sometimes, it would be a big performance gain if we could do it. Tony Hosking wrote: > It is a much more pervasive hack than I would be comfortable with > since it touches on the compiler (for all the type operations) as well > as the run-time system in ways that are pretty gross. I would much > rather have a new TAGGED builtin. ISTYPE would not work on it since > that only works on references. The only thing you need is a way to > extract the value -- we could overload VAL(x, T) where x can be a > TAGGED and T can be REFANY or INTEGER. > > From carson at taltos.org Mon Apr 6 05:17:02 2009 From: carson at taltos.org (Carson Gaspar) Date: Sun, 05 Apr 2009 20:17:02 -0700 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: References: Message-ID: <49D9742E.6080100@taltos.org> Jay wrote: ... > When I build a "regular" build, historically, on Linux, > binaries have a big bunch of paths run together in them, like: > > > /cm3/pkg/m3core/AMD64_LINUX:/cm3/pkg/libm3/AMD64_LINUX:etc. ... > Now, today I have made things a bit better. > > > The first path is $ORIGIN/../lib. > $ORIGIN is a special syntax for "The directory with the executable". > That really is not a sufficient mechanism, but it is a small step forwarder. > YOu want relativity from the referencing file, not just the executable. > Or something more abstract not dealing with paths at all.. If you're saying that today you produce binaries with an RPATH of: $ORIGIN/../lib:/cm3/pkg/m3core/AMD64_LINUX:... That's just... horrid. Assuming all of your libraries are in ${exe_path}/../lib, you need exactly one RPATH entry: $ORIGIN/../lib Get rid of _all_ the other "-R foo" link arguments, and all will be well. No need to relink if you link properly the first time. -- Carson From jay.krell at cornell.edu Mon Apr 6 06:23:14 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 6 Apr 2009 04:23:14 +0000 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: <49D9742E.6080100@taltos.org> References: <49D9742E.6080100@taltos.org> Message-ID: - The horrid RPATH is not my doing. It has "always" been that way. - The horrid RPATH is needed, for running not installed binaries, a very real scenario, - Jay ---------------------------------------- > Date: Sun, 5 Apr 2009 20:17:02 -0700 > From: carson at taltos.org > To: m3devel at elegosoft.com > Subject: Re: [M3devel] runpath/unshipped vs. shipped binaries > > Jay wrote: > ... >> When I build a "regular" build, historically, on Linux, >> binaries have a big bunch of paths run together in them, like: >> >> >> /cm3/pkg/m3core/AMD64_LINUX:/cm3/pkg/libm3/AMD64_LINUX:etc. > ... >> Now, today I have made things a bit better. >> >> >> The first path is $ORIGIN/../lib. >> $ORIGIN is a special syntax for "The directory with the executable". >> That really is not a sufficient mechanism, but it is a small step forwarder. >> YOu want relativity from the referencing file, not just the executable. >> Or something more abstract not dealing with paths at all.. > > If you're saying that today you produce binaries with an RPATH of: > > $ORIGIN/../lib:/cm3/pkg/m3core/AMD64_LINUX:... > > That's just... horrid. > > Assuming all of your libraries are in ${exe_path}/../lib, you need > exactly one RPATH entry: > > $ORIGIN/../lib > > Get rid of _all_ the other "-R foo" link arguments, and all will be > well. No need to relink if you link properly the first time. > > -- > Carson From hosking at cs.purdue.edu Mon Apr 6 07:08:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 6 Apr 2009 15:08:29 +1000 Subject: [M3devel] small objects In-Reply-To: <49D95E70.6000004@wichita.edu> References: <200903300333.n2U3XBME062502@camembert.async.caltech.edu> <49D95E70.6000004@wichita.edu> Message-ID: <40B7AD71-FBDD-4321-837F-D294DD4A3D45@cs.purdue.edu> I like the notion of having a TAGGED INTEGER type that is a hybrid ordinal/reference. Subtyping rules for references would now be as follows: NULL <: REF T <: REFANY TAGGED INTEGER <: REF T <: REFANY ROOT <: REFANY NULL <: T OBJECT ... END <: T TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: REFANY, not T <: ADDRESS) Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference type. Values of TAGGED INTEGER are non-pointer values similar to the value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and NARROW(x, TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to ISTYPE(x, NULL), NARROW(x, NULL), and TYPECODE(NULL). Because TAGGED INTEGER is an ordinal we can extract the integer value it holds using ORD(x). Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED INTEGER). ***The only problem with this scheme is how to efficiently perform run- time tests for dereferencing NULL, and TAGGED INTEGER?*** So, here is a slightly less elegant alternative that is probably straightforward to implement. Introduce a separate TAGGED hierarchy. NULL <: REF T <: REFANY NULL <: UNTRACED REF T <: ADDRESS TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. ROOT <: REFANY TAGGED ROOT <: TAGGED REFANY NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED REFANY. This way, tagged references only need a run-time test for the tag on dereference (we can throw an "attempt to dereference TAGGED INTEGER" at run time, just like we throw "attempt to dereference NIL" for untagged references). This check can be a straightforward test of the low bit tag. Of course, the weird thing here is now that we don't have a single NULL value for TAGGED references --- we have multiple null values VAL(x, TAGGED INTEGER). Instead of asking "x == NIL" we must ask "ISTYPE(x, TAGGED INTEGER)". Of course, because TAGGED INTEGER is an ordinal, we can also perform the usual ordinal operations like INC(x), DEC(x), wherever x is typed TAGGED INTEGER. On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: > I spent quite a bit of time playing with a more general system where > there is a set of "tagged" types, with (an implementation-defined > subrange of) INTEGER and a reference type both being a subtype of a > tagged type. It might have been tolerable, if it weren't for the > interaction with object subtypes and opaque types, which quickly > gets deep into a deep linguistic tar pit. > > Tony's approach is much simpler and would serve what I see as the > need. It does sacrifice any static checking of what reference type > is being tagged, and will also require an extra runtime ISTYPE/ > TYPECASE. > > Would INTEGER and REFANY be assignable to TAGGED, or would there > also need to be an explicit conversion in that direction too, say > VAL(x, TAGGED)? I think I favor the explicit conversion here. It > is a bit inconsistent with the usual Modula-3 assignability > philosophy, > but not requiring the explicit conversion already gets your toes > into tar. > > We would have to have something more like ISTYPE, though, which will > tell which type the value belongs to without risking a runtime error, > which VAL would do. > > An intermediate approach might be to have a set of tagged types > constructed by, say, TAGGED T, where I is a reference type, but > with no subtype relations on them at all, thus still requiring > the explicit conversions and checks. > > I do want to say, I _really_ want this capability somehow. I have > an ADT module whose internal data structure, for full generality, > needs to have two heap objects (the second because it has nonstatic > size) and 11 total words counting the orginal pointer, in the case of > values that would fit directly into the "pointer" word. Moreover, > these small cases are in the great majority. > > Besides the 11-to-one increase in actual occupied space, there > is extra time for allocation, periodic tracing, and collection, space > loss due to heap fragmentation, and time/space tradeoff loss due to > reduced locality of reference. So sometimes, it would be a big > performance gain if we could do it. > > > Tony Hosking wrote: >> It is a much more pervasive hack than I would be comfortable with >> since it touches on the compiler (for all the type operations) as >> well >> as the run-time system in ways that are pretty gross. I would much >> rather have a new TAGGED builtin. ISTYPE would not work on it since >> that only works on references. The only thing you need is a way to >> extract the value -- we could overload VAL(x, T) where x can be a >> TAGGED and T can be REFANY or INTEGER. >> From jay.krell at cornell.edu Mon Apr 6 07:14:01 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 6 Apr 2009 05:14:01 +0000 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: <49D9742E.6080100@taltos.org> References: <49D9742E.6080100@taltos.org> Message-ID: Here's another point I just discovered...granted, I did say I was only talking about Linux..but on Solaris, I just learned about -s on ldd: ldd -s /cm3/bin/Juno find object=libm3.so.5; required by /home/jay/cm3/bin/../lib/libjuno-compiler.so.5 search path=/usr/local/lib (LD_LIBRARY_PATH) trying path=/usr/local/lib/libm3.so.5 search path=$ORIGIN/../lib:/cm3/pkg/juno-machine/SOLgnu:/cm3/pkg/libm3/SOLgnu:/cm3/pkg/m3core/SO Lgnu (RPATH from file /home/jay/cm3/bin/../lib/libjuno-compiler.so.5) trying path=/home/jay/cm3/pkg/juno-compiler/SOLgnu/../lib/libm3.so.5 trying path=/cm3/pkg/juno-machine/SOLgnu/libm3.so.5 trying path=/cm3/pkg/libm3/SOLgnu/libm3.so.5 find object=libm3core.so.5; required by /home/jay/cm3/bin/../lib/libjuno-compiler.so.5 search path=/usr/local/lib (LD_LIBRARY_PATH) trying path=/usr/local/lib/libm3core.so.5 search path=$ORIGIN/../lib:/cm3/pkg/juno-machine/SOLgnu:/cm3/pkg/libm3/SOLgnu:/cm3/pkg/m3core/SO Lgnu (RPATH from file /home/jay/cm3/bin/../lib/libjuno-compiler.so.5) trying path=/home/jay/cm3/pkg/juno-compiler/SOLgnu/../lib/libm3core.so.5 trying path=/cm3/pkg/juno-machine/SOLgnu/libm3core.so.5 Which shows us that $ORIGIN is not the executable, it is the referencing file. Could be ipmlemented to be "both", have it search both, but I don't think it is. This begs for another large change. Don't ship any /cm3/pkg/foo/platform/libfoo.so. Ship only /cm3/lib/libfoo.so The second is already a symlink to the first anyway. And then add $ORIGIN and $ORIGIN/../lib to RPATH. Heck -- might as well just shove it all into /cm3/bin and just use $ORIGIN, kind of like how NT works..ok, I know that last step wouldn't likely be popular and it isn't important -- keep lib and bin split. One of the qeustions is -- do we believe we have a "useful" "hierarchy", or the world is really kind of flat anyway, embrace it? Given that lib is full of symlinks into pkg, seems like flat is the case and the hierarchy just looks nice, at least for .so file placement (*.i3/*.m3/*.m3x/*.a files would remain asis). I also think there's an issue here that..the ship structure and source structure should perhaps have been kept in parallel. That might allow for relative rpaths to work for uninstalled or installed binaries. Except, the source structure has more hierarchy than the ship structure, always. That is, shipping is a rearrangement of the source structure -- insert "pkg" and flatten. src/m3-libs/m3core => install/pkg/m3core src/m3-foo/bar => install/pkg/bar If instead it went: src/m3-libs/m3core => install/m3-libs/m3core src/m3-foo/bar => install/m3-foo/bar or: src/m3-libs/m3core => install/pkg/m3-libs/m3core src/m3-foo/bar => install/pkg/m3-foo/bar Then relative paths could probably be used in both roots with the same meaning. But they can't. I come back to..I guess..removing all the .so files from the pkg store, or reversing the sense of the symlinks. Or heck, just telling the linker -L /cm3/lib instead of -L/cm3/pkg/foo. That last step might be trivial and helpful. I'll try it, later. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: carson at taltos.org; m3devel at elegosoft.com > Subject: RE: [M3devel] runpath/unshipped vs. shipped binaries > Date: Mon, 6 Apr 2009 04:23:14 +0000 > > > > - The horrid RPATH is not my doing. It has "always" been that way. > > - The horrid RPATH is needed, for running not installed binaries, a very real scenario, > > - Jay > > > > ---------------------------------------- >> Date: Sun, 5 Apr 2009 20:17:02 -0700 >> From: carson at taltos.org >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] runpath/unshipped vs. shipped binaries >> >> Jay wrote: >> ... >>> When I build a "regular" build, historically, on Linux, >>> binaries have a big bunch of paths run together in them, like: >>> >>> >>> /cm3/pkg/m3core/AMD64_LINUX:/cm3/pkg/libm3/AMD64_LINUX:etc. >> ... >>> Now, today I have made things a bit better. >>> >>> >>> The first path is $ORIGIN/../lib. >>> $ORIGIN is a special syntax for "The directory with the executable". >>> That really is not a sufficient mechanism, but it is a small step forwarder. >>> YOu want relativity from the referencing file, not just the executable. >>> Or something more abstract not dealing with paths at all.. >> >> If you're saying that today you produce binaries with an RPATH of: >> >> $ORIGIN/../lib:/cm3/pkg/m3core/AMD64_LINUX:... >> >> That's just... horrid. >> >> Assuming all of your libraries are in ${exe_path}/../lib, you need >> exactly one RPATH entry: >> >> $ORIGIN/../lib >> >> Get rid of _all_ the other "-R foo" link arguments, and all will be >> well. No need to relink if you link properly the first time. >> >> -- >> Carson From carson at taltos.org Mon Apr 6 08:54:00 2009 From: carson at taltos.org (Carson Gaspar) Date: Sun, 05 Apr 2009 23:54:00 -0700 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: References: <49D9742E.6080100@taltos.org> Message-ID: <49D9A708.1050101@taltos.org> Jay wrote: > > - The horrid RPATH is not my doing. It has "always" been that way. > > - The horrid RPATH is needed, for running not installed binaries, a very real scenario, No. It's not needed. Please provide a use case where a crappy polluted RPATH provides any benefit, and be specific. If you need to _temporarily_ run binaries in the build tree, where ${exe_path}/../lib does not contain libraries, set LD_LIBRARY_PATH (which overrides RPATH). Or, better still, fix the build to put things in $foo/bin and $foo/lib before you run them. Hard-coding /tmp/frobnitz/blah/lib in RPATH is _extremely_ bad from many perspectives, including security. Don't do it. No really, don't. -- Carson From carson at taltos.org Mon Apr 6 09:00:27 2009 From: carson at taltos.org (Carson Gaspar) Date: Mon, 06 Apr 2009 00:00:27 -0700 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: References: <49D9742E.6080100@taltos.org> Message-ID: <49D9A88B.4070109@taltos.org> Jay wrote: > Which shows us that $ORIGIN is not the executable, it is the referencing file. > Could be ipmlemented to be "both", have it search both, but I don't think it is. $ORIGIN is the location of the object being linked. That may be the executable, or may be a shared library. So if you have: foo.so bar.so, linked against foo.so baz.exe, linked against bar.so And RPATH for all of them is "$ORIGIN/../lib", when you execute baz.exe, it looks for bar.so in $path_to_baz/../lib/bar.so. It then looks for foo.so in $path_to_bar/../lib/foo.so. Note that this is _different_ from linking baz.exe _explicitly_ against foo.so, instead of _implicitly_ via bar.so. Make sure the RPATH you use when linking objects, whether they be executables or shared objects, is correct. -- Carson From jay.krell at cornell.edu Mon Apr 6 10:08:50 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 6 Apr 2009 08:08:50 +0000 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: <49D9A708.1050101@taltos.org> References: <49D9742E.6080100@taltos.org> <49D9A708.1050101@taltos.org> Message-ID: Well, the big polluted runpath is how Modula-3 has always built things. The only reason for /tmp/tmprandom is because I build up an entire new install from scratch. Otherwise it would be /usr/local/cm3/pkg/... or such. If you look at the distributions Olaf has put out you can see he does similar. I think the Tinderbox builds are the same. This is tied up in the Quake code: M3_SPLIT_LIBNAMES = TRUE % --- split library names and pass -L/-l arguments to the linker if not defined("M3_SHARED_LIB_ARG") M3_SHARED_LIB_ARG = "-Wl,-R" end plus the fact that "install" is very interested in a "package store" and each set of files going in their own directory, and "imported libraries" coming from there, not a flattened /cm3/lib. I'm not sure I like it either, but it has been this way. Running uninstalled binaries seems very reasonable to me, and is also a long standing practise in the cm3 system, but maybe only one instance. I'm trying to find a way to - have a small portable runpath - allow uninstalled binaries to work but I think you might be right that LD_LIBRARY_PATH is how to get the second scenario to work. But that does require LD_LIBRARY_PATH be set within making a distribution. Or maybe just build PklFonts standalone, or ship it and then run it. Standalone is easiest. But this is really tying people's hands it seems, in terms of how much uninstalled binaries work. Maybe there should be an option to install .sos to /usr/lib so LD_LIBRARY_PATH can be left alone? I'm still looking into it all though. Could be that -L/cm3/pkg/foo -lfoo is fine, as long as the -R is dropped. I'll have to check that the full path to libfoo.so isn't recorded, but just the leaf libfoo.so. I guess for .so files we can use rpath like $ORIGIN/../../../lib. Where the ".." are backing up over pkg/package/platform to get back to root. - Jay ---------------------------------------- > Date: Sun, 5 Apr 2009 23:54:00 -0700 > From: carson at taltos.org > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] runpath/unshipped vs. shipped binaries > > Jay wrote: >> >> - The horrid RPATH is not my doing. It has "always" been that way. >> >> - The horrid RPATH is needed, for running not installed binaries, a very real scenario, > > No. It's not needed. Please provide a use case where a crappy polluted > RPATH provides any benefit, and be specific. > > If you need to _temporarily_ run binaries in the build tree, where > ${exe_path}/../lib does not contain libraries, set LD_LIBRARY_PATH > (which overrides RPATH). Or, better still, fix the build to put things > in $foo/bin and $foo/lib before you run them. > > Hard-coding /tmp/frobnitz/blah/lib in RPATH is _extremely_ bad from many > perspectives, including security. Don't do it. No really, don't. > > -- > Carson From carson at taltos.org Mon Apr 6 10:35:42 2009 From: carson at taltos.org (Carson Gaspar) Date: Mon, 06 Apr 2009 01:35:42 -0700 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: References: <49D9742E.6080100@taltos.org> <49D9A708.1050101@taltos.org> Message-ID: <49D9BEDE.1010603@taltos.org> BTW, I'm glad you're working on this, I just want to make sure we end up someplace better ;-) Jay wrote: > Well, the big polluted runpath is how Modula-3 has always built > things. The only reason for /tmp/tmprandom is because I build up an > entire new install from scratch. Otherwise it would be > /usr/local/cm3/pkg/... or such. If you look at the distributions Olaf > has put out you can see he does similar. I think the Tinderbox builds > are the same. The problem with using /tmp is that _any_ user can throw their own .so's in there. Bogus /usr/... paths are still unfortunate, but not a security nightmare like /tmp/... paths are. It may be that re-organizing the build system to behave better is more work than you have time for at the moment, and throwing in a $ORIGIN RPATH isn't a bad thing even if you don't fix the rest. But please don't ship binaries with an RPATH containing /tmp - someone will hurt themselves. -- Carson From jay.krell at cornell.edu Mon Apr 6 10:37:24 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 6 Apr 2009 08:37:24 +0000 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: <49D9A708.1050101@taltos.org> References: <49D9742E.6080100@taltos.org> <49D9A708.1050101@taltos.org> Message-ID: ok, nevermind, thanks Carson, that helped. Like you said: RUNPATH shall be small and portable and just $ORIGIN/../lib. I saw $ORIGIN within pkg and not lib, but now I see it only within lib. Maybe a clean rebuild fixed that, not sure (I had been just deleting all the .a files). If it flips and becomes consistently pkg, I'll try ORIGIN/../../../lib. Too many dot dots seems bad, could be escaping some part of the file system into who-knows-where. I have an idea you could verify your location something like $ORIGIN/../../../pkg/package/platform/.../../../lib. The extra traversal "../../../pkg/package/platform" ensure things are kind of how you expect, though wasteful. Anyway, hopefully not this. Running uninstalled binaries shall require either LD_LIBRARY_PATH or build_standalone(). m3tests uses build_standalone. This is maybe why more stuff is build_standalone -- anything that runs uninstalled when doing buildlobal, the various stub code generators. Systems that don't support $ORIGIN, hopefully that is not many, such as NetBSD, will require LD_LIBRARY_PATH. Another option is to relink on the target and point at /cm3/lib or such, but that requires the notion of relinking on target, which is in limbo. No full path is likely to be baked into any binary, for any system. Darwin is different but achieves similar goals. I changed my configuration files for PPC_DARWIN. I don't have the other architectures available (hm, maybe non-OSX Darwin in a VM, maybe). NT386 is different but achieves similar goals. There all the .exes and .dlls are shipped to the same directory. .exe directories are generally searched for .dlls. A lot of this is still speculative. Solaris seems in good shape, and Darwin, but I have to look into others still. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: carson at taltos.org > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] runpath/unshipped vs. shipped binaries > Date: Mon, 6 Apr 2009 08:08:50 +0000 > > > Well, the big polluted runpath is how Modula-3 has always built things. > The only reason for /tmp/tmprandom is because I build up an entire new install from scratch. Otherwise it would be /usr/local/cm3/pkg/... or such. > If you look at the distributions Olaf has put out you can see he does similar. > I think the Tinderbox builds are the same. > > > This is tied up in the Quake code: > M3_SPLIT_LIBNAMES = TRUE > % --- split library names and pass -L/-l arguments to the linker > if not defined("M3_SHARED_LIB_ARG") > M3_SHARED_LIB_ARG = "-Wl,-R" > end > > plus the fact that "install" is very interested in a "package store" and each set of files going in their own directory, and "imported libraries" coming from there, not a flattened /cm3/lib. > > > I'm not sure I like it either, but it has been this way. > > Running uninstalled binaries seems very reasonable to me, and is also a long standing practise in the cm3 system, but maybe only one instance. > > > I'm trying to find a way to > - have a small portable runpath > - allow uninstalled binaries to work > > but I think you might be right that LD_LIBRARY_PATH is how to get the second scenario to work. But that does require LD_LIBRARY_PATH be set within making a distribution. Or maybe just build PklFonts standalone, or ship it and then run it. Standalone is easiest. > > But this is really tying people's hands it seems, in terms of how much uninstalled binaries work. Maybe there should be an option to install .sos to /usr/lib so LD_LIBRARY_PATH can be left alone? > > > I'm still looking into it all though. > Could be that -L/cm3/pkg/foo -lfoo is fine, as long as the -R is dropped. > I'll have to check that the full path to libfoo.so isn't recorded, but just the leaf libfoo.so. > > I guess for .so files we can use rpath like $ORIGIN/../../../lib. > Where the ".." are backing up over pkg/package/platform to get back to root. > > > > - Jay > > > ---------------------------------------- >> Date: Sun, 5 Apr 2009 23:54:00 -0700 >> From: carson at taltos.org >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] runpath/unshipped vs. shipped binaries >> >> Jay wrote: >>> >>> - The horrid RPATH is not my doing. It has "always" been that way. >>> >>> - The horrid RPATH is needed, for running not installed binaries, a very real scenario, >> >> No. It's not needed. Please provide a use case where a crappy polluted >> RPATH provides any benefit, and be specific. >> >> If you need to _temporarily_ run binaries in the build tree, where >> ${exe_path}/../lib does not contain libraries, set LD_LIBRARY_PATH >> (which overrides RPATH). Or, better still, fix the build to put things >> in $foo/bin and $foo/lib before you run them. >> >> Hard-coding /tmp/frobnitz/blah/lib in RPATH is _extremely_ bad from many >> perspectives, including security. Don't do it. No really, don't. >> >> -- >> Carson From jay.krell at cornell.edu Mon Apr 6 10:43:52 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 6 Apr 2009 08:43:52 +0000 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: <49D9BEDE.1010603@taltos.org> References: <49D9742E.6080100@taltos.org> <49D9A708.1050101@taltos.org> <49D9BEDE.1010603@taltos.org> Message-ID: Good point thanks, /usr/random better than /tmp/random. I'd build as root, so you are safe from non-root, or somesuch. Hopefully it'll become moot. I have made progress inserting $ORIGIN at the front already. I need to double check if that is /cm3/lib or /cm3/pkg/foo/linuxlibc6. Hopefully /cm3/lib. And then see about removing the rest. Solaris is looking good, at least. NetBSD doesn't support $origin. (but hey, my NetBSD machine is booted to FreeBSD currently, where, besides these issues, I want to switch to the new/small/portable Unix/*.i3 files :) ) Ok, Linux/x86 is looking good. Just a tad ugly, you end up with "../lib" for each level in the dependency tree: ldd -v /cm3/bin/Juno: libm3X11R4.so.5 => /home/jay/cm3/bin/../lib/../lib/libm3X11R4.so.5 but that's ok. Pray tell, what's the difference between RPATH and RUNPATH? objdump -f -x /cm3/bin/Juno Dynamic Section: NEEDED libjuno-compiler.so.5 NEEDED libjuno-machine.so.5 NEEDED libm3formsvbt.so.5 NEEDED libm3vbtkit.so.5 NEEDED libm3ui.so.5 NEEDED libm3netobj.so.5 NEEDED libm3.so.5 NEEDED libm3core.so.5 NEEDED libc.so.6 RPATH $ORIGIN/../lib RUNPATH $ORIGIN/../lib - Jay ---------------------------------------- > Date: Mon, 6 Apr 2009 01:35:42 -0700 > From: carson at taltos.org > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] runpath/unshipped vs. shipped binaries > > BTW, I'm glad you're working on this, I just want to make sure we end up > someplace better ;-) > > Jay wrote: >> Well, the big polluted runpath is how Modula-3 has always built >> things. The only reason for /tmp/tmprandom is because I build up an >> entire new install from scratch. Otherwise it would be >> /usr/local/cm3/pkg/... or such. If you look at the distributions Olaf >> has put out you can see he does similar. I think the Tinderbox builds >> are the same. > > The problem with using /tmp is that _any_ user can throw their own .so's > in there. Bogus /usr/... paths are still unfortunate, but not a security > nightmare like /tmp/... paths are. > > It may be that re-organizing the build system to behave better is more > work than you have time for at the moment, and throwing in a $ORIGIN > RPATH isn't a bad thing even if you don't fix the rest. But please don't > ship binaries with an RPATH containing /tmp - someone will hurt themselves. > > -- > Carson From carson at taltos.org Mon Apr 6 10:51:40 2009 From: carson at taltos.org (Carson Gaspar) Date: Mon, 06 Apr 2009 01:51:40 -0700 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: References: <49D9742E.6080100@taltos.org> <49D9A708.1050101@taltos.org> <49D9BEDE.1010603@taltos.org> Message-ID: <49D9C29C.9000404@taltos.org> Jay wrote: > Pray tell, what's the difference between RPATH and RUNPATH? > > objdump -f -x /cm3/bin/Juno > > Dynamic Section: > NEEDED libjuno-compiler.so.5 > NEEDED libjuno-machine.so.5 > NEEDED libm3formsvbt.so.5 > NEEDED libm3vbtkit.so.5 > NEEDED libm3ui.so.5 > NEEDED libm3netobj.so.5 > NEEDED libm3.so.5 > NEEDED libm3core.so.5 > NEEDED libc.so.6 > RPATH $ORIGIN/../lib > RUNPATH $ORIGIN/../lib AFAIK none. At least on Solaris they always point to the same string address. I suspect one is legacy and the other is ELF standard. -- Carson From jay.krell at cornell.edu Mon Apr 6 14:33:15 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 6 Apr 2009 12:33:15 +0000 Subject: [M3devel] some new archives -- AMD64_LINUX, PPC_DARWIN, NT386 Message-ID: NT386 now also. (This part is not difficult..) - Jay ________________________________ > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: some new archives -- AMD64_LINUX and PPC_DARWIN > Date: Sun, 5 Apr 2009 12:59:24 +0000 > > some new archives > > I put up PPC_DARWIN and AMD64_LINUX binaries on http://modula3.elegosoft.com/cm3/uploaded-archives. > > > PPC_DARWIN still has the usually crashing formsvbt. > I've started building Solaris 5.4 locally to see if it has the bug > > and then will proceed from there... > > > > AMD64_LINUX has paths like /tmp/tmprandom, and $ORIGIN/../lib in it, as mentioned > in my other mail. > > > AMD64_LINUX built easily starting with the earlier archives there. > > - Jay From wagner at elegosoft.com Mon Apr 6 14:42:42 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 06 Apr 2009 14:42:42 +0200 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: References: <49D9742E.6080100@taltos.org> <49D9A708.1050101@taltos.org> Message-ID: <20090406144242.almwq5chwgo04kwo@mail.elegosoft.com> Quoting Jay : > Running uninstalled binaries shall require either LD_LIBRARY_PATH > or build_standalone(). m3tests uses build_standalone. This is maybe > why more stuff is build_standalone -- anything that runs uninstalled > when doing buildlobal, the various stub code generators. Please just use build_standalone for all binaries that are needed by the build system itself. That shouldn't be many. Otherwise, I think setting LD_LIBRARY_PATH is acceptable. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Mon Apr 6 16:50:25 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 07:50:25 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Sun, 05 Apr 2009 20:45:15 CDT." <49D95EAB.8020802@cox.net> Message-ID: <200904061450.n36EoPk9085841@camembert.async.caltech.edu> Hi Rodney, I would like this capability too, but I am a bit wary of Tony's idea of changing the Modula-3 language---even in a "minor" way. I've been working for the last week or so on an application using the Modula-3 Toolkit, and I must say I have realized that the Modula-3 type system has a lot more subtleties than I thought. I would not want to make any real changes to it. There's a paper called "The Modula-3 Type System" by Cardelli, Donahue, Kalsow, and Nelson that is worth studying in detail before making any changes whatsoever, I think. Also remember that changes to the type system will affect m3tk and anything that depends on m3tk (which includes two or three stub generators in the main tree and who knows how many dependencies outside of it). I'm still not sure why we can't take the approach of Word.T . Make a RefanyOrInt.T that can safely be: 1. Tested whether it is a small integer or a REFANY 2. If a REFANY, be dereferenced as normal, *or* via RefanyOrInt.ToRefany 3. If a small integer, can be extracted via RefanyOrInt.ToInt 4. Created either as a small integer or a REFANY Any other operations on it (including ISTYPE and TYPECASE, at least when the object is a small integer) would result in a checked runtime error. Note that with the declaration "RefanyOrInt.T = REFANY", the current compiler will as far as I know not accept any operations on RefanyOrInt.T outside of ISTYPE, TYPECASE, and NARROW (explicit or implicit). I wouldn't be surprised if most of what I'm proposing already works (i.e., crashes with a checked runtime error as it should) with the current runtime. Anything that slips through would need to be fixed up with a one-bit check of the LSB of the REFANY for the operations mentioned above. Unfortunately this has to be done for operations on every REFANY, not just the new type. I think that Modula-3 programmers are already aware that using REFANYs involves forcing the runtime to do extra type-checking work, so they already know not to use them if they are looking for maximum performance, so I don't think that burdening operations on REFANY with an extra one-bit check is too onerous. An advantage of my proposal is that the amount of code in the new proposed library is truly diminutive. In fact, I think I posted pretty much that code to the list a few weeks ago. (If you missed it, it's http://www.async.caltech.edu/~mika/interp/ ) Mika "Rodney M. Bates" writes: >I spent quite a bit of time playing with a more general system where >there is a set of "tagged" types, with (an implementation-defined >subrange of) INTEGER and a reference type both being a subtype of a >tagged type. It might have been tolerable, if it weren't for the >interaction with object subtypes and opaque types, which quickly >gets deep into a deep linguistic tar pit. > >Tony's approach is much simpler and would serve what I see as the >need. It does sacrifice any static checking of what reference type >is being tagged, and will also require an extra runtime ISTYPE/TYPECASE. > >Would INTEGER and REFANY be assignable to TAGGED, or would there >also need to be an explicit conversion in that direction too, say >VAL(x, TAGGED)? I think I favor the explicit conversion here. It >is a bit inconsistent with the usual Modula-3 assignability philosophy, >but not requiring the explicit conversion already gets your toes into tar. > >We would have to have something more like ISTYPE, though, which will >tell which type the value belongs to without risking a runtime error, >which VAL would do. > >An intermediate approach might be to have a set of tagged types >constructed by, say, TAGGED T, where I is a reference type, but >with no subtype relations on them at all, thus still requiring >the explicit conversions and checks. > >I do want to say, I _really_ want this capability somehow. I have >an ADT module whose internal data structure, for full generality, >needs to have two heap objects (the second because it has nonstatic >size) and 11 total words counting the orginal pointer, in the case of >values that would fit directly into the "pointer" word. Moreover, >these small cases are in the great majority. > >Besides the 11-to-one increase in actual occupied space, there >is extra time for allocation, periodic tracing, and collection, space >loss due to heap fragmentation, and time/space tradeoff loss due to >reduced locality of reference. So sometimes, it would be a big >performance gain if we could do it. > > >Tony Hosking wrote: > It is a much more pervasive hack than I would be comfortable with >> since it touches on the compiler (for all the type operations) as well >> as the run-time system in ways that are pretty gross. I would much >> rather have a new TAGGED builtin. ISTYPE would not work on it since >> that only works on references. The only thing you need is a way to >> extract the value -- we could overload VAL(x, T) where x can be a >> TAGGED and T can be REFANY or INTEGER. >> >> From mika at async.caltech.edu Mon Apr 6 17:29:29 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 08:29:29 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Mon, 06 Apr 2009 15:08:29 +1000." <40B7AD71-FBDD-4321-837F-D294DD4A3D45@cs.purdue.edu> Message-ID: <200904061529.n36FTTn0086974@camembert.async.caltech.edu> Ah I should read my whole inbox before replying. I take it you would worry that in my proposal (to do this all in a library) the use of REFANY to store an integer could be abused somehow. That the Modula-3 type system (as it exists now) explicitly rules out doing such things, and therefore, a language change is necessary.... Mika Tony Hosking writes: >I like the notion of having a TAGGED INTEGER type that is a hybrid >ordinal/reference. > >Subtyping rules for references would now be as follows: > >NULL <: REF T <: REFANY >TAGGED INTEGER <: REF T <: REFANY > >ROOT <: REFANY >NULL <: T OBJECT ... END <: T >TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: REFANY, not >T <: ADDRESS) > >Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >type. Values of TAGGED INTEGER are non-pointer values similar to the >value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and NARROW(x, >TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to ISTYPE(x, >NULL), NARROW(x, NULL), and TYPECODE(NULL). > >Because TAGGED INTEGER is an ordinal we can extract the integer value >it holds using ORD(x). >Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >INTEGER). > >***The only problem with this scheme is how to efficiently perform run- >time tests for dereferencing NULL, and TAGGED INTEGER?*** > >So, here is a slightly less elegant alternative that is probably >straightforward to implement. Introduce a separate TAGGED hierarchy. > >NULL <: REF T <: REFANY >NULL <: UNTRACED REF T <: ADDRESS >TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY > >Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. > >ROOT <: REFANY >TAGGED ROOT <: TAGGED REFANY >NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY > >Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED >REFANY. > >This way, tagged references only need a run-time test for the tag on >dereference (we can throw an "attempt to dereference TAGGED INTEGER" >at run time, just like we throw "attempt to dereference NIL" for >untagged references). This check can be a straightforward test of the >low bit tag. Of course, the weird thing here is now that we don't >have a single NULL value for TAGGED references --- we have multiple >null values VAL(x, TAGGED INTEGER). Instead of asking "x == NIL" we >must ask "ISTYPE(x, TAGGED INTEGER)". > >Of course, because TAGGED INTEGER is an ordinal, we can also perform >the usual ordinal operations like INC(x), DEC(x), wherever x is typed >TAGGED INTEGER. > > >On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: > >> I spent quite a bit of time playing with a more general system where >> there is a set of "tagged" types, with (an implementation-defined >> subrange of) INTEGER and a reference type both being a subtype of a >> tagged type. It might have been tolerable, if it weren't for the >> interaction with object subtypes and opaque types, which quickly >> gets deep into a deep linguistic tar pit. >> >> Tony's approach is much simpler and would serve what I see as the >> need. It does sacrifice any static checking of what reference type >> is being tagged, and will also require an extra runtime ISTYPE/ >> TYPECASE. >> >> Would INTEGER and REFANY be assignable to TAGGED, or would there >> also need to be an explicit conversion in that direction too, say >> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >> is a bit inconsistent with the usual Modula-3 assignability >> philosophy, >> but not requiring the explicit conversion already gets your toes >> into tar. >> >> We would have to have something more like ISTYPE, though, which will >> tell which type the value belongs to without risking a runtime error, >> which VAL would do. >> >> An intermediate approach might be to have a set of tagged types >> constructed by, say, TAGGED T, where I is a reference type, but >> with no subtype relations on them at all, thus still requiring >> the explicit conversions and checks. >> >> I do want to say, I _really_ want this capability somehow. I have >> an ADT module whose internal data structure, for full generality, >> needs to have two heap objects (the second because it has nonstatic >> size) and 11 total words counting the orginal pointer, in the case of >> values that would fit directly into the "pointer" word. Moreover, >> these small cases are in the great majority. >> >> Besides the 11-to-one increase in actual occupied space, there >> is extra time for allocation, periodic tracing, and collection, space >> loss due to heap fragmentation, and time/space tradeoff loss due to >> reduced locality of reference. So sometimes, it would be a big >> performance gain if we could do it. >> >> >> Tony Hosking wrote: >>> It is a much more pervasive hack than I would be comfortable with >>> since it touches on the compiler (for all the type operations) as >>> well >>> as the run-time system in ways that are pretty gross. I would much >>> rather have a new TAGGED builtin. ISTYPE would not work on it since >>> that only works on references. The only thing you need is a way to >>> extract the value -- we could overload VAL(x, T) where x can be a >>> TAGGED and T can be REFANY or INTEGER. >>> From mika at async.caltech.edu Mon Apr 6 17:32:56 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 08:32:56 -0700 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: Your message of "Mon, 06 Apr 2009 14:42:42 +0200." <20090406144242.almwq5chwgo04kwo@mail.elegosoft.com> Message-ID: <200904061532.n36FWunc087102@camembert.async.caltech.edu> Would this mean that users of CM3 have to set LD_LIBRARY_PATH for things they build themselves but don't ship? I almost never ship binaries because I don't want user "mika" to have write access to the place whither the Modula-3 compiler normally ships. But I use them... from cron and other places. Other users may use them too... Mika Olaf Wagner writes: >Quoting Jay : > >> Running uninstalled binaries shall require either LD_LIBRARY_PATH >> or build_standalone(). m3tests uses build_standalone. This is maybe >> why more stuff is build_standalone -- anything that runs uninstalled >> when doing buildlobal, the various stub code generators. > >Please just use build_standalone for all binaries that are needed >by the build system itself. That shouldn't be many. > >Otherwise, I think setting LD_LIBRARY_PATH is acceptable. > >Olaf >-- >Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb??ude 12, 13355 Berlin, Germany >phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 6 17:51:19 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 06 Apr 2009 17:51:19 +0200 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: <200904061532.n36FWunc087102@camembert.async.caltech.edu> References: <200904061532.n36FWunc087102@camembert.async.caltech.edu> Message-ID: <20090406175119.5nknbzf9dwkcwkks@mail.elegosoft.com> Quoting Mika Nystrom : > > Would this mean that users of CM3 have to set LD_LIBRARY_PATH for > things they build themselves but don't ship? Probably. If the libraries cannot be located by the system in a standard path, it needs help. We could probably come up with a small script which prints the needed settings for a local M3 workspace. > I almost never ship binaries because I don't want user "mika" to > have write access to the place whither the Modula-3 compiler normally > ships. But I use them... from cron and other places. Other users > may use them too... Have you got a better suggestion? This is really not an M3 problem, but a general Unix question. How should dynamic shared object files be found (especially, when they are scattered across an M3 workspace)? If we burn in the local paths, we need to relink the objects before shipping. I also wouldn't like it when some installed program stops to work because the original creator made changes to his home directories... Any ideas? Olaf > Mika > > Olaf Wagner writes: >> Quoting Jay : >> >>> Running uninstalled binaries shall require either LD_LIBRARY_PATH >>> or build_standalone(). m3tests uses build_standalone. This is maybe >>> why more stuff is build_standalone -- anything that runs uninstalled >>> when doing buildlobal, the various stub code generators. >> >> Please just use build_standalone for all binaries that are needed >> by the build system itself. That shouldn't be many. >> >> Otherwise, I think setting LD_LIBRARY_PATH is acceptable. >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb??ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 mika at async.caltech.edu Mon Apr 6 19:12:55 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 10:12:55 -0700 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: Your message of "Mon, 06 Apr 2009 17:51:19 +0200." <20090406175119.5nknbzf9dwkcwkks@mail.elegosoft.com> Message-ID: <200904061712.n36HCtNO089745@camembert.async.caltech.edu> I think what Jay was trying to do sounds right. I think the binary should run without jumping through hoops if it hasn't been shipped. Once shipped it should not be possible to break it by fiddling around in the build directories. This does seem to imply that m3ship does something a bit more than "cp". I think it would be enough if it reordered the defaults, from "link with build tree first, /usr/local/lib second" to "link with /usr/local/lib first, build tree second" (or not at all build tree). Is it bad to have m3ship re-link? Mika Olaf Wagner writes: >Quoting Mika Nystrom : > >> >> Would this mean that users of CM3 have to set LD_LIBRARY_PATH for >> things they build themselves but don't ship? > >Probably. If the libraries cannot be located by the system in a >standard path, it needs help. We could probably come up with a small >script which prints the needed settings for a local M3 workspace. > >> I almost never ship binaries because I don't want user "mika" to >> have write access to the place whither the Modula-3 compiler normally >> ships. But I use them... from cron and other places. Other users >> may use them too... > >Have you got a better suggestion? >This is really not an M3 problem, but a general Unix question. >How should dynamic shared object files be found (especially, when >they are scattered across an M3 workspace)? If we burn in the local >paths, we need to relink the objects before shipping. I also wouldn't >like it when some installed program stops to work because the original >creator made changes to his home directories... > >Any ideas? > >Olaf > >> Mika >> >> Olaf Wagner writes: >>> Quoting Jay : >>> >>>> Running uninstalled binaries shall require either LD_LIBRARY_PATH >>>> or build_standalone(). m3tests uses build_standalone. This is maybe >>>> why more stuff is build_standalone -- anything that runs uninstalled >>>> when doing buildlobal, the various stub code generators. >>> >>> Please just use build_standalone for all binaries that are needed >>> by the build system itself. That shouldn't be many. >>> >>> Otherwise, I think setting LD_LIBRARY_PATH is acceptable. >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb????ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 rodney.m.bates at cox.net Mon Apr 6 21:11:29 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 06 Apr 2009 14:11:29 -0500 Subject: [M3devel] small objects In-Reply-To: <200904061529.n36FTTn0086974@camembert.async.caltech.edu> References: <200904061529.n36FTTn0086974@camembert.async.caltech.edu> Message-ID: <49DA53E1.8020408@cox.net> At first, I just envisioned implementing a small object type entirely inside an UNSAFE module, using unsafe operations to construct/test/separate the values. I think if the GC were to just to ignore words in heap objects that the type system claims are unambiguously pointers but actually have misaligned values, this could be done. But it flies in the face of a fundamental principle of Modula-3, namely that an UNSAFE module, if coded correctly, can prevent all other code from consequences of the unsafety. Unfortunately, this can't be done with the small pointers, because, even if opaque, they are still reference types, and client code can dereference them (including the implicit dereference in accessing a method or field of an object) and do ISTYPE, NARROW, TYPECASE, and assignments that do an implicit NARROW. All these operations could be done outside the implementing module and all could suffer from misaligned values. In fact, misaligned integer "objects" violate another principle that the bit pattern must always be a valid representation of some value of the type. However, this does suggest a different and very simple linguistic solution: Just have a new builtin type, say VERYOPAQUE, that supports no operations other than moving it around, i.e., assignment, bindings, passing as a parameter, etc. Only unsafe code could do anyhing with it, by using LOOPHOLE. The only problem is, would somebody then want one of these in a size other than one word? Mika Nystrom wrote: > Ah I should read my whole inbox before replying. > > I take it you would worry that in my proposal (to do this all in a > library) the use of REFANY to store an integer could be abused > somehow. That the Modula-3 type system (as it exists now) explicitly > rules out doing such things, and therefore, a language change is > necessary.... > > Mika > > Tony Hosking writes: > >> I like the notion of having a TAGGED INTEGER type that is a hybrid >> ordinal/reference. >> >> Subtyping rules for references would now be as follows: >> >> NULL <: REF T <: REFANY >> TAGGED INTEGER <: REF T <: REFANY >> >> ROOT <: REFANY >> NULL <: T OBJECT ... END <: T >> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: REFANY, not >> T <: ADDRESS) >> >> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >> type. Values of TAGGED INTEGER are non-pointer values similar to the >> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and NARROW(x, >> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to ISTYPE(x, >> NULL), NARROW(x, NULL), and TYPECODE(NULL). >> >> Because TAGGED INTEGER is an ordinal we can extract the integer value >> it holds using ORD(x). >> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >> INTEGER). >> >> ***The only problem with this scheme is how to efficiently perform run- >> time tests for dereferencing NULL, and TAGGED INTEGER?*** >> >> So, here is a slightly less elegant alternative that is probably >> straightforward to implement. Introduce a separate TAGGED hierarchy. >> >> NULL <: REF T <: REFANY >> NULL <: UNTRACED REF T <: ADDRESS >> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >> >> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >> >> ROOT <: REFANY >> TAGGED ROOT <: TAGGED REFANY >> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >> >> Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED >> REFANY. >> >> This way, tagged references only need a run-time test for the tag on >> dereference (we can throw an "attempt to dereference TAGGED INTEGER" >> at run time, just like we throw "attempt to dereference NIL" for >> untagged references). This check can be a straightforward test of the >> low bit tag. Of course, the weird thing here is now that we don't >> have a single NULL value for TAGGED references --- we have multiple >> null values VAL(x, TAGGED INTEGER). Instead of asking "x == NIL" we >> must ask "ISTYPE(x, TAGGED INTEGER)". >> >> Of course, because TAGGED INTEGER is an ordinal, we can also perform >> the usual ordinal operations like INC(x), DEC(x), wherever x is typed >> TAGGED INTEGER. >> >> >> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >> >> >>> I spent quite a bit of time playing with a more general system where >>> there is a set of "tagged" types, with (an implementation-defined >>> subrange of) INTEGER and a reference type both being a subtype of a >>> tagged type. It might have been tolerable, if it weren't for the >>> interaction with object subtypes and opaque types, which quickly >>> gets deep into a deep linguistic tar pit. >>> >>> Tony's approach is much simpler and would serve what I see as the >>> need. It does sacrifice any static checking of what reference type >>> is being tagged, and will also require an extra runtime ISTYPE/ >>> TYPECASE. >>> >>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>> also need to be an explicit conversion in that direction too, say >>> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >>> is a bit inconsistent with the usual Modula-3 assignability >>> philosophy, >>> but not requiring the explicit conversion already gets your toes >>> into tar. >>> >>> We would have to have something more like ISTYPE, though, which will >>> tell which type the value belongs to without risking a runtime error, >>> which VAL would do. >>> >>> An intermediate approach might be to have a set of tagged types >>> constructed by, say, TAGGED T, where I is a reference type, but >>> with no subtype relations on them at all, thus still requiring >>> the explicit conversions and checks. >>> >>> I do want to say, I _really_ want this capability somehow. I have >>> an ADT module whose internal data structure, for full generality, >>> needs to have two heap objects (the second because it has nonstatic >>> size) and 11 total words counting the orginal pointer, in the case of >>> values that would fit directly into the "pointer" word. Moreover, >>> these small cases are in the great majority. >>> >>> Besides the 11-to-one increase in actual occupied space, there >>> is extra time for allocation, periodic tracing, and collection, space >>> loss due to heap fragmentation, and time/space tradeoff loss due to >>> reduced locality of reference. So sometimes, it would be a big >>> performance gain if we could do it. >>> >>> >>> Tony Hosking wrote: >>> >>>> It is a much more pervasive hack than I would be comfortable with >>>> since it touches on the compiler (for all the type operations) as >>>> well >>>> as the run-time system in ways that are pretty gross. I would much >>>> rather have a new TAGGED builtin. ISTYPE would not work on it since >>>> that only works on references. The only thing you need is a way to >>>> extract the value -- we could overload VAL(x, T) where x can be a >>>> TAGGED and T can be REFANY or INTEGER. >>>> >>>> > > From mika at async.caltech.edu Mon Apr 6 22:03:03 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 13:03:03 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Mon, 06 Apr 2009 14:11:29 CDT." <49DA53E1.8020408@cox.net> Message-ID: <200904062003.n36K3381094096@camembert.async.caltech.edu> "Rodney M. Bates" writes: >At first, I just envisioned implementing a small object type >entirely inside an UNSAFE module, using unsafe operations >to construct/test/separate the values. I think if the GC were >to just to ignore words in heap objects that the type system >claims are unambiguously pointers but actually have misaligned >values, this could be done. Right that's precisely what the module I posted does. > >But it flies in the face of a fundamental principle of Modula-3, >namely that an UNSAFE module, if coded correctly, can prevent >all other code from consequences of the unsafety. Unfortunately, >this can't be done with the small pointers, because, even if >opaque, they are still reference types, and client code can >dereference them (including the implicit dereference in accessing >a method or field of an object) and do ISTYPE, NARROW, TYPECASE, >and assignments that do an implicit NARROW. All these operations >could be done outside the implementing module and all could >suffer from misaligned values. Well yes that is true. But the client can't dereference REFANY. Modula-3 doesn't permit that. That's an important practical point, because now we're limited to the other things: ISTYPE, NARROW (implicit and explicit), TYPECASE. (There are two more, actually, and they are = and #.) As long as those can be guaranteed to fail you're OK. [ Actually see my P.S. below! ] > >In fact, misaligned integer "objects" violate another principle that >the bit pattern must always be a valid representation of some value >of the type. Yes I think maybe this is what Tony is worried about. But let's just change the definition of REFANY to include anything with the LSB set...? In Modula-3-ese it would be more like the following: "REFANY can hold three types of objects. NIL, REF something or an implementation-defined other set of values that can only be accessed in an UNSAFE module. It is a checked runtime error to pass a 'REFANY of the third kind' to ISTYPE, NARROW, TYPECASE." [ Actually see my P.S. below! ] Then I propose we punt the handling of the new REFANYs to this unsafe module we spoke about above. As far as Modula-3 is concerned, there's just a set of values of (apparently) very little utility that can be represented by REFANY. If you think about it, this is really not so crazy. Any module that uses REFANY today is designed around to the fact that there are plenty of values of REFANY that can be of no interest to that module except for passing along to another module. (REFANY can easily represent a type which a module has no way of accessing *any* declaration of beyond just REFANY.) We're just adding some others, the only difference being that the new values are of no interest to any non-UNSAFE module. (Eh, technically this is already true for any reference type that is declared in an UNSAFE module today so one might argue we have in fact added nothing.) > >However, this does suggest a different and very simple linguistic >solution: Just have a new builtin type, say VERYOPAQUE, that >supports no operations other than moving it around, i.e., >assignment, bindings, passing as a parameter, etc. Only unsafe >code could do anyhing with it, by using LOOPHOLE. The only >problem is, would somebody then want one of these in a size other >than one word? This is nice, and we already have a candidate type, in fact: ADDRESS. But the problem is that the GC doesn't follow this even if the LSB is clear... which we *do* want. Why are you worried about getting it in sizes other than one word? That seems to me to be an application problem. If someone wants an ARRAY OF VERYOPAQUE is that a problem? Mika P.S. Illustration of the above, in today's Modula-3: UNSAFE MODULE Unsafe; (* this module is just declared UNSAFE to conform with the definition above, namely, that T can only be manipulated in an UNSAFE module, which this is! *) TYPE T = BRANDED OBJECT END; BEGIN Safe.P(NEW(T)) END Unsafe. (****************************************) MODULE Safe; PROCEDURE P(r : REFANY) = BEGIN NARROW(r, X); (* checked runtime error for all X *) ISTYPE(r, X); (* returns FALSE for all X except REFANY itself *) TYPECASE r OF X => (* only gets executed for X = REFANY *) END; END P; BEGIN END Safe. Actually is this behavior so bad for tagged integers? Since it is the behavior of existing code... why not keep it? Then you can even store a tagged integer in a RefList.T, say, even if that RefList.T uses NARROW or ISTYPE on the argument (I don't see why it would, but why not...?) > >Mika Nystrom wrote: >> Ah I should read my whole inbox before replying. >> >> I take it you would worry that in my proposal (to do this all in a >> library) the use of REFANY to store an integer could be abused >> somehow. That the Modula-3 type system (as it exists now) explicitly >> rules out doing such things, and therefore, a language change is >> necessary.... >> >> Mika >> >> Tony Hosking writes: >> >>> I like the notion of having a TAGGED INTEGER type that is a hybrid >>> ordinal/reference. >>> >>> Subtyping rules for references would now be as follows: >>> >>> NULL <: REF T <: REFANY >>> TAGGED INTEGER <: REF T <: REFANY >>> >>> ROOT <: REFANY >>> NULL <: T OBJECT ... END <: T >>> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: REFANY, not >>> T <: ADDRESS) >>> >>> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >>> type. Values of TAGGED INTEGER are non-pointer values similar to the >>> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and NARROW(x, >>> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to ISTYPE(x, >>> NULL), NARROW(x, NULL), and TYPECODE(NULL). >>> >>> Because TAGGED INTEGER is an ordinal we can extract the integer value >>> it holds using ORD(x). >>> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >>> INTEGER). >>> >>> ***The only problem with this scheme is how to efficiently perform run- >>> time tests for dereferencing NULL, and TAGGED INTEGER?*** >> >>> So, here is a slightly less elegant alternative that is probably >>> straightforward to implement. Introduce a separate TAGGED hierarchy. >>> >>> NULL <: REF T <: REFANY >>> NULL <: UNTRACED REF T <: ADDRESS >>> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >>> >>> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >>> >>> ROOT <: REFANY >>> TAGGED ROOT <: TAGGED REFANY >>> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >>> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >>> >>> Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED >>> REFANY. >>> >>> This way, tagged references only need a run-time test for the tag on >>> dereference (we can throw an "attempt to dereference TAGGED INTEGER" >>> at run time, just like we throw "attempt to dereference NIL" for >>> untagged references). This check can be a straightforward test of the >>> low bit tag. Of course, the weird thing here is now that we don't >>> have a single NULL value for TAGGED references --- we have multiple >>> null values VAL(x, TAGGED INTEGER). Instead of asking "x == NIL" we >>> must ask "ISTYPE(x, TAGGED INTEGER)". >>> >>> Of course, because TAGGED INTEGER is an ordinal, we can also perform >>> the usual ordinal operations like INC(x), DEC(x), wherever x is typed >>> TAGGED INTEGER. >>> >>> >>> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >>> >>> >>>> I spent quite a bit of time playing with a more general system where >>>> there is a set of "tagged" types, with (an implementation-defined >>>> subrange of) INTEGER and a reference type both being a subtype of a >>>> tagged type. It might have been tolerable, if it weren't for the >>>> interaction with object subtypes and opaque types, which quickly >>>> gets deep into a deep linguistic tar pit. >>>> >>>> Tony's approach is much simpler and would serve what I see as the >>>> need. It does sacrifice any static checking of what reference type >>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>> TYPECASE. >>>> >>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>> also need to be an explicit conversion in that direction too, say >>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >>>> is a bit inconsistent with the usual Modula-3 assignability >>>> philosophy, >>>> but not requiring the explicit conversion already gets your toes >>>> into tar. >>>> >>>> We would have to have something more like ISTYPE, though, which will >>>> tell which type the value belongs to without risking a runtime error, >>>> which VAL would do. >>>> >>>> An intermediate approach might be to have a set of tagged types >>>> constructed by, say, TAGGED T, where I is a reference type, but >>>> with no subtype relations on them at all, thus still requiring >>>> the explicit conversions and checks. >>>> >>>> I do want to say, I _really_ want this capability somehow. I have >>>> an ADT module whose internal data structure, for full generality, >>>> needs to have two heap objects (the second because it has nonstatic >>>> size) and 11 total words counting the orginal pointer, in the case of >>>> values that would fit directly into the "pointer" word. Moreover, >>>> these small cases are in the great majority. >>>> >>>> Besides the 11-to-one increase in actual occupied space, there >>>> is extra time for allocation, periodic tracing, and collection, space >>>> loss due to heap fragmentation, and time/space tradeoff loss due to >>>> reduced locality of reference. So sometimes, it would be a big >>>> performance gain if we could do it. >>>> >>>> >>>> Tony Hosking wrote: >>>> >>>>> It is a much more pervasive hack than I would be comfortable with >>>>> since it touches on the compiler (for all the type operations) as >>>>> well >>>>> as the run-time system in ways that are pretty gross. I would much >>>>> rather have a new TAGGED builtin. ISTYPE would not work on it since >>>>> that only works on references. The only thing you need is a way to >>>>> extract the value -- we could overload VAL(x, T) where x can be a >>>>> TAGGED and T can be REFANY or INTEGER. >>>>> >>>>> >> >> From mika at async.caltech.edu Mon Apr 6 22:17:37 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 13:17:37 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Mon, 06 Apr 2009 13:03:03 PDT." <200904062003.n36K3381094096@camembert.async.caltech.edu> Message-ID: <200904062017.n36KHbcq094473@camembert.async.caltech.edu> Ok I admit I missed something important. TYPECODE. It's easy enough to allocate a special TYPECODE to the tagged integer. One not used by any "real" type of course. It will break pickles and fingerprints. Pickles can be fixed, check the typecode and call a routine in the TaggedInteger interface (by default, user can override it?) to translate to and fro. But what about fingerprints? Again I guess we can just return the fingerprint of a nonexistent type............................. Hummm humm. Ok, how about this... let's declare a completely hidden type ... UNSAFE MODULE TaggedInteger; TYPE T = BRANDED OBJECT x : INTEGER END; BEGIN END TaggedInteger. Now, fix up TYPECODE, ISTYPE, NARROW, TYPECASE so that they all act *precisely* as if TaggedInteger.T were passed to them, when they see a REFANY with the LSB set. fingerprinting the type will give you the fingerprint of TaggedInteger.T. (But you better not rely on that! Only UNSAFE modules can do anything with this information, anyhow, so who cares, but see below.) I don't see how this breaks anything at all once we introduce the 'REFANY of the third kind', which is so small a change to the language's type system that I'm not sure it even qualifies as a change. Pickles are already unsafe, so the fact that the current pickles package would subvert the type system based on what I propose is a non-issue (language wise), it just means a few extra lines of code in the pickles package. The reason for the x : field above is that I propose that this be how the tagged integer be un/pickled, as an instance of an object of the (actual) type TaggedInteger.T. Mika Mika Nystrom writes: >"Rodney M. Bates" writes: >>At first, I just envisioned implementing a small object type >>entirely inside an UNSAFE module, using unsafe operations >>to construct/test/separate the values. I think if the GC were >>to just to ignore words in heap objects that the type system >>claims are unambiguously pointers but actually have misaligned >>values, this could be done. > >Right that's precisely what the module I posted does. > >> >>But it flies in the face of a fundamental principle of Modula-3, >>namely that an UNSAFE module, if coded correctly, can prevent >>all other code from consequences of the unsafety. Unfortunately, >>this can't be done with the small pointers, because, even if >>opaque, they are still reference types, and client code can >>dereference them (including the implicit dereference in accessing >>a method or field of an object) and do ISTYPE, NARROW, TYPECASE, >>and assignments that do an implicit NARROW. All these operations >>could be done outside the implementing module and all could >>suffer from misaligned values. > >Well yes that is true. But the client can't dereference REFANY. >Modula-3 doesn't permit that. That's an important practical point, >because now we're limited to the other things: ISTYPE, NARROW >(implicit and explicit), TYPECASE. (There are two more, actually, >and they are = and #.) As long as those can be guaranteed to fail >you're OK. [ Actually see my P.S. below! ] > >> >>In fact, misaligned integer "objects" violate another principle that >>the bit pattern must always be a valid representation of some value >>of the type. > >Yes I think maybe this is what Tony is worried about. But let's >just change the definition of REFANY to include anything with the >LSB set...? > >In Modula-3-ese it would be more like the following: > >"REFANY can hold three types of objects. NIL, REF something or an >implementation-defined other set of values that can only be accessed >in an UNSAFE module. It is a checked runtime error to pass a 'REFANY >of the third kind' to ISTYPE, NARROW, TYPECASE." [ Actually see my P.S. below! ] > >Then I propose we punt the handling of the new REFANYs to this >unsafe module we spoke about above. As far as Modula-3 is concerned, >there's just a set of values of (apparently) very little utility >that can be represented by REFANY. If you think about it, this is >really not so crazy. Any module that uses REFANY today is designed >around to the fact that there are plenty of values of REFANY that >can be of no interest to that module except for passing along to >another module. (REFANY can easily represent a type which a module >has no way of accessing *any* declaration of beyond just REFANY.) >We're just adding some others, the only difference being that the >new values are of no interest to any non-UNSAFE module. (Eh, >technically this is already true for any reference type that is >declared in an UNSAFE module today so one might argue we have in >fact added nothing.) > >> >>However, this does suggest a different and very simple linguistic >>solution: Just have a new builtin type, say VERYOPAQUE, that >>supports no operations other than moving it around, i.e., >>assignment, bindings, passing as a parameter, etc. Only unsafe >>code could do anyhing with it, by using LOOPHOLE. The only >>problem is, would somebody then want one of these in a size other >>than one word? > >This is nice, and we already have a candidate type, in fact: ADDRESS. >But the problem is that the GC doesn't follow this even if the LSB >is clear... which we *do* want. > >Why are you worried about getting it in sizes other than one word? >That seems to me to be an application problem. If someone wants >an ARRAY OF VERYOPAQUE is that a problem? > > Mika > >P.S. Illustration of the above, in today's Modula-3: > >UNSAFE MODULE Unsafe; > >(* this module is just declared UNSAFE to conform with the definition > above, namely, that T can only be manipulated in an UNSAFE > module, which this is! *) > >TYPE T = BRANDED OBJECT END; > >BEGIN > Safe.P(NEW(T)) >END Unsafe. > >(****************************************) > >MODULE Safe; > >PROCEDURE P(r : REFANY) = > BEGIN > NARROW(r, X); (* checked runtime error for all X *) > > ISTYPE(r, X); (* returns FALSE for all X except REFANY itself *) > > TYPECASE r OF > X => (* only gets executed for X = REFANY *) > END; > END P; > >BEGIN END Safe. > >Actually is this behavior so bad for tagged integers? Since it is >the behavior of existing code... why not keep it? Then you can even >store a tagged integer in a RefList.T, say, even if that RefList.T >uses NARROW or ISTYPE on the argument (I don't see why it would, but >why not...?) > > > >> >>Mika Nystrom wrote: >>> Ah I should read my whole inbox before replying. >>> >>> I take it you would worry that in my proposal (to do this all in a >>> library) the use of REFANY to store an integer could be abused >>> somehow. That the Modula-3 type system (as it exists now) explicitly >>> rules out doing such things, and therefore, a language change is >>> necessary.... >>> >>> Mika >>> >>> Tony Hosking writes: >>> >>>> I like the notion of having a TAGGED INTEGER type that is a hybrid >>>> ordinal/reference. >>>> >>>> Subtyping rules for references would now be as follows: >>>> >>>> NULL <: REF T <: REFANY >>>> TAGGED INTEGER <: REF T <: REFANY >>>> >>>> ROOT <: REFANY >>>> NULL <: T OBJECT ... END <: T >>>> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: REFANY, not >>>> T <: ADDRESS) >>>> >>>> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >>>> type. Values of TAGGED INTEGER are non-pointer values similar to the >>>> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and NARROW(x, >>>> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to ISTYPE(x, >>>> NULL), NARROW(x, NULL), and TYPECODE(NULL). >>>> >>>> Because TAGGED INTEGER is an ordinal we can extract the integer value >>>> it holds using ORD(x). >>>> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >>>> INTEGER). >>>> >>>> ***The only problem with this scheme is how to efficiently perform run- >>>> time tests for dereferencing NULL, and TAGGED INTEGER?*** >>> >>>> So, here is a slightly less elegant alternative that is probably >>>> straightforward to implement. Introduce a separate TAGGED hierarchy. >>>> >>>> NULL <: REF T <: REFANY >>>> NULL <: UNTRACED REF T <: ADDRESS >>>> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >>>> >>>> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >>>> >>>> ROOT <: REFANY >>>> TAGGED ROOT <: TAGGED REFANY >>>> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >>>> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >>>> >>>> Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED >>>> REFANY. >>>> >>>> This way, tagged references only need a run-time test for the tag on >>>> dereference (we can throw an "attempt to dereference TAGGED INTEGER" >>>> at run time, just like we throw "attempt to dereference NIL" for >>>> untagged references). This check can be a straightforward test of the >>>> low bit tag. Of course, the weird thing here is now that we don't >>>> have a single NULL value for TAGGED references --- we have multiple >>>> null values VAL(x, TAGGED INTEGER). Instead of asking "x == NIL" we >>>> must ask "ISTYPE(x, TAGGED INTEGER)". >>>> >>>> Of course, because TAGGED INTEGER is an ordinal, we can also perform >>>> the usual ordinal operations like INC(x), DEC(x), wherever x is typed >>>> TAGGED INTEGER. >>>> >>>> >>>> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >>>> >>>> >>>>> I spent quite a bit of time playing with a more general system where >>>>> there is a set of "tagged" types, with (an implementation-defined >>>>> subrange of) INTEGER and a reference type both being a subtype of a >>>>> tagged type. It might have been tolerable, if it weren't for the >>>>> interaction with object subtypes and opaque types, which quickly >>>>> gets deep into a deep linguistic tar pit. >>>>> >>>>> Tony's approach is much simpler and would serve what I see as the >>>>> need. It does sacrifice any static checking of what reference type >>>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>>> TYPECASE. >>>>> >>>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>>> also need to be an explicit conversion in that direction too, say >>>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >>>>> is a bit inconsistent with the usual Modula-3 assignability >>>>> philosophy, >>>>> but not requiring the explicit conversion already gets your toes >>>>> into tar. >>>>> >>>>> We would have to have something more like ISTYPE, though, which will >>>>> tell which type the value belongs to without risking a runtime error, >>>>> which VAL would do. >>>>> >>>>> An intermediate approach might be to have a set of tagged types >>>>> constructed by, say, TAGGED T, where I is a reference type, but >>>>> with no subtype relations on them at all, thus still requiring >>>>> the explicit conversions and checks. >>>>> >>>>> I do want to say, I _really_ want this capability somehow. I have >>>>> an ADT module whose internal data structure, for full generality, >>>>> needs to have two heap objects (the second because it has nonstatic >>>>> size) and 11 total words counting the orginal pointer, in the case of >>>>> values that would fit directly into the "pointer" word. Moreover, >>>>> these small cases are in the great majority. >>>>> >>>>> Besides the 11-to-one increase in actual occupied space, there >>>>> is extra time for allocation, periodic tracing, and collection, space >>>>> loss due to heap fragmentation, and time/space tradeoff loss due to >>>>> reduced locality of reference. So sometimes, it would be a big >>>>> performance gain if we could do it. >>>>> >>>>> >>>>> Tony Hosking wrote: >>>>> >>>>>> It is a much more pervasive hack than I would be comfortable with >>>>>> since it touches on the compiler (for all the type operations) as >>>>>> well >>>>>> as the run-time system in ways that are pretty gross. I would much >>>>>> rather have a new TAGGED builtin. ISTYPE would not work on it since >>>>>> that only works on references. The only thing you need is a way to >>>>>> extract the value -- we could overload VAL(x, T) where x can be a >>>>>> TAGGED and T can be REFANY or INTEGER. >>>>>> >>>>>> >>> >>> From mika at async.caltech.edu Mon Apr 6 22:31:57 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 13:31:57 -0700 Subject: [M3devel] Implementing the "Singleton pattern" in Modula-3 Message-ID: <200904062031.n36KVvC2094839@camembert.async.caltech.edu> Tony, Jay, you two seem to be most knowledgeable about this. Let's say I wanted to implement the "singleton pattern" in Modula-3. At present there seems to be no way of doing this. What about changing RTAllocator.callback as follows (or adding another callback): VAR callback : PROCEDURE(r : REFANY) : REFANY := NIL; (* If non-NIL, the allocator calls "callback(r)" just before returning a new traced reference "r" and instead returns the result of callback(r). See "RTAllocStats" for an example client. It is a checked runtime error for the typecode of r to differ from the typecode of the return value of callback(r). *) Mika From mika at async.caltech.edu Mon Apr 6 22:39:18 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 13:39:18 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Mon, 06 Apr 2009 13:03:03 PDT." <200904062003.n36K3381094096@camembert.async.caltech.edu> Message-ID: <200904062039.n36KdIsY095003@camembert.async.caltech.edu> And finally, to forestall a possible objection to the scheme I proposed: Yes, it is true that even a non-UNSAFE module can allocate a TaggedInteger.T by calling new := RTAllocator.NewTraced(TYPECODE(r)) where r is a tagged integer. But since it cannot dereference that new value or do anything else with it, I don't think this is a problem. The Pickler (built into the TaggedInteger module, one must assume) would simply have to be on the lookout for values of the "real" TaggedInteger.T versus those that are just numbers with the LSB set, and act accordingly. Since the T declaration is only visible within the UNSAFE module there can never be any question of another module's muddling the two types up. Mika Mika Nystrom writes: >"Rodney M. Bates" writes: >>At first, I just envisioned implementing a small object type >>entirely inside an UNSAFE module, using unsafe operations >>to construct/test/separate the values. I think if the GC were >>to just to ignore words in heap objects that the type system >>claims are unambiguously pointers but actually have misaligned >>values, this could be done. > >Right that's precisely what the module I posted does. > >> >>But it flies in the face of a fundamental principle of Modula-3, >>namely that an UNSAFE module, if coded correctly, can prevent >>all other code from consequences of the unsafety. Unfortunately, >>this can't be done with the small pointers, because, even if >>opaque, they are still reference types, and client code can >>dereference them (including the implicit dereference in accessing >>a method or field of an object) and do ISTYPE, NARROW, TYPECASE, >>and assignments that do an implicit NARROW. All these operations >>could be done outside the implementing module and all could >>suffer from misaligned values. > >Well yes that is true. But the client can't dereference REFANY. >Modula-3 doesn't permit that. That's an important practical point, >because now we're limited to the other things: ISTYPE, NARROW >(implicit and explicit), TYPECASE. (There are two more, actually, >and they are = and #.) As long as those can be guaranteed to fail >you're OK. [ Actually see my P.S. below! ] > >> >>In fact, misaligned integer "objects" violate another principle that >>the bit pattern must always be a valid representation of some value >>of the type. > >Yes I think maybe this is what Tony is worried about. But let's >just change the definition of REFANY to include anything with the >LSB set...? > >In Modula-3-ese it would be more like the following: > >"REFANY can hold three types of objects. NIL, REF something or an >implementation-defined other set of values that can only be accessed >in an UNSAFE module. It is a checked runtime error to pass a 'REFANY >of the third kind' to ISTYPE, NARROW, TYPECASE." [ Actually see my P.S. below! ] > >Then I propose we punt the handling of the new REFANYs to this >unsafe module we spoke about above. As far as Modula-3 is concerned, >there's just a set of values of (apparently) very little utility >that can be represented by REFANY. If you think about it, this is >really not so crazy. Any module that uses REFANY today is designed >around to the fact that there are plenty of values of REFANY that >can be of no interest to that module except for passing along to >another module. (REFANY can easily represent a type which a module >has no way of accessing *any* declaration of beyond just REFANY.) >We're just adding some others, the only difference being that the >new values are of no interest to any non-UNSAFE module. (Eh, >technically this is already true for any reference type that is >declared in an UNSAFE module today so one might argue we have in >fact added nothing.) > >> >>However, this does suggest a different and very simple linguistic >>solution: Just have a new builtin type, say VERYOPAQUE, that >>supports no operations other than moving it around, i.e., >>assignment, bindings, passing as a parameter, etc. Only unsafe >>code could do anyhing with it, by using LOOPHOLE. The only >>problem is, would somebody then want one of these in a size other >>than one word? > >This is nice, and we already have a candidate type, in fact: ADDRESS. >But the problem is that the GC doesn't follow this even if the LSB >is clear... which we *do* want. > >Why are you worried about getting it in sizes other than one word? >That seems to me to be an application problem. If someone wants >an ARRAY OF VERYOPAQUE is that a problem? > > Mika > >P.S. Illustration of the above, in today's Modula-3: > >UNSAFE MODULE Unsafe; > >(* this module is just declared UNSAFE to conform with the definition > above, namely, that T can only be manipulated in an UNSAFE > module, which this is! *) > >TYPE T = BRANDED OBJECT END; > >BEGIN > Safe.P(NEW(T)) >END Unsafe. > >(****************************************) > >MODULE Safe; > >PROCEDURE P(r : REFANY) = > BEGIN > NARROW(r, X); (* checked runtime error for all X *) > > ISTYPE(r, X); (* returns FALSE for all X except REFANY itself *) > > TYPECASE r OF > X => (* only gets executed for X = REFANY *) > END; > END P; > >BEGIN END Safe. > >Actually is this behavior so bad for tagged integers? Since it is >the behavior of existing code... why not keep it? Then you can even >store a tagged integer in a RefList.T, say, even if that RefList.T >uses NARROW or ISTYPE on the argument (I don't see why it would, but >why not...?) > > > >> >>Mika Nystrom wrote: >>> Ah I should read my whole inbox before replying. >>> >>> I take it you would worry that in my proposal (to do this all in a >>> library) the use of REFANY to store an integer could be abused >>> somehow. That the Modula-3 type system (as it exists now) explicitly >>> rules out doing such things, and therefore, a language change is >>> necessary.... >>> >>> Mika >>> >>> Tony Hosking writes: >>> >>>> I like the notion of having a TAGGED INTEGER type that is a hybrid >>>> ordinal/reference. >>>> >>>> Subtyping rules for references would now be as follows: >>>> >>>> NULL <: REF T <: REFANY >>>> TAGGED INTEGER <: REF T <: REFANY >>>> >>>> ROOT <: REFANY >>>> NULL <: T OBJECT ... END <: T >>>> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: REFANY, not >>>> T <: ADDRESS) >>>> >>>> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >>>> type. Values of TAGGED INTEGER are non-pointer values similar to the >>>> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and NARROW(x, >>>> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to ISTYPE(x, >>>> NULL), NARROW(x, NULL), and TYPECODE(NULL). >>>> >>>> Because TAGGED INTEGER is an ordinal we can extract the integer value >>>> it holds using ORD(x). >>>> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >>>> INTEGER). >>>> >>>> ***The only problem with this scheme is how to efficiently perform run- >>>> time tests for dereferencing NULL, and TAGGED INTEGER?*** >>> >>>> So, here is a slightly less elegant alternative that is probably >>>> straightforward to implement. Introduce a separate TAGGED hierarchy. >>>> >>>> NULL <: REF T <: REFANY >>>> NULL <: UNTRACED REF T <: ADDRESS >>>> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >>>> >>>> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >>>> >>>> ROOT <: REFANY >>>> TAGGED ROOT <: TAGGED REFANY >>>> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >>>> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >>>> >>>> Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED >>>> REFANY. >>>> >>>> This way, tagged references only need a run-time test for the tag on >>>> dereference (we can throw an "attempt to dereference TAGGED INTEGER" >>>> at run time, just like we throw "attempt to dereference NIL" for >>>> untagged references). This check can be a straightforward test of the >>>> low bit tag. Of course, the weird thing here is now that we don't >>>> have a single NULL value for TAGGED references --- we have multiple >>>> null values VAL(x, TAGGED INTEGER). Instead of asking "x == NIL" we >>>> must ask "ISTYPE(x, TAGGED INTEGER)". >>>> >>>> Of course, because TAGGED INTEGER is an ordinal, we can also perform >>>> the usual ordinal operations like INC(x), DEC(x), wherever x is typed >>>> TAGGED INTEGER. >>>> >>>> >>>> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >>>> >>>> >>>>> I spent quite a bit of time playing with a more general system where >>>>> there is a set of "tagged" types, with (an implementation-defined >>>>> subrange of) INTEGER and a reference type both being a subtype of a >>>>> tagged type. It might have been tolerable, if it weren't for the >>>>> interaction with object subtypes and opaque types, which quickly >>>>> gets deep into a deep linguistic tar pit. >>>>> >>>>> Tony's approach is much simpler and would serve what I see as the >>>>> need. It does sacrifice any static checking of what reference type >>>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>>> TYPECASE. >>>>> >>>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>>> also need to be an explicit conversion in that direction too, say >>>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >>>>> is a bit inconsistent with the usual Modula-3 assignability >>>>> philosophy, >>>>> but not requiring the explicit conversion already gets your toes >>>>> into tar. >>>>> >>>>> We would have to have something more like ISTYPE, though, which will >>>>> tell which type the value belongs to without risking a runtime error, >>>>> which VAL would do. >>>>> >>>>> An intermediate approach might be to have a set of tagged types >>>>> constructed by, say, TAGGED T, where I is a reference type, but >>>>> with no subtype relations on them at all, thus still requiring >>>>> the explicit conversions and checks. >>>>> >>>>> I do want to say, I _really_ want this capability somehow. I have >>>>> an ADT module whose internal data structure, for full generality, >>>>> needs to have two heap objects (the second because it has nonstatic >>>>> size) and 11 total words counting the orginal pointer, in the case of >>>>> values that would fit directly into the "pointer" word. Moreover, >>>>> these small cases are in the great majority. >>>>> >>>>> Besides the 11-to-one increase in actual occupied space, there >>>>> is extra time for allocation, periodic tracing, and collection, space >>>>> loss due to heap fragmentation, and time/space tradeoff loss due to >>>>> reduced locality of reference. So sometimes, it would be a big >>>>> performance gain if we could do it. >>>>> >>>>> >>>>> Tony Hosking wrote: >>>>> >>>>>> It is a much more pervasive hack than I would be comfortable with >>>>>> since it touches on the compiler (for all the type operations) as >>>>>> well >>>>>> as the run-time system in ways that are pretty gross. I would much >>>>>> rather have a new TAGGED builtin. ISTYPE would not work on it since >>>>>> that only works on references. The only thing you need is a way to >>>>>> extract the value -- we could overload VAL(x, T) where x can be a >>>>>> TAGGED and T can be REFANY or INTEGER. >>>>>> >>>>>> >>> >>> From hosking at cs.purdue.edu Tue Apr 7 02:06:03 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 10:06:03 +1000 Subject: [M3devel] small objects In-Reply-To: <200904061450.n36EoPk9085841@camembert.async.caltech.edu> References: <200904061450.n36EoPk9085841@camembert.async.caltech.edu> Message-ID: <59082335-E94F-48FC-AD7B-6632542B5ED4@cs.purdue.edu> I really don't like your proposal for the reasons you mention. It makes regular REF more expensive than it currently is. What is it about my relatively minor changes to the type system that you object to? I've just about finished changing the compiler front-end (in relatively minor ways) to accomodate the proposal I made yesterday. And it has the advantage of separating REF from TAGGED REF so we keep the standard REF clean. On 7 Apr 2009, at 00:50, Mika Nystrom wrote: > Hi Rodney, > > I would like this capability too, but I am a bit wary of Tony's > idea of changing the Modula-3 language---even in a "minor" way. > I've been working for the last week or so on an application using > the Modula-3 Toolkit, and I must say I have realized that the > Modula-3 type system has a lot more subtleties than I thought. I > would not want to make any real changes to it. There's a paper > called "The Modula-3 Type System" by Cardelli, Donahue, Kalsow, and > Nelson that is worth studying in detail before making any changes > whatsoever, I think. Also remember that changes to the type system > will affect m3tk and anything that depends on m3tk (which includes > two or three stub generators in the main tree and who knows how > many dependencies outside of it). > > I'm still not sure why we can't take the approach of Word.T . > Make a RefanyOrInt.T that can safely be: > > 1. Tested whether it is a small integer or a REFANY > > 2. If a REFANY, be dereferenced as normal, *or* via > RefanyOrInt.ToRefany > > 3. If a small integer, can be extracted via RefanyOrInt.ToInt > > 4. Created either as a small integer or a REFANY > > Any other operations on it (including ISTYPE and TYPECASE, at least > when the object is a small integer) would result in a checked runtime > error. > > Note that with the declaration "RefanyOrInt.T = REFANY", the current > compiler will as far as I know not accept any operations on > RefanyOrInt.T outside of ISTYPE, TYPECASE, and NARROW (explicit or > implicit). > > I wouldn't be surprised if most of what I'm proposing already works > (i.e., crashes with a checked runtime error as it should) with the > current runtime. Anything that slips through would need to be fixed > up with a one-bit check of the LSB of the REFANY for the operations > mentioned above. Unfortunately this has to be done for operations on > every REFANY, not just the new type. > > I think that Modula-3 programmers are already aware that using > REFANYs involves forcing the runtime to do extra type-checking work, > so they already know not to use them if they are looking for maximum > performance, so I don't think that burdening operations on REFANY > with an extra one-bit check is too onerous. > > An advantage of my proposal is that the amount of code in the new > proposed library is truly diminutive. In fact, I think I posted > pretty much that code to the list a few weeks ago. > > (If you missed it, it's > > http://www.async.caltech.edu/~mika/interp/ > > ) > > Mika > > > "Rodney M. Bates" writes: >> I spent quite a bit of time playing with a more general system where >> there is a set of "tagged" types, with (an implementation-defined >> subrange of) INTEGER and a reference type both being a subtype of a >> tagged type. It might have been tolerable, if it weren't for the >> interaction with object subtypes and opaque types, which quickly >> gets deep into a deep linguistic tar pit. >> >> Tony's approach is much simpler and would serve what I see as the >> need. It does sacrifice any static checking of what reference type >> is being tagged, and will also require an extra runtime ISTYPE/ >> TYPECASE. >> >> Would INTEGER and REFANY be assignable to TAGGED, or would there >> also need to be an explicit conversion in that direction too, say >> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >> is a bit inconsistent with the usual Modula-3 assignability >> philosophy, >> but not requiring the explicit conversion already gets your toes >> into tar. >> >> We would have to have something more like ISTYPE, though, which will >> tell which type the value belongs to without risking a runtime error, >> which VAL would do. >> >> An intermediate approach might be to have a set of tagged types >> constructed by, say, TAGGED T, where I is a reference type, but >> with no subtype relations on them at all, thus still requiring >> the explicit conversions and checks. >> >> I do want to say, I _really_ want this capability somehow. I have >> an ADT module whose internal data structure, for full generality, >> needs to have two heap objects (the second because it has nonstatic >> size) and 11 total words counting the orginal pointer, in the case of >> values that would fit directly into the "pointer" word. Moreover, >> these small cases are in the great majority. >> >> Besides the 11-to-one increase in actual occupied space, there >> is extra time for allocation, periodic tracing, and collection, space >> loss due to heap fragmentation, and time/space tradeoff loss due to >> reduced locality of reference. So sometimes, it would be a big >> performance gain if we could do it. >> >> >> Tony Hosking wrote: >> It is a much more pervasive hack than I would be comfortable with >>> since it touches on the compiler (for all the type operations) as >>> well >>> as the run-time system in ways that are pretty gross. I would much >>> rather have a new TAGGED builtin. ISTYPE would not work on it since >>> that only works on references. The only thing you need is a way to >>> extract the value -- we could overload VAL(x, T) where x can be a >>> TAGGED and T can be REFANY or INTEGER. >>> >>> From hosking at cs.purdue.edu Tue Apr 7 02:07:10 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 10:07:10 +1000 Subject: [M3devel] small objects In-Reply-To: <200904061450.n36EoPk9085841@camembert.async.caltech.edu> References: <200904061450.n36EoPk9085841@camembert.async.caltech.edu> Message-ID: PS What you propose has more pervasive impact on the run-time system and performance than my proposal simply because it conflates tagging with existing REFANY. On 7 Apr 2009, at 00:50, Mika Nystrom wrote: > Hi Rodney, > > I would like this capability too, but I am a bit wary of Tony's > idea of changing the Modula-3 language---even in a "minor" way. > I've been working for the last week or so on an application using > the Modula-3 Toolkit, and I must say I have realized that the > Modula-3 type system has a lot more subtleties than I thought. I > would not want to make any real changes to it. There's a paper > called "The Modula-3 Type System" by Cardelli, Donahue, Kalsow, and > Nelson that is worth studying in detail before making any changes > whatsoever, I think. Also remember that changes to the type system > will affect m3tk and anything that depends on m3tk (which includes > two or three stub generators in the main tree and who knows how > many dependencies outside of it). > > I'm still not sure why we can't take the approach of Word.T . > Make a RefanyOrInt.T that can safely be: > > 1. Tested whether it is a small integer or a REFANY > > 2. If a REFANY, be dereferenced as normal, *or* via > RefanyOrInt.ToRefany > > 3. If a small integer, can be extracted via RefanyOrInt.ToInt > > 4. Created either as a small integer or a REFANY > > Any other operations on it (including ISTYPE and TYPECASE, at least > when the object is a small integer) would result in a checked runtime > error. > > Note that with the declaration "RefanyOrInt.T = REFANY", the current > compiler will as far as I know not accept any operations on > RefanyOrInt.T outside of ISTYPE, TYPECASE, and NARROW (explicit or > implicit). > > I wouldn't be surprised if most of what I'm proposing already works > (i.e., crashes with a checked runtime error as it should) with the > current runtime. Anything that slips through would need to be fixed > up with a one-bit check of the LSB of the REFANY for the operations > mentioned above. Unfortunately this has to be done for operations on > every REFANY, not just the new type. > > I think that Modula-3 programmers are already aware that using > REFANYs involves forcing the runtime to do extra type-checking work, > so they already know not to use them if they are looking for maximum > performance, so I don't think that burdening operations on REFANY > with an extra one-bit check is too onerous. > > An advantage of my proposal is that the amount of code in the new > proposed library is truly diminutive. In fact, I think I posted > pretty much that code to the list a few weeks ago. > > (If you missed it, it's > > http://www.async.caltech.edu/~mika/interp/ > > ) > > Mika > > > "Rodney M. Bates" writes: >> I spent quite a bit of time playing with a more general system where >> there is a set of "tagged" types, with (an implementation-defined >> subrange of) INTEGER and a reference type both being a subtype of a >> tagged type. It might have been tolerable, if it weren't for the >> interaction with object subtypes and opaque types, which quickly >> gets deep into a deep linguistic tar pit. >> >> Tony's approach is much simpler and would serve what I see as the >> need. It does sacrifice any static checking of what reference type >> is being tagged, and will also require an extra runtime ISTYPE/ >> TYPECASE. >> >> Would INTEGER and REFANY be assignable to TAGGED, or would there >> also need to be an explicit conversion in that direction too, say >> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >> is a bit inconsistent with the usual Modula-3 assignability >> philosophy, >> but not requiring the explicit conversion already gets your toes >> into tar. >> >> We would have to have something more like ISTYPE, though, which will >> tell which type the value belongs to without risking a runtime error, >> which VAL would do. >> >> An intermediate approach might be to have a set of tagged types >> constructed by, say, TAGGED T, where I is a reference type, but >> with no subtype relations on them at all, thus still requiring >> the explicit conversions and checks. >> >> I do want to say, I _really_ want this capability somehow. I have >> an ADT module whose internal data structure, for full generality, >> needs to have two heap objects (the second because it has nonstatic >> size) and 11 total words counting the orginal pointer, in the case of >> values that would fit directly into the "pointer" word. Moreover, >> these small cases are in the great majority. >> >> Besides the 11-to-one increase in actual occupied space, there >> is extra time for allocation, periodic tracing, and collection, space >> loss due to heap fragmentation, and time/space tradeoff loss due to >> reduced locality of reference. So sometimes, it would be a big >> performance gain if we could do it. >> >> >> Tony Hosking wrote: >> It is a much more pervasive hack than I would be comfortable with >>> since it touches on the compiler (for all the type operations) as >>> well >>> as the run-time system in ways that are pretty gross. I would much >>> rather have a new TAGGED builtin. ISTYPE would not work on it since >>> that only works on references. The only thing you need is a way to >>> extract the value -- we could overload VAL(x, T) where x can be a >>> TAGGED and T can be REFANY or INTEGER. >>> >>> From mika at async.caltech.edu Tue Apr 7 02:42:23 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 17:42:23 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Tue, 07 Apr 2009 10:06:03 +1000." <59082335-E94F-48FC-AD7B-6632542B5ED4@cs.purdue.edu> Message-ID: <200904070042.n370gNK3001242@camembert.async.caltech.edu> You mean this proposal (you had two, I think)? --- NULL <: REF T <: REFANY NULL <: UNTRACED REF T <: ADDRESS TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. ROOT <: REFANY TAGGED ROOT <: TAGGED REFANY NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED REFANY. --- I like it fine, I think... I'm just worried, generally, about changing the type system. Hmmmm... you mean that the TAGGED things would just be a separate hierarchy? So you'd just add TAGGED in front of the REFs for this new hierarchy. But why no NULL? And you're comfortable with doing the conversions automatically? So tx : TAGGED INTEGER := 5; x : INTEGER := tx; would be OK? In that case it's just the m3tk that needs to be modified, and that's just busy work, I think. If it works it's beautiful... Mika Tony Hosking writes: >I really don't like your proposal for the reasons you mention. It >makes regular REF more expensive than it currently is. What is it >about my relatively minor changes to the type system that you object >to? I've just about finished changing the compiler front-end (in >relatively minor ways) to accomodate the proposal I made yesterday. >And it has the advantage of separating REF from TAGGED REF so we keep >the standard REF clean. > >On 7 Apr 2009, at 00:50, Mika Nystrom wrote: > >> Hi Rodney, >> >> I would like this capability too, but I am a bit wary of Tony's >> idea of changing the Modula-3 language---even in a "minor" way. >> I've been working for the last week or so on an application using >> the Modula-3 Toolkit, and I must say I have realized that the > Modula-3 type system has a lot more subtleties than I thought. I >> would not want to make any real changes to it. There's a paper >> called "The Modula-3 Type System" by Cardelli, Donahue, Kalsow, and >> Nelson that is worth studying in detail before making any changes >> whatsoever, I think. Also remember that changes to the type system >> will affect m3tk and anything that depends on m3tk (which includes >> two or three stub generators in the main tree and who knows how >> many dependencies outside of it). >> >> I'm still not sure why we can't take the approach of Word.T . >> Make a RefanyOrInt.T that can safely be: >> >> 1. Tested whether it is a small integer or a REFANY >> >> 2. If a REFANY, be dereferenced as normal, *or* via >> RefanyOrInt.ToRefany >> >> 3. If a small integer, can be extracted via RefanyOrInt.ToInt >> >> 4. Created either as a small integer or a REFANY >> >> Any other operations on it (including ISTYPE and TYPECASE, at least >> when the object is a small integer) would result in a checked runtime >> error. >> >> Note that with the declaration "RefanyOrInt.T = REFANY", the current >> compiler will as far as I know not accept any operations on >> RefanyOrInt.T outside of ISTYPE, TYPECASE, and NARROW (explicit or >> implicit). >> >> I wouldn't be surprised if most of what I'm proposing already works >> (i.e., crashes with a checked runtime error as it should) with the >> current runtime. Anything that slips through would need to be fixed >> up with a one-bit check of the LSB of the REFANY for the operations >> mentioned above. Unfortunately this has to be done for operations on >> every REFANY, not just the new type. >> >> I think that Modula-3 programmers are already aware that using >> REFANYs involves forcing the runtime to do extra type-checking work, >> so they already know not to use them if they are looking for maximum >> performance, so I don't think that burdening operations on REFANY >> with an extra one-bit check is too onerous. >> >> An advantage of my proposal is that the amount of code in the new >> proposed library is truly diminutive. In fact, I think I posted >> pretty much that code to the list a few weeks ago. >> >> (If you missed it, it's >> >> http://www.async.caltech.edu/~mika/interp/ >> >> ) >> >> Mika >> >> >> "Rodney M. Bates" writes: >>> I spent quite a bit of time playing with a more general system where >>> there is a set of "tagged" types, with (an implementation-defined >>> subrange of) INTEGER and a reference type both being a subtype of a >>> tagged type. It might have been tolerable, if it weren't for the >>> interaction with object subtypes and opaque types, which quickly >>> gets deep into a deep linguistic tar pit. >>> >>> Tony's approach is much simpler and would serve what I see as the >>> need. It does sacrifice any static checking of what reference type >>> is being tagged, and will also require an extra runtime ISTYPE/ >>> TYPECASE. >>> >>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>> also need to be an explicit conversion in that direction too, say >>> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >>> is a bit inconsistent with the usual Modula-3 assignability >>> philosophy, >>> but not requiring the explicit conversion already gets your toes >>> into tar. >>> >>> We would have to have something more like ISTYPE, though, which will >>> tell which type the value belongs to without risking a runtime error, >>> which VAL would do. >>> >>> An intermediate approach might be to have a set of tagged types >>> constructed by, say, TAGGED T, where I is a reference type, but >>> with no subtype relations on them at all, thus still requiring >>> the explicit conversions and checks. >>> >>> I do want to say, I _really_ want this capability somehow. I have >>> an ADT module whose internal data structure, for full generality, >>> needs to have two heap objects (the second because it has nonstatic >>> size) and 11 total words counting the orginal pointer, in the case of >>> values that would fit directly into the "pointer" word. Moreover, >>> these small cases are in the great majority. >>> >>> Besides the 11-to-one increase in actual occupied space, there >>> is extra time for allocation, periodic tracing, and collection, space >>> loss due to heap fragmentation, and time/space tradeoff loss due to >>> reduced locality of reference. So sometimes, it would be a big >>> performance gain if we could do it. >>> >>> >>> Tony Hosking wrote: >>> It is a much more pervasive hack than I would be comfortable with >>>> since it touches on the compiler (for all the type operations) as >>>> well >>>> as the run-time system in ways that are pretty gross. I would much >>>> rather have a new TAGGED builtin. ISTYPE would not work on it since >>>> that only works on references. The only thing you need is a way to >>>> extract the value -- we could overload VAL(x, T) where x can be a >>>> TAGGED and T can be REFANY or INTEGER. >>>> >>>> From hosking at cs.purdue.edu Tue Apr 7 03:00:46 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 11:00:46 +1000 Subject: [M3devel] Implementing the "Singleton pattern" in Modula-3 In-Reply-To: <200904062031.n36KVvC2094839@camembert.async.caltech.edu> References: <200904062031.n36KVvC2094839@camembert.async.caltech.edu> Message-ID: <110C0337-7E0A-4283-9F1C-BEBAF26929F8@cs.purdue.edu> I would exploit opaque types and branding. If T is opaque then you cannot instantiate T except in scopes where T's concrete type has been revealed or is known to be an object type. Thus, you could define an interface: GENERIC INTERFACE Singleton(Rep); TYPE T <: REFANY; VAR t: T; END Singleton. GENERIC MODULE Singleton(Rep); REVEAL T = BRANDED REF Rep.T; BEGIN t := NEW(T); END Singleton. where Rep defines the type T. You could do similar for object types. On 7 Apr 2009, at 06:31, Mika Nystrom wrote: > > Tony, Jay, you two seem to be most knowledgeable about this. > > Let's say I wanted to implement the "singleton pattern" in > Modula-3. At present there seems to be no way of doing this. > > What about changing RTAllocator.callback as follows (or adding > another callback): > > VAR callback : PROCEDURE(r : REFANY) : REFANY := NIL; > > (* If non-NIL, the allocator calls "callback(r)" just before returning > a new traced reference "r" and instead returns the result of > callback(r). > See "RTAllocStats" for an example client. It is a checked runtime > error > for the typecode of r to differ from the typecode of the return > value of > callback(r). *) > > Mika > > > From mika at async.caltech.edu Tue Apr 7 03:18:19 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 18:18:19 -0700 Subject: [M3devel] Implementing the "Singleton pattern" in Modula-3 In-Reply-To: Your message of "Tue, 07 Apr 2009 11:00:46 +1000." <110C0337-7E0A-4283-9F1C-BEBAF26929F8@cs.purdue.edu> Message-ID: <200904070118.n371IJQn002161@camembert.async.caltech.edu> Well I think the problem is with this "is known to be an object type"... You may in fact want to override the methods of the singleton, but ensure that only one ever gets instantiated. It's a minor problem, but it does sometimes bother me that it is difficult to prevent clients from NEWing pretty much anything they like. By the way, the "Modula-3 Type System" paper also talks about a nifty way to do narrowing very quickly (page 10, last paragraph). I remember this is occasionally problematic. (RTType.IsSubtype isn't great.) They speak of keeping an array of supertypes for each type, and recording the "depth" (distance from REFANY) of every type in, I guess, RT0.TypeDefn. This seems moderately space-efficient (better than a 2D array of all the typecodes), and very fast. Mika Tony Hosking writes: >I would exploit opaque types and branding. If T is opaque then you >cannot instantiate T except in scopes where T's concrete type has been >revealed or is known to be an object type. Thus, you could define an >interface: > >GENERIC INTERFACE Singleton(Rep); >TYPE T <: REFANY; >VAR t: T; >END Singleton. > >GENERIC MODULE Singleton(Rep); >REVEAL T = BRANDED REF Rep.T; >BEGIN > t := NEW(T); >END Singleton. > >where Rep defines the type T. You could do similar for object types. > > >On 7 Apr 2009, at 06:31, Mika Nystrom wrote: > >> >> Tony, Jay, you two seem to be most knowledgeable about this. >> >> Let's say I wanted to implement the "singleton pattern" in >> Modula-3. At present there seems to be no way of doing this. >> >> What about changing RTAllocator.callback as follows (or adding >> another callback): >> >> VAR callback : PROCEDURE(r : REFANY) : REFANY := NIL; >> >> (* If non-NIL, the allocator calls "callback(r)" just before returning >> a new traced reference "r" and instead returns the result of >> callback(r). >> See "RTAllocStats" for an example client. It is a checked runtime >> error >> for the typecode of r to differ from the typecode of the return >> value of >> callback(r). *) >> >> Mika >> >> >> From hosking at cs.purdue.edu Tue Apr 7 04:02:10 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 12:02:10 +1000 Subject: [M3devel] small objects In-Reply-To: <200904061529.n36FTTn0086974@camembert.async.caltech.edu> References: <200904061529.n36FTTn0086974@camembert.async.caltech.edu> Message-ID: <3F4FF36C-E96A-45F7-A345-4D557D424F52@cs.purdue.edu> On 7 Apr 2009, at 01:29, Mika Nystrom wrote: > Ah I should read my whole inbox before replying. As should I... ;-) > I take it you would worry that in my proposal (to do this all in a > library) the use of REFANY to store an integer could be abused > somehow. That the Modula-3 type system (as it exists now) explicitly > rules out doing such things, and therefore, a language change is > necessary.... My concern is the mismatch between NIL checking and tag-checking. I'd like to partition tagged references from regular references to keep things clean. I never liked overloading, especially for a systems language like Modula-3 where operations and typing should have a reasonable (and efficient) operational semantics. > > > Mika > > Tony Hosking writes: >> I like the notion of having a TAGGED INTEGER type that is a hybrid >> ordinal/reference. >> >> Subtyping rules for references would now be as follows: >> >> NULL <: REF T <: REFANY >> TAGGED INTEGER <: REF T <: REFANY >> >> ROOT <: REFANY >> NULL <: T OBJECT ... END <: T >> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: REFANY, >> not >> T <: ADDRESS) >> >> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >> type. Values of TAGGED INTEGER are non-pointer values similar to the >> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and NARROW(x, >> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to ISTYPE(x, >> NULL), NARROW(x, NULL), and TYPECODE(NULL). >> >> Because TAGGED INTEGER is an ordinal we can extract the integer value >> it holds using ORD(x). >> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >> INTEGER). >> >> ***The only problem with this scheme is how to efficiently perform >> run- >> time tests for dereferencing NULL, and TAGGED INTEGER?*** >> >> So, here is a slightly less elegant alternative that is probably >> straightforward to implement. Introduce a separate TAGGED hierarchy. >> >> NULL <: REF T <: REFANY >> NULL <: UNTRACED REF T <: ADDRESS >> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >> >> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >> >> ROOT <: REFANY >> TAGGED ROOT <: TAGGED REFANY >> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >> >> Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED >> REFANY. >> >> This way, tagged references only need a run-time test for the tag on >> dereference (we can throw an "attempt to dereference TAGGED INTEGER" >> at run time, just like we throw "attempt to dereference NIL" for >> untagged references). This check can be a straightforward test of >> the >> low bit tag. Of course, the weird thing here is now that we don't >> have a single NULL value for TAGGED references --- we have multiple >> null values VAL(x, TAGGED INTEGER). Instead of asking "x == NIL" we >> must ask "ISTYPE(x, TAGGED INTEGER)". >> >> Of course, because TAGGED INTEGER is an ordinal, we can also perform >> the usual ordinal operations like INC(x), DEC(x), wherever x is typed >> TAGGED INTEGER. >> >> >> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >> >>> I spent quite a bit of time playing with a more general system where >>> there is a set of "tagged" types, with (an implementation-defined >>> subrange of) INTEGER and a reference type both being a subtype of a >>> tagged type. It might have been tolerable, if it weren't for the >>> interaction with object subtypes and opaque types, which quickly >>> gets deep into a deep linguistic tar pit. >>> >>> Tony's approach is much simpler and would serve what I see as the >>> need. It does sacrifice any static checking of what reference type >>> is being tagged, and will also require an extra runtime ISTYPE/ >>> TYPECASE. >>> >>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>> also need to be an explicit conversion in that direction too, say >>> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >>> is a bit inconsistent with the usual Modula-3 assignability >>> philosophy, >>> but not requiring the explicit conversion already gets your toes >>> into tar. >>> >>> We would have to have something more like ISTYPE, though, which will >>> tell which type the value belongs to without risking a runtime >>> error, >>> which VAL would do. >>> >>> An intermediate approach might be to have a set of tagged types >>> constructed by, say, TAGGED T, where I is a reference type, but >>> with no subtype relations on them at all, thus still requiring >>> the explicit conversions and checks. >>> >>> I do want to say, I _really_ want this capability somehow. I have >>> an ADT module whose internal data structure, for full generality, >>> needs to have two heap objects (the second because it has nonstatic >>> size) and 11 total words counting the orginal pointer, in the case >>> of >>> values that would fit directly into the "pointer" word. Moreover, >>> these small cases are in the great majority. >>> >>> Besides the 11-to-one increase in actual occupied space, there >>> is extra time for allocation, periodic tracing, and collection, >>> space >>> loss due to heap fragmentation, and time/space tradeoff loss due to >>> reduced locality of reference. So sometimes, it would be a big >>> performance gain if we could do it. >>> >>> >>> Tony Hosking wrote: >>>> It is a much more pervasive hack than I would be comfortable with >>>> since it touches on the compiler (for all the type operations) as >>>> well >>>> as the run-time system in ways that are pretty gross. I would much >>>> rather have a new TAGGED builtin. ISTYPE would not work on it >>>> since >>>> that only works on references. The only thing you need is a way to >>>> extract the value -- we could overload VAL(x, T) where x can be a >>>> TAGGED and T can be REFANY or INTEGER. >>>> From hosking at cs.purdue.edu Tue Apr 7 04:03:35 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 12:03:35 +1000 Subject: [M3devel] small objects In-Reply-To: <200904062003.n36K3381094096@camembert.async.caltech.edu> References: <200904062003.n36K3381094096@camembert.async.caltech.edu> Message-ID: <92E0969B-63C7-43BE-A501-B78A5E520B55@cs.purdue.edu> On 7 Apr 2009, at 06:03, Mika Nystrom wrote: > "Rodney M. Bates" writes: >> At first, I just envisioned implementing a small object type >> entirely inside an UNSAFE module, using unsafe operations >> to construct/test/separate the values. I think if the GC were >> to just to ignore words in heap objects that the type system >> claims are unambiguously pointers but actually have misaligned >> values, this could be done. > > Right that's precisely what the module I posted does. > >> >> But it flies in the face of a fundamental principle of Modula-3, >> namely that an UNSAFE module, if coded correctly, can prevent >> all other code from consequences of the unsafety. Unfortunately, >> this can't be done with the small pointers, because, even if >> opaque, they are still reference types, and client code can >> dereference them (including the implicit dereference in accessing >> a method or field of an object) and do ISTYPE, NARROW, TYPECASE, >> and assignments that do an implicit NARROW. All these operations >> could be done outside the implementing module and all could >> suffer from misaligned values. > > Well yes that is true. But the client can't dereference REFANY. > Modula-3 doesn't permit that. That's an important practical point, > because now we're limited to the other things: ISTYPE, NARROW > (implicit and explicit), TYPECASE. (There are two more, actually, > and they are = and #.) As long as those can be guaranteed to fail > you're OK. [ Actually see my P.S. below! ] > >> >> In fact, misaligned integer "objects" violate another principle that >> the bit pattern must always be a valid representation of some value >> of the type. > > Yes I think maybe this is what Tony is worried about. But let's > just change the definition of REFANY to include anything with the > LSB set...? But then a "NULL" check needs to both test for zero and test for lsb set. I am not comfortable with this. > In Modula-3-ese it would be more like the following: > > "REFANY can hold three types of objects. NIL, REF something or an > implementation-defined other set of values that can only be accessed > in an UNSAFE module. It is a checked runtime error to pass a 'REFANY > of the third kind' to ISTYPE, NARROW, TYPECASE." [ Actually see my > P.S. below! ] > > Then I propose we punt the handling of the new REFANYs to this > unsafe module we spoke about above. As far as Modula-3 is concerned, > there's just a set of values of (apparently) very little utility > that can be represented by REFANY. If you think about it, this is > really not so crazy. Any module that uses REFANY today is designed > around to the fact that there are plenty of values of REFANY that > can be of no interest to that module except for passing along to > another module. (REFANY can easily represent a type which a module > has no way of accessing *any* declaration of beyond just REFANY.) > We're just adding some others, the only difference being that the > new values are of no interest to any non-UNSAFE module. (Eh, > technically this is already true for any reference type that is > declared in an UNSAFE module today so one might argue we have in > fact added nothing.) > >> >> However, this does suggest a different and very simple linguistic >> solution: Just have a new builtin type, say VERYOPAQUE, that >> supports no operations other than moving it around, i.e., >> assignment, bindings, passing as a parameter, etc. Only unsafe >> code could do anyhing with it, by using LOOPHOLE. The only >> problem is, would somebody then want one of these in a size other >> than one word? > > This is nice, and we already have a candidate type, in fact: ADDRESS. > But the problem is that the GC doesn't follow this even if the LSB > is clear... which we *do* want. > > Why are you worried about getting it in sizes other than one word? > That seems to me to be an application problem. If someone wants > an ARRAY OF VERYOPAQUE is that a problem? > > Mika > > P.S. Illustration of the above, in today's Modula-3: > > UNSAFE MODULE Unsafe; > > (* this module is just declared UNSAFE to conform with the definition > above, namely, that T can only be manipulated in an UNSAFE > module, which this is! *) > > TYPE T = BRANDED OBJECT END; > > BEGIN > Safe.P(NEW(T)) > END Unsafe. > > (****************************************) > > MODULE Safe; > > PROCEDURE P(r : REFANY) = > BEGIN > NARROW(r, X); (* checked runtime error for all X *) > > ISTYPE(r, X); (* returns FALSE for all X except REFANY itself *) > > TYPECASE r OF > X => (* only gets executed for X = REFANY *) > END; > END P; > > BEGIN END Safe. > > Actually is this behavior so bad for tagged integers? Since it is > the behavior of existing code... why not keep it? Then you can even > store a tagged integer in a RefList.T, say, even if that RefList.T > uses NARROW or ISTYPE on the argument (I don't see why it would, but > why not...?) > > > >> >> Mika Nystrom wrote: >>> Ah I should read my whole inbox before replying. >>> >>> I take it you would worry that in my proposal (to do this all in a >>> library) the use of REFANY to store an integer could be abused >>> somehow. That the Modula-3 type system (as it exists now) >>> explicitly >>> rules out doing such things, and therefore, a language change is >>> necessary.... >>> >>> Mika >>> >>> Tony Hosking writes: >>> >>>> I like the notion of having a TAGGED INTEGER type that is a hybrid >>>> ordinal/reference. >>>> >>>> Subtyping rules for references would now be as follows: >>>> >>>> NULL <: REF T <: REFANY >>>> TAGGED INTEGER <: REF T <: REFANY >>>> >>>> ROOT <: REFANY >>>> NULL <: T OBJECT ... END <: T >>>> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: >>>> REFANY, not >>>> T <: ADDRESS) >>>> >>>> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >>>> type. Values of TAGGED INTEGER are non-pointer values similar to >>>> the >>>> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and NARROW(x, >>>> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to >>>> ISTYPE(x, >>>> NULL), NARROW(x, NULL), and TYPECODE(NULL). >>>> >>>> Because TAGGED INTEGER is an ordinal we can extract the integer >>>> value >>>> it holds using ORD(x). >>>> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >>>> INTEGER). >>>> >>>> ***The only problem with this scheme is how to efficiently >>>> perform run- >>>> time tests for dereferencing NULL, and TAGGED INTEGER?*** >>> >>>> So, here is a slightly less elegant alternative that is probably >>>> straightforward to implement. Introduce a separate TAGGED >>>> hierarchy. >>>> >>>> NULL <: REF T <: REFANY >>>> NULL <: UNTRACED REF T <: ADDRESS >>>> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >>>> >>>> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >>>> >>>> ROOT <: REFANY >>>> TAGGED ROOT <: TAGGED REFANY >>>> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >>>> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >>>> >>>> Note that NULL is not a subtype of T OBJECT ... END where T <: >>>> TAGGED >>>> REFANY. >>>> >>>> This way, tagged references only need a run-time test for the tag >>>> on >>>> dereference (we can throw an "attempt to dereference TAGGED >>>> INTEGER" >>>> at run time, just like we throw "attempt to dereference NIL" for >>>> untagged references). This check can be a straightforward test >>>> of the >>>> low bit tag. Of course, the weird thing here is now that we don't >>>> have a single NULL value for TAGGED references --- we have multiple >>>> null values VAL(x, TAGGED INTEGER). Instead of asking "x == NIL" >>>> we >>>> must ask "ISTYPE(x, TAGGED INTEGER)". >>>> >>>> Of course, because TAGGED INTEGER is an ordinal, we can also >>>> perform >>>> the usual ordinal operations like INC(x), DEC(x), wherever x is >>>> typed >>>> TAGGED INTEGER. >>>> >>>> >>>> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >>>> >>>> >>>>> I spent quite a bit of time playing with a more general system >>>>> where >>>>> there is a set of "tagged" types, with (an implementation-defined >>>>> subrange of) INTEGER and a reference type both being a subtype >>>>> of a >>>>> tagged type. It might have been tolerable, if it weren't for the >>>>> interaction with object subtypes and opaque types, which quickly >>>>> gets deep into a deep linguistic tar pit. >>>>> >>>>> Tony's approach is much simpler and would serve what I see as the >>>>> need. It does sacrifice any static checking of what reference >>>>> type >>>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>>> TYPECASE. >>>>> >>>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>>> also need to be an explicit conversion in that direction too, say >>>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >>>>> is a bit inconsistent with the usual Modula-3 assignability >>>>> philosophy, >>>>> but not requiring the explicit conversion already gets your toes >>>>> into tar. >>>>> >>>>> We would have to have something more like ISTYPE, though, which >>>>> will >>>>> tell which type the value belongs to without risking a runtime >>>>> error, >>>>> which VAL would do. >>>>> >>>>> An intermediate approach might be to have a set of tagged types >>>>> constructed by, say, TAGGED T, where I is a reference type, but >>>>> with no subtype relations on them at all, thus still requiring >>>>> the explicit conversions and checks. >>>>> >>>>> I do want to say, I _really_ want this capability somehow. I have >>>>> an ADT module whose internal data structure, for full generality, >>>>> needs to have two heap objects (the second because it has >>>>> nonstatic >>>>> size) and 11 total words counting the orginal pointer, in the >>>>> case of >>>>> values that would fit directly into the "pointer" word. >>>>> Moreover, >>>>> these small cases are in the great majority. >>>>> >>>>> Besides the 11-to-one increase in actual occupied space, there >>>>> is extra time for allocation, periodic tracing, and collection, >>>>> space >>>>> loss due to heap fragmentation, and time/space tradeoff loss due >>>>> to >>>>> reduced locality of reference. So sometimes, it would be a big >>>>> performance gain if we could do it. >>>>> >>>>> >>>>> Tony Hosking wrote: >>>>> >>>>>> It is a much more pervasive hack than I would be comfortable with >>>>>> since it touches on the compiler (for all the type operations) as >>>>>> well >>>>>> as the run-time system in ways that are pretty gross. I would >>>>>> much >>>>>> rather have a new TAGGED builtin. ISTYPE would not work on it >>>>>> since >>>>>> that only works on references. The only thing you need is a >>>>>> way to >>>>>> extract the value -- we could overload VAL(x, T) where x can be a >>>>>> TAGGED and T can be REFANY or INTEGER. >>>>>> >>>>>> >>> >>> From hosking at cs.purdue.edu Tue Apr 7 04:04:51 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 12:04:51 +1000 Subject: [M3devel] small objects In-Reply-To: <200904062017.n36KHbcq094473@camembert.async.caltech.edu> References: <200904062017.n36KHbcq094473@camembert.async.caltech.edu> Message-ID: <06AB3448-B400-4D98-8283-399355263471@cs.purdue.edu> I still don't understand the objections to my proposal. I think it is a similarly small change that does not pollute the old REFANY hierarchy. On 7 Apr 2009, at 06:17, Mika Nystrom wrote: > Ok I admit I missed something important. > > TYPECODE. > > It's easy enough to allocate a special TYPECODE to the tagged > integer. One not used by any "real" type of course. > > It will break pickles and fingerprints. Pickles can be fixed, > check the typecode and call a routine in the TaggedInteger > interface (by default, user can override it?) to translate > to and fro. > > But what about fingerprints? Again I guess we can just > return the fingerprint of a nonexistent > type............................. > > Hummm humm. > > Ok, how about this... > > let's declare a completely hidden type ... > > UNSAFE MODULE TaggedInteger; > > TYPE T = BRANDED OBJECT x : INTEGER END; > > BEGIN END TaggedInteger. > > Now, fix up TYPECODE, ISTYPE, NARROW, TYPECASE so that they all > act *precisely* as if TaggedInteger.T were passed to them, > when they see a REFANY with the LSB set. fingerprinting the > type will give you the fingerprint of TaggedInteger.T. (But > you better not rely on that! Only UNSAFE modules can do anything > with this information, anyhow, so who cares, but see below.) > > I don't see how this breaks anything at all once we introduce the > 'REFANY of the third kind', which is so small a change to the > language's type system that I'm not sure it even qualifies as a > change. Pickles are already unsafe, so the fact that the current > pickles package would subvert the type system based on what I propose > is a non-issue (language wise), it just means a few extra lines of > code in the pickles package. > > The reason for the x : field above is that I propose that this > be how the tagged integer be un/pickled, as an instance of an > object of the (actual) type TaggedInteger.T. > > Mika > > > > > Mika Nystrom writes: >> "Rodney M. Bates" writes: >>> At first, I just envisioned implementing a small object type >>> entirely inside an UNSAFE module, using unsafe operations >>> to construct/test/separate the values. I think if the GC were >>> to just to ignore words in heap objects that the type system >>> claims are unambiguously pointers but actually have misaligned >>> values, this could be done. >> >> Right that's precisely what the module I posted does. >> >>> >>> But it flies in the face of a fundamental principle of Modula-3, >>> namely that an UNSAFE module, if coded correctly, can prevent >>> all other code from consequences of the unsafety. Unfortunately, >>> this can't be done with the small pointers, because, even if >>> opaque, they are still reference types, and client code can >>> dereference them (including the implicit dereference in accessing >>> a method or field of an object) and do ISTYPE, NARROW, TYPECASE, >>> and assignments that do an implicit NARROW. All these operations >>> could be done outside the implementing module and all could >>> suffer from misaligned values. >> >> Well yes that is true. But the client can't dereference REFANY. >> Modula-3 doesn't permit that. That's an important practical point, >> because now we're limited to the other things: ISTYPE, NARROW >> (implicit and explicit), TYPECASE. (There are two more, actually, >> and they are = and #.) As long as those can be guaranteed to fail >> you're OK. [ Actually see my P.S. below! ] >> >>> >>> In fact, misaligned integer "objects" violate another principle >>> that >>> the bit pattern must always be a valid representation of some value >>> of the type. >> >> Yes I think maybe this is what Tony is worried about. But let's >> just change the definition of REFANY to include anything with the >> LSB set...? >> >> In Modula-3-ese it would be more like the following: >> >> "REFANY can hold three types of objects. NIL, REF something or an >> implementation-defined other set of values that can only be accessed >> in an UNSAFE module. It is a checked runtime error to pass a 'REFANY >> of the third kind' to ISTYPE, NARROW, TYPECASE." [ Actually see my >> P.S. below! ] >> >> Then I propose we punt the handling of the new REFANYs to this >> unsafe module we spoke about above. As far as Modula-3 is concerned, >> there's just a set of values of (apparently) very little utility >> that can be represented by REFANY. If you think about it, this is >> really not so crazy. Any module that uses REFANY today is designed >> around to the fact that there are plenty of values of REFANY that >> can be of no interest to that module except for passing along to >> another module. (REFANY can easily represent a type which a module >> has no way of accessing *any* declaration of beyond just REFANY.) >> We're just adding some others, the only difference being that the >> new values are of no interest to any non-UNSAFE module. (Eh, >> technically this is already true for any reference type that is >> declared in an UNSAFE module today so one might argue we have in >> fact added nothing.) >> >>> >>> However, this does suggest a different and very simple linguistic >>> solution: Just have a new builtin type, say VERYOPAQUE, that >>> supports no operations other than moving it around, i.e., >>> assignment, bindings, passing as a parameter, etc. Only unsafe >>> code could do anyhing with it, by using LOOPHOLE. The only >>> problem is, would somebody then want one of these in a size other >>> than one word? >> >> This is nice, and we already have a candidate type, in fact: ADDRESS. >> But the problem is that the GC doesn't follow this even if the LSB >> is clear... which we *do* want. >> >> Why are you worried about getting it in sizes other than one word? >> That seems to me to be an application problem. If someone wants >> an ARRAY OF VERYOPAQUE is that a problem? >> >> Mika >> >> P.S. Illustration of the above, in today's Modula-3: >> >> UNSAFE MODULE Unsafe; >> >> (* this module is just declared UNSAFE to conform with the definition >> above, namely, that T can only be manipulated in an UNSAFE >> module, which this is! *) >> >> TYPE T = BRANDED OBJECT END; >> >> BEGIN >> Safe.P(NEW(T)) >> END Unsafe. >> >> (****************************************) >> >> MODULE Safe; >> >> PROCEDURE P(r : REFANY) = >> BEGIN >> NARROW(r, X); (* checked runtime error for all X *) >> >> ISTYPE(r, X); (* returns FALSE for all X except REFANY itself *) >> >> TYPECASE r OF >> X => (* only gets executed for X = REFANY *) >> END; >> END P; >> >> BEGIN END Safe. >> >> Actually is this behavior so bad for tagged integers? Since it is >> the behavior of existing code... why not keep it? Then you can even >> store a tagged integer in a RefList.T, say, even if that RefList.T >> uses NARROW or ISTYPE on the argument (I don't see why it would, but >> why not...?) >> >> >> >>> >>> Mika Nystrom wrote: >>>> Ah I should read my whole inbox before replying. >>>> >>>> I take it you would worry that in my proposal (to do this all in a >>>> library) the use of REFANY to store an integer could be abused >>>> somehow. That the Modula-3 type system (as it exists now) >>>> explicitly >>>> rules out doing such things, and therefore, a language change is >>>> necessary.... >>>> >>>> Mika >>>> >>>> Tony Hosking writes: >>>> >>>>> I like the notion of having a TAGGED INTEGER type that is a hybrid >>>>> ordinal/reference. >>>>> >>>>> Subtyping rules for references would now be as follows: >>>>> >>>>> NULL <: REF T <: REFANY >>>>> TAGGED INTEGER <: REF T <: REFANY >>>>> >>>>> ROOT <: REFANY >>>>> NULL <: T OBJECT ... END <: T >>>>> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: >>>>> REFANY, not >>>>> T <: ADDRESS) >>>>> >>>>> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >>>>> type. Values of TAGGED INTEGER are non-pointer values similar >>>>> to the >>>>> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and >>>>> NARROW(x, >>>>> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to >>>>> ISTYPE(x, >>>>> NULL), NARROW(x, NULL), and TYPECODE(NULL). >>>>> >>>>> Because TAGGED INTEGER is an ordinal we can extract the integer >>>>> value >>>>> it holds using ORD(x). >>>>> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >>>>> INTEGER). >>>>> >>>>> ***The only problem with this scheme is how to efficiently >>>>> perform run- >>>>> time tests for dereferencing NULL, and TAGGED INTEGER?*** >>>> >>>>> So, here is a slightly less elegant alternative that is probably >>>>> straightforward to implement. Introduce a separate TAGGED >>>>> hierarchy. >>>>> >>>>> NULL <: REF T <: REFANY >>>>> NULL <: UNTRACED REF T <: ADDRESS >>>>> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >>>>> >>>>> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >>>>> >>>>> ROOT <: REFANY >>>>> TAGGED ROOT <: TAGGED REFANY >>>>> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >>>>> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >>>>> >>>>> Note that NULL is not a subtype of T OBJECT ... END where T <: >>>>> TAGGED >>>>> REFANY. >>>>> >>>>> This way, tagged references only need a run-time test for the >>>>> tag on >>>>> dereference (we can throw an "attempt to dereference TAGGED >>>>> INTEGER" >>>>> at run time, just like we throw "attempt to dereference NIL" for >>>>> untagged references). This check can be a straightforward test >>>>> of the >>>>> low bit tag. Of course, the weird thing here is now that we don't >>>>> have a single NULL value for TAGGED references --- we have >>>>> multiple >>>>> null values VAL(x, TAGGED INTEGER). Instead of asking "x == >>>>> NIL" we >>>>> must ask "ISTYPE(x, TAGGED INTEGER)". >>>>> >>>>> Of course, because TAGGED INTEGER is an ordinal, we can also >>>>> perform >>>>> the usual ordinal operations like INC(x), DEC(x), wherever x is >>>>> typed >>>>> TAGGED INTEGER. >>>>> >>>>> >>>>> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >>>>> >>>>> >>>>>> I spent quite a bit of time playing with a more general system >>>>>> where >>>>>> there is a set of "tagged" types, with (an implementation-defined >>>>>> subrange of) INTEGER and a reference type both being a subtype >>>>>> of a >>>>>> tagged type. It might have been tolerable, if it weren't for the >>>>>> interaction with object subtypes and opaque types, which quickly >>>>>> gets deep into a deep linguistic tar pit. >>>>>> >>>>>> Tony's approach is much simpler and would serve what I see as the >>>>>> need. It does sacrifice any static checking of what reference >>>>>> type >>>>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>>>> TYPECASE. >>>>>> >>>>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>>>> also need to be an explicit conversion in that direction too, say >>>>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. >>>>>> It >>>>>> is a bit inconsistent with the usual Modula-3 assignability >>>>>> philosophy, >>>>>> but not requiring the explicit conversion already gets your toes >>>>>> into tar. >>>>>> >>>>>> We would have to have something more like ISTYPE, though, which >>>>>> will >>>>>> tell which type the value belongs to without risking a runtime >>>>>> error, >>>>>> which VAL would do. >>>>>> >>>>>> An intermediate approach might be to have a set of tagged types >>>>>> constructed by, say, TAGGED T, where I is a reference type, but >>>>>> with no subtype relations on them at all, thus still requiring >>>>>> the explicit conversions and checks. >>>>>> >>>>>> I do want to say, I _really_ want this capability somehow. I >>>>>> have >>>>>> an ADT module whose internal data structure, for full generality, >>>>>> needs to have two heap objects (the second because it has >>>>>> nonstatic >>>>>> size) and 11 total words counting the orginal pointer, in the >>>>>> case of >>>>>> values that would fit directly into the "pointer" word. >>>>>> Moreover, >>>>>> these small cases are in the great majority. >>>>>> >>>>>> Besides the 11-to-one increase in actual occupied space, there >>>>>> is extra time for allocation, periodic tracing, and collection, >>>>>> space >>>>>> loss due to heap fragmentation, and time/space tradeoff loss >>>>>> due to >>>>>> reduced locality of reference. So sometimes, it would be a big >>>>>> performance gain if we could do it. >>>>>> >>>>>> >>>>>> Tony Hosking wrote: >>>>>> >>>>>>> It is a much more pervasive hack than I would be comfortable >>>>>>> with >>>>>>> since it touches on the compiler (for all the type operations) >>>>>>> as >>>>>>> well >>>>>>> as the run-time system in ways that are pretty gross. I would >>>>>>> much >>>>>>> rather have a new TAGGED builtin. ISTYPE would not work on it >>>>>>> since >>>>>>> that only works on references. The only thing you need is a >>>>>>> way to >>>>>>> extract the value -- we could overload VAL(x, T) where x can >>>>>>> be a >>>>>>> TAGGED and T can be REFANY or INTEGER. >>>>>>> >>>>>>> >>>> >>>> From hosking at cs.purdue.edu Tue Apr 7 04:07:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 12:07:19 +1000 Subject: [M3devel] Implementing the "Singleton pattern" in Modula-3 In-Reply-To: <200904070118.n371IJQn002161@camembert.async.caltech.edu> References: <200904070118.n371IJQn002161@camembert.async.caltech.edu> Message-ID: On 7 Apr 2009, at 11:18, Mika Nystrom wrote: > Well I think the problem is with this "is known to be an object > type"... But if the opaque type T is T<:REFANY and the only revelation is branded and private to a module (not exported by its interfaces) then no-one can determine that it is an object type without forging the BRAND. > You may in fact want to override the methods of the singleton, but > ensure that only one ever gets instantiated. > > It's a minor problem, but it does sometimes bother me that it is > difficult to prevent clients from NEWing pretty much anything they > like. > > By the way, the "Modula-3 Type System" paper also talks about a > nifty way to do narrowing very quickly (page 10, last paragraph). > I remember this is occasionally problematic. (RTType.IsSubtype > isn't great.) They speak of keeping an array of supertypes > for each type, and recording the "depth" (distance from REFANY) > of every type in, I guess, RT0.TypeDefn. This seems moderately > space-efficient (better than a 2D array of all the typecodes), > and very fast. > > Mika > > Tony Hosking writes: >> I would exploit opaque types and branding. If T is opaque then you >> cannot instantiate T except in scopes where T's concrete type has >> been >> revealed or is known to be an object type. Thus, you could define an >> interface: >> >> GENERIC INTERFACE Singleton(Rep); >> TYPE T <: REFANY; >> VAR t: T; >> END Singleton. >> >> GENERIC MODULE Singleton(Rep); >> REVEAL T = BRANDED REF Rep.T; >> BEGIN >> t := NEW(T); >> END Singleton. >> >> where Rep defines the type T. You could do similar for object types. >> >> >> On 7 Apr 2009, at 06:31, Mika Nystrom wrote: >> >>> >>> Tony, Jay, you two seem to be most knowledgeable about this. >>> >>> Let's say I wanted to implement the "singleton pattern" in >>> Modula-3. At present there seems to be no way of doing this. >>> >>> What about changing RTAllocator.callback as follows (or adding >>> another callback): >>> >>> VAR callback : PROCEDURE(r : REFANY) : REFANY := NIL; >>> >>> (* If non-NIL, the allocator calls "callback(r)" just before >>> returning >>> a new traced reference "r" and instead returns the result of >>> callback(r). >>> See "RTAllocStats" for an example client. It is a checked runtime >>> error >>> for the typecode of r to differ from the typecode of the return >>> value of >>> callback(r). *) >>> >>> Mika >>> >>> >>> From hosking at cs.purdue.edu Tue Apr 7 04:16:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 12:16:29 +1000 Subject: [M3devel] small objects In-Reply-To: <200904070042.n370gNK3001242@camembert.async.caltech.edu> References: <200904070042.n370gNK3001242@camembert.async.caltech.edu> Message-ID: <9F2237E2-73A2-4926-A438-A6032F70B4F6@cs.purdue.edu> On 7 Apr 2009, at 10:42, Mika Nystrom wrote: > You mean this proposal (you had two, I think)? Yes, this is the proposal I converged on. It really is only minimal change to the type system: introduction of a third hierarchy of TAGGED reference types. I did something similar for orthogonal persistence a few years ago where it was useful to have a TRANSIENT reference hierarchy for things that should not persist. [The semantics was that every run of a program would initialize TRANSIENT references to NIL rather than have them have the persistent value. This was slightly messier in that I also permitted TRANSIENT REFANY <: REFANY, which was a little odd.] > -- > > NULL <: REF T <: REFANY > NULL <: UNTRACED REF T <: ADDRESS > TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY > > Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. > > ROOT <: REFANY > TAGGED ROOT <: TAGGED REFANY > NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS > TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY > > Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED > REFANY. > > --- > > I like it fine, I think... I'm just worried, generally, about > changing the type system. Hmmmm... you mean that the TAGGED > things would just be a separate hierarchy? The change is relatively minor in that it doesn't touch the original REFANY hierarchy. > So you'd just add TAGGED in front of the REFs for this new hierarchy. > But why no NULL? No NULL because then we need a test for both NIL and values of type TAGGED INTEGER on every dereference. You can easily declare: TYPE Null = TAGGED INTEGER; CONST Nil = VAL(0, TAGGED INTEGER); The point is that TAGGED INTEGER now lets you have a range of non- pointer reference values, whereas NIL is the singleton non-reference value in type NULL. > And you're comfortable with doing the conversions automatically? No, I said that the conversions needed to be explicit > > So > > tx : TAGGED INTEGER := 5; tx: TAGGED INTEGER := VAL(5,TAGGED INTEGER); > x : INTEGER := tx; x: INTEGER := ORD(tx); > would be OK? > > In that case it's just the m3tk that needs to be modified, and > that's just busy work, I think. If it works it's beautiful... As I said, I am almost done with the compiler changes, and only need to push it into the run-time. Things like m3tk and pickles will need to be smartened up as necessary. > > > Mika > > > > Tony Hosking writes: >> I really don't like your proposal for the reasons you mention. It >> makes regular REF more expensive than it currently is. What is it >> about my relatively minor changes to the type system that you object >> to? I've just about finished changing the compiler front-end (in >> relatively minor ways) to accomodate the proposal I made yesterday. >> And it has the advantage of separating REF from TAGGED REF so we keep >> the standard REF clean. >> >> On 7 Apr 2009, at 00:50, Mika Nystrom wrote: >> >>> Hi Rodney, >>> >>> I would like this capability too, but I am a bit wary of Tony's >>> idea of changing the Modula-3 language---even in a "minor" way. >>> I've been working for the last week or so on an application using >>> the Modula-3 Toolkit, and I must say I have realized that the >> Modula-3 type system has a lot more subtleties than I thought. I >>> would not want to make any real changes to it. There's a paper >>> called "The Modula-3 Type System" by Cardelli, Donahue, Kalsow, and >>> Nelson that is worth studying in detail before making any changes >>> whatsoever, I think. Also remember that changes to the type system >>> will affect m3tk and anything that depends on m3tk (which includes >>> two or three stub generators in the main tree and who knows how >>> many dependencies outside of it). >>> >>> I'm still not sure why we can't take the approach of Word.T . >>> Make a RefanyOrInt.T that can safely be: >>> >>> 1. Tested whether it is a small integer or a REFANY >>> >>> 2. If a REFANY, be dereferenced as normal, *or* via >>> RefanyOrInt.ToRefany >>> >>> 3. If a small integer, can be extracted via RefanyOrInt.ToInt >>> >>> 4. Created either as a small integer or a REFANY >>> >>> Any other operations on it (including ISTYPE and TYPECASE, at least >>> when the object is a small integer) would result in a checked >>> runtime >>> error. >>> >>> Note that with the declaration "RefanyOrInt.T = REFANY", the current >>> compiler will as far as I know not accept any operations on >>> RefanyOrInt.T outside of ISTYPE, TYPECASE, and NARROW (explicit or >>> implicit). >>> >>> I wouldn't be surprised if most of what I'm proposing already works >>> (i.e., crashes with a checked runtime error as it should) with the >>> current runtime. Anything that slips through would need to be fixed >>> up with a one-bit check of the LSB of the REFANY for the operations >>> mentioned above. Unfortunately this has to be done for operations >>> on >>> every REFANY, not just the new type. >>> >>> I think that Modula-3 programmers are already aware that using >>> REFANYs involves forcing the runtime to do extra type-checking work, >>> so they already know not to use them if they are looking for maximum >>> performance, so I don't think that burdening operations on REFANY >>> with an extra one-bit check is too onerous. >>> >>> An advantage of my proposal is that the amount of code in the new >>> proposed library is truly diminutive. In fact, I think I posted >>> pretty much that code to the list a few weeks ago. >>> >>> (If you missed it, it's >>> >>> http://www.async.caltech.edu/~mika/interp/ >>> >>> ) >>> >>> Mika >>> >>> >>> "Rodney M. Bates" writes: >>>> I spent quite a bit of time playing with a more general system >>>> where >>>> there is a set of "tagged" types, with (an implementation-defined >>>> subrange of) INTEGER and a reference type both being a subtype of a >>>> tagged type. It might have been tolerable, if it weren't for the >>>> interaction with object subtypes and opaque types, which quickly >>>> gets deep into a deep linguistic tar pit. >>>> >>>> Tony's approach is much simpler and would serve what I see as the >>>> need. It does sacrifice any static checking of what reference type >>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>> TYPECASE. >>>> >>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>> also need to be an explicit conversion in that direction too, say >>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >>>> is a bit inconsistent with the usual Modula-3 assignability >>>> philosophy, >>>> but not requiring the explicit conversion already gets your toes >>>> into tar. >>>> >>>> We would have to have something more like ISTYPE, though, which >>>> will >>>> tell which type the value belongs to without risking a runtime >>>> error, >>>> which VAL would do. >>>> >>>> An intermediate approach might be to have a set of tagged types >>>> constructed by, say, TAGGED T, where I is a reference type, but >>>> with no subtype relations on them at all, thus still requiring >>>> the explicit conversions and checks. >>>> >>>> I do want to say, I _really_ want this capability somehow. I have >>>> an ADT module whose internal data structure, for full generality, >>>> needs to have two heap objects (the second because it has nonstatic >>>> size) and 11 total words counting the orginal pointer, in the >>>> case of >>>> values that would fit directly into the "pointer" word. Moreover, >>>> these small cases are in the great majority. >>>> >>>> Besides the 11-to-one increase in actual occupied space, there >>>> is extra time for allocation, periodic tracing, and collection, >>>> space >>>> loss due to heap fragmentation, and time/space tradeoff loss due to >>>> reduced locality of reference. So sometimes, it would be a big >>>> performance gain if we could do it. >>>> >>>> >>>> Tony Hosking wrote: >>>> It is a much more pervasive hack than I would be comfortable with >>>>> since it touches on the compiler (for all the type operations) as >>>>> well >>>>> as the run-time system in ways that are pretty gross. I would >>>>> much >>>>> rather have a new TAGGED builtin. ISTYPE would not work on it >>>>> since >>>>> that only works on references. The only thing you need is a way >>>>> to >>>>> extract the value -- we could overload VAL(x, T) where x can be a >>>>> TAGGED and T can be REFANY or INTEGER. >>>>> >>>>> From rcoleburn at scires.com Tue Apr 7 04:27:42 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 06 Apr 2009 22:27:42 -0400 Subject: [M3devel] small objects In-Reply-To: <9F2237E2-73A2-4926-A438-A6032F70B4F6@cs.purdue.edu> References: <200904070042.n370gNK3001242@camembert.async.caltech.edu> <9F2237E2-73A2-4926-A438-A6032F70B4F6@cs.purdue.edu> Message-ID: <49DA8196.1E75.00D7.1@scires.com> Hey, will this proposal mean that packages like "stable" and "stubgen" need to be changed also, in addition to both versions of pickles? What about any package that deals with parsing of M3 code, e.g. pretty-printers, CM3IDE, etc.? Regards, Randy >>> Tony Hosking 4/6/2009 10:16 PM >>> On 7 Apr 2009, at 10:42, Mika Nystrom wrote: > You mean this proposal (you had two, I think)? Yes, this is the proposal I converged on. It really is only minimal change to the type system: introduction of a third hierarchy of TAGGED reference types. I did something similar for orthogonal persistence a few years ago where it was useful to have a TRANSIENT reference hierarchy for things that should not persist. [The semantics was that every run of a program would initialize TRANSIENT references to NIL rather than have them have the persistent value. This was slightly messier in that I also permitted TRANSIENT REFANY <: REFANY, which was a little odd.] > -- > > NULL <: REF T <: REFANY > NULL <: UNTRACED REF T <: ADDRESS > TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY > > Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. > > ROOT <: REFANY > TAGGED ROOT <: TAGGED REFANY > NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS > TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY > > Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED > REFANY. > > --- > > I like it fine, I think... I'm just worried, generally, about > changing the type system. Hmmmm... you mean that the TAGGED > things would just be a separate hierarchy? The change is relatively minor in that it doesn't touch the original REFANY hierarchy. > So you'd just add TAGGED in front of the REFs for this new hierarchy. > But why no NULL? No NULL because then we need a test for both NIL and values of type TAGGED INTEGER on every dereference. You can easily declare: TYPE Null = TAGGED INTEGER; CONST Nil = VAL(0, TAGGED INTEGER); The point is that TAGGED INTEGER now lets you have a range of non- pointer reference values, whereas NIL is the singleton non-reference value in type NULL. > And you're comfortable with doing the conversions automatically? No, I said that the conversions needed to be explicit > > So > > tx : TAGGED INTEGER := 5; tx: TAGGED INTEGER := VAL(5,TAGGED INTEGER); > x : INTEGER := tx; x: INTEGER := ORD(tx); > would be OK? > > In that case it's just the m3tk that needs to be modified, and > that's just busy work, I think. If it works it's beautiful... As I said, I am almost done with the compiler changes, and only need to push it into the run-time. Things like m3tk and pickles will need to be smartened up as necessary. > > > Mika > > > > Tony Hosking writes: >> I really don't like your proposal for the reasons you mention. It >> makes regular REF more expensive than it currently is. What is it >> about my relatively minor changes to the type system that you object >> to? I've just about finished changing the compiler front-end (in >> relatively minor ways) to accomodate the proposal I made yesterday. >> And it has the advantage of separating REF from TAGGED REF so we keep >> the standard REF clean. >> >> On 7 Apr 2009, at 00:50, Mika Nystrom wrote: >> >>> Hi Rodney, >>> >>> I would like this capability too, but I am a bit wary of Tony's >>> idea of changing the Modula-3 language---even in a "minor" way. >>> I've been working for the last week or so on an application using >>> the Modula-3 Toolkit, and I must say I have realized that the >> Modula-3 type system has a lot more subtleties than I thought. I >>> would not want to make any real changes to it. There's a paper >>> called "The Modula-3 Type System" by Cardelli, Donahue, Kalsow, and >>> Nelson that is worth studying in detail before making any changes >>> whatsoever, I think. Also remember that changes to the type system >>> will affect m3tk and anything that depends on m3tk (which includes >>> two or three stub generators in the main tree and who knows how >>> many dependencies outside of it). >>> >>> I'm still not sure why we can't take the approach of Word.T . >>> Make a RefanyOrInt.T that can safely be: >>> >>> 1. Tested whether it is a small integer or a REFANY >>> >>> 2. If a REFANY, be dereferenced as normal, *or* via >>> RefanyOrInt.ToRefany >>> >>> 3. If a small integer, can be extracted via RefanyOrInt.ToInt >>> >>> 4. Created either as a small integer or a REFANY >>> >>> Any other operations on it (including ISTYPE and TYPECASE, at least >>> when the object is a small integer) would result in a checked >>> runtime >>> error. >>> >>> Note that with the declaration "RefanyOrInt.T = REFANY", the current >>> compiler will as far as I know not accept any operations on >>> RefanyOrInt.T outside of ISTYPE, TYPECASE, and NARROW (explicit or >>> implicit). >>> >>> I wouldn't be surprised if most of what I'm proposing already works >>> (i.e., crashes with a checked runtime error as it should) with the >>> current runtime. Anything that slips through would need to be fixed >>> up with a one-bit check of the LSB of the REFANY for the operations >>> mentioned above. Unfortunately this has to be done for operations >>> on >>> every REFANY, not just the new type. >>> >>> I think that Modula-3 programmers are already aware that using >>> REFANYs involves forcing the runtime to do extra type-checking work, >>> so they already know not to use them if they are looking for maximum >>> performance, so I don't think that burdening operations on REFANY >>> with an extra one-bit check is too onerous. >>> >>> An advantage of my proposal is that the amount of code in the new >>> proposed library is truly diminutive. In fact, I think I posted >>> pretty much that code to the list a few weeks ago. >>> >>> (If you missed it, it's >>> >>> http://www.async.caltech.edu/~mika/interp/ >>> >>> ) >>> >>> Mika >>> >>> >>> "Rodney M. Bates" writes: >>>> I spent quite a bit of time playing with a more general system >>>> where >>>> there is a set of "tagged" types, with (an implementation-defined >>>> subrange of) INTEGER and a reference type both being a subtype of a >>>> tagged type. It might have been tolerable, if it weren't for the >>>> interaction with object subtypes and opaque types, which quickly >>>> gets deep into a deep linguistic tar pit. >>>> >>>> Tony's approach is much simpler and would serve what I see as the >>>> need. It does sacrifice any static checking of what reference type >>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>> TYPECASE. >>>> >>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>> also need to be an explicit conversion in that direction too, say >>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >>>> is a bit inconsistent with the usual Modula-3 assignability >>>> philosophy, >>>> but not requiring the explicit conversion already gets your toes >>>> into tar. >>>> >>>> We would have to have something more like ISTYPE, though, which >>>> will >>>> tell which type the value belongs to without risking a runtime >>>> error, >>>> which VAL would do. >>>> >>>> An intermediate approach might be to have a set of tagged types >>>> constructed by, say, TAGGED T, where I is a reference type, but >>>> with no subtype relations on them at all, thus still requiring >>>> the explicit conversions and checks. >>>> >>>> I do want to say, I _really_ want this capability somehow. I have >>>> an ADT module whose internal data structure, for full generality, >>>> needs to have two heap objects (the second because it has nonstatic >>>> size) and 11 total words counting the orginal pointer, in the >>>> case of >>>> values that would fit directly into the "pointer" word. Moreover, >>>> these small cases are in the great majority. >>>> >>>> Besides the 11-to-one increase in actual occupied space, there >>>> is extra time for allocation, periodic tracing, and collection, >>>> space >>>> loss due to heap fragmentation, and time/space tradeoff loss due to >>>> reduced locality of reference. So sometimes, it would be a big >>>> performance gain if we could do it. >>>> >>>> >>>> Tony Hosking wrote: >>>> It is a much more pervasive hack than I would be comfortable with >>>>> since it touches on the compiler (for all the type operations) as >>>>> well >>>>> as the run-time system in ways that are pretty gross. I would >>>>> much >>>>> rather have a new TAGGED builtin. ISTYPE would not work on it >>>>> since >>>>> that only works on references. The only thing you need is a way >>>>> to >>>>> extract the value -- we could overload VAL(x, T) where x can be a >>>>> TAGGED and T can be REFANY or INTEGER. >>>>> >>>>> 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 Tue Apr 7 04:52:59 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 12:52:59 +1000 Subject: [M3devel] small objects In-Reply-To: <49DA8196.1E75.00D7.1@scires.com> References: <200904070042.n370gNK3001242@camembert.async.caltech.edu> <9F2237E2-73A2-4926-A438-A6032F70B4F6@cs.purdue.edu> <49DA8196.1E75.00D7.1@scires.com> Message-ID: <985F59A0-82EA-4F55-B6C8-DA057B9E23DB@cs.purdue.edu> On 7 Apr 2009, at 12:27, Randy Coleburn wrote: > Hey, will this proposal mean that packages like "stable" and > "stubgen" need to be changed also, in addition to both versions of > pickles? They build on m3tk so should just work, modulo any builtin typecode information. TAGGED INTEGER will have a predefined typecode just like NULL. > What about any package that deals with parsing of M3 code, e.g. > pretty-printers, CM3IDE, etc.? Same. To that end, how do those cope with LONGINT right now? I did push the changes for LONGINT into m3tk. > Regards, > Randy > > >>> Tony Hosking 4/6/2009 10:16 PM >>> > On 7 Apr 2009, at 10:42, Mika Nystrom wrote: > > > You mean this proposal (you had two, I think)? > > Yes, this is the proposal I converged on. It really is only minimal > change to the type system: introduction of a third hierarchy of > TAGGED reference types. I did something similar for orthogonal > persistence a few years ago where it was useful to have a TRANSIENT > reference hierarchy for things that should not persist. [The > semantics was that every run of a program would initialize TRANSIENT > references to NIL rather than have them have the persistent value. > This was slightly messier in that I also permitted TRANSIENT REFANY <: > REFANY, which was a little odd.] > > > -- > > > > NULL <: REF T <: REFANY > > NULL <: UNTRACED REF T <: ADDRESS > > TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY > > > > Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. > > > > ROOT <: REFANY > > TAGGED ROOT <: TAGGED REFANY > > NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS > > TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY > > > > Note that NULL is not a subtype of T OBJECT ... END where T <: > TAGGED > > REFANY. > > > > --- > > > > I like it fine, I think... I'm just worried, generally, about > > changing the type system. Hmmmm... you mean that the TAGGED > > things would just be a separate hierarchy? > > The change is relatively minor in that it doesn't touch the original > REFANY hierarchy. > > > So you'd just add TAGGED in front of the REFs for this new > hierarchy. > > But why no NULL? > > No NULL because then we need a test for both NIL and values of type > TAGGED INTEGER on every dereference. You can easily declare: > > TYPE Null = TAGGED INTEGER; > CONST Nil = VAL(0, TAGGED INTEGER); > > The point is that TAGGED INTEGER now lets you have a range of non- > pointer reference values, whereas NIL is the singleton non-reference > value in type NULL. > > > And you're comfortable with doing the conversions automatically? > > No, I said that the conversions needed to be explicit > > > > > So > > > > tx : TAGGED INTEGER := 5; > > tx: TAGGED INTEGER := VAL(5,TAGGED INTEGER); > > > x : INTEGER := tx; > > x: INTEGER := ORD(tx); > > > would be OK? > > > > In that case it's just the m3tk that needs to be modified, and > > that's just busy work, I think. If it works it's beautiful... > > As I said, I am almost done with the compiler changes, and only need > to push it into the run-time. Things like m3tk and pickles will need > to be smartened up as necessary. > > > > > > > Mika > > > > > > > > Tony Hosking writes: > >> I really don't like your proposal for the reasons you mention. It > >> makes regular REF more expensive than it currently is. What is it > >> about my relatively minor changes to the type system that you > object > >> to? I've just about finished changing the compiler front-end (in > >> relatively minor ways) to accomodate the proposal I made yesterday. > >> And it has the advantage of separating REF from TAGGED REF so we > keep > >> the standard REF clean. > >> > >> On 7 Apr 2009, at 00:50, Mika Nystrom wrote: > >> > >>> Hi Rodney, > >>> > >>> I would like this capability too, but I am a bit wary of Tony's > >>> idea of changing the Modula-3 language---even in a "minor" way. > >>> I've been working for the last week or so on an application using > >>> the Modula-3 Toolkit, and I must say I have realized that the > >> Modula-3 type system has a lot more subtleties than I thought. I > >>> would not want to make any real changes to it. There's a paper > >>> called "The Modula-3 Type System" by Cardelli, Donahue, Kalsow, > and > >>> Nelson that is worth studying in detail before making any changes > >>> whatsoever, I think. Also remember that changes to the type > system > >>> will affect m3tk and anything that depends on m3tk (which includes > >>> two or three stub generators in the main tree and who knows how > >>> many dependencies outside of it). > >>> > >>> I'm still not sure why we can't take the approach of Word.T . > >>> Make a RefanyOrInt.T that can safely be: > >>> > >>> 1. Tested whether it is a small integer or a REFANY > >>> > >>> 2. If a REFANY, be dereferenced as normal, *or* via > >>> RefanyOrInt.ToRefany > >>> > >>> 3. If a small integer, can be extracted via RefanyOrInt.ToInt > >>> > >>> 4. Created either as a small integer or a REFANY > >>> > >>> Any other operations on it (including ISTYPE and TYPECASE, at > least > >>> when the object is a small integer) would result in a checked > >>> runtime > >>> error. > >>> > >>> Note that with the declaration "RefanyOrInt.T = REFANY", the > current > >>> compiler will as far as I know not accept any operations on > >>> RefanyOrInt.T outside of ISTYPE, TYPECASE, and NARROW (explicit or > >>> implicit). > >>> > >>> I wouldn't be surprised if most of what I'm proposing already > works > >>> (i.e., crashes with a checked runtime error as it should) with the > >>> current runtime. Anything that slips through would need to be > fixed > >>> up with a one-bit check of the LSB of the REFANY for the > operations > >>> mentioned above. Unfortunately this has to be done for operations > >>> on > >>> every REFANY, not just the new type. > >>> > >>> I think that Modula-3 programmers are already aware that using > >>> REFANYs involves forcing the runtime to do extra type-checking > work, > >>> so they already know not to use them if they are looking for > maximum > >>> performance, so I don't think that burdening operations on REFANY > >>> with an extra one-bit check is too onerous. > >>> > >>> An advantage of my proposal is that the amount of code in the new > >>> proposed library is truly diminutive. In fact, I think I posted > >>> pretty much that code to the list a few weeks ago. > >>> > >>> (If you missed it, it's > >>> > >>> http://www.async.caltech.edu/~mika/interp/ > >>> > >>> ) > >>> > >>> Mika > >>> > >>> > >>> "Rodney M. Bates" writes: > >>>> I spent quite a bit of time playing with a more general system > >>>> where > >>>> there is a set of "tagged" types, with (an implementation-defined > >>>> subrange of) INTEGER and a reference type both being a subtype > of a > >>>> tagged type. It might have been tolerable, if it weren't for the > >>>> interaction with object subtypes and opaque types, which quickly > >>>> gets deep into a deep linguistic tar pit. > >>>> > >>>> Tony's approach is much simpler and would serve what I see as the > >>>> need. It does sacrifice any static checking of what reference > type > >>>> is being tagged, and will also require an extra runtime ISTYPE/ > >>>> TYPECASE. > >>>> > >>>> Would INTEGER and REFANY be assignable to TAGGED, or would there > >>>> also need to be an explicit conversion in that direction too, say > >>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. > It > >>>> is a bit inconsistent with the usual Modula-3 assignability > >>>> philosophy, > >>>> but not requiring the explicit conversion already gets your toes > >>>> into tar. > >>>> > >>>> We would have to have something more like ISTYPE, though, which > >>>> will > >>>> tell which type the value belongs to without risking a runtime > >>>> error, > >>>> which VAL would do. > >>>> > >>>> An intermediate approach might be to have a set of tagged types > >>>> constructed by, say, TAGGED T, where I is a reference type, but > >>>> with no subtype relations on them at all, thus still requiring > >>>> the explicit conversions and checks. > >>>> > >>>> I do want to say, I _really_ want this capability somehow. I > have > >>>> an ADT module whose internal data structure, for full generality, > >>>> needs to have two heap objects (the second because it has > nonstatic > >>>> size) and 11 total words counting the orginal pointer, in the > >>>> case of > >>>> values that would fit directly into the "pointer" word. > Moreover, > >>>> these small cases are in the great majority. > >>>> > >>>> Besides the 11-to-one increase in actual occupied space, there > >>>> is extra time for allocation, periodic tracing, and collection, > >>>> space > >>>> loss due to heap fragmentation, and time/space tradeoff loss > due to > >>>> reduced locality of reference. So sometimes, it would be a big > >>>> performance gain if we could do it. > >>>> > >>>> > >>>> Tony Hosking wrote: > >>>> It is a much more pervasive hack than I would be comfortable with > >>>>> since it touches on the compiler (for all the type operations) > as > >>>>> well > >>>>> as the run-time system in ways that are pretty gross. I would > >>>>> much > >>>>> rather have a new TAGGED builtin. ISTYPE would not work on it > >>>>> since > >>>>> that only works on references. The only thing you need is a way > >>>>> to > >>>>> extract the value -- we could overload VAL(x, T) where x can > be a > >>>>> TAGGED and T can be REFANY or INTEGER. > >>>>> > >>>>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Apr 7 07:28:32 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 22:28:32 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Tue, 07 Apr 2009 12:16:29 +1000." <9F2237E2-73A2-4926-A438-A6032F70B4F6@cs.purdue.edu> Message-ID: <200904070528.n375SWNg010291@camembert.async.caltech.edu> Ok, I see. You've done this before! Then I think you are qualified to say that it's doable and straightforward. It certainly seems all right from what you say. It sounds like it's implementation-wise not very different from the library idea I was proposing, but much more elegant. But but... this NULL business. You don't think that we who want to use the TAGGED INTEGER deserve to pay an extra instruction for the convenience? Is there actually an instruction checking for NULL? You don't just let the system segfault the process? Is this because you might have an indexed pointer that might be persuaded to point into mapped memory even if 0 is an illegal address? (Could you insert the NULL check only for pointers to types that are larger than a certain size, say one page?) It seems a little inconvenient to me not to have a pointer that's NIL. What you suggest doesn't really work super-elegantly... I'm thinking: in my Scheme interpreter, I represent Scheme types as Modula-3 REFs (following Norvig's JScheme almost exactly). The empty list is just Modula-3's NIL. But what you're saying is that some integer should be selected as "special" to denote the empty list, the non-object, or whatever you want to call it. What if I want to represent that integer? In any case, the all-zeros bit pattern would not be a legal TAGGED type, would it, under your proposal? Or am I completely missing something here? Mika Tony Hosking writes: >On 7 Apr 2009, at 10:42, Mika Nystrom wrote: > >> You mean this proposal (you had two, I think)? > >Yes, this is the proposal I converged on. It really is only minimal >change to the type system: introduction of a third hierarchy of >TAGGED reference types. I did something similar for orthogonal >persistence a few years ago where it was useful to have a TRANSIENT >reference hierarchy for things that should not persist. [The >semantics was that every run of a program would initialize TRANSIENT >references to NIL rather than have them have the persistent value. >This was slightly messier in that I also permitted TRANSIENT REFANY <: >REFANY, which was a little odd.] > >> -- >> >> NULL <: REF T <: REFANY >> NULL <: UNTRACED REF T <: ADDRESS >> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >> >> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >> >> ROOT <: REFANY >> TAGGED ROOT <: TAGGED REFANY >> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >> >> Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED >> REFANY. >> >> --- >> >> I like it fine, I think... I'm just worried, generally, about >> changing the type system. Hmmmm... you mean that the TAGGED >> things would just be a separate hierarchy? > >The change is relatively minor in that it doesn't touch the original >REFANY hierarchy. > >> So you'd just add TAGGED in front of the REFs for this new hierarchy. >> But why no NULL? > >No NULL because then we need a test for both NIL and values of type >TAGGED INTEGER on every dereference. You can easily declare: > >TYPE Null = TAGGED INTEGER; >CONST Nil = VAL(0, TAGGED INTEGER); > >The point is that TAGGED INTEGER now lets you have a range of non- >pointer reference values, whereas NIL is the singleton non-reference >value in type NULL. > >> And you're comfortable with doing the conversions automatically? > >No, I said that the conversions needed to be explicit > >> >> So >> >> tx : TAGGED INTEGER := 5; > >tx: TAGGED INTEGER := VAL(5,TAGGED INTEGER); > >> x : INTEGER := tx; > >x: INTEGER := ORD(tx); > >> would be OK? >> >> In that case it's just the m3tk that needs to be modified, and >> that's just busy work, I think. If it works it's beautiful... > >As I said, I am almost done with the compiler changes, and only need >to push it into the run-time. Things like m3tk and pickles will need >to be smartened up as necessary. > >> >> >> Mika >> >> >> >> Tony Hosking writes: >>> I really don't like your proposal for the reasons you mention. It >>> makes regular REF more expensive than it currently is. What is it >>> about my relatively minor changes to the type system that you object >>> to? I've just about finished changing the compiler front-end (in >>> relatively minor ways) to accomodate the proposal I made yesterday. >>> And it has the advantage of separating REF from TAGGED REF so we keep >>> the standard REF clean. >>> >>> On 7 Apr 2009, at 00:50, Mika Nystrom wrote: >>> >>>> Hi Rodney, >>>> >>>> I would like this capability too, but I am a bit wary of Tony's >>>> idea of changing the Modula-3 language---even in a "minor" way. >>>> I've been working for the last week or so on an application using >>>> the Modula-3 Toolkit, and I must say I have realized that the >>> Modula-3 type system has a lot more subtleties than I thought. I >>>> would not want to make any real changes to it. There's a paper >>>> called "The Modula-3 Type System" by Cardelli, Donahue, Kalsow, and >>>> Nelson that is worth studying in detail before making any changes >>>> whatsoever, I think. Also remember that changes to the type system >>>> will affect m3tk and anything that depends on m3tk (which includes >>>> two or three stub generators in the main tree and who knows how >>>> many dependencies outside of it). >>>> >>>> I'm still not sure why we can't take the approach of Word.T . >>>> Make a RefanyOrInt.T that can safely be: >>>> >>>> 1. Tested whether it is a small integer or a REFANY >>>> >>>> 2. If a REFANY, be dereferenced as normal, *or* via >>>> RefanyOrInt.ToRefany >>>> >>>> 3. If a small integer, can be extracted via RefanyOrInt.ToInt >>>> >>>> 4. Created either as a small integer or a REFANY >>>> >>>> Any other operations on it (including ISTYPE and TYPECASE, at least >>>> when the object is a small integer) would result in a checked >>> runtime >>>> error. >>>> >>>> Note that with the declaration "RefanyOrInt.T = REFANY", the current >>>> compiler will as far as I know not accept any operations on >>>> RefanyOrInt.T outside of ISTYPE, TYPECASE, and NARROW (explicit or >>>> implicit). >>>> >>>> I wouldn't be surprised if most of what I'm proposing already works >>>> (i.e., crashes with a checked runtime error as it should) with the >>>> current runtime. Anything that slips through would need to be fixed >>>> up with a one-bit check of the LSB of the REFANY for the operations >>>> mentioned above. Unfortunately this has to be done for operations >>>> on >>>> every REFANY, not just the new type. >>>> >>>> I think that Modula-3 programmers are already aware that using >>>> REFANYs involves forcing the runtime to do extra type-checking work, >>>> so they already know not to use them if they are looking for maximum >>>> performance, so I don't think that burdening operations on REFANY >>>> with an extra one-bit check is too onerous. >>>> >>>> An advantage of my proposal is that the amount of code in the new >>>> proposed library is truly diminutive. In fact, I think I posted >>>> pretty much that code to the list a few weeks ago. >>>> >>>> (If you missed it, it's >>>> >>>> http://www.async.caltech.edu/~mika/interp/ >>>> >>>> ) >>>> >>>> Mika >>>> >>>> >>>> "Rodney M. Bates" writes: >>>>> I spent quite a bit of time playing with a more general system >>>>> where >>>>> there is a set of "tagged" types, with (an implementation-defined >>>>> subrange of) INTEGER and a reference type both being a subtype of a >>>>> tagged type. It might have been tolerable, if it weren't for the >>>>> interaction with object subtypes and opaque types, which quickly >>>>> gets deep into a deep linguistic tar pit. >>>>> >>>>> Tony's approach is much simpler and would serve what I see as the >>>>> need. It does sacrifice any static checking of what reference type >>>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>>> TYPECASE. >>>>> >>>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>>> also need to be an explicit conversion in that direction too, say >>>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >>>>> is a bit inconsistent with the usual Modula-3 assignability >>>>> philosophy, >>>>> but not requiring the explicit conversion already gets your toes >>>>> into tar. >>>>> >>>>> We would have to have something more like ISTYPE, though, which >>>>> will >>>>> tell which type the value belongs to without risking a runtime >>>>> error, >>>>> which VAL would do. >>>>> >>>>> An intermediate approach might be to have a set of tagged types >>>>> constructed by, say, TAGGED T, where I is a reference type, but >>>>> with no subtype relations on them at all, thus still requiring >>>>> the explicit conversions and checks. >>>>> >>>>> I do want to say, I _really_ want this capability somehow. I have >>>>> an ADT module whose internal data structure, for full generality, >>>>> needs to have two heap objects (the second because it has nonstatic >>>>> size) and 11 total words counting the orginal pointer, in the >>>>> case of >>>>> values that would fit directly into the "pointer" word. Moreover, >>>>> these small cases are in the great majority. >>>>> >>>>> Besides the 11-to-one increase in actual occupied space, there >>>>> is extra time for allocation, periodic tracing, and collection, >>>>> space >>>>> loss due to heap fragmentation, and time/space tradeoff loss due to >>>>> reduced locality of reference. So sometimes, it would be a big >>>>> performance gain if we could do it. >>>> >>>>> >>>>> Tony Hosking wrote: >>>>> It is a much more pervasive hack than I would be comfortable with >>>>>> since it touches on the compiler (for all the type operations) as >>>>>> well >>>>>> as the run-time system in ways that are pretty gross. I would >>>>>> much >>>>>> rather have a new TAGGED builtin. ISTYPE would not work on it >>>>>> since >>>>>> that only works on references. The only thing you need is a way >>>>>> to >>>>>> extract the value -- we could overload VAL(x, T) where x can be a >>>>>> TAGGED and T can be REFANY or INTEGER. >>>>>> >>>>>> From mika at async.caltech.edu Tue Apr 7 07:39:17 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 22:39:17 -0700 Subject: [M3devel] Implementing the "Singleton pattern" in Modula-3 In-Reply-To: Your message of "Tue, 07 Apr 2009 12:07:19 +1000." Message-ID: <200904070539.n375dHGR010710@camembert.async.caltech.edu> Hmm, well ... so in C++ and Smalltalk you can accomplish something along these lines: INTERFACE Singleton; TYPE T = SomeSuperTypeIReallyWantToSubClass OBJECT METHODS m(); END; END Singleton. (****************************************) MODULE Client; BEGIN theSingleton := NEW(Singleton.T, m := MyM); theSingleton2 := NEW(Singleton.T, m := MyM); END Client. And by some magic involving overriding "new methods", you are guaranteed that theSingleton and theSingleton2 are the same object... In Modula-3 you can do something similar by providing an appropriate init, but this can still get a bit hairy since the client can override init and then you're back where you started. As I said this is really quite a minor issue but it has annoyed me a few times that I have to be very careful about allocating only one of something, especially when it might be allocated from lots of places and you want to make sure only one ever gets allocated in a single program execution. (E.g., various types of "registries"...) Mika Tony Hosking writes: >On 7 Apr 2009, at 11:18, Mika Nystrom wrote: > >> Well I think the problem is with this "is known to be an object >> type"... > >But if the opaque type T is T<:REFANY and the only revelation is >branded and private to a module (not exported by its interfaces) then >no-one can determine that it is an object type without forging the >BRAND. > >> You may in fact want to override the methods of the singleton, but >> ensure that only one ever gets instantiated. >> >> It's a minor problem, but it does sometimes bother me that it is >> difficult to prevent clients from NEWing pretty much anything they >> like. >> >> By the way, the "Modula-3 Type System" paper also talks about a >> nifty way to do narrowing very quickly (page 10, last paragraph). >> I remember this is occasionally problematic. (RTType.IsSubtype >> isn't great.) They speak of keeping an array of supertypes >> for each type, and recording the "depth" (distance from REFANY) >> of every type in, I guess, RT0.TypeDefn. This seems moderately >> space-efficient (better than a 2D array of all the typecodes), >> and very fast. >> >> Mika >> >> Tony Hosking writes: >>> I would exploit opaque types and branding. If T is opaque then you >>> cannot instantiate T except in scopes where T's concrete type has >>> been >>> revealed or is known to be an object type. Thus, you could define an >>> interface: >>> >>> GENERIC INTERFACE Singleton(Rep); >>> TYPE T <: REFANY; >>> VAR t: T; >>> END Singleton. >>> >>> GENERIC MODULE Singleton(Rep); >>> REVEAL T = BRANDED REF Rep.T; >>> BEGIN >>> t := NEW(T); >>> END Singleton. >>> >>> where Rep defines the type T. You could do similar for object types. >>> >>> >>> On 7 Apr 2009, at 06:31, Mika Nystrom wrote: >>> >>>> >>>> Tony, Jay, you two seem to be most knowledgeable about this. >>>> >>>> Let's say I wanted to implement the "singleton pattern" in >>>> Modula-3. At present there seems to be no way of doing this. >>>> >>>> What about changing RTAllocator.callback as follows (or adding >>>> another callback): >>>> >>>> VAR callback : PROCEDURE(r : REFANY) : REFANY := NIL; >>>> >>>> (* If non-NIL, the allocator calls "callback(r)" just before >>>> returning >>>> a new traced reference "r" and instead returns the result of >>>> callback(r). >>>> See "RTAllocStats" for an example client. It is a checked runtime >>>> error >>>> for the typecode of r to differ from the typecode of the return >>>> value of >>>> callback(r). *) >>>> >>>> Mika >>>> >>>> >>>> From hosking at cs.purdue.edu Tue Apr 7 08:15:50 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 16:15:50 +1000 Subject: [M3devel] Implementing the "Singleton pattern" in Modula-3 In-Reply-To: <200904070539.n375dHGR010710@camembert.async.caltech.edu> References: <200904070539.n375dHGR010710@camembert.async.caltech.edu> Message-ID: <2D76BEAC-54E2-48FB-BFF3-90339E0E1F75@cs.purdue.edu> Yes, I admit this is cumbersome: GENERIC MODULE Singleton(Super, Impl); REVEAL T = Super BRANDED OBJECT OVERRIDES m := Impl.m END; BEGIN t := NEW(T); END Singleton. On 7 Apr 2009, at 15:39, Mika Nystrom wrote: > > Hmm, well ... so in C++ and Smalltalk you can accomplish something > along these lines: > > INTERFACE Singleton; > > TYPE > T = SomeSuperTypeIReallyWantToSubClass OBJECT METHODS > m(); > END; > > END Singleton. > > (****************************************) > > MODULE Client; > > BEGIN > > theSingleton := NEW(Singleton.T, m := MyM); > theSingleton2 := NEW(Singleton.T, m := MyM); > > END Client. > > And by some magic involving overriding "new methods", you are > guaranteed that theSingleton and theSingleton2 are the same object... > > In Modula-3 you can do something similar by providing an appropriate > init, but this can still get a bit hairy since the client can > override init and then you're back where you started. > > As I said this is really quite a minor issue but it has annoyed me > a few times that I have to be very careful about allocating only one > of something, especially when it might be allocated from lots of > places and you want to make sure only one ever gets allocated in a > single > program execution. (E.g., various types of "registries"...) > > Mika > > Tony Hosking writes: >> On 7 Apr 2009, at 11:18, Mika Nystrom wrote: >> >>> Well I think the problem is with this "is known to be an object >>> type"... >> >> But if the opaque type T is T<:REFANY and the only revelation is >> branded and private to a module (not exported by its interfaces) then >> no-one can determine that it is an object type without forging the >> BRAND. >> >>> You may in fact want to override the methods of the singleton, but >>> ensure that only one ever gets instantiated. >>> >>> It's a minor problem, but it does sometimes bother me that it is >>> difficult to prevent clients from NEWing pretty much anything they >>> like. >>> >>> By the way, the "Modula-3 Type System" paper also talks about a >>> nifty way to do narrowing very quickly (page 10, last paragraph). >>> I remember this is occasionally problematic. (RTType.IsSubtype >>> isn't great.) They speak of keeping an array of supertypes >>> for each type, and recording the "depth" (distance from REFANY) >>> of every type in, I guess, RT0.TypeDefn. This seems moderately >>> space-efficient (better than a 2D array of all the typecodes), >>> and very fast. >>> >>> Mika >>> >>> Tony Hosking writes: >>>> I would exploit opaque types and branding. If T is opaque then you >>>> cannot instantiate T except in scopes where T's concrete type has >>>> been >>>> revealed or is known to be an object type. Thus, you could >>>> define an >>>> interface: >>>> >>>> GENERIC INTERFACE Singleton(Rep); >>>> TYPE T <: REFANY; >>>> VAR t: T; >>>> END Singleton. >>>> >>>> GENERIC MODULE Singleton(Rep); >>>> REVEAL T = BRANDED REF Rep.T; >>>> BEGIN >>>> t := NEW(T); >>>> END Singleton. >>>> >>>> where Rep defines the type T. You could do similar for object >>>> types. >>>> >>>> >>>> On 7 Apr 2009, at 06:31, Mika Nystrom wrote: >>>> >>>>> >>>>> Tony, Jay, you two seem to be most knowledgeable about this. >>>>> >>>>> Let's say I wanted to implement the "singleton pattern" in >>>>> Modula-3. At present there seems to be no way of doing this. >>>>> >>>>> What about changing RTAllocator.callback as follows (or adding >>>>> another callback): >>>>> >>>>> VAR callback : PROCEDURE(r : REFANY) : REFANY := NIL; >>>>> >>>>> (* If non-NIL, the allocator calls "callback(r)" just before >>>>> returning >>>>> a new traced reference "r" and instead returns the result of >>>>> callback(r). >>>>> See "RTAllocStats" for an example client. It is a checked runtime >>>>> error >>>>> for the typecode of r to differ from the typecode of the return >>>>> value of >>>>> callback(r). *) >>>>> >>>>> Mika >>>>> >>>>> >>>>> From hosking at cs.purdue.edu Tue Apr 7 08:27:41 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 16:27:41 +1000 Subject: [M3devel] small objects In-Reply-To: <200904070528.n375SWNg010291@camembert.async.caltech.edu> References: <200904070528.n375SWNg010291@camembert.async.caltech.edu> Message-ID: <8D54C0C3-478C-4E87-BBD7-216215FF2921@cs.purdue.edu> No, you are right on the money. I was just trying to avoid attempts to dereference tagged integers with a run-time check like a nil-check. I am starting to come around to your library idea. As you say, TaggedInteger.T would give a static error on dereference, so no need for a run-time check. Similarly, because one cannot NARROW (implicitly or explicitly) a TaggedInteger.T it is impossible to assign to anything other than a REFANY which avoids polluting other reference fields and so eliminates my initial concern. Hmmm.... ;-) On 7 Apr 2009, at 15:28, Mika Nystrom wrote: > > Ok, I see. You've done this before! Then I think you are qualified > to say that it's doable and straightforward. It certainly seems all > right from what you say. It sounds like it's implementation-wise not > very different from the library idea I was proposing, but much more > elegant. > > But but... this NULL business. You don't think that we who want to > use the TAGGED INTEGER deserve to pay an extra instruction for the > convenience? Is there actually an instruction checking for NULL? > You don't just let the system segfault the process? Is this because > you might have an indexed pointer that might be persuaded to point > into > mapped memory even if 0 is an illegal address? (Could you insert the > NULL check only for pointers to types that are larger than a certain > size, say one page?) > > It seems a little inconvenient to me not to have a pointer that's > NIL. What you suggest doesn't really work super-elegantly... > > I'm thinking: in my Scheme interpreter, I represent Scheme types as > Modula-3 REFs (following Norvig's JScheme almost exactly). The > empty list is just Modula-3's NIL. > > But what you're saying is that some integer should be selected as > "special" to denote the empty list, the non-object, or whatever you > want to call it. What if I want to represent that integer? > > In any case, the all-zeros bit pattern would not be a legal TAGGED > type, would it, under your proposal? > > Or am I completely missing something here? > > Mika > > Tony Hosking writes: >> On 7 Apr 2009, at 10:42, Mika Nystrom wrote: >> >>> You mean this proposal (you had two, I think)? >> >> Yes, this is the proposal I converged on. It really is only minimal >> change to the type system: introduction of a third hierarchy of >> TAGGED reference types. I did something similar for orthogonal >> persistence a few years ago where it was useful to have a TRANSIENT >> reference hierarchy for things that should not persist. [The >> semantics was that every run of a program would initialize TRANSIENT >> references to NIL rather than have them have the persistent value. >> This was slightly messier in that I also permitted TRANSIENT REFANY >> <: >> REFANY, which was a little odd.] >> >>> -- >>> >>> NULL <: REF T <: REFANY >>> NULL <: UNTRACED REF T <: ADDRESS >>> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >>> >>> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >>> >>> ROOT <: REFANY >>> TAGGED ROOT <: TAGGED REFANY >>> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >>> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >>> >>> Note that NULL is not a subtype of T OBJECT ... END where T <: >>> TAGGED >>> REFANY. >>> >>> --- >>> >>> I like it fine, I think... I'm just worried, generally, about >>> changing the type system. Hmmmm... you mean that the TAGGED >>> things would just be a separate hierarchy? >> >> The change is relatively minor in that it doesn't touch the original >> REFANY hierarchy. >> >>> So you'd just add TAGGED in front of the REFs for this new >>> hierarchy. >>> But why no NULL? >> >> No NULL because then we need a test for both NIL and values of type >> TAGGED INTEGER on every dereference. You can easily declare: >> >> TYPE Null = TAGGED INTEGER; >> CONST Nil = VAL(0, TAGGED INTEGER); >> >> The point is that TAGGED INTEGER now lets you have a range of non- >> pointer reference values, whereas NIL is the singleton non-reference >> value in type NULL. >> >>> And you're comfortable with doing the conversions automatically? >> >> No, I said that the conversions needed to be explicit >> >>> >>> So >>> >>> tx : TAGGED INTEGER := 5; >> >> tx: TAGGED INTEGER := VAL(5,TAGGED INTEGER); >> >>> x : INTEGER := tx; >> >> x: INTEGER := ORD(tx); >> >>> would be OK? >>> >>> In that case it's just the m3tk that needs to be modified, and >>> that's just busy work, I think. If it works it's beautiful... >> >> As I said, I am almost done with the compiler changes, and only need >> to push it into the run-time. Things like m3tk and pickles will need >> to be smartened up as necessary. >> >>> >>> >>> Mika >>> >>> >>> >>> Tony Hosking writes: >>>> I really don't like your proposal for the reasons you mention. It >>>> makes regular REF more expensive than it currently is. What is it >>>> about my relatively minor changes to the type system that you >>>> object >>>> to? I've just about finished changing the compiler front-end (in >>>> relatively minor ways) to accomodate the proposal I made yesterday. >>>> And it has the advantage of separating REF from TAGGED REF so we >>>> keep >>>> the standard REF clean. >>>> >>>> On 7 Apr 2009, at 00:50, Mika Nystrom wrote: >>>> >>>>> Hi Rodney, >>>>> >>>>> I would like this capability too, but I am a bit wary of Tony's >>>>> idea of changing the Modula-3 language---even in a "minor" way. >>>>> I've been working for the last week or so on an application using >>>>> the Modula-3 Toolkit, and I must say I have realized that the >>>> Modula-3 type system has a lot more subtleties than I thought. I >>>>> would not want to make any real changes to it. There's a paper >>>>> called "The Modula-3 Type System" by Cardelli, Donahue, Kalsow, >>>>> and >>>>> Nelson that is worth studying in detail before making any changes >>>>> whatsoever, I think. Also remember that changes to the type >>>>> system >>>>> will affect m3tk and anything that depends on m3tk (which includes >>>>> two or three stub generators in the main tree and who knows how >>>>> many dependencies outside of it). >>>>> >>>>> I'm still not sure why we can't take the approach of Word.T . >>>>> Make a RefanyOrInt.T that can safely be: >>>>> >>>>> 1. Tested whether it is a small integer or a REFANY >>>>> >>>>> 2. If a REFANY, be dereferenced as normal, *or* via >>>>> RefanyOrInt.ToRefany >>>>> >>>>> 3. If a small integer, can be extracted via RefanyOrInt.ToInt >>>>> >>>>> 4. Created either as a small integer or a REFANY >>>>> >>>>> Any other operations on it (including ISTYPE and TYPECASE, at >>>>> least >>>>> when the object is a small integer) would result in a checked >>>> runtime >>>>> error. >>>>> >>>>> Note that with the declaration "RefanyOrInt.T = REFANY", the >>>>> current >>>>> compiler will as far as I know not accept any operations on >>>>> RefanyOrInt.T outside of ISTYPE, TYPECASE, and NARROW (explicit or >>>>> implicit). >>>>> >>>>> I wouldn't be surprised if most of what I'm proposing already >>>>> works >>>>> (i.e., crashes with a checked runtime error as it should) with the >>>>> current runtime. Anything that slips through would need to be >>>>> fixed >>>>> up with a one-bit check of the LSB of the REFANY for the >>>>> operations >>>>> mentioned above. Unfortunately this has to be done for operations >>>>> on >>>>> every REFANY, not just the new type. >>>>> >>>>> I think that Modula-3 programmers are already aware that using >>>>> REFANYs involves forcing the runtime to do extra type-checking >>>>> work, >>>>> so they already know not to use them if they are looking for >>>>> maximum >>>>> performance, so I don't think that burdening operations on REFANY >>>>> with an extra one-bit check is too onerous. >>>>> >>>>> An advantage of my proposal is that the amount of code in the new >>>>> proposed library is truly diminutive. In fact, I think I posted >>>>> pretty much that code to the list a few weeks ago. >>>>> >>>>> (If you missed it, it's >>>>> >>>>> http://www.async.caltech.edu/~mika/interp/ >>>>> >>>>> ) >>>>> >>>>> Mika >>>>> >>>>> >>>>> "Rodney M. Bates" writes: >>>>>> I spent quite a bit of time playing with a more general system >>>>>> where >>>>>> there is a set of "tagged" types, with (an implementation-defined >>>>>> subrange of) INTEGER and a reference type both being a subtype >>>>>> of a >>>>>> tagged type. It might have been tolerable, if it weren't for the >>>>>> interaction with object subtypes and opaque types, which quickly >>>>>> gets deep into a deep linguistic tar pit. >>>>>> >>>>>> Tony's approach is much simpler and would serve what I see as the >>>>>> need. It does sacrifice any static checking of what reference >>>>>> type >>>>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>>>> TYPECASE. >>>>>> >>>>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>>>> also need to be an explicit conversion in that direction too, say >>>>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. >>>>>> It >>>>>> is a bit inconsistent with the usual Modula-3 assignability >>>>>> philosophy, >>>>>> but not requiring the explicit conversion already gets your toes >>>>>> into tar. >>>>>> >>>>>> We would have to have something more like ISTYPE, though, which >>>>>> will >>>>>> tell which type the value belongs to without risking a runtime >>>>>> error, >>>>>> which VAL would do. >>>>>> >>>>>> An intermediate approach might be to have a set of tagged types >>>>>> constructed by, say, TAGGED T, where I is a reference type, but >>>>>> with no subtype relations on them at all, thus still requiring >>>>>> the explicit conversions and checks. >>>>>> >>>>>> I do want to say, I _really_ want this capability somehow. I >>>>>> have >>>>>> an ADT module whose internal data structure, for full generality, >>>>>> needs to have two heap objects (the second because it has >>>>>> nonstatic >>>>>> size) and 11 total words counting the orginal pointer, in the >>>>>> case of >>>>>> values that would fit directly into the "pointer" word. >>>>>> Moreover, >>>>>> these small cases are in the great majority. >>>>>> >>>>>> Besides the 11-to-one increase in actual occupied space, there >>>>>> is extra time for allocation, periodic tracing, and collection, >>>>>> space >>>>>> loss due to heap fragmentation, and time/space tradeoff loss >>>>>> due to >>>>>> reduced locality of reference. So sometimes, it would be a big >>>>>> performance gain if we could do it. >>>>> >>>>>> >>>>>> Tony Hosking wrote: >>>>>> It is a much more pervasive hack than I would be comfortable with >>>>>>> since it touches on the compiler (for all the type operations) >>>>>>> as >>>>>>> well >>>>>>> as the run-time system in ways that are pretty gross. I would >>>>>>> much >>>>>>> rather have a new TAGGED builtin. ISTYPE would not work on it >>>>>>> since >>>>>>> that only works on references. The only thing you need is a way >>>>>>> to >>>>>>> extract the value -- we could overload VAL(x, T) where x can >>>>>>> be a >>>>>>> TAGGED and T can be REFANY or INTEGER. >>>>>>> >>>>>>> From hosking at cs.purdue.edu Tue Apr 7 08:55:12 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 16:55:12 +1000 Subject: [M3devel] small objects In-Reply-To: <200904062039.n36KdIsY095003@camembert.async.caltech.edu> References: <200904062039.n36KdIsY095003@camembert.async.caltech.edu> Message-ID: After all of this -- I may simply be coming back around to your original proposal -- why not simply declare: TaggedInteger.T = REFANY; ? You can't instantiate a REFANY. All we really need is the LOOPHOLEing of your original proposal to extract the integer values, and to make sure that ISTYPE and NARROW have the behavior you describe for tagged REFANY. Does it make sense that TYPECODE(r) = TYPECODE(REFANY) for any tagged REFANY? What else are we missing? On 7 Apr 2009, at 06:39, Mika Nystrom wrote: > And finally, to forestall a possible objection to the scheme > I proposed: > > Yes, it is true that even a non-UNSAFE module can allocate a > TaggedInteger.T by calling > > new := RTAllocator.NewTraced(TYPECODE(r)) > > where r is a tagged integer. > > But since it cannot dereference that new value or do anything else > with it, I don't think this is a problem. The Pickler (built into > the TaggedInteger module, one must assume) would simply have to > be on the lookout for values of the "real" TaggedInteger.T versus > those that are just numbers with the LSB set, and act accordingly. > Since the T declaration is only visible within the UNSAFE module > there can never be any question of another module's muddling the > two types up. > > Mika > > Mika Nystrom writes: >> "Rodney M. Bates" writes: >>> At first, I just envisioned implementing a small object type >>> entirely inside an UNSAFE module, using unsafe operations >>> to construct/test/separate the values. I think if the GC were >>> to just to ignore words in heap objects that the type system >>> claims are unambiguously pointers but actually have misaligned >>> values, this could be done. >> >> Right that's precisely what the module I posted does. >> >>> >>> But it flies in the face of a fundamental principle of Modula-3, >>> namely that an UNSAFE module, if coded correctly, can prevent >>> all other code from consequences of the unsafety. Unfortunately, >>> this can't be done with the small pointers, because, even if >>> opaque, they are still reference types, and client code can >>> dereference them (including the implicit dereference in accessing >>> a method or field of an object) and do ISTYPE, NARROW, TYPECASE, >>> and assignments that do an implicit NARROW. All these operations >>> could be done outside the implementing module and all could >>> suffer from misaligned values. >> >> Well yes that is true. But the client can't dereference REFANY. >> Modula-3 doesn't permit that. That's an important practical point, >> because now we're limited to the other things: ISTYPE, NARROW >> (implicit and explicit), TYPECASE. (There are two more, actually, >> and they are = and #.) As long as those can be guaranteed to fail >> you're OK. [ Actually see my P.S. below! ] >> >>> >>> In fact, misaligned integer "objects" violate another principle >>> that >>> the bit pattern must always be a valid representation of some value >>> of the type. >> >> Yes I think maybe this is what Tony is worried about. But let's >> just change the definition of REFANY to include anything with the >> LSB set...? >> >> In Modula-3-ese it would be more like the following: >> >> "REFANY can hold three types of objects. NIL, REF something or an >> implementation-defined other set of values that can only be accessed >> in an UNSAFE module. It is a checked runtime error to pass a 'REFANY >> of the third kind' to ISTYPE, NARROW, TYPECASE." [ Actually see my >> P.S. below! ] >> >> Then I propose we punt the handling of the new REFANYs to this >> unsafe module we spoke about above. As far as Modula-3 is concerned, >> there's just a set of values of (apparently) very little utility >> that can be represented by REFANY. If you think about it, this is >> really not so crazy. Any module that uses REFANY today is designed >> around to the fact that there are plenty of values of REFANY that >> can be of no interest to that module except for passing along to >> another module. (REFANY can easily represent a type which a module >> has no way of accessing *any* declaration of beyond just REFANY.) >> We're just adding some others, the only difference being that the >> new values are of no interest to any non-UNSAFE module. (Eh, >> technically this is already true for any reference type that is >> declared in an UNSAFE module today so one might argue we have in >> fact added nothing.) >> >>> >>> However, this does suggest a different and very simple linguistic >>> solution: Just have a new builtin type, say VERYOPAQUE, that >>> supports no operations other than moving it around, i.e., >>> assignment, bindings, passing as a parameter, etc. Only unsafe >>> code could do anyhing with it, by using LOOPHOLE. The only >>> problem is, would somebody then want one of these in a size other >>> than one word? >> >> This is nice, and we already have a candidate type, in fact: ADDRESS. >> But the problem is that the GC doesn't follow this even if the LSB >> is clear... which we *do* want. >> >> Why are you worried about getting it in sizes other than one word? >> That seems to me to be an application problem. If someone wants >> an ARRAY OF VERYOPAQUE is that a problem? >> >> Mika >> >> P.S. Illustration of the above, in today's Modula-3: >> >> UNSAFE MODULE Unsafe; >> >> (* this module is just declared UNSAFE to conform with the definition >> above, namely, that T can only be manipulated in an UNSAFE >> module, which this is! *) >> >> TYPE T = BRANDED OBJECT END; >> >> BEGIN >> Safe.P(NEW(T)) >> END Unsafe. >> >> (****************************************) >> >> MODULE Safe; >> >> PROCEDURE P(r : REFANY) = >> BEGIN >> NARROW(r, X); (* checked runtime error for all X *) >> >> ISTYPE(r, X); (* returns FALSE for all X except REFANY itself *) >> >> TYPECASE r OF >> X => (* only gets executed for X = REFANY *) >> END; >> END P; >> >> BEGIN END Safe. >> >> Actually is this behavior so bad for tagged integers? Since it is >> the behavior of existing code... why not keep it? Then you can even >> store a tagged integer in a RefList.T, say, even if that RefList.T >> uses NARROW or ISTYPE on the argument (I don't see why it would, but >> why not...?) >> >> >> >>> >>> Mika Nystrom wrote: >>>> Ah I should read my whole inbox before replying. >>>> >>>> I take it you would worry that in my proposal (to do this all in a >>>> library) the use of REFANY to store an integer could be abused >>>> somehow. That the Modula-3 type system (as it exists now) >>>> explicitly >>>> rules out doing such things, and therefore, a language change is >>>> necessary.... >>>> >>>> Mika >>>> >>>> Tony Hosking writes: >>>> >>>>> I like the notion of having a TAGGED INTEGER type that is a hybrid >>>>> ordinal/reference. >>>>> >>>>> Subtyping rules for references would now be as follows: >>>>> >>>>> NULL <: REF T <: REFANY >>>>> TAGGED INTEGER <: REF T <: REFANY >>>>> >>>>> ROOT <: REFANY >>>>> NULL <: T OBJECT ... END <: T >>>>> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: >>>>> REFANY, not >>>>> T <: ADDRESS) >>>>> >>>>> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >>>>> type. Values of TAGGED INTEGER are non-pointer values similar >>>>> to the >>>>> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and >>>>> NARROW(x, >>>>> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to >>>>> ISTYPE(x, >>>>> NULL), NARROW(x, NULL), and TYPECODE(NULL). >>>>> >>>>> Because TAGGED INTEGER is an ordinal we can extract the integer >>>>> value >>>>> it holds using ORD(x). >>>>> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >>>>> INTEGER). >>>>> >>>>> ***The only problem with this scheme is how to efficiently >>>>> perform run- >>>>> time tests for dereferencing NULL, and TAGGED INTEGER?*** >>>> >>>>> So, here is a slightly less elegant alternative that is probably >>>>> straightforward to implement. Introduce a separate TAGGED >>>>> hierarchy. >>>>> >>>>> NULL <: REF T <: REFANY >>>>> NULL <: UNTRACED REF T <: ADDRESS >>>>> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >>>>> >>>>> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >>>>> >>>>> ROOT <: REFANY >>>>> TAGGED ROOT <: TAGGED REFANY >>>>> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >>>>> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >>>>> >>>>> Note that NULL is not a subtype of T OBJECT ... END where T <: >>>>> TAGGED >>>>> REFANY. >>>>> >>>>> This way, tagged references only need a run-time test for the >>>>> tag on >>>>> dereference (we can throw an "attempt to dereference TAGGED >>>>> INTEGER" >>>>> at run time, just like we throw "attempt to dereference NIL" for >>>>> untagged references). This check can be a straightforward test >>>>> of the >>>>> low bit tag. Of course, the weird thing here is now that we don't >>>>> have a single NULL value for TAGGED references --- we have >>>>> multiple >>>>> null values VAL(x, TAGGED INTEGER). Instead of asking "x == >>>>> NIL" we >>>>> must ask "ISTYPE(x, TAGGED INTEGER)". >>>>> >>>>> Of course, because TAGGED INTEGER is an ordinal, we can also >>>>> perform >>>>> the usual ordinal operations like INC(x), DEC(x), wherever x is >>>>> typed >>>>> TAGGED INTEGER. >>>>> >>>>> >>>>> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >>>>> >>>>> >>>>>> I spent quite a bit of time playing with a more general system >>>>>> where >>>>>> there is a set of "tagged" types, with (an implementation-defined >>>>>> subrange of) INTEGER and a reference type both being a subtype >>>>>> of a >>>>>> tagged type. It might have been tolerable, if it weren't for the >>>>>> interaction with object subtypes and opaque types, which quickly >>>>>> gets deep into a deep linguistic tar pit. >>>>>> >>>>>> Tony's approach is much simpler and would serve what I see as the >>>>>> need. It does sacrifice any static checking of what reference >>>>>> type >>>>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>>>> TYPECASE. >>>>>> >>>>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>>>> also need to be an explicit conversion in that direction too, say >>>>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. >>>>>> It >>>>>> is a bit inconsistent with the usual Modula-3 assignability >>>>>> philosophy, >>>>>> but not requiring the explicit conversion already gets your toes >>>>>> into tar. >>>>>> >>>>>> We would have to have something more like ISTYPE, though, which >>>>>> will >>>>>> tell which type the value belongs to without risking a runtime >>>>>> error, >>>>>> which VAL would do. >>>>>> >>>>>> An intermediate approach might be to have a set of tagged types >>>>>> constructed by, say, TAGGED T, where I is a reference type, but >>>>>> with no subtype relations on them at all, thus still requiring >>>>>> the explicit conversions and checks. >>>>>> >>>>>> I do want to say, I _really_ want this capability somehow. I >>>>>> have >>>>>> an ADT module whose internal data structure, for full generality, >>>>>> needs to have two heap objects (the second because it has >>>>>> nonstatic >>>>>> size) and 11 total words counting the orginal pointer, in the >>>>>> case of >>>>>> values that would fit directly into the "pointer" word. >>>>>> Moreover, >>>>>> these small cases are in the great majority. >>>>>> >>>>>> Besides the 11-to-one increase in actual occupied space, there >>>>>> is extra time for allocation, periodic tracing, and collection, >>>>>> space >>>>>> loss due to heap fragmentation, and time/space tradeoff loss >>>>>> due to >>>>>> reduced locality of reference. So sometimes, it would be a big >>>>>> performance gain if we could do it. >>>>>> >>>>>> >>>>>> Tony Hosking wrote: >>>>>> >>>>>>> It is a much more pervasive hack than I would be comfortable >>>>>>> with >>>>>>> since it touches on the compiler (for all the type operations) >>>>>>> as >>>>>>> well >>>>>>> as the run-time system in ways that are pretty gross. I would >>>>>>> much >>>>>>> rather have a new TAGGED builtin. ISTYPE would not work on it >>>>>>> since >>>>>>> that only works on references. The only thing you need is a >>>>>>> way to >>>>>>> extract the value -- we could overload VAL(x, T) where x can >>>>>>> be a >>>>>>> TAGGED and T can be REFANY or INTEGER. >>>>>>> >>>>>>> >>>> >>>> From hosking at cs.purdue.edu Tue Apr 7 08:58:43 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 16:58:43 +1000 Subject: [M3devel] small objects In-Reply-To: References: <200904062039.n36KdIsY095003@camembert.async.caltech.edu> Message-ID: erratum: TYPECODE(r) = RT0.RefanyTypecode if r is a tagged REFANY. (It is a static error to say TYPECODE(REFANY)) On 7 Apr 2009, at 16:55, Tony Hosking wrote: > After all of this -- I may simply be coming back around to your > original proposal -- why not simply declare: > > TaggedInteger.T = REFANY; > > ? > > You can't instantiate a REFANY. > > All we really need is the LOOPHOLEing of your original proposal to > extract the integer values, and to make sure that ISTYPE and NARROW > have the behavior you describe for tagged REFANY. Does it make > sense that TYPECODE(r) = TYPECODE(REFANY) for any tagged REFANY? > What else are we missing? > > On 7 Apr 2009, at 06:39, Mika Nystrom wrote: > >> And finally, to forestall a possible objection to the scheme >> I proposed: >> >> Yes, it is true that even a non-UNSAFE module can allocate a >> TaggedInteger.T by calling >> >> new := RTAllocator.NewTraced(TYPECODE(r)) >> >> where r is a tagged integer. >> >> But since it cannot dereference that new value or do anything else >> with it, I don't think this is a problem. The Pickler (built into >> the TaggedInteger module, one must assume) would simply have to >> be on the lookout for values of the "real" TaggedInteger.T versus >> those that are just numbers with the LSB set, and act accordingly. >> Since the T declaration is only visible within the UNSAFE module >> there can never be any question of another module's muddling the >> two types up. >> >> Mika >> >> Mika Nystrom writes: >>> "Rodney M. Bates" writes: >>>> At first, I just envisioned implementing a small object type >>>> entirely inside an UNSAFE module, using unsafe operations >>>> to construct/test/separate the values. I think if the GC were >>>> to just to ignore words in heap objects that the type system >>>> claims are unambiguously pointers but actually have misaligned >>>> values, this could be done. >>> >>> Right that's precisely what the module I posted does. >>> >>>> >>>> But it flies in the face of a fundamental principle of Modula-3, >>>> namely that an UNSAFE module, if coded correctly, can prevent >>>> all other code from consequences of the unsafety. Unfortunately, >>>> this can't be done with the small pointers, because, even if >>>> opaque, they are still reference types, and client code can >>>> dereference them (including the implicit dereference in accessing >>>> a method or field of an object) and do ISTYPE, NARROW, TYPECASE, >>>> and assignments that do an implicit NARROW. All these operations >>>> could be done outside the implementing module and all could >>>> suffer from misaligned values. >>> >>> Well yes that is true. But the client can't dereference REFANY. >>> Modula-3 doesn't permit that. That's an important practical point, >>> because now we're limited to the other things: ISTYPE, NARROW >>> (implicit and explicit), TYPECASE. (There are two more, actually, >>> and they are = and #.) As long as those can be guaranteed to fail >>> you're OK. [ Actually see my P.S. below! ] >>> >>>> >>>> In fact, misaligned integer "objects" violate another principle >>>> that >>>> the bit pattern must always be a valid representation of some value >>>> of the type. >>> >>> Yes I think maybe this is what Tony is worried about. But let's >>> just change the definition of REFANY to include anything with the >>> LSB set...? >>> >>> In Modula-3-ese it would be more like the following: >>> >>> "REFANY can hold three types of objects. NIL, REF something or an >>> implementation-defined other set of values that can only be accessed >>> in an UNSAFE module. It is a checked runtime error to pass a >>> 'REFANY >>> of the third kind' to ISTYPE, NARROW, TYPECASE." [ Actually see my >>> P.S. below! ] >>> >>> Then I propose we punt the handling of the new REFANYs to this >>> unsafe module we spoke about above. As far as Modula-3 is >>> concerned, >>> there's just a set of values of (apparently) very little utility >>> that can be represented by REFANY. If you think about it, this is >>> really not so crazy. Any module that uses REFANY today is designed >>> around to the fact that there are plenty of values of REFANY that >>> can be of no interest to that module except for passing along to >>> another module. (REFANY can easily represent a type which a module >>> has no way of accessing *any* declaration of beyond just REFANY.) >>> We're just adding some others, the only difference being that the >>> new values are of no interest to any non-UNSAFE module. (Eh, >>> technically this is already true for any reference type that is >>> declared in an UNSAFE module today so one might argue we have in >>> fact added nothing.) >>> >>>> >>>> However, this does suggest a different and very simple linguistic >>>> solution: Just have a new builtin type, say VERYOPAQUE, that >>>> supports no operations other than moving it around, i.e., >>>> assignment, bindings, passing as a parameter, etc. Only unsafe >>>> code could do anyhing with it, by using LOOPHOLE. The only >>>> problem is, would somebody then want one of these in a size other >>>> than one word? >>> >>> This is nice, and we already have a candidate type, in fact: >>> ADDRESS. >>> But the problem is that the GC doesn't follow this even if the LSB >>> is clear... which we *do* want. >>> >>> Why are you worried about getting it in sizes other than one word? >>> That seems to me to be an application problem. If someone wants >>> an ARRAY OF VERYOPAQUE is that a problem? >>> >>> Mika >>> >>> P.S. Illustration of the above, in today's Modula-3: >>> >>> UNSAFE MODULE Unsafe; >>> >>> (* this module is just declared UNSAFE to conform with the >>> definition >>> above, namely, that T can only be manipulated in an UNSAFE >>> module, which this is! *) >>> >>> TYPE T = BRANDED OBJECT END; >>> >>> BEGIN >>> Safe.P(NEW(T)) >>> END Unsafe. >>> >>> (****************************************) >>> >>> MODULE Safe; >>> >>> PROCEDURE P(r : REFANY) = >>> BEGIN >>> NARROW(r, X); (* checked runtime error for all X *) >>> >>> ISTYPE(r, X); (* returns FALSE for all X except REFANY itself *) >>> >>> TYPECASE r OF >>> X => (* only gets executed for X = REFANY *) >>> END; >>> END P; >>> >>> BEGIN END Safe. >>> >>> Actually is this behavior so bad for tagged integers? Since it is >>> the behavior of existing code... why not keep it? Then you can even >>> store a tagged integer in a RefList.T, say, even if that RefList.T >>> uses NARROW or ISTYPE on the argument (I don't see why it would, but >>> why not...?) >>> >>> >>> >>>> >>>> Mika Nystrom wrote: >>>>> Ah I should read my whole inbox before replying. >>>>> >>>>> I take it you would worry that in my proposal (to do this all in a >>>>> library) the use of REFANY to store an integer could be abused >>>>> somehow. That the Modula-3 type system (as it exists now) >>>>> explicitly >>>>> rules out doing such things, and therefore, a language change is >>>>> necessary.... >>>>> >>>>> Mika >>>>> >>>>> Tony Hosking writes: >>>>> >>>>>> I like the notion of having a TAGGED INTEGER type that is a >>>>>> hybrid >>>>>> ordinal/reference. >>>>>> >>>>>> Subtyping rules for references would now be as follows: >>>>>> >>>>>> NULL <: REF T <: REFANY >>>>>> TAGGED INTEGER <: REF T <: REFANY >>>>>> >>>>>> ROOT <: REFANY >>>>>> NULL <: T OBJECT ... END <: T >>>>>> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: >>>>>> REFANY, not >>>>>> T <: ADDRESS) >>>>>> >>>>>> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >>>>>> type. Values of TAGGED INTEGER are non-pointer values similar >>>>>> to the >>>>>> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and >>>>>> NARROW(x, >>>>>> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to >>>>>> ISTYPE(x, >>>>>> NULL), NARROW(x, NULL), and TYPECODE(NULL). >>>>>> >>>>>> Because TAGGED INTEGER is an ordinal we can extract the integer >>>>>> value >>>>>> it holds using ORD(x). >>>>>> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >>>>>> INTEGER). >>>>>> >>>>>> ***The only problem with this scheme is how to efficiently >>>>>> perform run- >>>>>> time tests for dereferencing NULL, and TAGGED INTEGER?*** >>>>> >>>>>> So, here is a slightly less elegant alternative that is probably >>>>>> straightforward to implement. Introduce a separate TAGGED >>>>>> hierarchy. >>>>>> >>>>>> NULL <: REF T <: REFANY >>>>>> NULL <: UNTRACED REF T <: ADDRESS >>>>>> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >>>>>> >>>>>> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >>>>>> >>>>>> ROOT <: REFANY >>>>>> TAGGED ROOT <: TAGGED REFANY >>>>>> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >>>>>> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >>>>>> >>>>>> Note that NULL is not a subtype of T OBJECT ... END where T <: >>>>>> TAGGED >>>>>> REFANY. >>>>>> >>>>>> This way, tagged references only need a run-time test for the >>>>>> tag on >>>>>> dereference (we can throw an "attempt to dereference TAGGED >>>>>> INTEGER" >>>>>> at run time, just like we throw "attempt to dereference NIL" for >>>>>> untagged references). This check can be a straightforward test >>>>>> of the >>>>>> low bit tag. Of course, the weird thing here is now that we >>>>>> don't >>>>>> have a single NULL value for TAGGED references --- we have >>>>>> multiple >>>>>> null values VAL(x, TAGGED INTEGER). Instead of asking "x == >>>>>> NIL" we >>>>>> must ask "ISTYPE(x, TAGGED INTEGER)". >>>>>> >>>>>> Of course, because TAGGED INTEGER is an ordinal, we can also >>>>>> perform >>>>>> the usual ordinal operations like INC(x), DEC(x), wherever x is >>>>>> typed >>>>>> TAGGED INTEGER. >>>>>> >>>>>> >>>>>> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >>>>>> >>>>>> >>>>>>> I spent quite a bit of time playing with a more general system >>>>>>> where >>>>>>> there is a set of "tagged" types, with (an implementation- >>>>>>> defined >>>>>>> subrange of) INTEGER and a reference type both being a subtype >>>>>>> of a >>>>>>> tagged type. It might have been tolerable, if it weren't for >>>>>>> the >>>>>>> interaction with object subtypes and opaque types, which quickly >>>>>>> gets deep into a deep linguistic tar pit. >>>>>>> >>>>>>> Tony's approach is much simpler and would serve what I see as >>>>>>> the >>>>>>> need. It does sacrifice any static checking of what reference >>>>>>> type >>>>>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>>>>> TYPECASE. >>>>>>> >>>>>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>>>>> also need to be an explicit conversion in that direction too, >>>>>>> say >>>>>>> VAL(x, TAGGED)? I think I favor the explicit conversion >>>>>>> here. It >>>>>>> is a bit inconsistent with the usual Modula-3 assignability >>>>>>> philosophy, >>>>>>> but not requiring the explicit conversion already gets your toes >>>>>>> into tar. >>>>>>> >>>>>>> We would have to have something more like ISTYPE, though, >>>>>>> which will >>>>>>> tell which type the value belongs to without risking a runtime >>>>>>> error, >>>>>>> which VAL would do. >>>>>>> >>>>>>> An intermediate approach might be to have a set of tagged types >>>>>>> constructed by, say, TAGGED T, where I is a reference type, but >>>>>>> with no subtype relations on them at all, thus still requiring >>>>>>> the explicit conversions and checks. >>>>>>> >>>>>>> I do want to say, I _really_ want this capability somehow. I >>>>>>> have >>>>>>> an ADT module whose internal data structure, for full >>>>>>> generality, >>>>>>> needs to have two heap objects (the second because it has >>>>>>> nonstatic >>>>>>> size) and 11 total words counting the orginal pointer, in the >>>>>>> case of >>>>>>> values that would fit directly into the "pointer" word. >>>>>>> Moreover, >>>>>>> these small cases are in the great majority. >>>>>>> >>>>>>> Besides the 11-to-one increase in actual occupied space, there >>>>>>> is extra time for allocation, periodic tracing, and >>>>>>> collection, space >>>>>>> loss due to heap fragmentation, and time/space tradeoff loss >>>>>>> due to >>>>>>> reduced locality of reference. So sometimes, it would be a big >>>>>>> performance gain if we could do it. >>>>>>> >>>>>>> >>>>>>> Tony Hosking wrote: >>>>>>> >>>>>>>> It is a much more pervasive hack than I would be comfortable >>>>>>>> with >>>>>>>> since it touches on the compiler (for all the type >>>>>>>> operations) as >>>>>>>> well >>>>>>>> as the run-time system in ways that are pretty gross. I >>>>>>>> would much >>>>>>>> rather have a new TAGGED builtin. ISTYPE would not work on >>>>>>>> it since >>>>>>>> that only works on references. The only thing you need is a >>>>>>>> way to >>>>>>>> extract the value -- we could overload VAL(x, T) where x can >>>>>>>> be a >>>>>>>> TAGGED and T can be REFANY or INTEGER. >>>>>>>> >>>>>>>> >>>>> >>>>> From mika at async.caltech.edu Tue Apr 7 09:27:13 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 07 Apr 2009 00:27:13 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Tue, 07 Apr 2009 16:58:43 +1000." Message-ID: <200904070727.n377RDug014714@camembert.async.caltech.edu> Oh I see. I think... You're saying that because RT0.RefanyTypecode is essentially "useless", it's OK to have values with that typecode since no (existing) module can do anything with that knowledge? So...this proposal says that ISTYPE returns FALSE for everything except ISTYPE(r,REFANY). TYPECASE, same. TYPECODE, as you say, RT0.RefanyTypecode. In other words, it's a useless value except for whatever unsafe code is lurking inside TaggedInteger. So normally, TYPECODE never returns RT0.RefanyTypecode? That's the only thing that would change as far as I can tell... I can't see how that could possibly break anything. Checking for the tagged integers can then be done by checking whether TYPECODE returns RT0.RefanyTypecode. The pickler would build an object when it sees that and pickle that, instead of the tagged integer. So change the language spec to allow the above behavior for a value of type REFANY and to say that unsafe modules may be able to do some other implementation-dependent things with these 'REFANYs of the third kind'? Mika Tony Hosking writes: >erratum: > >TYPECODE(r) = RT0.RefanyTypecode if r is a tagged REFANY. > >(It is a static error to say TYPECODE(REFANY)) > >On 7 Apr 2009, at 16:55, Tony Hosking wrote: > >> After all of this -- I may simply be coming back around to your >> original proposal -- why not simply declare: >> >> TaggedInteger.T = REFANY; >> >> ? >> >> You can't instantiate a REFANY. >> >> All we really need is the LOOPHOLEing of your original proposal to >> extract the integer values, and to make sure that ISTYPE and NARROW >> have the behavior you describe for tagged REFANY. Does it make >> sense that TYPECODE(r) = TYPECODE(REFANY) for any tagged REFANY? >> What else are we missing? >> >> On 7 Apr 2009, at 06:39, Mika Nystrom wrote: >> >>> And finally, to forestall a possible objection to the scheme >>> I proposed: >>> >>> Yes, it is true that even a non-UNSAFE module can allocate a >>> TaggedInteger.T by calling >>> >>> new := RTAllocator.NewTraced(TYPECODE(r)) >>> >>> where r is a tagged integer. >>> >>> But since it cannot dereference that new value or do anything else >>> with it, I don't think this is a problem. The Pickler (built into >>> the TaggedInteger module, one must assume) would simply have to >>> be on the lookout for values of the "real" TaggedInteger.T versus >>> those that are just numbers with the LSB set, and act accordingly. >>> Since the T declaration is only visible within the UNSAFE module >>> there can never be any question of another module's muddling the >>> two types up. >>> >>> Mika >>> >>> Mika Nystrom writes: >>>> "Rodney M. Bates" writes: >>>>> At first, I just envisioned implementing a small object type >>>>> entirely inside an UNSAFE module, using unsafe operations >>>>> to construct/test/separate the values. I think if the GC were >>>>> to just to ignore words in heap objects that the type system >>>>> claims are unambiguously pointers but actually have misaligned >>>>> values, this could be done. >>>> >>>> Right that's precisely what the module I posted does. >>>> >>>>> >>>>> But it flies in the face of a fundamental principle of Modula-3, >>>>> namely that an UNSAFE module, if coded correctly, can prevent >>>>> all other code from consequences of the unsafety. Unfortunately, >>>>> this can't be done with the small pointers, because, even if >>>>> opaque, they are still reference types, and client code can >>>>> dereference them (including the implicit dereference in accessing >>>>> a method or field of an object) and do ISTYPE, NARROW, TYPECASE, >>>>> and assignments that do an implicit NARROW. All these operations >>>>> could be done outside the implementing module and all could >>>>> suffer from misaligned values. >>>> >>>> Well yes that is true. But the client can't dereference REFANY. >>>> Modula-3 doesn't permit that. That's an important practical point, >>>> because now we're limited to the other things: ISTYPE, NARROW >>>> (implicit and explicit), TYPECASE. (There are two more, actually, >>>> and they are = and #.) As long as those can be guaranteed to fail >>>> you're OK. [ Actually see my P.S. below! ] >>>> >>>>> >>>>> In fact, misaligned integer "objects" violate another principle >>>>> that >>>>> the bit pattern must always be a valid representation of some value >>>>> of the type. >>>> >>>> Yes I think maybe this is what Tony is worried about. But let's >>>> just change the definition of REFANY to include anything with the >>>> LSB set...? >>>> >>>> In Modula-3-ese it would be more like the following: >>>> >>>> "REFANY can hold three types of objects. NIL, REF something or an >>>> implementation-defined other set of values that can only be accessed >>>> in an UNSAFE module. It is a checked runtime error to pass a >>>> 'REFANY >>>> of the third kind' to ISTYPE, NARROW, TYPECASE." [ Actually see my >>>> P.S. below! ] >>>> >>>> Then I propose we punt the handling of the new REFANYs to this >>>> unsafe module we spoke about above. As far as Modula-3 is >>>> concerned, >>>> there's just a set of values of (apparently) very little utility >>>> that can be represented by REFANY. If you think about it, this is >>>> really not so crazy. Any module that uses REFANY today is designed >>>> around to the fact that there are plenty of values of REFANY that >>>> can be of no interest to that module except for passing along to >>>> another module. (REFANY can easily represent a type which a module >>>> has no way of accessing *any* declaration of beyond just REFANY.) >>>> We're just adding some others, the only difference being that the >>>> new values are of no interest to any non-UNSAFE module. (Eh, >>>> technically this is already true for any reference type that is >>>> declared in an UNSAFE module today so one might argue we have in >>>> fact added nothing.) >>>> >>>>> >>>>> However, this does suggest a different and very simple linguistic >>>>> solution: Just have a new builtin type, say VERYOPAQUE, that >>>>> supports no operations other than moving it around, i.e., >>>>> assignment, bindings, passing as a parameter, etc. Only unsafe >>>>> code could do anyhing with it, by using LOOPHOLE. The only >>>>> problem is, would somebody then want one of these in a size other >>>>> than one word? >>>> >>>> This is nice, and we already have a candidate type, in fact: >>>> ADDRESS. >>>> But the problem is that the GC doesn't follow this even if the LSB >>>> is clear... which we *do* want. >>>> >>>> Why are you worried about getting it in sizes other than one word? >>>> That seems to me to be an application problem. If someone wants >>>> an ARRAY OF VERYOPAQUE is that a problem? >>>> >>>> Mika >>>> >>>> P.S. Illustration of the above, in today's Modula-3: >>>> >>>> UNSAFE MODULE Unsafe; >>>> >>>> (* this module is just declared UNSAFE to conform with the >>>> definition >>>> above, namely, that T can only be manipulated in an UNSAFE >>>> module, which this is! *) >>>> >>>> TYPE T = BRANDED OBJECT END; >>>> >>>> BEGIN >>>> Safe.P(NEW(T)) >>>> END Unsafe. >>>> >>>> (****************************************) >>>> >>>> MODULE Safe; >>>> >>>> PROCEDURE P(r : REFANY) = >>>> BEGIN >>>> NARROW(r, X); (* checked runtime error for all X *) >>>> >>>> ISTYPE(r, X); (* returns FALSE for all X except REFANY itself *) >>>> >>>> TYPECASE r OF >>>> X => (* only gets executed for X = REFANY *) >>>> END; >>>> END P; >>>> >>>> BEGIN END Safe. >>>> >>>> Actually is this behavior so bad for tagged integers? Since it is >>>> the behavior of existing code... why not keep it? Then you can even >>>> store a tagged integer in a RefList.T, say, even if that RefList.T >>>> uses NARROW or ISTYPE on the argument (I don't see why it would, but >>>> why not...?) >>>> >>>> >>>> >>>>> >>>>> Mika Nystrom wrote: >>>>>> Ah I should read my whole inbox before replying. >>>>>> >>>>>> I take it you would worry that in my proposal (to do this all in a >>>>>> library) the use of REFANY to store an integer could be abused >>>>>> somehow. That the Modula-3 type system (as it exists now) >>>>>> explicitly >>>>>> rules out doing such things, and therefore, a language change is >>>>>> necessary.... >>>>>> >>>>>> Mika >>>>>> >>>>>> Tony Hosking writes: >>>>>> >>>>>>> I like the notion of having a TAGGED INTEGER type that is a >>>>>>> hybrid >>>>>>> ordinal/reference. >>>>>>> >>>>>>> Subtyping rules for references would now be as follows: >>>>>>> >>>>>>> NULL <: REF T <: REFANY >>>>>>> TAGGED INTEGER <: REF T <: REFANY >>>>>>> >>>>>>> ROOT <: REFANY >>>>>>> NULL <: T OBJECT ... END <: T >>>>>>> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: >>>>>>> REFANY, not >>>>>>> T <: ADDRESS) >>>>>>> >>>>>>> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >>>>>>> type. Values of TAGGED INTEGER are non-pointer values similar >>>>>>> to the >>>>>>> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and >>>>>>> NARROW(x, >>>>>>> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to >>>>>>> ISTYPE(x, >>>>>>> NULL), NARROW(x, NULL), and TYPECODE(NULL). >>>>>> >>>>>>> Because TAGGED INTEGER is an ordinal we can extract the integer >>>>>>> value >>>>>>> it holds using ORD(x). >>>>>>> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >>>>>>> INTEGER). >>>>>>> >>>>>>> ***The only problem with this scheme is how to efficiently >>>>>>> perform run- >>>>>>> time tests for dereferencing NULL, and TAGGED INTEGER?*** >>>>>> >>>>>>> So, here is a slightly less elegant alternative that is probably >>>>>>> straightforward to implement. Introduce a separate TAGGED >>>>>>> hierarchy. >>>>>>> >>>>>>> NULL <: REF T <: REFANY >>>>>>> NULL <: UNTRACED REF T <: ADDRESS >>>>>>> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >>>>>>> >>>>>>> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >>>>>>> >>>>>>> ROOT <: REFANY >>>>>>> TAGGED ROOT <: TAGGED REFANY >>>>>>> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >>>>>>> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >>>>>>> >>>>>>> Note that NULL is not a subtype of T OBJECT ... END where T <: >>>>>>> TAGGED >>>>>>> REFANY. >>>>>>> >>>>>>> This way, tagged references only need a run-time test for the >>>>>>> tag on >>>>>>> dereference (we can throw an "attempt to dereference TAGGED >>>>>>> INTEGER" >>>>>>> at run time, just like we throw "attempt to dereference NIL" for >>>>>>> untagged references). This check can be a straightforward test >>>>>>> of the >>>>>>> low bit tag. Of course, the weird thing here is now that we >>>>>>> don't >>>>>>> have a single NULL value for TAGGED references --- we have >>>>>>> multiple >>>>>>> null values VAL(x, TAGGED INTEGER). Instead of asking "x == >>>>>>> NIL" we >>>>>>> must ask "ISTYPE(x, TAGGED INTEGER)". >>>>>>> >>>>>>> Of course, because TAGGED INTEGER is an ordinal, we can also >>>>>>> perform >>>>>>> the usual ordinal operations like INC(x), DEC(x), wherever x is >>>>>>> typed >>>>>>> TAGGED INTEGER. >>>>>>> >>>>>>> >>>>>>> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >>>>>>> >>>>>>> >>>>>>>> I spent quite a bit of time playing with a more general system >>>>>>>> where >>>>>>>> there is a set of "tagged" types, with (an implementation- >>>>>>>> defined >>>>>>>> subrange of) INTEGER and a reference type both being a subtype >>>>>>>> of a >>>>>>>> tagged type. It might have been tolerable, if it weren't for >>>>>>>> the >>>>>>>> interaction with object subtypes and opaque types, which quickly >>>>>>>> gets deep into a deep linguistic tar pit. >>>>>>>> >>>>>>>> Tony's approach is much simpler and would serve what I see as >>>>>>>> the >>>>>>>> need. It does sacrifice any static checking of what reference >>>>>>>> type >>>>>>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>>>>>> TYPECASE. >>>>>>>> >>>>>>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>>>>>> also need to be an explicit conversion in that direction too, >>>>>>>> say >>>>>>>> VAL(x, TAGGED)? I think I favor the explicit conversion >>>>>>>> here. It >>>>>>>> is a bit inconsistent with the usual Modula-3 assignability >>>>>>>> philosophy, >>>>>>>> but not requiring the explicit conversion already gets your toes >>>>>>>> into tar. >>>>>>>> >>>>>>>> We would have to have something more like ISTYPE, though, >>>>>>>> which will >>>>>>>> tell which type the value belongs to without risking a runtime >>>>>>>> error, >>>>>>>> which VAL would do. >>>>>>>> >>>>>>>> An intermediate approach might be to have a set of tagged types >>>>>>>> constructed by, say, TAGGED T, where I is a reference type, but >>>>>>>> with no subtype relations on them at all, thus still requiring >>>>>>>> the explicit conversions and checks. >>>>>>>> >>>>>>>> I do want to say, I _really_ want this capability somehow. I >>>>>>>> have >>>>>>>> an ADT module whose internal data structure, for full >>>>>>>> generality, >>>>>>>> needs to have two heap objects (the second because it has >>>>>>>> nonstatic >>>>>>>> size) and 11 total words counting the orginal pointer, in the >>>>>>>> case of >>>>>>>> values that would fit directly into the "pointer" word. >>>>>>>> Moreover, >>>>>>>> these small cases are in the great majority. >>>>>>>> >>>>>>>> Besides the 11-to-one increase in actual occupied space, there >>>>>>>> is extra time for allocation, periodic tracing, and >>>>>>>> collection, space >>>>>>>> loss due to heap fragmentation, and time/space tradeoff loss >>>>>>>> due to >>>>>>>> reduced locality of reference. So sometimes, it would be a big >>>>>>>> performance gain if we could do it. >>>>>>>> >>>>>>>> >>>>>>>> Tony Hosking wrote: >>>>>>>> >>>>>>>>> It is a much more pervasive hack than I would be comfortable >>>>>>>>> with >>>>>>>>> since it touches on the compiler (for all the type >>>>>>>>> operations) as >>>>>>>>> well >>>>>>>>> as the run-time system in ways that are pretty gross. I >>>>>>>>> would much >>>>>>>>> rather have a new TAGGED builtin. ISTYPE would not work on >>>>>>>>> it since >>>>>>>>> that only works on references. The only thing you need is a >>>>>>>>> way to >>>>>>>>> extract the value -- we could overload VAL(x, T) where x can >>>>>>>>> be a >>>>>>>>> TAGGED and T can be REFANY or INTEGER. >>>>>>>>> >>>>>>>>> >>>>>> >>>>>> From hosking at cs.purdue.edu Tue Apr 7 11:27:04 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 19:27:04 +1000 Subject: [M3devel] small objects In-Reply-To: <200904070727.n377RDug014714@camembert.async.caltech.edu> References: <200904070727.n377RDug014714@camembert.async.caltech.edu> Message-ID: <46A56B65-6B75-47E8-ABDC-CBFC357594CE@cs.purdue.edu> Exactly! I really like this. But why wouldn't the pickler have a special for tagged REFANY? By the way, I think it is language definition agnostic - the behaviours are consistent with the spec: > ISTYPE (x: Reference; T: RefType) : BOOLEAN x a tagged REFANY returns FALSE, unless T is REFANY > ISTYPE(x, T) is TRUE if and only if x is a member of T. T must be an > object type or traced reference type, and x must be assignable to T. > NARROW (x: Reference; T: RefType): T > x a tagged REFANY causes a runtime error > NARROW(x, T) returns x after checking that x is a member of T. If > the check fails, a runtime error occurs. T must be an object type or > traced reference type, and x must be assignable to T. > > TYPECODE (T: RefType) : CARDINAL > (r: REFANY) : CARDINAL > r a tagged REFANY returns RT0.RefanyTypecode > (r: UNTRACED ROOT) : CARDINAL > > Every object type or traced reference type (including NULL) has an > associated integer code. Different types have different codes. The > code for a type is constant for any single execution of a program, > but may differ for different executions. TYPECODE(T) returns the > code for the type T and TYPECODE(r) returns the code for the > allocated type of r. It is a static error if T is REFANY or is not > an object type or traced reference type. Does anyone have a good reason why TYPECODE(REFANY) should be a static error? On 7 Apr 2009, at 17:27, Mika Nystrom wrote: > Oh I see. I think... > > You're saying that because RT0.RefanyTypecode is essentially > "useless", it's OK to have values with that typecode since no > (existing) module can do anything with that knowledge? > > So...this proposal says that ISTYPE returns FALSE for everything > except ISTYPE(r,REFANY). > > TYPECASE, same. > > TYPECODE, as you say, RT0.RefanyTypecode. > > In other words, it's a useless value except for whatever unsafe code > is lurking inside TaggedInteger. > > So normally, TYPECODE never returns RT0.RefanyTypecode? That's the > only thing that would change as far as I can tell... I can't see how > that could possibly break anything. > > Checking for the tagged integers can then be done by checking whether > TYPECODE returns RT0.RefanyTypecode. The pickler would build an > object when it sees that and pickle that, instead of the tagged > integer. > > So change the language spec to allow the above behavior for a value > of type REFANY and to say that unsafe modules may be able to do > some other implementation-dependent things with these 'REFANYs of > the third kind'? > > Mika > > > Tony Hosking writes: >> erratum: >> >> TYPECODE(r) = RT0.RefanyTypecode if r is a tagged REFANY. >> >> (It is a static error to say TYPECODE(REFANY)) >> >> On 7 Apr 2009, at 16:55, Tony Hosking wrote: >> >>> After all of this -- I may simply be coming back around to your >>> original proposal -- why not simply declare: >>> >>> TaggedInteger.T = REFANY; >>> >>> ? >>> >>> You can't instantiate a REFANY. >>> >>> All we really need is the LOOPHOLEing of your original proposal to >>> extract the integer values, and to make sure that ISTYPE and NARROW >>> have the behavior you describe for tagged REFANY. Does it make >>> sense that TYPECODE(r) = TYPECODE(REFANY) for any tagged REFANY? >>> What else are we missing? >>> >>> On 7 Apr 2009, at 06:39, Mika Nystrom wrote: >>> >>>> And finally, to forestall a possible objection to the scheme >>>> I proposed: >>>> >>>> Yes, it is true that even a non-UNSAFE module can allocate a >>>> TaggedInteger.T by calling >>>> >>>> new := RTAllocator.NewTraced(TYPECODE(r)) >>>> >>>> where r is a tagged integer. >>>> >>>> But since it cannot dereference that new value or do anything else >>>> with it, I don't think this is a problem. The Pickler (built into >>>> the TaggedInteger module, one must assume) would simply have to >>>> be on the lookout for values of the "real" TaggedInteger.T versus >>>> those that are just numbers with the LSB set, and act accordingly. >>>> Since the T declaration is only visible within the UNSAFE module >>>> there can never be any question of another module's muddling the >>>> two types up. >>>> >>>> Mika >>>> >>>> Mika Nystrom writes: >>>>> "Rodney M. Bates" writes: >>>>>> At first, I just envisioned implementing a small object type >>>>>> entirely inside an UNSAFE module, using unsafe operations >>>>>> to construct/test/separate the values. I think if the GC were >>>>>> to just to ignore words in heap objects that the type system >>>>>> claims are unambiguously pointers but actually have misaligned >>>>>> values, this could be done. >>>>> >>>>> Right that's precisely what the module I posted does. >>>>> >>>>>> >>>>>> But it flies in the face of a fundamental principle of Modula-3, >>>>>> namely that an UNSAFE module, if coded correctly, can prevent >>>>>> all other code from consequences of the unsafety. Unfortunately, >>>>>> this can't be done with the small pointers, because, even if >>>>>> opaque, they are still reference types, and client code can >>>>>> dereference them (including the implicit dereference in accessing >>>>>> a method or field of an object) and do ISTYPE, NARROW, TYPECASE, >>>>>> and assignments that do an implicit NARROW. All these operations >>>>>> could be done outside the implementing module and all could >>>>>> suffer from misaligned values. >>>>> >>>>> Well yes that is true. But the client can't dereference REFANY. >>>>> Modula-3 doesn't permit that. That's an important practical >>>>> point, >>>>> because now we're limited to the other things: ISTYPE, NARROW >>>>> (implicit and explicit), TYPECASE. (There are two more, actually, >>>>> and they are = and #.) As long as those can be guaranteed to fail >>>>> you're OK. [ Actually see my P.S. below! ] >>>>> >>>>>> >>>>>> In fact, misaligned integer "objects" violate another principle >>>>>> that >>>>>> the bit pattern must always be a valid representation of some >>>>>> value >>>>>> of the type. >>>>> >>>>> Yes I think maybe this is what Tony is worried about. But let's >>>>> just change the definition of REFANY to include anything with the >>>>> LSB set...? >>>>> >>>>> In Modula-3-ese it would be more like the following: >>>>> >>>>> "REFANY can hold three types of objects. NIL, REF something or an >>>>> implementation-defined other set of values that can only be >>>>> accessed >>>>> in an UNSAFE module. It is a checked runtime error to pass a >>>>> 'REFANY >>>>> of the third kind' to ISTYPE, NARROW, TYPECASE." [ Actually see my >>>>> P.S. below! ] >>>>> >>>>> Then I propose we punt the handling of the new REFANYs to this >>>>> unsafe module we spoke about above. As far as Modula-3 is >>>>> concerned, >>>>> there's just a set of values of (apparently) very little utility >>>>> that can be represented by REFANY. If you think about it, this is >>>>> really not so crazy. Any module that uses REFANY today is >>>>> designed >>>>> around to the fact that there are plenty of values of REFANY that >>>>> can be of no interest to that module except for passing along to >>>>> another module. (REFANY can easily represent a type which a >>>>> module >>>>> has no way of accessing *any* declaration of beyond just REFANY.) >>>>> We're just adding some others, the only difference being that the >>>>> new values are of no interest to any non-UNSAFE module. (Eh, >>>>> technically this is already true for any reference type that is >>>>> declared in an UNSAFE module today so one might argue we have in >>>>> fact added nothing.) >>>>> >>>>>> >>>>>> However, this does suggest a different and very simple linguistic >>>>>> solution: Just have a new builtin type, say VERYOPAQUE, that >>>>>> supports no operations other than moving it around, i.e., >>>>>> assignment, bindings, passing as a parameter, etc. Only unsafe >>>>>> code could do anyhing with it, by using LOOPHOLE. The only >>>>>> problem is, would somebody then want one of these in a size other >>>>>> than one word? >>>>> >>>>> This is nice, and we already have a candidate type, in fact: >>>>> ADDRESS. >>>>> But the problem is that the GC doesn't follow this even if the LSB >>>>> is clear... which we *do* want. >>>>> >>>>> Why are you worried about getting it in sizes other than one word? >>>>> That seems to me to be an application problem. If someone wants >>>>> an ARRAY OF VERYOPAQUE is that a problem? >>>>> >>>>> Mika >>>>> >>>>> P.S. Illustration of the above, in today's Modula-3: >>>>> >>>>> UNSAFE MODULE Unsafe; >>>>> >>>>> (* this module is just declared UNSAFE to conform with the >>>>> definition >>>>> above, namely, that T can only be manipulated in an UNSAFE >>>>> module, which this is! *) >>>>> >>>>> TYPE T = BRANDED OBJECT END; >>>>> >>>>> BEGIN >>>>> Safe.P(NEW(T)) >>>>> END Unsafe. >>>>> >>>>> (****************************************) >>>>> >>>>> MODULE Safe; >>>>> >>>>> PROCEDURE P(r : REFANY) = >>>>> BEGIN >>>>> NARROW(r, X); (* checked runtime error for all X *) >>>>> >>>>> ISTYPE(r, X); (* returns FALSE for all X except REFANY itself *) >>>>> >>>>> TYPECASE r OF >>>>> X => (* only gets executed for X = REFANY *) >>>>> END; >>>>> END P; >>>>> >>>>> BEGIN END Safe. >>>>> >>>>> Actually is this behavior so bad for tagged integers? Since it is >>>>> the behavior of existing code... why not keep it? Then you can >>>>> even >>>>> store a tagged integer in a RefList.T, say, even if that RefList.T >>>>> uses NARROW or ISTYPE on the argument (I don't see why it would, >>>>> but >>>>> why not...?) >>>>> >>>>> >>>>> >>>>>> >>>>>> Mika Nystrom wrote: >>>>>>> Ah I should read my whole inbox before replying. >>>>>>> >>>>>>> I take it you would worry that in my proposal (to do this all >>>>>>> in a >>>>>>> library) the use of REFANY to store an integer could be abused >>>>>>> somehow. That the Modula-3 type system (as it exists now) >>>>>>> explicitly >>>>>>> rules out doing such things, and therefore, a language change is >>>>>>> necessary.... >>>>>>> >>>>>>> Mika >>>>>>> >>>>>>> Tony Hosking writes: >>>>>>> >>>>>>>> I like the notion of having a TAGGED INTEGER type that is a >>>>>>>> hybrid >>>>>>>> ordinal/reference. >>>>>>>> >>>>>>>> Subtyping rules for references would now be as follows: >>>>>>>> >>>>>>>> NULL <: REF T <: REFANY >>>>>>>> TAGGED INTEGER <: REF T <: REFANY >>>>>>>> >>>>>>>> ROOT <: REFANY >>>>>>>> NULL <: T OBJECT ... END <: T >>>>>>>> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: >>>>>>>> REFANY, not >>>>>>>> T <: ADDRESS) >>>>>>>> >>>>>>>> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/ >>>>>>>> reference >>>>>>>> type. Values of TAGGED INTEGER are non-pointer values similar >>>>>>>> to the >>>>>>>> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and >>>>>>>> NARROW(x, >>>>>>>> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to >>>>>>>> ISTYPE(x, >>>>>>>> NULL), NARROW(x, NULL), and TYPECODE(NULL). >>>>>>> >>>>>>>> Because TAGGED INTEGER is an ordinal we can extract the integer >>>>>>>> value >>>>>>>> it holds using ORD(x). >>>>>>>> Similarly, we can construct a TAGGED INTEGER using VAL(x, >>>>>>>> TAGGED >>>>>>>> INTEGER). >>>>>>>> >>>>>>>> ***The only problem with this scheme is how to efficiently >>>>>>>> perform run- >>>>>>>> time tests for dereferencing NULL, and TAGGED INTEGER?*** >>>>>>> >>>>>>>> So, here is a slightly less elegant alternative that is >>>>>>>> probably >>>>>>>> straightforward to implement. Introduce a separate TAGGED >>>>>>>> hierarchy. >>>>>>>> >>>>>>>> NULL <: REF T <: REFANY >>>>>>>> NULL <: UNTRACED REF T <: ADDRESS >>>>>>>> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >>>>>>>> >>>>>>>> Note that NULL is not a subtype of TAGGED REF T or TAGGED >>>>>>>> REFANY. >>>>>>>> >>>>>>>> ROOT <: REFANY >>>>>>>> TAGGED ROOT <: TAGGED REFANY >>>>>>>> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >>>>>>>> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED >>>>>>>> REFANY >>>>>>>> >>>>>>>> Note that NULL is not a subtype of T OBJECT ... END where T <: >>>>>>>> TAGGED >>>>>>>> REFANY. >>>>>>>> >>>>>>>> This way, tagged references only need a run-time test for the >>>>>>>> tag on >>>>>>>> dereference (we can throw an "attempt to dereference TAGGED >>>>>>>> INTEGER" >>>>>>>> at run time, just like we throw "attempt to dereference NIL" >>>>>>>> for >>>>>>>> untagged references). This check can be a straightforward test >>>>>>>> of the >>>>>>>> low bit tag. Of course, the weird thing here is now that we >>>>>>>> don't >>>>>>>> have a single NULL value for TAGGED references --- we have >>>>>>>> multiple >>>>>>>> null values VAL(x, TAGGED INTEGER). Instead of asking "x == >>>>>>>> NIL" we >>>>>>>> must ask "ISTYPE(x, TAGGED INTEGER)". >>>>>>>> >>>>>>>> Of course, because TAGGED INTEGER is an ordinal, we can also >>>>>>>> perform >>>>>>>> the usual ordinal operations like INC(x), DEC(x), wherever x is >>>>>>>> typed >>>>>>>> TAGGED INTEGER. >>>>>>>> >>>>>>>> >>>>>>>> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >>>>>>>> >>>>>>>> >>>>>>>>> I spent quite a bit of time playing with a more general system >>>>>>>>> where >>>>>>>>> there is a set of "tagged" types, with (an implementation- >>>>>>>>> defined >>>>>>>>> subrange of) INTEGER and a reference type both being a subtype >>>>>>>>> of a >>>>>>>>> tagged type. It might have been tolerable, if it weren't for >>>>>>>>> the >>>>>>>>> interaction with object subtypes and opaque types, which >>>>>>>>> quickly >>>>>>>>> gets deep into a deep linguistic tar pit. >>>>>>>>> >>>>>>>>> Tony's approach is much simpler and would serve what I see as >>>>>>>>> the >>>>>>>>> need. It does sacrifice any static checking of what reference >>>>>>>>> type >>>>>>>>> is being tagged, and will also require an extra runtime >>>>>>>>> ISTYPE/ >>>>>>>>> TYPECASE. >>>>>>>>> >>>>>>>>> Would INTEGER and REFANY be assignable to TAGGED, or would >>>>>>>>> there >>>>>>>>> also need to be an explicit conversion in that direction too, >>>>>>>>> say >>>>>>>>> VAL(x, TAGGED)? I think I favor the explicit conversion >>>>>>>>> here. It >>>>>>>>> is a bit inconsistent with the usual Modula-3 assignability >>>>>>>>> philosophy, >>>>>>>>> but not requiring the explicit conversion already gets your >>>>>>>>> toes >>>>>>>>> into tar. >>>>>>>>> >>>>>>>>> We would have to have something more like ISTYPE, though, >>>>>>>>> which will >>>>>>>>> tell which type the value belongs to without risking a runtime >>>>>>>>> error, >>>>>>>>> which VAL would do. >>>>>>>>> >>>>>>>>> An intermediate approach might be to have a set of tagged >>>>>>>>> types >>>>>>>>> constructed by, say, TAGGED T, where I is a reference type, >>>>>>>>> but >>>>>>>>> with no subtype relations on them at all, thus still requiring >>>>>>>>> the explicit conversions and checks. >>>>>>>>> >>>>>>>>> I do want to say, I _really_ want this capability somehow. I >>>>>>>>> have >>>>>>>>> an ADT module whose internal data structure, for full >>>>>>>>> generality, >>>>>>>>> needs to have two heap objects (the second because it has >>>>>>>>> nonstatic >>>>>>>>> size) and 11 total words counting the orginal pointer, in the >>>>>>>>> case of >>>>>>>>> values that would fit directly into the "pointer" word. >>>>>>>>> Moreover, >>>>>>>>> these small cases are in the great majority. >>>>>>>>> >>>>>>>>> Besides the 11-to-one increase in actual occupied space, there >>>>>>>>> is extra time for allocation, periodic tracing, and >>>>>>>>> collection, space >>>>>>>>> loss due to heap fragmentation, and time/space tradeoff loss >>>>>>>>> due to >>>>>>>>> reduced locality of reference. So sometimes, it would be a >>>>>>>>> big >>>>>>>>> performance gain if we could do it. >>>>>>>>> >>>>>>>>> >>>>>>>>> Tony Hosking wrote: >>>>>>>>> >>>>>>>>>> It is a much more pervasive hack than I would be comfortable >>>>>>>>>> with >>>>>>>>>> since it touches on the compiler (for all the type >>>>>>>>>> operations) as >>>>>>>>>> well >>>>>>>>>> as the run-time system in ways that are pretty gross. I >>>>>>>>>> would much >>>>>>>>>> rather have a new TAGGED builtin. ISTYPE would not work on >>>>>>>>>> it since >>>>>>>>>> that only works on references. The only thing you need is a >>>>>>>>>> way to >>>>>>>>>> extract the value -- we could overload VAL(x, T) where x can >>>>>>>>>> be a >>>>>>>>>> TAGGED and T can be REFANY or INTEGER. >>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Apr 7 13:49:58 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 7 Apr 2009 07:49:58 -0400 Subject: [M3devel] small objects In-Reply-To: <985F59A0-82EA-4F55-B6C8-DA057B9E23DB@cs.purdue.edu> References: <200904070042.n370gNK3001242@camembert.async.caltech.edu> <9F2237E2-73A2-4926-A438-A6032F70B4F6@cs.purdue.edu> <49DA8196.1E75.00D7.1@scires.com> <985F59A0-82EA-4F55-B6C8-DA057B9E23DB@cs.purdue.edu> Message-ID: <20090407114957.GA27695@topoi.pooq.com> On Tue, Apr 07, 2009 at 12:52:59PM +1000, Tony Hosking wrote: > On 7 Apr 2009, at 12:27, Randy Coleburn wrote: > > >Hey, will this proposal mean that packages like "stable" and > >"stubgen" need to be changed also, in addition to both versions of > >pickles? > > They build on m3tk so should just work, modulo any builtin typecode > information. TAGGED INTEGER will have a predefined typecode just like > NULL. I'm confused. I thought the only tagged types were reference types. -- hendrik From hendrik at topoi.pooq.com Tue Apr 7 14:12:17 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 7 Apr 2009 08:12:17 -0400 Subject: [M3devel] small objects In-Reply-To: References: <200904062039.n36KdIsY095003@camembert.async.caltech.edu> Message-ID: <20090407121217.GB27695@topoi.pooq.com> On Tue, Apr 07, 2009 at 04:55:12PM +1000, Tony Hosking wrote: > After all of this -- I may simply be coming back around to your > original proposal -- why not simply declare: > > TaggedInteger.T = REFANY; You'd be adding a range of integers to the set of things a REFANY could hold. Might that enable one to pass these integers as REFANYs to existing code that isn't expecting it? Might code that checks its input for suitable preconditions then let this case slide? Or would any test that checks that a REFANY holds an appropriate reference or NIL automatically manage to exclude tagged integers, just as it excludes inappropriate references? I don't mind the proposed semantics for REFANY -- if it had been there from the beginning. But with a lot of existing code in existing libraries, would it be safer to use a new type for this new meaning? You could, of course, stull have an unsafe module that defines TaggedInteger.T = NEWTYPEWITHNEWNAME; -- hendrik From hendrik at topoi.pooq.com Tue Apr 7 14:21:28 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 7 Apr 2009 08:21:28 -0400 Subject: [M3devel] small objects In-Reply-To: <200904070727.n377RDug014714@camembert.async.caltech.edu> References: <200904070727.n377RDug014714@camembert.async.caltech.edu> Message-ID: <20090407122128.GC27695@topoi.pooq.com> On Tue, Apr 07, 2009 at 12:27:13AM -0700, Mika Nystrom wrote: > Oh I see. I think... > > You're saying that because RT0.RefanyTypecode is essentially > "useless", it's OK to have values with that typecode since no > (existing) module can do anything with that knowledge? This looks like inelegant semantics. A way of retrofitting a new feature in an existing semantic gap. The kind of patch that will bite us if ever there is a proper use for the typecode for REFANY. (I can imagine someday someone might have a use for such a thing, such as a dynamic test on typecodes to determine whether one type is a subtypoe of another ... I can't really imagine what someone might need in the future). But I thing this kind of thing might really stand in the way. REFANY is about references. Let's have a new type, with its own typecode, for things that can be other than references. -- hendrik From hosking at cs.purdue.edu Tue Apr 7 14:26:08 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 22:26:08 +1000 Subject: [M3devel] small objects In-Reply-To: <20090407121217.GB27695@topoi.pooq.com> References: <200904062039.n36KdIsY095003@camembert.async.caltech.edu> <20090407121217.GB27695@topoi.pooq.com> Message-ID: You can't do anything directly with a REFANY. To use it you need to narrow to a concrete type. We would disallow that for tagged values with a run-time check. Existing code needs to check (using ISTYPE or TYPECASE), or know by design, what type is safe to narrow to, before narrowing anyway. So I think all is ok. On 7 Apr 2009, at 22:12, hendrik at topoi.pooq.com wrote: > On Tue, Apr 07, 2009 at 04:55:12PM +1000, Tony Hosking wrote: >> After all of this -- I may simply be coming back around to your >> original proposal -- why not simply declare: >> >> TaggedInteger.T = REFANY; > > You'd be adding a range of integers to the set of things a REFANY > could > hold. Might that enable one to pass these integers as REFANYs to > existing code that isn't expecting it? Might code that checks its > input > for suitable preconditions then let this case slide? Or would any > test > that checks that a REFANY holds an appropriate reference or NIL > automatically manage to exclude tagged integers, just as it excludes > inappropriate references? > > I don't mind the proposed semantics for REFANY -- if it had been > there from the beginning. But with a lot of existing code in existing > libraries, would it be safer to use a new type for this new meaning? > > You could, of course, stull have an unsafe module that defines > > TaggedInteger.T = NEWTYPEWITHNEWNAME; > > -- hendrik From mika at async.caltech.edu Tue Apr 7 19:12:55 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 07 Apr 2009 10:12:55 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Tue, 07 Apr 2009 22:26:08 +1000." Message-ID: <200904071712.n37HCtda030844@camembert.async.caltech.edu> Tony, I think you have convinced me that what you say is workable. However I share Hendrik's concern that using RT0.RefanyTypecode might hurt some day in the future, even if I think you have shown pretty convincingly that it doesn't hurt today. How about my "second proposal". Do pretty much what you suggest but instead of returning RT0.RefanyTypecode, return TYPECODE(TaggedInteger.T), where TaggedInteger.T is an object type that is declared entirely privately to the TaggedInteger unsafe module... this also gives a completely obvious implementation for pickling the tagged integers. Simply convert them to TaggedInteger.T and pickle that. An implementation that doesn't support tagged integers in pointers could also allocate "real" TaggedInteger.Ts.... not sure that is useful though or if it just confuses. Actually I think it is useful, because it lets you represent the values even if unpickling in a system that doesn't support tagged integers in REFANYs. I would go so far as saying this... I believe it is possible to guarantee that any safe code outside of the TaggedInteger module couldn't distinguish between a REFANY that holds a tagged integer vs. one that holds a reference to a (heap-allocated) TaggedInteger.T. How's that for not breaking the language definition? Hendrik, I think Tony's and my arguments that you can't break any existing code by allowing the squirreling away of integers into REFANYs are pretty solid. Pre-existing code simply can't do anything useful with unrevealed REFANYs. There are also good reasons for permitting this oddness (vide Smalltalk and Scheme small integers). Mika Tony Hosking writes: >You can't do anything directly with a REFANY. To use it you need to >narrow to a concrete type. We would disallow that for tagged values >with a run-time check. Existing code needs to check (using ISTYPE or >TYPECASE), or know by design, what type is safe to narrow to, before >narrowing anyway. So I think all is ok. > >On 7 Apr 2009, at 22:12, hendrik at topoi.pooq.com wrote: > >> On Tue, Apr 07, 2009 at 04:55:12PM +1000, Tony Hosking wrote: >>> After all of this -- I may simply be coming back around to your >>> original proposal -- why not simply declare: >>> >>> TaggedInteger.T = REFANY; >> >> You'd be adding a range of integers to the set of things a REFANY >> could >> hold. Might that enable one to pass these integers as REFANYs to >> existing code that isn't expecting it? Might code that checks its >> input >> for suitable preconditions then let this case slide? Or would any >> test >> that checks that a REFANY holds an appropriate reference or NIL >> automatically manage to exclude tagged integers, just as it excludes >> inappropriate references? >> >> I don't mind the proposed semantics for REFANY -- if it had been >> there from the beginning. But with a lot of existing code in existing >> libraries, would it be safer to use a new type for this new meaning? >> >> You could, of course, stull have an unsafe module that defines >> >> TaggedInteger.T = NEWTYPEWITHNEWNAME; >> >> -- hendrik From rodney.m.bates at cox.net Tue Apr 7 18:11:48 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Tue, 07 Apr 2009 11:11:48 -0500 Subject: [M3devel] small objects In-Reply-To: <40B7AD71-FBDD-4321-837F-D294DD4A3D45@cs.purdue.edu> References: <200903300333.n2U3XBME062502@camembert.async.caltech.edu> <49D95E70.6000004@wichita.edu> <40B7AD71-FBDD-4321-837F-D294DD4A3D45@cs.purdue.edu> Message-ID: <49DB7B44.2000000@cox.net> Tagged types and object type hierarchies: At first, I was imagining that you could create an object subtype of a TAGGED type: (* An untagged hierarchy: *) TYPE O1 = OBJECT F1: INTEGER END; TYPE O2 = O1 OBJECT F2: CHAR END; TYPE O3 = O2 OBJECT F3: BOOLEAN END: (* Tag each one directly: *) TYPE TO1 = TAGGED O1; TYPE TO2 = TAGGED O2; TYPE TO3 = TAGGED O3; (* A tagged hierarchy: *) TYPE TO2S = TO1 OBJECT F2: CHAR END; TYPE TO3S = TO2S OBJECT F3: BOOLEAN END; Is TO2S = TO2 and TO3S = TO3? Is O2 <: TO2S and O3 <: TO3S? Therein lies tar. The type equality and subtype relations are getting awfully elaborate for a language that advertises relative simplicity. Then I thought about two parallel hierarchies, one tagged and one not, as Tony's second proposal. But that leaves it awfully inconvenient to have both a tagged and untagged counterpart that are otherwise the same, and you need the untagged counterpart to do ISTYPE/NARROW/TYPECASE/:= to get the "definitely-a-heap-reference" value out of a tagged type. If I read it right, Tony's first proposal does not allow to subclass an already tagged type (i.e., no "tagged hierarchy" as above). Is that what you meant, Tony? If so, I think this is enough, and avoids the complicated type equality and subtype relations. A separate issue: On the INTEGER side of this, I think we need a builtin type that is an implementation-defined subrange of INTEGER, that can hold just the integer values a tagged type can hold. Maybe "TAG"? (Actually, this name is a poor choice, since it's not the tag itself, but it's the best I can think right now, so I will use it in discussion). If we really want to constrain the implementation to always use exactly the low bit as the tag, then CARDINAL would do for this. A new builtin type would leave open other tagging representations with other ranges of representable integers, as well as the low-bit tag with signed integers. Then we could also allow ISTYPE(x, TAG), etc. to get the "definitely-an- integer" value out. This gives fully type-safe support for small objects, which I really prefer, if not too complicated. Tony Hosking wrote: > I like the notion of having a TAGGED INTEGER type that is a hybrid > ordinal/reference. > > Subtyping rules for references would now be as follows: > > NULL <: REF T <: REFANY > TAGGED INTEGER <: REF T <: REFANY > > ROOT <: REFANY > NULL <: T OBJECT ... END <: T > TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: REFANY, not > T <: ADDRESS) > > Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference > type. Values of TAGGED INTEGER are non-pointer values similar to the > value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and NARROW(x, > TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to ISTYPE(x, > NULL), NARROW(x, NULL), and TYPECODE(NULL). > > Because TAGGED INTEGER is an ordinal we can extract the integer value > it holds using ORD(x). > Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED > INTEGER). > > ***The only problem with this scheme is how to efficiently perform > run-time tests for dereferencing NULL, and TAGGED INTEGER?*** > > So, here is a slightly less elegant alternative that is probably > straightforward to implement. Introduce a separate TAGGED hierarchy. > > NULL <: REF T <: REFANY > NULL <: UNTRACED REF T <: ADDRESS > TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY > > Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. > > ROOT <: REFANY > TAGGED ROOT <: TAGGED REFANY > NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS > TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY > > Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED > REFANY. > > This way, tagged references only need a run-time test for the tag on > dereference (we can throw an "attempt to dereference TAGGED INTEGER" > at run time, just like we throw "attempt to dereference NIL" for > untagged references). This check can be a straightforward test of the > low bit tag. Of course, the weird thing here is now that we don't > have a single NULL value for TAGGED references --- we have multiple > null values VAL(x, TAGGED INTEGER). Instead of asking "x == NIL" we > must ask "ISTYPE(x, TAGGED INTEGER)". > > Of course, because TAGGED INTEGER is an ordinal, we can also perform > the usual ordinal operations like INC(x), DEC(x), wherever x is typed > TAGGED INTEGER. > From mika at async.caltech.edu Tue Apr 7 20:33:05 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 07 Apr 2009 11:33:05 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Tue, 07 Apr 2009 11:11:48 CDT." <49DB7B44.2000000@cox.net> Message-ID: <200904071833.n37IX5Hg033221@camembert.async.caltech.edu> So following my previous email, I suggest the following, which doesn't change the language definition at all: INTERFACE TaggedInteger; IMPORT Word; TYPE T <: REFANY; V = [ TaggedMin .. TaggedMax ]; CONST TaggedMin = -Word.Shift(1,BITSIZE(REFANY)-2); TaggedMax = Word.Shift(1,BITSIZE(REFANY)-2) - 1; PROCECURE Extract(t : T) : V; PROCEDURE New(v : V) : T; (* ...the usual generic support routines... *) END TaggedInteger. The compiler, runtime, and the implementation of this interface would be responsible for hiding the values in REFANYs, doing the correct thing for NARROW, ISTYPE, TYPECASE, TYPECODE, # and =... What functionality is missing? I think the compiler/runtime changes are pretty much the same no matter which of the proposals you go with... Mika "Rodney M. Bates" writes: >Tagged types and object type hierarchies: > >At first, I was imagining that you could create >an object subtype of a TAGGED type: > >(* An untagged hierarchy: *) >TYPE O1 = OBJECT F1: INTEGER END; >TYPE O2 = O1 OBJECT F2: CHAR END; >TYPE O3 = O2 OBJECT F3: BOOLEAN END: > >(* Tag each one directly: *) >TYPE TO1 = TAGGED O1; >TYPE TO2 = TAGGED O2; >TYPE TO3 = TAGGED O3; > >(* A tagged hierarchy: *) >TYPE TO2S = TO1 OBJECT F2: CHAR END; >TYPE TO3S = TO2S OBJECT F3: BOOLEAN END; > >Is TO2S = TO2 and TO3S = TO3? > >Is O2 <: TO2S and O3 <: TO3S? > >Therein lies tar. The type equality and subtype relations are getting >awfully elaborate for a language that advertises relative simplicity. > >Then I thought about two parallel hierarchies, one tagged and one not, >as Tony's second proposal. But that leaves it awfully inconvenient >to have both a tagged and untagged counterpart that are otherwise the >same, and you need the untagged counterpart to do ISTYPE/NARROW/TYPECASE/:= >to get the "definitely-a-heap-reference" value out of a tagged type. > >If I read it right, Tony's first proposal does not allow to subclass an >already tagged type (i.e., no "tagged hierarchy" as above). Is that >what you meant, Tony? If so, I think this is enough, and avoids the >complicated type equality and subtype relations. > >A separate issue: > >On the INTEGER side of this, I think we need a builtin type that is an >implementation-defined subrange of INTEGER, that can hold just the >integer values a tagged type can hold. Maybe "TAG"? (Actually, this >name is a poor choice, since it's not the tag itself, but it's the best >I can think right now, so I will use it in discussion). > >If we really want to constrain the implementation to always use exactly >the low bit as the tag, then CARDINAL would do for this. A new builtin >type would leave open other tagging representations with other ranges of >representable integers, as well as the low-bit tag with signed integers. > >Then we could also allow ISTYPE(x, TAG), etc. to get the "definitely-an- >integer" value out. > >This gives fully type-safe support for small objects, which I really >prefer, if not too complicated. > > > >Tony Hosking wrote: >> I like the notion of having a TAGGED INTEGER type that is a hybrid >> ordinal/reference. >> >> Subtyping rules for references would now be as follows: >> >> NULL <: REF T <: REFANY >> TAGGED INTEGER <: REF T <: REFANY >> >> ROOT <: REFANY >> NULL <: T OBJECT ... END <: T >> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: REFANY, not >> T <: ADDRESS) >> >> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >> type. Values of TAGGED INTEGER are non-pointer values similar to the >> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and NARROW(x, >> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to ISTYPE(x, >> NULL), NARROW(x, NULL), and TYPECODE(NULL). >> >> Because TAGGED INTEGER is an ordinal we can extract the integer value >> it holds using ORD(x). >> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >> INTEGER). >> >> ***The only problem with this scheme is how to efficiently perform >> run-time tests for dereferencing NULL, and TAGGED INTEGER?*** >> >> So, here is a slightly less elegant alternative that is probably >> straightforward to implement. Introduce a separate TAGGED hierarchy. >> >> NULL <: REF T <: REFANY >> NULL <: UNTRACED REF T <: ADDRESS >> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >> >> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >> >> ROOT <: REFANY >> TAGGED ROOT <: TAGGED REFANY >> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >> >> Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED >> REFANY. >> >> This way, tagged references only need a run-time test for the tag on >> dereference (we can throw an "attempt to dereference TAGGED INTEGER" >> at run time, just like we throw "attempt to dereference NIL" for >> untagged references). This check can be a straightforward test of the >> low bit tag. Of course, the weird thing here is now that we don't >> have a single NULL value for TAGGED references --- we have multiple >> null values VAL(x, TAGGED INTEGER). Instead of asking "x == NIL" we >> must ask "ISTYPE(x, TAGGED INTEGER)". >> >> Of course, because TAGGED INTEGER is an ordinal, we can also perform >> the usual ordinal operations like INC(x), DEC(x), wherever x is typed >> TAGGED INTEGER. >> From hendrik at topoi.pooq.com Tue Apr 7 23:28:53 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 7 Apr 2009 17:28:53 -0400 Subject: [M3devel] small objects In-Reply-To: <200904071712.n37HCtda030844@camembert.async.caltech.edu> References: <200904071712.n37HCtda030844@camembert.async.caltech.edu> Message-ID: <20090407212853.GB32252@topoi.pooq.com> On Tue, Apr 07, 2009 at 10:12:55AM -0700, Mika Nystrom wrote: > Tony, > > I think you have convinced me that what you say is workable. > > However I share Hendrik's concern that using RT0.RefanyTypecode > might hurt some day in the future, even if I think you have shown > pretty convincingly that it doesn't hurt today. I share this concern :-) > How about my "second > proposal". Do pretty much what you suggest but instead of returning > RT0.RefanyTypecode, return TYPECODE(TaggedInteger.T), where > TaggedInteger.T is an object type that is declared entirely privately > to the TaggedInteger unsafe module... this also gives a completely > obvious implementation for pickling the tagged integers. Simply > convert them to TaggedInteger.T and pickle that. An implementation > that doesn't support tagged integers in pointers could also allocate > "real" TaggedInteger.Ts.... not sure that is useful though or if > it just confuses. Actually I think it is useful, because it lets > you represent the values even if unpickling in a system that doesn't > support tagged integers in REFANYs. That may even work. It would take some thinking to be sure it always works, though. And ... could the "real" TaggedInteger.T's be used even when the integers that would be packed into pointers end up being out-of-bounds? > > I would go so far as saying this... I believe it is possible to > guarantee that any safe code outside of the TaggedInteger module > couldn't distinguish between a REFANY that holds a tagged integer > vs. one that holds a reference to a (heap-allocated) TaggedInteger.T. > How's that for not breaking the language definition? I agree. > > Hendrik, I think Tony's and my arguments that you can't break any > existing code by allowing the squirreling away of integers into > REFANYs are pretty solid. Pre-existing code simply can't do anything > useful with unrevealed REFANYs. There are also good reasons for > permitting this oddness (vide Smalltalk and Scheme small integers). > > Mika From hendrik at topoi.pooq.com Tue Apr 7 23:31:12 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 7 Apr 2009 17:31:12 -0400 Subject: [M3devel] small objects In-Reply-To: <49DB7B44.2000000@cox.net> References: <200903300333.n2U3XBME062502@camembert.async.caltech.edu> <49D95E70.6000004@wichita.edu> <40B7AD71-FBDD-4321-837F-D294DD4A3D45@cs.purdue.edu> <49DB7B44.2000000@cox.net> Message-ID: <20090407213112.GC32252@topoi.pooq.com> On Tue, Apr 07, 2009 at 11:11:48AM -0500, Rodney M. Bates wrote: > > A separate issue: > > On the INTEGER side of this, I think we need a builtin type that is an > implementation-defined subrange of INTEGER, that can hold just the > integer values a tagged type can hold. Maybe "TAG"? (Actually, this > name is a poor choice, since it's not the tag itself, but it's the best > I can think right now, so I will use it in discussion). Choosing good names is always difficult. -- hendrik From mika at async.caltech.edu Wed Apr 8 00:14:08 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 07 Apr 2009 15:14:08 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Tue, 07 Apr 2009 17:25:25 EDT." <20090407212524.GA32252@topoi.pooq.com> Message-ID: <200904072214.n37ME8Pj039105@camembert.async.caltech.edu> > >I'm inclined to accept these arguments. Now it's time to come up with >really good names for these things. > >-- hendrik Smalltalk punnily calls them "SmallIntegers". In Scheme they are "fixnums". Oh... I should add, if Tony can figure out a way to do what I proposed, an advantage of providing the interface is that a trivial, safe implementation can be used for compatibility with older compilers. (Yes I still sometimes use PM3 even though I am in fact slowly converting.) Mika From jay.krell at cornell.edu Wed Apr 8 03:03:06 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 8 Apr 2009 01:03:06 +0000 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: <20090406175119.5nknbzf9dwkcwkks@mail.elegosoft.com> References: <200904061532.n36FWunc087102@camembert.async.caltech.edu> <20090406175119.5nknbzf9dwkcwkks@mail.elegosoft.com> Message-ID: Relinking upon install I still think provides desired results and is not a terrible idea, but it is more work to implement. I think the perf is probably acceptable. I don't like to expose too many options to uninformed users, but making this an option might be good. It will have an acceptable default, which makes it being an option much less bad. It's not just one option. There is: 1) using the local machine's install point -- /usr/local/cm3/lib, 2) vs. using $ORIGIN/../lib. Not available on all systems. 3) vs. using package store paths 4) vs. using source tree paths and they can be combined, in various orders. Plus Darwin is different, though maybe Darwin 10.5 is the same. (certainly not pre-10.5 though). I also still think this is related to "buildlocal" vs. " buildship". In fact that is already partly accounted for. I think I didn't understand the full state of things. [I think] You were always getting big runpaths. [I think] They were either to installed libraries or uninstalled libraries. If they were to uinstalled binaries, you could not ship -- buildlocal. [I think] Now we are moving toward always small runpaths, always pointing to installed libraries. This is dubious for buildlocal. [I think] Buildlocal should probably retain its old behavior -- big runpaths, into the source tree. Or maybe a list of paths, source tree followed by install tree. So user might build some of his own shared libraries, but not necessarily all. I should set that -Wl,-R thing based on local vs. global. I didn't look into how to detect that. More later. Yes, this is a more general question of how to find dependant shared libraries. I don't think anyone has solved it all that well, nor do I believe we will, but there are still some better and worse options. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.m.bates at cox.net Wed Apr 8 03:49:46 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Tue, 07 Apr 2009 20:49:46 -0500 Subject: [M3devel] small objects In-Reply-To: <200904071712.n37HCtda030844@camembert.async.caltech.edu> References: <200904071712.n37HCtda030844@camembert.async.caltech.edu> Message-ID: <49DC02BA.8080900@cox.net> Mika Nystrom wrote: > Tony, > > I think you have convinced me that what you say is workable. > > However I share Hendrik's concern that using RT0.RefanyTypecode > might hurt some day in the future, even if I think you have shown > pretty convincingly that it doesn't hurt today. How about my "second > proposal". Do pretty much what you suggest but instead of returning > RT0.RefanyTypecode, return TYPECODE(TaggedInteger.T), where > TaggedInteger.T is an object type that is declared entirely privately > to the TaggedInteger unsafe module... this also gives a completely > obvious implementation for pickling the tagged integers. Simply > convert them to TaggedInteger.T and pickle that. An implementation > that doesn't support tagged integers in pointers could also allocate > "real" TaggedInteger.Ts.... not sure that is useful though or if > it just confuses. Actually I think it is useful, because it lets > you represent the values even if unpickling in a system that doesn't > support tagged integers in REFANYs. > > I would go so far as saying this... I believe it is possible to > guarantee that any safe code outside of the TaggedInteger module > couldn't distinguish between a REFANY that holds a tagged integer > vs. one that holds a reference to a (heap-allocated) TaggedInteger.T. > How's that for not breaking the language definition? > > Hendrik, I think Tony's and my arguments that you can't break any > existing code by allowing the squirreling away of integers into > REFANYs are pretty solid. Pre-existing code simply can't do anything > useful with unrevealed REFANYs. This is only true of _unrevealed opaque subtypes_ of REFANY, not of REFANY itself. There is lots of existing code that uses REFANY, and there, ISTYPE, NARROW, TYPECASE, and assigment can be and regularly are used on it. It is essential not to alter the semantics there. Aside from actual semantic changes, I agree with Tony that we should not burden any existing type with additional runtime work. Even though I expect small objects to support big performance gains in certain important cases, non-tagged references will still greatly predominate in most code. Create new type(s) for tagged references. > There are also good reasons for > permitting this oddness (vide Smalltalk and Scheme small integers). > From hosking at cs.purdue.edu Wed Apr 8 04:26:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 8 Apr 2009 12:26:57 +1000 Subject: [M3devel] small objects In-Reply-To: <49DC02BA.8080900@cox.net> References: <200904071712.n37HCtda030844@camembert.async.caltech.edu> <49DC02BA.8080900@cox.net> Message-ID: <3B067900-F4D0-430A-A328-38C1F548B97F@cs.purdue.edu> On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: > Mika Nystrom wrote: >> >> Hendrik, I think Tony's and my arguments that you can't break any >> existing code by allowing the squirreling away of integers into >> REFANYs are pretty solid. Pre-existing code simply can't do anything >> useful with unrevealed REFANYs. > > This is only true of _unrevealed opaque subtypes_ of REFANY, > not of REFANY itself. There is lots of existing code that uses > REFANY, > and there, ISTYPE, NARROW, TYPECASE, and assigment can be and > regularly are used on it. It is essential not to alter the > semantics there. Pre-existing code won't be able to do anything useful with tagged REFANYs: Suppose we have VAR r: REFANY = SmallInteger.FromInt(0); then ISTYPE(r, REFANY) => TRUE ISTYPE(r, T) => FALSE for any T # REFANY Similarly, for TYPECASE, r will only trigger the REFANY branch. NARROW(r, REFANY) => r NARROW(r, T) => run-time error for any T #REFANY VAR x: REFANY => assignment succeeds VAR x: T := r => run-time error for any T # REFANY (because of implicit NARROW) It is impossible to dereference an expression statically typed as REFANY, so there is no need for a "tagged" check on dereference. Because a tagged REFANY cannot be assigned to anything other than something typed REFANY, it can never propagate to a place where it can be dereferenced. > Aside from actual semantic changes, I agree with Tony that we should > not burden any existing type with additional runtime work. Even > though > I expect small objects to support big performance gains in certain > important cases, non-tagged references will still greatly predominate > in most code. Create new type(s) for tagged references. I'm not sure that we are seeing any semantic changes at all. And with Mika's definition of SmallInteger.T as a "boxed" INTEGER object (actually it would be a subrange for values that fit into BITSIZE(Word.T)-1 bits), it is essentially transparent. It just happens to be a run-time optimization that unboxes the INTEGER value. I think I can implement the compiler and run-time support for this very quickly. From mika at async.caltech.edu Wed Apr 8 05:22:21 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 07 Apr 2009 20:22:21 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Wed, 08 Apr 2009 12:26:57 +1000." <3B067900-F4D0-430A-A328-38C1F548B97F@cs.purdue.edu> Message-ID: <200904080322.n383MLuu048696@camembert.async.caltech.edu> Tony Hosking writes: ... > >It is impossible to dereference an expression statically typed as >REFANY, so there is no need for a "tagged" check on dereference. >Because a tagged REFANY cannot be assigned to anything other than >something typed REFANY, it can never propagate to a place where it can >be dereferenced. ... But it's correct, isn't it, that you get an extra one-bit check for ISTYPE, TYPECASE, TYPECODE, and NARROW? There's no problem with dereferencing, nor is there a problem with assignment. No need to introduce overhead for either of those, since dereferencing can't happen and assignment is transparent (or an implicit NARROW). I was going to say to Rodney that I think that Modula-3 programmers know that using REFANY does cause some overhead (it must), and in any case the normal ISTYPE code is going to be hundreds of times slower than the single-bit check, and no one (except me) seems to have had any problem with this so far. So yes, the change does affect existing code, but only code that's already using REFANY, ISTYPE, TYPECASE, and the extra overhead is very minor compared to the work ISTYPE and TYPECASE are already doing. I think I really like the idea of boxing it in this other opaque type if that doesn't cause any problems, specifically because it doesn't make any semantic change to the language at all. Actually, it is important for the application of embedded interpreters that these tagged types be compatible with a standard REFANY. The whole point is to be able to write a fast interpreter that deals in normal Modula-3 types and not in a special parallel hierarchy... Look at how the various languages embedded in Java (JScheme, Groovy, Jython(?)) do these things: it's really pretty nifty. But *they* can't do efficient small integers! Mika From hendrik at topoi.pooq.com Wed Apr 8 05:38:04 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 7 Apr 2009 23:38:04 -0400 Subject: [M3devel] small objects In-Reply-To: <92E0969B-63C7-43BE-A501-B78A5E520B55@cs.purdue.edu> References: <200904062003.n36K3381094096@camembert.async.caltech.edu> <92E0969B-63C7-43BE-A501-B78A5E520B55@cs.purdue.edu> Message-ID: <20090408033804.GA2137@topoi.pooq.com> On Tue, Apr 07, 2009 at 12:03:35PM +1000, Tony Hosking wrote: > On 7 Apr 2009, at 06:03, Mika Nystrom wrote: > > > >Yes I think maybe this is what Tony is worried about. But let's > >just change the definition of REFANY to include anything with the > >LSB set...? > > But then a "NULL" check needs to both test for zero and test for lsb > set. I am not comfortable with this. Nor am I, for both efficiency and conceptual reasons. AN INTEGER isn't a reference, and we shouldn't treat it as if it were. So I'd like a separate type. REFANY is for references. It's bad enough that NIL is in there, too. Except for major incompatibility with almost all past software, I'd like to consider having separate types for pointers that can be NIL and those that can't. But that's too much a deviation from the existing language (and cause all kinds of troubles with variables that are declared before they are initialised, a discussion I've had here sometime last year). -- hendrik. From hendrik at topoi.pooq.com Wed Apr 8 05:42:26 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 7 Apr 2009 23:42:26 -0400 Subject: [M3devel] small objects In-Reply-To: <3B067900-F4D0-430A-A328-38C1F548B97F@cs.purdue.edu> References: <200904071712.n37HCtda030844@camembert.async.caltech.edu> <49DC02BA.8080900@cox.net> <3B067900-F4D0-430A-A328-38C1F548B97F@cs.purdue.edu> Message-ID: <20090408034226.GB2137@topoi.pooq.com> On Wed, Apr 08, 2009 at 12:26:57PM +1000, Tony Hosking wrote: > > I'm not sure that we are seeing any semantic changes at all. And with > Mika's definition of SmallInteger.T as a "boxed" INTEGER object > (actually it would be a subrange for values that fit into > BITSIZE(Word.T)-1 bits), it is essentially transparent. It just > happens to be a run-time optimization that unboxes the INTEGER value. You should also be able to box a CARDINAL. Isn't that a subrange of integers that can be encoded in the right bit width? Hardwarewise, it would be decoded with a logical shift instead of an arithmetic shift. -- hendrik P.S. Apologies for the word "Hardwarewise". It's late here, and I don't have enough brain left for both English and technical content. -- hendrik From mika at async.caltech.edu Wed Apr 8 05:51:24 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 07 Apr 2009 20:51:24 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Tue, 07 Apr 2009 23:42:26 EDT." <20090408034226.GB2137@topoi.pooq.com> Message-ID: <200904080351.n383pOeR049888@camembert.async.caltech.edu> hendrik at topoi.pooq.com writes: >On Wed, Apr 08, 2009 at 12:26:57PM +1000, Tony Hosking wrote: >> >> I'm not sure that we are seeing any semantic changes at all. And with >> Mika's definition of SmallInteger.T as a "boxed" INTEGER object >> (actually it would be a subrange for values that fit into >> BITSIZE(Word.T)-1 bits), it is essentially transparent. It just >> happens to be a run-time optimization that unboxes the INTEGER value. > >You should also be able to box a CARDINAL. Isn't that a subrange of >integers that can be encoded in the right bit width? Hardwarewise, it >would be decoded with a logical shift instead of an arithmetic shift. I think you can do either, but not both... a REFANY containing 0xffffffff stands for either the boxed CARDINAL 2,147,483,647 or the boxed INTEGER -1. It can't really be both... I think INTEGERs are more useful, since you can get [0..2^30-1] in there? > >-- hendrik > >P.S. Apologies for the word "Hardwarewise". It's late here, and I >don't have enough brain left for both English and technical content. > >-- hendrik From hosking at cs.purdue.edu Wed Apr 8 05:55:00 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 8 Apr 2009 13:55:00 +1000 Subject: [M3devel] small objects In-Reply-To: <200904080322.n383MLuu048696@camembert.async.caltech.edu> References: <200904080322.n383MLuu048696@camembert.async.caltech.edu> Message-ID: <5B98E111-7E4F-4FC7-9B8C-2281CEBCDE6C@cs.purdue.edu> On 8 Apr 2009, at 13:22, Mika Nystrom wrote: > Tony Hosking writes: > ... >> >> It is impossible to dereference an expression statically typed as >> REFANY, so there is no need for a "tagged" check on dereference. >> Because a tagged REFANY cannot be assigned to anything other than >> something typed REFANY, it can never propagate to a place where it >> can >> be dereferenced. > ... > > But it's correct, isn't it, that you get an extra one-bit check for > ISTYPE, TYPECASE, TYPECODE, and NARROW? There's no problem with > dereferencing, nor is there a problem with assignment. No need to > introduce overhead for either of those, since dereferencing can't > happen and assignment is transparent (or an implicit NARROW). Correct. > I was going to say to Rodney that I think that Modula-3 programmers > know that using REFANY does cause some overhead (it must), and in > any case the normal ISTYPE code is going to be hundreds of times > slower than the single-bit check, and no one (except me) seems to > have had any problem with this so far. Right. > So yes, the change does affect existing code, but only code that's > already using REFANY, ISTYPE, TYPECASE, and the extra overhead is > very minor compared to the work ISTYPE and TYPECASE are already > doing. It affects only performance. Existing code won't know about SmallInteger.T, so will never test for that type. > I think I really like the idea of boxing it in this other opaque > type if that doesn't cause any problems, specifically because it > doesn't make any semantic change to the language at all. Yeah. It should probably be BRANDED REF [FIRST(INTEGER) DIV 2 .. LAST(INTEGER) DIV 2] instead of an object type. I don't want to think about having "builtin" methods that apply to this type. I'd rather implement it like the builtin Word.T operations. I think the following interface is about right: INTERFACE ValRef; TYPE T <: REFANY; CONST First = FIRST(INTEGER) DIV 2; Last = LAST(INTEGER) DIV 2; TYPE Range = [First .. Last]; PROCEDURE New(val: Range): T; PROCEDURE Val(ref: T): Range; END ValRef. On further thought, the notion that someone could do RTAllocator.NewTraced(TYPECODE(ValRef.T)) makes me a little nervous. We would need to intercept that in RTAllocator.NewTraced and return ValRef.New(0). Of course, there is no way to create any ValRef.T that has a value other than 0 in this way. The pickler would need to have a pickle special for TYPECODE(ValRef.T) that simply extracts the value as the pickled representation, and invokes ValRef.New(value) when unpickliing. > Actually, it is important for the application of embedded interpreters > that these tagged types be compatible with a standard REFANY. The > whole point is to be able to write a fast interpreter that deals > in normal Modula-3 types and not in a special parallel hierarchy... > Look at how the various languages embedded in Java (JScheme, Groovy, > Jython(?)) do these things: it's really pretty nifty. But *they* > can't do efficient small integers! Indeed. From hendrik at topoi.pooq.com Wed Apr 8 05:54:20 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 7 Apr 2009 23:54:20 -0400 Subject: [M3devel] trackOutside and trackOffScreen behave strangely. Message-ID: <20090408035419.GA2391@topoi.pooq.com> I'm trying to track the mouse. I set a cage like: VBT.SetCage(self, VBT.CageFromPosition(cd.cp, trackOutside := TRUE)); and it would not track the mouse when it was outside my window, but still on the screen. But when I coded VBT.SetCage(self, VBT.CageFromPosition(cd.cp, trackOutside := TRUE, trackOffScreen := TRUE)); it suddenly started tracking properly, following the mouse outside the window. The mouse pointer never left the screen during either test. It can't. In case it makes a difference, I'm using icewm on Xorg on a Debian Lenny system on an 32-bit AMD processor. -- hendrik. From wagner at elegosoft.com Wed Apr 8 08:43:32 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 08 Apr 2009 08:43:32 +0200 Subject: [M3devel] installation archives for AMD64_LINUX for test and tinderbox status Message-ID: <20090408084332.k76kazqnc4804cwc@mail.elegosoft.com> I've made some small extensions to the installer and to the packaging script make-bin-dist-min.sh (which is now wrongly named), so that they both use Jay's new style config files by default. The old behaviour is still available with some switches. The archives are in the uploaded-archives section of www.opencm3.net: -rw-rw-r-- 1 wagner m3 24568485 2009-04-08 08:24 cm3-bin-core-POSIX-AMD64_LINUX-d5.7.1.tgz -rw-rw-r-- 1 wagner m3 59741158 2009-04-08 08:24 cm3-bin-std-POSIX-AMD64_LINUX-d5.7.1.tgz I haven't really tested them; would anybody care to try one of these? They are rather huge; one contains the core distribution and one the complete std package set in binary format. But it seems to be consensus that large archives containing everything is preferred to small archives with more complex installation. I know that the cminstall program doesn't now do much except copying the files to their destination and checking for diskspace (which may still be wrong, by the way), but it still _could_ also perform customizations and install patches etc. So it's no big overhead, and this way the migration will be easier especially regarding the automated regression scripts. If nobody objects, we can use these for a new release in some weeks. If you think this isn't really useful, please don't hesitate to say so, too. Regarding tinderbox, I haven't been able to log into the administration pages yet, but Michael will surely fix that today. Some basic things are working, but some documentation and configuraion seems to be lost. I'll see what I can restore. I'll be on holiday starting tomorrow, but I'll take my notebook with me and hope for some good connections ;-) CVSup isn't installed yet, which is why the FreeBSD tests from Elego are still missing. Michael will probably work on it next week. Thanks for your help and patience, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From carson at taltos.org Wed Apr 8 11:39:18 2009 From: carson at taltos.org (Carson Gaspar) Date: Wed, 08 Apr 2009 02:39:18 -0700 Subject: [M3devel] What happened to Utypes.i3? Message-ID: <49DC70C6.1000600@taltos.org> Trying to use the recently uploaded 5.7.1 Linux packages, Utypes.i3 has been gutted. Breaking cvsup. Again. Specifically, dev_t, mode_t, ino_t, etc. are all gone. Can someone comment on what's going on with these interfaces? Is there a method behind the path of destruction being left? -- Carson From jay.krell at cornell.edu Wed Apr 8 12:44:09 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 8 Apr 2009 10:44:09 +0000 Subject: [M3devel] What happened to Utypes.i3? In-Reply-To: <49DC70C6.1000600@taltos.org> References: <49DC70C6.1000600@taltos.org> Message-ID: m3-libs/m3core/src/Unix/*/*.i3 was a very large chunk of tedious error-prone dangerous (if errors occur) mostly dead platform specific code. It was one of the largest things to work on when porting to a new platform, and largely wasted work. (The other pieces are debugging whatever goes wrong, that's about it, porting is often pretty easy..) It is drastically reduced now, and often replaced by much safer C code. There is still a little more to do here. dev_t, mode_t, ino_t, were mosty only used along with stat. Those uses are gone. This is the exact danger however -- of breaking Modula-3 code outside the cm3 tree, that uses "low level" non-Modula-3 interfaces. Anything that just uses the higher level Modula-3 interfaces is not broken. I'll have to look at cvsup and see if it is easy to make the same sort of transform -- replace small pieces of Modula-3 that are dependent on tedious error prone Modula-3 with small portable C wrappers. If the only problem is really those three types, they can be restored, reluctantly. I'd much rather change cvsup to not use them. - Jay > Date: Wed, 8 Apr 2009 02:39:18 -0700 > From: carson at taltos.org > To: m3devel at elegosoft.com > Subject: [M3devel] What happened to Utypes.i3? > > Trying to use the recently uploaded 5.7.1 Linux packages, Utypes.i3 has > been gutted. Breaking cvsup. Again. Specifically, dev_t, mode_t, ino_t, > etc. are all gone. > > Can someone comment on what's going on with these interfaces? Is there a > method behind the path of destruction being left? > > -- > Carson -------------- next part -------------- An HTML attachment was scrubbed... URL: From carson at taltos.org Wed Apr 8 12:57:11 2009 From: carson at taltos.org (Carson Gaspar) Date: Wed, 08 Apr 2009 03:57:11 -0700 Subject: [M3devel] What happened to Utypes.i3? In-Reply-To: <49DC70C6.1000600@taltos.org> References: <49DC70C6.1000600@taltos.org> Message-ID: <49DC8307.7060906@taltos.org> Similarly, 5.7.0 and 5.7.1 are both missing TextF.i3, also breaking cvsup. *sigh* Carson Gaspar wrote: > Trying to use the recently uploaded 5.7.1 Linux packages, Utypes.i3 has > been gutted. Breaking cvsup. Again. Specifically, dev_t, mode_t, ino_t, > etc. are all gone. > > Can someone comment on what's going on with these interfaces? Is there a > method behind the path of destruction being left? > From carson at taltos.org Wed Apr 8 13:04:48 2009 From: carson at taltos.org (Carson Gaspar) Date: Wed, 08 Apr 2009 04:04:48 -0700 Subject: [M3devel] What happened to Utypes.i3? In-Reply-To: References: <49DC70C6.1000600@taltos.org> Message-ID: <49DC84D0.4030701@taltos.org> Jay wrote: > I'll have to look at cvsup and see if it is easy to make the same sort > of transform -- replace small pieces of Modula-3 that are dependent on > tedious error prone Modula-3 with small portable C wrappers. > > If the only problem is really those three types, they can be restored, > reluctantly. > I'd much rather change cvsup to not use them. The problems are larger that just those, sadly, as a build attempt will quickly reveal. The universe would be very happy to have a working, maintained modula-3 compiler that would build cvsup. Whether that involves more patches to cvsup or changes to cm3, either way it would be a Good Thing(tm). Sadly, my almost non-extant modula-3 foo isn't up to the task, or I'd volunteer. Given my deadlines, I'm going to punt and try and get 5.4.0 to work and give up a clean 64-bit version. -- Carson From jay.krell at cornell.edu Wed Apr 8 14:27:21 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 8 Apr 2009 12:27:21 +0000 Subject: [M3devel] What happened to Utypes.i3? In-Reply-To: <49DC8307.7060906@taltos.org> References: <49DC70C6.1000600@taltos.org> <49DC8307.7060906@taltos.org> Message-ID: I thought TextF got deleted way back in 4.1, when Unicode support came in. I can look later...probably not Wednesday or Thursday though. - Jay > Date: Wed, 8 Apr 2009 03:57:11 -0700 > From: carson at taltos.org > To: m3devel at elegosoft.com > Subject: Re: [M3devel] What happened to Utypes.i3? > > Similarly, 5.7.0 and 5.7.1 are both missing TextF.i3, also breaking > cvsup. *sigh* > > Carson Gaspar wrote: > > Trying to use the recently uploaded 5.7.1 Linux packages, Utypes.i3 has > > been gutted. Breaking cvsup. Again. Specifically, dev_t, mode_t, ino_t, > > etc. are all gone. > > > > Can someone comment on what's going on with these interfaces? Is there a > > method behind the path of destruction being left? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carson at taltos.org Wed Apr 8 14:42:36 2009 From: carson at taltos.org (Carson Gaspar) Date: Wed, 08 Apr 2009 05:42:36 -0700 Subject: [M3devel] What happened to Utypes.i3? In-Reply-To: References: <49DC70C6.1000600@taltos.org> <49DC8307.7060906@taltos.org> Message-ID: <49DC9BBC.5040600@taltos.org> Jay wrote: > I thought TextF got deleted way back in 4.1, when Unicode support came in. > I can look later...probably not Wednesday or Thursday though. It's in my 31-Jan-2009 CVS checkout... and is in the 5.4.0 tarball. -- Carson From wagner at elegosoft.com Wed Apr 8 14:51:15 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 08 Apr 2009 14:51:15 +0200 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: References: <200904061532.n36FWunc087102@camembert.async.caltech.edu> <20090406175119.5nknbzf9dwkcwkks@mail.elegosoft.com> Message-ID: <20090408145115.hgx4t0to0o4s0gg0@mail.elegosoft.com> Quoting Jay : > > Relinking upon install I still think provides desired results and > is not a terrible idea, but it is more work to implement. > I think the perf is probably acceptable. > > I don't like to expose too many options to uninformed users, but > making this an option might be good. It will have an acceptable default, > which makes it being an option much less bad. I'm still not convinced that this is the correct behaviour. I find the whole concept of fixed location paths questionable. I'll have to relink my libraries for every location change. Seems simply wrong to me :-/ > It's not just one option. > There is: > 1) using the local machine's install point -- /usr/local/cm3/lib, > 2) vs. using $ORIGIN/../lib. > Not available on all systems. > 3) vs. using package store paths This should be the default IMHO. And no relinking by default. Better still remove the paths completely from the libraries. Others will probably disagree ;-) Olaf > 4) vs. using source tree paths > > > > > and they can be combined, in various orders. > > > > > Plus Darwin is different, though maybe Darwin 10.5 is the same. > (certainly not pre-10.5 though). > > > > > > I also still think this is related to "buildlocal" vs. " buildship". > In fact that is already partly accounted for. > > > > > I think I didn't understand the full state of things. > > > > > [I think] You were always getting big runpaths. > [I think] They were either to installed libraries or uninstalled libraries. > > If they were to uinstalled binaries, you could not ship -- buildlocal. > [I think] Now we are moving toward always small runpaths, always > pointing to installed libraries. This is dubious for buildlocal. > > > > > [I think] Buildlocal should probably retain its old behavior -- big > runpaths, into > the source tree. Or maybe a list of paths, source tree followed by > install tree. > So user might build some of his own shared libraries, but not > necessarily all. > > > > > I should set that -Wl,-R thing based on local vs. global. > I didn't look into how to detect that. > > > > > More later. > > > > > > Yes, this is a more general question of how to find dependant shared > libraries. > > I don't think anyone has solved it all that well, nor do I believe > we will, but there are still some better and worse options. > > > > > - 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 Wed Apr 8 22:08:09 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 08 Apr 2009 15:08:09 -0500 Subject: [M3devel] small objects Message-ID: <49DD0429.5000306@cox.net> Here are two integrated proposals for language changes to allow small objects, while preserving the principles of the language. Neither of them changes the semantics of any existing type or burdens any existing code with extra runtime computation. The unsafe proposal: This is a much simpler proposal. It could also be used in more general ways than just using a tag bit to distinguish a true pointer from an in-word value. This is at the cost of requiring unsafe coding techniques in a module implementing the abstraction, which also inevitably means implementation-dependent too. Using it for small objects as discussed still requires the garbage collector not to be confused by trying to trace a reference with a misaligned value. There is a new builtin type OPAQUE. The only things you can do with it in safe code are copy values around (assigment, pass by VALUE, RETURN, etc.) and make reference bindings to it (pass by reference, WITH bindings). Not that this ia a _lot_ more opaque than opaque types. OPAQUE is known to be the same size as Word.T. In unsafe code, you can use this fact to LOOPHOLE it to anything you want and bit-twiddle to your heart's content from there. So an unsafe module could implement procedures that take OPAQUE parameters. Variation: Allow an opaque subtype of OPAQUE, which can be revealed to be any type with statically the same size. This would make it possible to prevent client code from mixing up two different unrelated abstractions that both happened to use OPAQUE. In fact, without this, the proposal really fails to preserve the existing principles of safe/unsafe code. This would require that the revelation be BRANDED, which would either mean restricting the revelation to a reference type (which could still be LOOPHOLEd to anything else) or allowing other types to be BRANDED. Example: INTERFACE ADT; TYPE T <: OPAQUE; PROCEDURE P (x:T); ... END ADT UNSAFE MODULE ADT; TYPE R = RECORD ... END; REVEAL T = BRANDED REF R; PROCEDURE P (x:T) VAR I: INTEGER; BEGIN IF LOOPHOLE(x,INTEGER) MOD 2 # 0 THEN I := Word.Shift(LOOPHOLE(x,INTEGER),-1); (* Use integer value I ... *) ELSE (* Use reference value x, according to its declared type. Prior to the check above, we couldn't afford to risk doing anything with it. ... *) END (* IF *); END P; ... END ADT; The safe proposal: This is more complicated and less general, but allows small object abstractions to be done in an entirely safe and implementation- independent way. It abstracts away all the bit-level representation questions. There is a new type TAG, which is a subrange of INTEGER, with implementation-defined bounds (which would then be accessible by FIRST/LAST). There is a new type constructor TAGGED. If T is any traced reference type or any untraced object type, TAGGED T defines a type, called a _tagged_ type, whose value set is the union of the value sets of TAG and T. TAG <: TAGGED T and T <: TAGGED T. There are no other subtype relations involving TAGGED T. Values of a tagged type can be copied and bound-to. The static rules for ISTYPE, NARROW, TYPECASE, and assignability of a type to a type are liberalized to allow their application to a tagged type, and to allow the type to be checked/converted-to to be any subtype of the tagged type. Already existing rules would require a runtime check that the value is a member of the stated type. No other operations are possible on a tagged type. A tagged type is not a reference type and does not have a typecode. Example: INTERFACE ADT; TYPE Op <: REFANY; TYPE T = TAGGED Op; PROCEDURE P (x:T); ... END ADT MODULE ADT; TYPE R = RECORD ... END; REVEAL Op = BRANDED REF R; PROCEDURE P (x:T) BEGIN TYPECASE x OF TAG (I) => (* Use integer value I ... *) | Op (RR) => (* Use reference value RR ... *) END (* IF *); END P; ... END ADT; Note: TAG is like CARDINAL in that it is "just like" a subrange of INTEGER, but not equal to that subrange. This enabled pickles to change the size of values of type TAG and of tagged types, as it now does with CARDINAL. Variation: The 4 runtime-checking operations can also be applied to any ordinal type and can check that an ordinal or tagged type has a value belonging to any subrange of the base type (or maybe just of the type being narrowed). This is pure fluff (well, maybe it is syntactic sugar), but adds some consistency and has a real use: How many times have I coded the following? IF FIRST(SomeOrdinalType <= x AND x <= LAST(SomeOrdinalType) THEN ... or worse, IF FIRST(SomeOrdinalType <= F(x) AND F(x) <= LAST(SomeOrdinalType) THEN ... which I then feel morally obligated to recode using a local variable or WITH-temp to eliminate the duplicated calls F(x). It could then become: IF ISTYPE (F(x), SomeOrdinalType) THEN ... From rodney.m.bates at cox.net Wed Apr 8 22:13:33 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 08 Apr 2009 15:13:33 -0500 Subject: [M3devel] What happened to Utypes.i3? In-Reply-To: References: <49DC70C6.1000600@taltos.org> <49DC8307.7060906@taltos.org> Message-ID: <49DD056D.5050205@cox.net> TextF is still sitting out there in the CM3 repository, but what it declares is a lie in CM3. If you try to use it to compile code that assumes the PM3 text representation in CM3, something bad will surely happen. Probably a link-time failure because of contradictory revelations, or something. Such code will inevitably have to be modified to get it to compile and work in CM3. TextF is also unused in the CM3 repo. Jay wrote: > I thought TextF got deleted way back in 4.1, when Unicode support came in > From rodney.m.bates at cox.net Thu Apr 9 02:15:21 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 08 Apr 2009 19:15:21 -0500 Subject: [M3devel] small objects In-Reply-To: <3B067900-F4D0-430A-A328-38C1F548B97F@cs.purdue.edu> References: <200904071712.n37HCtda030844@camembert.async.caltech.edu> <49DC02BA.8080900@cox.net> <3B067900-F4D0-430A-A328-38C1F548B97F@cs.purdue.edu> Message-ID: <49DD3E19.20209@cox.net> Tony Hosking wrote: > On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: > >> Mika Nystrom wrote: >>> >>> Hendrik, I think Tony's and my arguments that you can't break any >>> existing code by allowing the squirreling away of integers into >>> REFANYs are pretty solid. Pre-existing code simply can't do anything >>> useful with unrevealed REFANYs. >> >> This is only true of _unrevealed opaque subtypes_ of REFANY, >> not of REFANY itself. There is lots of existing code that uses REFANY, >> and there, ISTYPE, NARROW, TYPECASE, and assigment can be and >> regularly are used on it. It is essential not to alter the >> semantics there. > > Pre-existing code won't be able to do anything useful with tagged > REFANYs: > > Suppose we have > > VAR r: REFANY = SmallInteger.FromInt(0); > > then > > ISTYPE(r, REFANY) => TRUE > ISTYPE(r, T) => FALSE for any T # REFANY > > Similarly, for TYPECASE, r will only trigger the REFANY branch. > > NARROW(r, REFANY) => r > NARROW(r, T) => run-time error for any T #REFANY > > VAR x: REFANY => assignment succeeds > VAR x: T := r => run-time error for any T # REFANY (because of > implicit NARROW) I think I am getting a bit lost in all the proposals, variations, counterproposals, etc., but from this argument I am inferring that your plan is that only variables declared REFANY and not any proper subtype of REFANY can ever have a value with a tag bit set? Then the 4 narrowing operations, when and only when applied to an expression of static type REFANY, would change to make a runtime check for a tag bit and fail if it's set? It would take this to prevent a tagged value from getting into a variable declared a proper subtype of REFANY, which can be dereferenced. This would preclude making your abstract data type an opaque subtype of REFANY, and would mean all supposedly unrelated ADT modules that used the tag technique could be broken by client code that mixed up the REFANY values of one of them with those of another. I consider this a definite breach of Modula-3's otherwise bulletproof type safety. > > It is impossible to dereference an expression statically typed as > REFANY, so there is no need for a "tagged" check on dereference. > Because a tagged REFANY cannot be assigned to anything other than > something typed REFANY, it can never propagate to a place where it can > be dereferenced. > >> Aside from actual semantic changes, I agree with Tony that we should >> not burden any existing type with additional runtime work. Even though >> I expect small objects to support big performance gains in certain >> important cases, non-tagged references will still greatly predominate >> in most code. Create new type(s) for tagged references. > > I'm not sure that we are seeing any semantic changes at all. And with > Mika's definition of SmallInteger.T as a "boxed" INTEGER object > (actually it would be a subrange for values that fit into > BITSIZE(Word.T)-1 bits), it is essentially transparent. It just > happens to be a run-time optimization that unboxes the INTEGER value. > > > I think I can implement the compiler and run-time support for this > very quickly. > > From mika at async.caltech.edu Thu Apr 9 02:23:12 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 08 Apr 2009 17:23:12 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Wed, 08 Apr 2009 15:08:09 CDT." <49DD0429.5000306@cox.net> Message-ID: <200904090023.n390NC2b096664@camembert.async.caltech.edu> Hmm, if you're going to do something along these lines, isn't the logical thing to do to introduce a new root of the (traced) type system, that is REFANY <: REFORINT SMALLINT = [MinSmallInteger .. MaxSmallInteger] SMALLINT <: REFORINT a REFORINT can be a REFANY or a small integer. It stands to reason that it is a supertype of REFANY as well as of SMALLINT, because isn't that exactly what we're looking for? The problem with this proposal (as well as both of yours) is that you get to go through and inspect all existing code that takes REFANY and wonder whether maybe it should take REFORINT instead.... The proposal that Tony and I seem to have agreed on, on the other hand, allows the implementation to hide small integers completely transparently in the already existing REFANY, at the cost of an LSB check on a number of operations, such as ISTYPE, TYPECASE, etc., to any REFANY. I maintain the following: I. Since hiding integers in REFANY is intended to be entirely transparent, you could have it as a compile or even run-time option. Yes, ok this is ugly. II.Assume we go with REFORINT, or OPAQUE, or TAGGED. What existing uses of REFANY, in any code of importance, is going to stay REFANY, and what uses will we want to convert to the new types? I would suggest considering the following argument: A. The new types are strictly more useful than REFANY; they can represent more values because they can represent all of REFANY plus other values (after all that was the point all along). B. Existing uses of REFANY are either 1. uses of REFANY because the code is intended to be very generic. Programmers will want to migrate such code to the new type, so that they can process the new type as well (since the code is generic it should work for either). 2. uses of REFANY because the programmer was too lazy to instantiate a generic for his specific type and decided to cast the values to REFANY (e.g., to insert in a RefList) and back. Such programmers deserve what they get. I conclude that code that continues to want to use REFANY rather than the new type is code that is not performance sensitive. Hence, I conclude that using REFANY directly to represent small integers is as reasonable as introducing a new type, and does it with less work, both in updating the language definition and in updating all the libraries in libm3 and elsewhere. What current uses of REFANY do not fit the cases in II.B.? Some trickery to simulate multiple inheritance? Even in those you should have created a common supertype, I think. Mika "Rodney M. Bates" writes: >Here are two integrated proposals for language changes to allow small >objects, while preserving the principles of the language. Neither of >them changes the semantics of any existing type or burdens any >existing code with extra runtime computation. > >The unsafe proposal: > >This is a much simpler proposal. It could also be used in more >general ways than just using a tag bit to distinguish a true pointer >from an in-word value. This is at the cost of requiring unsafe coding >techniques in a module implementing the abstraction, which also >inevitably means implementation-dependent too. Using it for small >objects as discussed still requires the garbage collector not to be >confused by trying to trace a reference with a misaligned value. > >There is a new builtin type OPAQUE. The only things you can do with >it in safe code are copy values around (assigment, pass by VALUE, >RETURN, etc.) and make reference bindings to it (pass by reference, >WITH bindings). Not that this ia a _lot_ more opaque than opaque >types. > >OPAQUE is known to be the same size as Word.T. In unsafe code, you >can use this fact to LOOPHOLE it to anything you want and bit-twiddle >to your heart's content from there. So an unsafe module could >implement procedures that take OPAQUE parameters. > >Variation: > >Allow an opaque subtype of OPAQUE, which can be revealed to be any >type with statically the same size. This would make it possible to >prevent client code from mixing up two different unrelated >abstractions that both happened to use OPAQUE. In fact, without this, >the proposal really fails to preserve the existing principles of >safe/unsafe code. This would require that the revelation be BRANDED, >which would either mean restricting the revelation to a reference type >(which could still be LOOPHOLEd to anything else) or allowing other >types to be BRANDED. > >Example: > >INTERFACE ADT; > TYPE T <: OPAQUE; > PROCEDURE P (x:T); > ... >END ADT > >UNSAFE MODULE ADT; > TYPE R = RECORD ... END; > REVEAL T = BRANDED REF R; > > PROCEDURE P (x:T) > VAR I: INTEGER; > BEGIN > IF LOOPHOLE(x,INTEGER) MOD 2 # 0 > THEN > I := Word.Shift(LOOPHOLE(x,INTEGER),-1); > (* Use integer value I ... *) > ELSE > (* Use reference value x, according to its declared type. > Prior to the check above, we couldn't afford to risk > doing anything with it. ... *) > END (* IF *); > END P; > ... >END ADT; > >The safe proposal: > >This is more complicated and less general, but allows small object >abstractions to be done in an entirely safe and implementation- >independent way. It abstracts away all the bit-level representation >questions. > >There is a new type TAG, which is a subrange of INTEGER, with >implementation-defined bounds (which would then be accessible by >FIRST/LAST). > >There is a new type constructor TAGGED. If T is any traced reference >type or any untraced object type, TAGGED T defines a type, called a >_tagged_ type, whose value set is the union of the value sets of TAG >and T. > >TAG <: TAGGED T and T <: TAGGED T. > >There are no other subtype relations involving TAGGED T. > >Values of a tagged type can be copied and bound-to. > >The static rules for ISTYPE, NARROW, TYPECASE, and assignability of a >type to a type are liberalized to allow their application to a tagged >type, and to allow the type to be checked/converted-to to be any >subtype of the tagged type. Already existing rules would require a >runtime check that the value is a member of the stated type. > >No other operations are possible on a tagged type. A tagged type is >not a reference type and does not have a typecode. > >Example: > >INTERFACE ADT; > TYPE Op <: REFANY; > TYPE T = TAGGED Op; > PROCEDURE P (x:T); > ... >END ADT > >MODULE ADT; > TYPE R = RECORD ... END; > REVEAL Op = BRANDED REF R; > > PROCEDURE P (x:T) > BEGIN > TYPECASE x > OF TAG (I) > => (* Use integer value I ... *) > | Op (RR) > => (* Use reference value RR ... *) > END (* IF *); > END P; > ... >END ADT; > >Note: TAG is like CARDINAL in that it is "just like" a subrange of >INTEGER, but not equal to that subrange. This enabled pickles to >change the size of values of type TAG and of tagged types, as it now >does with CARDINAL. > >Variation: > >The 4 runtime-checking operations can also be applied to any ordinal >type and can check that an ordinal or tagged type has a value >belonging to any subrange of the base type (or maybe just of the type >being narrowed). This is pure fluff (well, maybe it is syntactic >sugar), but adds some consistency and has a real use: > >How many times have I coded the following? > >IF FIRST(SomeOrdinalType <= x AND x <= LAST(SomeOrdinalType) THEN ... > >or worse, > >IF FIRST(SomeOrdinalType <= F(x) AND F(x) <= LAST(SomeOrdinalType) THEN ... > >which I then feel morally obligated to recode using a local variable or >WITH-temp to eliminate the duplicated calls F(x). > >It could then become: > >IF ISTYPE (F(x), SomeOrdinalType) THEN ... > > > > > > From mika at async.caltech.edu Thu Apr 9 02:38:23 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 08 Apr 2009 17:38:23 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Wed, 08 Apr 2009 19:15:21 CDT." <49DD3E19.20209@cox.net> Message-ID: <200904090038.n390cNsg097270@camembert.async.caltech.edu> Hmm, ok, there's one big difference between what you're saying and what Tony and I have been talking about. (I think your understanding sounds pretty correct.) You want to do objects other than small integers. Like what? And why? I was thinking the trick would apply only to one specific type of integer. Hmm, so your idea is to statically determine what type the references can have if they are non-references. So you are thinking to put various kinds of subranges into the "TAGGED" types. But you have to be able to determine, statically, which subrange it is... am I understanding this correctly? Mika "Rodney M. Bates" writes: >Tony Hosking wrote: >> On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: >> >>> Mika Nystrom wrote: >>>> >>>> Hendrik, I think Tony's and my arguments that you can't break any >>>> existing code by allowing the squirreling away of integers into >>>> REFANYs are pretty solid. Pre-existing code simply can't do anything >>>> useful with unrevealed REFANYs. >>> >>> This is only true of _unrevealed opaque subtypes_ of REFANY, >>> not of REFANY itself. There is lots of existing code that uses REFANY, >>> and there, ISTYPE, NARROW, TYPECASE, and assigment can be and >>> regularly are used on it. It is essential not to alter the >>> semantics there. >> >> Pre-existing code won't be able to do anything useful with tagged >> REFANYs: >> >> Suppose we have >> >> VAR r: REFANY = SmallInteger.FromInt(0); >> >> then >> >> ISTYPE(r, REFANY) => TRUE >> ISTYPE(r, T) => FALSE for any T # REFANY >> >> Similarly, for TYPECASE, r will only trigger the REFANY branch. >> >> NARROW(r, REFANY) => r >> NARROW(r, T) => run-time error for any T #REFANY >> >> VAR x: REFANY => assignment succeeds >> VAR x: T := r => run-time error for any T # REFANY (because of >> implicit NARROW) > >I think I am getting a bit lost in all the proposals, variations, >counterproposals, etc., but >from this argument I am inferring that your plan is that only variables >declared REFANY >and not any proper subtype of REFANY can ever have a value with a tag >bit set? Then >the 4 narrowing operations, when and only when applied to an expression >of static >type REFANY, would change to make a runtime check for a tag bit and fail >if it's set? >It would take this to prevent a tagged value from getting into a >variable declared a >proper subtype of REFANY, which can be dereferenced. > >This would preclude making your abstract data type an opaque subtype of >REFANY, >and would mean all supposedly unrelated ADT modules that used the tag >technique >could be broken by client code that mixed up the REFANY values of one of >them with >those of another. I consider this a definite breach of Modula-3's >otherwise bulletproof >type safety. >> >> It is impossible to dereference an expression statically typed as >> REFANY, so there is no need for a "tagged" check on dereference. >> Because a tagged REFANY cannot be assigned to anything other than >> something typed REFANY, it can never propagate to a place where it can >> be dereferenced. >> >>> Aside from actual semantic changes, I agree with Tony that we should >>> not burden any existing type with additional runtime work. Even though >>> I expect small objects to support big performance gains in certain >>> important cases, non-tagged references will still greatly predominate >>> in most code. Create new type(s) for tagged references. >> >> I'm not sure that we are seeing any semantic changes at all. And with >> Mika's definition of SmallInteger.T as a "boxed" INTEGER object >> (actually it would be a subrange for values that fit into >> BITSIZE(Word.T)-1 bits), it is essentially transparent. It just >> happens to be a run-time optimization that unboxes the INTEGER value. >> >> >> I think I can implement the compiler and run-time support for this >> very quickly. >> >> From hosking at cs.purdue.edu Thu Apr 9 03:39:50 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 9 Apr 2009 11:39:50 +1000 Subject: [M3devel] What happened to Utypes.i3? In-Reply-To: <49DD056D.5050205@cox.net> References: <49DC70C6.1000600@taltos.org> <49DC8307.7060906@taltos.org> <49DD056D.5050205@cox.net> Message-ID: <83F0F22E-19BA-493D-9185-2107A92D29C4@cs.purdue.edu> TextF is not part of the installed code-base for m3core. The old source is there, but does not get built. I know I have built CVS up since *after* TextF went away. There were a few minor patches needed. Of course, that was all before Utypes got pruned away. I really don't think it can possibly be too hard to build CVSup against the current CM3 head. Yes, there may be some declarations needed for various Unix foibles, but ideally we could hide those away behind C helper code as Jay suggests. On 9 Apr 2009, at 06:13, Rodney M. Bates wrote: > TextF is still sitting out there in the CM3 repository, but what it > declares is a lie in CM3. If you try to use it to compile code that > assumes the PM3 text representation in CM3, something bad > will surely happen. Probably a link-time failure because of > contradictory revelations, or something. Such code will inevitably > have to be modified to get it to compile and work in CM3. > TextF is also unused in the CM3 repo. > Jay wrote: >> I thought TextF got deleted way back in 4.1, when Unicode support >> came in >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Apr 9 03:51:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 9 Apr 2009 11:51:36 +1000 Subject: [M3devel] small objects In-Reply-To: <49DD3E19.20209@cox.net> References: <200904071712.n37HCtda030844@camembert.async.caltech.edu> <49DC02BA.8080900@cox.net> <3B067900-F4D0-430A-A328-38C1F548B97F@cs.purdue.edu> <49DD3E19.20209@cox.net> Message-ID: <8AA8B3CE-12D0-45E3-8F24-5B2A6FED13CF@cs.purdue.edu> On 9 Apr 2009, at 10:15, Rodney M. Bates wrote: > I think I am getting a bit lost in all the proposals, variations, > counterproposals, etc., but > from this argument I am inferring that your plan is that only > variables declared REFANY > and not any proper subtype of REFANY can ever have a value with a > tag bit set? Then > the 4 narrowing operations, when and only when applied to an > expression of static > type REFANY, would change to make a runtime check for a tag bit and > fail if it's set? > It would take this to prevent a tagged value from getting into a > variable declared a > proper subtype of REFANY, which can be dereferenced. Yes, that's the minimalist proposal that Mika initiated and I refined slightly to handle TYPECODE. > This would preclude making your abstract data type an opaque subtype > of REFANY, > and would mean all supposedly unrelated ADT modules that used the > tag technique > could be broken by client code that mixed up the REFANY values of > one of them with > those of another. I consider this a definite breach of Modula-3's > otherwise bulletproof > type safety. Umm. I don't see how they can "break". Can you offer a scenario? Either a REFANY is tagged or it is not. "Unrelated ADT modules that use the tag technique" would all still work. Are you saying you want a way to stamp out differently typed tagged REFANYs? Seems a little tricky given that we are proposing just a single bit to distinguish tagged from untagged REFANY. Unless you propose a completely static type constructor that stamps out different tagged reference types that are completely unrelated, and cannot be stored in a REFANY? But that breaks the whole purpose of tagging which is to support values embedded in references. From hosking at cs.purdue.edu Thu Apr 9 03:57:35 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 9 Apr 2009 11:57:35 +1000 Subject: [M3devel] small objects In-Reply-To: <200904090023.n390NC2b096664@camembert.async.caltech.edu> References: <200904090023.n390NC2b096664@camembert.async.caltech.edu> Message-ID: Thanks Mika, nicely summarised. I'll just add that from the language design perspective we have made no change. The only thing we are doing is introducing a run-time *optimisation* that allows things that look like: T = BRANDED "SmallInt.T" REF [FIRST(INTEGER) DIV 2.. LAST(INTEGER) DIV 2] to be *represented* by the run-time system as a tagged reference by packing the value into the non-tag bits of the reference. The main thing to protect against is that someone bypasses the opaque definition of this type as <: REFANY and actually allocates a heap value of the above type. The only way to do that is to use RTAllocator.NewTraced(tc) with TYPECODE(T). The run-time system can explicitly check for that in RTAllocator and return a properly tagged reference. On 9 Apr 2009, at 10:23, Mika Nystrom wrote: > Hmm, if you're going to do something along these lines, isn't the > logical > thing to do to introduce a new root of the (traced) type system, that > is > > REFANY <: REFORINT > SMALLINT = [MinSmallInteger .. MaxSmallInteger] > SMALLINT <: REFORINT > > a REFORINT can be a REFANY or a small integer. It stands to reason > that > it is a supertype of REFANY as well as of SMALLINT, because isn't > that exactly what we're looking for? > > The problem with this proposal (as well as both of yours) is that > you get to go through and inspect all existing code that takes > REFANY and wonder whether maybe it should take REFORINT instead.... > > The proposal that Tony and I seem to have agreed on, on the other > hand, allows the implementation to hide small integers completely > transparently in the already existing REFANY, at the cost of an LSB > check on a number of operations, such as ISTYPE, TYPECASE, etc., > to any REFANY. > > I maintain the following: > > I. Since hiding integers in REFANY is intended to be entirely > transparent, you could have it as a compile or even run-time > option. Yes, ok this is ugly. > > II.Assume we go with REFORINT, or OPAQUE, or TAGGED. What existing > uses of REFANY, in any code of importance, is going to stay > REFANY, and what uses will we want to convert to the new types? > > I would suggest considering the following argument: > > A. The new types are strictly more useful than REFANY; they can > represent more values because they can represent all of REFANY > plus other values (after all that was the point all along). > > B. Existing uses of REFANY are either > 1. uses of REFANY because the code is intended to be very generic. > Programmers will want to migrate such code to the new type, > so that they can process the new type as well (since the code > is > generic it should work for either). > 2. uses of REFANY because the programmer was too lazy to > instantiate > a generic for his specific type and decided to cast the values > to REFANY (e.g., to insert in a RefList) and back. Such > programmers > deserve what they get. > > I conclude that code that continues to want to use REFANY rather > than the new type is code that is not performance sensitive. Hence, > I conclude that using REFANY directly to represent small integers > is as reasonable as introducing a new type, and does it with less > work, > both in updating the language definition and in updating all the > libraries in libm3 and elsewhere. > > What current uses of REFANY do not fit the cases in II.B.? Some > trickery to simulate multiple inheritance? Even in those you should > have created a common supertype, I think. > > Mika > > "Rodney M. Bates" writes: >> Here are two integrated proposals for language changes to allow small >> objects, while preserving the principles of the language. Neither of >> them changes the semantics of any existing type or burdens any >> existing code with extra runtime computation. >> >> The unsafe proposal: >> >> This is a much simpler proposal. It could also be used in more >> general ways than just using a tag bit to distinguish a true pointer >> from an in-word value. This is at the cost of requiring unsafe >> coding >> techniques in a module implementing the abstraction, which also >> inevitably means implementation-dependent too. Using it for small >> objects as discussed still requires the garbage collector not to be >> confused by trying to trace a reference with a misaligned value. >> >> There is a new builtin type OPAQUE. The only things you can do with >> it in safe code are copy values around (assigment, pass by VALUE, >> RETURN, etc.) and make reference bindings to it (pass by reference, >> WITH bindings). Not that this ia a _lot_ more opaque than opaque >> types. >> >> OPAQUE is known to be the same size as Word.T. In unsafe code, you >> can use this fact to LOOPHOLE it to anything you want and bit-twiddle >> to your heart's content from there. So an unsafe module could >> implement procedures that take OPAQUE parameters. >> >> Variation: >> >> Allow an opaque subtype of OPAQUE, which can be revealed to be any >> type with statically the same size. This would make it possible to >> prevent client code from mixing up two different unrelated >> abstractions that both happened to use OPAQUE. In fact, without >> this, >> the proposal really fails to preserve the existing principles of >> safe/unsafe code. This would require that the revelation be BRANDED, >> which would either mean restricting the revelation to a reference >> type >> (which could still be LOOPHOLEd to anything else) or allowing other >> types to be BRANDED. >> >> Example: >> >> INTERFACE ADT; >> TYPE T <: OPAQUE; >> PROCEDURE P (x:T); >> ... >> END ADT >> >> UNSAFE MODULE ADT; >> TYPE R = RECORD ... END; >> REVEAL T = BRANDED REF R; >> >> PROCEDURE P (x:T) >> VAR I: INTEGER; >> BEGIN >> IF LOOPHOLE(x,INTEGER) MOD 2 # 0 >> THEN >> I := Word.Shift(LOOPHOLE(x,INTEGER),-1); >> (* Use integer value I ... *) >> ELSE >> (* Use reference value x, according to its declared type. >> Prior to the check above, we couldn't afford to risk >> doing anything with it. ... *) >> END (* IF *); >> END P; >> ... >> END ADT; >> >> The safe proposal: >> >> This is more complicated and less general, but allows small object >> abstractions to be done in an entirely safe and implementation- >> independent way. It abstracts away all the bit-level representation >> questions. >> >> There is a new type TAG, which is a subrange of INTEGER, with >> implementation-defined bounds (which would then be accessible by >> FIRST/LAST). >> >> There is a new type constructor TAGGED. If T is any traced reference >> type or any untraced object type, TAGGED T defines a type, called a >> _tagged_ type, whose value set is the union of the value sets of TAG >> and T. >> >> TAG <: TAGGED T and T <: TAGGED T. >> >> There are no other subtype relations involving TAGGED T. >> >> Values of a tagged type can be copied and bound-to. >> >> The static rules for ISTYPE, NARROW, TYPECASE, and assignability of a >> type to a type are liberalized to allow their application to a tagged >> type, and to allow the type to be checked/converted-to to be any >> subtype of the tagged type. Already existing rules would require a >> runtime check that the value is a member of the stated type. >> >> No other operations are possible on a tagged type. A tagged type is >> not a reference type and does not have a typecode. >> >> Example: >> >> INTERFACE ADT; >> TYPE Op <: REFANY; >> TYPE T = TAGGED Op; >> PROCEDURE P (x:T); >> ... >> END ADT >> >> MODULE ADT; >> TYPE R = RECORD ... END; >> REVEAL Op = BRANDED REF R; >> >> PROCEDURE P (x:T) >> BEGIN >> TYPECASE x >> OF TAG (I) >> => (* Use integer value I ... *) >> | Op (RR) >> => (* Use reference value RR ... *) >> END (* IF *); >> END P; >> ... >> END ADT; >> >> Note: TAG is like CARDINAL in that it is "just like" a subrange of >> INTEGER, but not equal to that subrange. This enabled pickles to >> change the size of values of type TAG and of tagged types, as it now >> does with CARDINAL. >> >> Variation: >> >> The 4 runtime-checking operations can also be applied to any ordinal >> type and can check that an ordinal or tagged type has a value >> belonging to any subrange of the base type (or maybe just of the type >> being narrowed). This is pure fluff (well, maybe it is syntactic >> sugar), but adds some consistency and has a real use: >> >> How many times have I coded the following? >> >> IF FIRST(SomeOrdinalType <= x AND x <= LAST(SomeOrdinalType) THEN ... >> >> or worse, >> >> IF FIRST(SomeOrdinalType <= F(x) AND F(x) <= LAST(SomeOrdinalType) >> THEN ... >> >> which I then feel morally obligated to recode using a local >> variable or >> WITH-temp to eliminate the duplicated calls F(x). >> >> It could then become: >> >> IF ISTYPE (F(x), SomeOrdinalType) THEN ... >> >> >> >> >> >> From rodney.m.bates at cox.net Thu Apr 9 04:13:47 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 08 Apr 2009 21:13:47 -0500 Subject: [M3devel] small objects In-Reply-To: <200904090038.n390cNsg097270@camembert.async.caltech.edu> References: <200904090038.n390cNsg097270@camembert.async.caltech.edu> Message-ID: <49DD59DB.4050404@cox.net> Mika Nystrom wrote: > Hmm, ok, there's one big difference between what you're saying and > what Tony and I have been talking about. (I think your understanding > sounds pretty correct.) > > You want to do objects other than small integers. Like what? And why? > I was thinking the trick would apply only to one specific type of integer. > Yes, I want a language mechanism that can be used by various modules to implement various abstract data types, each of which can perform the sometimes dramatic space optimization of putting values that are common and will fit directly in the word. One module I spoke of implements general sets of integers with dynamically variable and sometimes large range. This differs from the builtin SET OF.., which must have a static (and probably relatively small) base subrange. Thus the general, heap-allocated values contain open arrays of Word.T, treated as sets, or if you prefer, packed arrays of booleans, although I manipulate them with bit-twiddling operations from Word. There is another, static-sized, heap-allocated object in front of each array, containing biases on what bits correspond to what integers in the abstract set, etc. It all works fine now, but the usage pattern of some clients has a high percentage very small sets that would fit in a word, and there would be an 11-to-1 space savings if that could be done. BTW, there are also two different kinds of heap objects, one that represents a range set by just its bounds. So I am TYPECASEing these already. It would be very convenient if I could just add another alternative to the TYPECASE for in-word values. In another case, I need truly dynamically variable sized arrays of integers in [0..15], and the great majority are 7 elements or less, which would fit directly in the word, but I still the need full generality to be available, so it's open arrays all the time, with three additional words each. If you can pack a union of a pointer and an integer into a word and can separate them with runtime checks, then you can use the separated integer any way you want, with bit twiddling, type conversions, LOOPHOLE, or whatever. That is what I am trying to get, not just Smalltalk-like integers. Note that Smalltalk has zero static typing, so only one internal representation must do for the union of all possible values in the language. In Modula-3, it would be very inconsistent with the language's philosophy to be this restricted. > Hmm, so your idea is to statically determine what type the references > can have if they are non-references. So you are thinking to put various > kinds of subranges into the "TAGGED" types. But you have to be able to > determine, statically, which subrange it is... am I understanding this > correctly? > From the language, all I want is to be able to dynamically determine whether it is a true pointer to a heap object or a value stored directly in the word, while preserving the safety principles and the semantics of everything already there. So I want some new types, different from any existing types, that statically are known to hold this kind of valueset union and can be converted/assigned to a variable of existing type that is statically known to be either a pointer or an integer (but not both), with a suitable runtime check. It is also necessary to have a way to do this without risking a runtime error, if your code doesn't know yet which kind of value it has. Various ADT modules can take it from there. > Mika > > "Rodney M. Bates" writes: > >> Tony Hosking wrote: >> >>> On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: >>> >>> >>>> Mika Nystrom wrote: >>>> >>>>> Hendrik, I think Tony's and my arguments that you can't break any >>>>> existing code by allowing the squirreling away of integers into >>>>> REFANYs are pretty solid. Pre-existing code simply can't do anything >>>>> useful with unrevealed REFANYs. >>>>> >>>> This is only true of _unrevealed opaque subtypes_ of REFANY, >>>> not of REFANY itself. There is lots of existing code that uses REFANY, >>>> and there, ISTYPE, NARROW, TYPECASE, and assigment can be and >>>> regularly are used on it. It is essential not to alter the >>>> semantics there. >>>> >>> Pre-existing code won't be able to do anything useful with tagged >>> REFANYs: >>> >>> Suppose we have >>> >>> VAR r: REFANY = SmallInteger.FromInt(0); >>> >>> then >>> >>> ISTYPE(r, REFANY) => TRUE >>> ISTYPE(r, T) => FALSE for any T # REFANY >>> >>> Similarly, for TYPECASE, r will only trigger the REFANY branch. >>> >>> NARROW(r, REFANY) => r >>> NARROW(r, T) => run-time error for any T #REFANY >>> >>> VAR x: REFANY => assignment succeeds >>> VAR x: T := r => run-time error for any T # REFANY (because of >>> implicit NARROW) >>> >> I think I am getting a bit lost in all the proposals, variations, >> counterproposals, etc., but >> > >from this argument I am inferring that your plan is that only variables > >> declared REFANY >> and not any proper subtype of REFANY can ever have a value with a tag >> bit set? Then >> the 4 narrowing operations, when and only when applied to an expression >> of static >> type REFANY, would change to make a runtime check for a tag bit and fail >> if it's set? >> It would take this to prevent a tagged value from getting into a >> variable declared a >> proper subtype of REFANY, which can be dereferenced. >> >> This would preclude making your abstract data type an opaque subtype of >> REFANY, >> and would mean all supposedly unrelated ADT modules that used the tag >> technique >> could be broken by client code that mixed up the REFANY values of one of >> them with >> those of another. I consider this a definite breach of Modula-3's >> otherwise bulletproof >> type safety. >> >>> It is impossible to dereference an expression statically typed as >>> REFANY, so there is no need for a "tagged" check on dereference. >>> Because a tagged REFANY cannot be assigned to anything other than >>> something typed REFANY, it can never propagate to a place where it can >>> be dereferenced. >>> >>> >>>> Aside from actual semantic changes, I agree with Tony that we should >>>> not burden any existing type with additional runtime work. Even though >>>> I expect small objects to support big performance gains in certain >>>> important cases, non-tagged references will still greatly predominate >>>> in most code. Create new type(s) for tagged references. >>>> >>> I'm not sure that we are seeing any semantic changes at all. And with >>> Mika's definition of SmallInteger.T as a "boxed" INTEGER object >>> (actually it would be a subrange for values that fit into >>> BITSIZE(Word.T)-1 bits), it is essentially transparent. It just >>> happens to be a run-time optimization that unboxes the INTEGER value. >>> >>> >>> I think I can implement the compiler and run-time support for this >>> very quickly. >>> >>> >>> > > From hosking at cs.purdue.edu Thu Apr 9 05:01:13 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 9 Apr 2009 13:01:13 +1000 Subject: [M3devel] small objects In-Reply-To: <49DD59DB.4050404@cox.net> References: <200904090038.n390cNsg097270@camembert.async.caltech.edu> <49DD59DB.4050404@cox.net> Message-ID: <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> Sounds like you want something like: TAGGED REFANY FOR T where T must be a type that fits into BITS(REFANY)-1? Branding could be used to prevent mixing otherwise structurally equivalent TAGGED REFANY. TAGGED BRANDED REFANY FOR T Where this breaks down is what are the subtyping rules, since I assume you'd like to store these in a REFANY and dynamically test for the appropriate tagged type: TAGGED REFANY FOR T <: REFANY But then how do we distinguish all the different TAGGED REFANY from each other at run-time? On 9 Apr 2009, at 12:13, Rodney M. Bates wrote: > Mika Nystrom wrote: >> Hmm, ok, there's one big difference between what you're saying and >> what Tony and I have been talking about. (I think your understanding >> sounds pretty correct.) >> >> You want to do objects other than small integers. Like what? And >> why? >> I was thinking the trick would apply only to one specific type of >> integer. >> > > Yes, I want a language mechanism that can be used by various > modules to implement various abstract data types, each of which > can perform the sometimes dramatic space optimization of putting > values that are common and will fit directly in the word. > One module I spoke of implements general sets of integers with > dynamically variable and sometimes large range. This differs from > the builtin SET OF.., which must have a static (and probably > relatively > small) base subrange. Thus the general, heap-allocated values contain > open arrays of Word.T, treated as sets, or if you prefer, packed > arrays > of booleans, although I manipulate them with bit-twiddling operations > from Word. > There is another, static-sized, heap-allocated object in front of > each array, > containing biases on what bits correspond to what integers in the > abstract set, etc. It all works fine now, but the usage pattern of > some > clients has a high percentage very small sets that would fit in a > word, > and there would be an 11-to-1 space savings if that could be done. > BTW, there are also two different kinds of heap objects, one that > represents a range set by just its bounds. So I am TYPECASEing > these already. It would be very convenient if I could just add > another > alternative to the TYPECASE for in-word values. > > In another case, I need truly dynamically variable sized arrays of > integers in [0..15], and the great majority are 7 elements or less, > which would fit directly in the word, but I still the need full > generality > to be available, so it's open arrays all the time, with three > additional > words each. > > If you can pack a union of a pointer and an integer into a word and > can separate them with runtime checks, then you can use the > separated integer any way you want, with bit twiddling, type > conversions, > LOOPHOLE, or whatever. That is what I am trying to get, not just > Smalltalk-like integers. > Note that Smalltalk has zero static typing, so only one internal > representation must do for the union of all possible values in > the language. In Modula-3, it would be very inconsistent with > the language's philosophy to be this restricted. >> Hmm, so your idea is to statically determine what type the references >> can have if they are non-references. So you are thinking to put >> various >> kinds of subranges into the "TAGGED" types. But you have to be >> able to >> determine, statically, which subrange it is... am I understanding >> this >> correctly? >> > > From the language, all I want is to be able to dynamically determine > whether it is a true pointer to a heap object or a value stored > directly in the word, while preserving the safety principles and > the semantics of everything already there. So I want some new > types, different from any existing types, that statically are known > to hold this kind of valueset union and can be converted/assigned > to a variable of existing type that is statically known to be either a > pointer or an integer (but not both), with a suitable runtime check. > It is also necessary to have a way to do this without risking a > runtime > error, if your code doesn't know yet which kind of value it has. > Various ADT modules can take it from there. >> Mika >> >> "Rodney M. Bates" writes: >> >>> Tony Hosking wrote: >>> >>>> On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: >>>> >>>> >>>>> Mika Nystrom wrote: >>>>> >>>>>> Hendrik, I think Tony's and my arguments that you can't break any >>>>>> existing code by allowing the squirreling away of integers into >>>>>> REFANYs are pretty solid. Pre-existing code simply can't do >>>>>> anything >>>>>> useful with unrevealed REFANYs. >>>>>> >>>>> This is only true of _unrevealed opaque subtypes_ of REFANY, >>>>> not of REFANY itself. There is lots of existing code that uses >>>>> REFANY, >>>>> and there, ISTYPE, NARROW, TYPECASE, and assigment can be and >>>>> regularly are used on it. It is essential not to alter the >>>>> semantics there. >>>>> >>>> Pre-existing code won't be able to do anything useful with tagged >>>> REFANYs: >>>> >>>> Suppose we have >>>> >>>> VAR r: REFANY = SmallInteger.FromInt(0); >>>> >>>> then >>>> >>>> ISTYPE(r, REFANY) => TRUE >>>> ISTYPE(r, T) => FALSE for any T # REFANY >>>> >>>> Similarly, for TYPECASE, r will only trigger the REFANY branch. >>>> >>>> NARROW(r, REFANY) => r >>>> NARROW(r, T) => run-time error for any T #REFANY >>>> >>>> VAR x: REFANY => assignment succeeds >>>> VAR x: T := r => run-time error for any T # REFANY (because of >>>> implicit NARROW) >>>> >>> I think I am getting a bit lost in all the proposals, variations, >>> counterproposals, etc., but >>> >> >from this argument I am inferring that your plan is that only >> variables >>> declared REFANY >>> and not any proper subtype of REFANY can ever have a value with a >>> tag bit set? Then >>> the 4 narrowing operations, when and only when applied to an >>> expression of static >>> type REFANY, would change to make a runtime check for a tag bit >>> and fail if it's set? >>> It would take this to prevent a tagged value from getting into a >>> variable declared a >>> proper subtype of REFANY, which can be dereferenced. >>> >>> This would preclude making your abstract data type an opaque >>> subtype of REFANY, >>> and would mean all supposedly unrelated ADT modules that used the >>> tag technique >>> could be broken by client code that mixed up the REFANY values of >>> one of them with >>> those of another. I consider this a definite breach of Modula-3's >>> otherwise bulletproof >>> type safety. >>>> It is impossible to dereference an expression statically typed as >>>> REFANY, so there is no need for a "tagged" check on dereference. >>>> Because a tagged REFANY cannot be assigned to anything other than >>>> something typed REFANY, it can never propagate to a place where >>>> it can be dereferenced. >>>> >>>> >>>>> Aside from actual semantic changes, I agree with Tony that we >>>>> should >>>>> not burden any existing type with additional runtime work. Even >>>>> though >>>>> I expect small objects to support big performance gains in certain >>>>> important cases, non-tagged references will still greatly >>>>> predominate >>>>> in most code. Create new type(s) for tagged references. >>>>> >>>> I'm not sure that we are seeing any semantic changes at all. And >>>> with Mika's definition of SmallInteger.T as a "boxed" INTEGER >>>> object (actually it would be a subrange for values that fit into >>>> BITSIZE(Word.T)-1 bits), it is essentially transparent. It just >>>> happens to be a run-time optimization that unboxes the INTEGER >>>> value. >>>> >>>> >>>> I think I can implement the compiler and run-time support for >>>> this very quickly. >>>> >>>> >>>> >> >> From jay.krell at cornell.edu Thu Apr 9 05:59:02 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 9 Apr 2009 03:59:02 +0000 Subject: [M3devel] small objects In-Reply-To: <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> References: <200904090038.n390cNsg097270@camembert.async.caltech.edu> <49DD59DB.4050404@cox.net> <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> Message-ID: Um, what do folks think of, like: struct { void* Type; union { size_t Integer; void* Pointer; } Value; } Variant; ? You know -- something that is two pointers, one pointer for the type, one for the value or integer? void* Type would actually be a pointer to something actually defined and elaborate. Obviously this is twice as large, not as small as it could be, but much more general and portable. No need to determine how many of bits can be the tag. And hope/assume for perf that such a small struct is passed in registers. On x86/NT 4 and 8 byte structs I think are. Type could also be an integer, index into some table, with some predefined values. #define TYPE_INTEGER 0 #define TYPE_FLOAT 1 #define TYPE_DOUBLE 2 #define TYPE_ADDRESS 3 more generally the union would have a float, and maybe a double on 64bit platforms. OR, on 64bit platforms, you probably can, with some porting work, dedicate a whole 8 bits or so to a type index, and still the thing in one "word". How many bits of address space does any 64bit platform these days or forseeable future actually implement? But 32 bits doesn't seem big enough to afford that, and still this is a portability problem -- anything less than a full pointer. - Jay > From: hosking at cs.purdue.edu > To: rodney.m.bates at cox.net > Date: Thu, 9 Apr 2009 13:01:13 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] small objects > > Sounds like you want something like: > > TAGGED REFANY FOR T > > where T must be a type that fits into BITS(REFANY)-1? > > Branding could be used to prevent mixing otherwise structurally > equivalent TAGGED REFANY. > > TAGGED BRANDED REFANY FOR T > > Where this breaks down is what are the subtyping rules, since I assume > you'd like to store these in a REFANY and dynamically test for the > appropriate tagged type: > > TAGGED REFANY FOR T <: REFANY > > But then how do we distinguish all the different TAGGED REFANY from > each other at run-time? > > On 9 Apr 2009, at 12:13, Rodney M. Bates wrote: > > > Mika Nystrom wrote: > >> Hmm, ok, there's one big difference between what you're saying and > >> what Tony and I have been talking about. (I think your understanding > >> sounds pretty correct.) > >> > >> You want to do objects other than small integers. Like what? And > >> why? > >> I was thinking the trick would apply only to one specific type of > >> integer. > >> > > > > Yes, I want a language mechanism that can be used by various > > modules to implement various abstract data types, each of which > > can perform the sometimes dramatic space optimization of putting > > values that are common and will fit directly in the word. > > One module I spoke of implements general sets of integers with > > dynamically variable and sometimes large range. This differs from > > the builtin SET OF.., which must have a static (and probably > > relatively > > small) base subrange. Thus the general, heap-allocated values contain > > open arrays of Word.T, treated as sets, or if you prefer, packed > > arrays > > of booleans, although I manipulate them with bit-twiddling operations > > from Word. > > There is another, static-sized, heap-allocated object in front of > > each array, > > containing biases on what bits correspond to what integers in the > > abstract set, etc. It all works fine now, but the usage pattern of > > some > > clients has a high percentage very small sets that would fit in a > > word, > > and there would be an 11-to-1 space savings if that could be done. > > BTW, there are also two different kinds of heap objects, one that > > represents a range set by just its bounds. So I am TYPECASEing > > these already. It would be very convenient if I could just add > > another > > alternative to the TYPECASE for in-word values. > > > > In another case, I need truly dynamically variable sized arrays of > > integers in [0..15], and the great majority are 7 elements or less, > > which would fit directly in the word, but I still the need full > > generality > > to be available, so it's open arrays all the time, with three > > additional > > words each. > > > > If you can pack a union of a pointer and an integer into a word and > > can separate them with runtime checks, then you can use the > > separated integer any way you want, with bit twiddling, type > > conversions, > > LOOPHOLE, or whatever. That is what I am trying to get, not just > > Smalltalk-like integers. > > Note that Smalltalk has zero static typing, so only one internal > > representation must do for the union of all possible values in > > the language. In Modula-3, it would be very inconsistent with > > the language's philosophy to be this restricted. > >> Hmm, so your idea is to statically determine what type the references > >> can have if they are non-references. So you are thinking to put > >> various > >> kinds of subranges into the "TAGGED" types. But you have to be > >> able to > >> determine, statically, which subrange it is... am I understanding > >> this > >> correctly? > >> > > > > From the language, all I want is to be able to dynamically determine > > whether it is a true pointer to a heap object or a value stored > > directly in the word, while preserving the safety principles and > > the semantics of everything already there. So I want some new > > types, different from any existing types, that statically are known > > to hold this kind of valueset union and can be converted/assigned > > to a variable of existing type that is statically known to be either a > > pointer or an integer (but not both), with a suitable runtime check. > > It is also necessary to have a way to do this without risking a > > runtime > > error, if your code doesn't know yet which kind of value it has. > > Various ADT modules can take it from there. > >> Mika > >> > >> "Rodney M. Bates" writes: > >> > >>> Tony Hosking wrote: > >>> > >>>> On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: > >>>> > >>>> > >>>>> Mika Nystrom wrote: > >>>>> > >>>>>> Hendrik, I think Tony's and my arguments that you can't break any > >>>>>> existing code by allowing the squirreling away of integers into > >>>>>> REFANYs are pretty solid. Pre-existing code simply can't do > >>>>>> anything > >>>>>> useful with unrevealed REFANYs. > >>>>>> > >>>>> This is only true of _unrevealed opaque subtypes_ of REFANY, > >>>>> not of REFANY itself. There is lots of existing code that uses > >>>>> REFANY, > >>>>> and there, ISTYPE, NARROW, TYPECASE, and assigment can be and > >>>>> regularly are used on it. It is essential not to alter the > >>>>> semantics there. > >>>>> > >>>> Pre-existing code won't be able to do anything useful with tagged > >>>> REFANYs: > >>>> > >>>> Suppose we have > >>>> > >>>> VAR r: REFANY = SmallInteger.FromInt(0); > >>>> > >>>> then > >>>> > >>>> ISTYPE(r, REFANY) => TRUE > >>>> ISTYPE(r, T) => FALSE for any T # REFANY > >>>> > >>>> Similarly, for TYPECASE, r will only trigger the REFANY branch. > >>>> > >>>> NARROW(r, REFANY) => r > >>>> NARROW(r, T) => run-time error for any T #REFANY > >>>> > >>>> VAR x: REFANY => assignment succeeds > >>>> VAR x: T := r => run-time error for any T # REFANY (because of > >>>> implicit NARROW) > >>>> > >>> I think I am getting a bit lost in all the proposals, variations, > >>> counterproposals, etc., but > >>> > >> >from this argument I am inferring that your plan is that only > >> variables > >>> declared REFANY > >>> and not any proper subtype of REFANY can ever have a value with a > >>> tag bit set? Then > >>> the 4 narrowing operations, when and only when applied to an > >>> expression of static > >>> type REFANY, would change to make a runtime check for a tag bit > >>> and fail if it's set? > >>> It would take this to prevent a tagged value from getting into a > >>> variable declared a > >>> proper subtype of REFANY, which can be dereferenced. > >>> > >>> This would preclude making your abstract data type an opaque > >>> subtype of REFANY, > >>> and would mean all supposedly unrelated ADT modules that used the > >>> tag technique > >>> could be broken by client code that mixed up the REFANY values of > >>> one of them with > >>> those of another. I consider this a definite breach of Modula-3's > >>> otherwise bulletproof > >>> type safety. > >>>> It is impossible to dereference an expression statically typed as > >>>> REFANY, so there is no need for a "tagged" check on dereference. > >>>> Because a tagged REFANY cannot be assigned to anything other than > >>>> something typed REFANY, it can never propagate to a place where > >>>> it can be dereferenced. > >>>> > >>>> > >>>>> Aside from actual semantic changes, I agree with Tony that we > >>>>> should > >>>>> not burden any existing type with additional runtime work. Even > >>>>> though > >>>>> I expect small objects to support big performance gains in certain > >>>>> important cases, non-tagged references will still greatly > >>>>> predominate > >>>>> in most code. Create new type(s) for tagged references. > >>>>> > >>>> I'm not sure that we are seeing any semantic changes at all. And > >>>> with Mika's definition of SmallInteger.T as a "boxed" INTEGER > >>>> object (actually it would be a subrange for values that fit into > >>>> BITSIZE(Word.T)-1 bits), it is essentially transparent. It just > >>>> happens to be a run-time optimization that unboxes the INTEGER > >>>> value. > >>>> > >>>> > >>>> I think I can implement the compiler and run-time support for > >>>> this very quickly. > >>>> > >>>> > >>>> > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Apr 9 06:22:52 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 9 Apr 2009 14:22:52 +1000 Subject: [M3devel] small objects In-Reply-To: References: <200904090038.n390cNsg097270@camembert.async.caltech.edu> <49DD59DB.4050404@cox.net> <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> Message-ID: <6DADF96B-7A17-45E8-8084-48A66372ED2D@cs.purdue.edu> I don't know what you are saving over just allocating: NEW(OBJECT i: INTEGER END) NEW(OBJECT r: REFANY END) Each is only 2 words: one for the object header and the other for the value. On 9 Apr 2009, at 13:59, Jay wrote: > Um, what do folks think of, like: > > struct > { > void* Type; > union > { > size_t Integer; > void* Pointer; > } Value; > } Variant; > > ? > You know -- something that is two pointers, one pointer for the > type, one for the value or integer? > void* Type would actually be a pointer to something actually defined > and elaborate. > > Obviously this is twice as large, not as small as it could be, but > much more general and portable. No need to determine how many of > bits can be the tag. > > And hope/assume for perf that such a small struct is passed in > registers. > On x86/NT 4 and 8 byte structs I think are. > > Type could also be an integer, index into some table, with some > predefined values. > #define TYPE_INTEGER 0 > #define TYPE_FLOAT 1 > #define TYPE_DOUBLE 2 > #define TYPE_ADDRESS 3 > > more generally the union would have a float, and maybe a double on > 64bit platforms. > > OR, on 64bit platforms, you probably can, with some porting work, > dedicate a whole 8 bits or so to a type index, and still the thing > in one "word". How many bits of address space does any 64bit > platform these days or forseeable future actually implement? > > But 32 bits doesn't seem big enough to afford that, and still this > is a portability problem -- anything less than a full pointer. > > - Jay > > > > From: hosking at cs.purdue.edu > > To: rodney.m.bates at cox.net > > Date: Thu, 9 Apr 2009 13:01:13 +1000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] small objects > > > > Sounds like you want something like: > > > > TAGGED REFANY FOR T > > > > where T must be a type that fits into BITS(REFANY)-1? > > > > Branding could be used to prevent mixing otherwise structurally > > equivalent TAGGED REFANY. > > > > TAGGED BRANDED REFANY FOR T > > > > Where this breaks down is what are the subtyping rules, since I > assume > > you'd like to store these in a REFANY and dynamically test for the > > appropriate tagged type: > > > > TAGGED REFANY FOR T <: REFANY > > > > But then how do we distinguish all the different TAGGED REFANY from > > each other at run-time? > > > > On 9 Apr 2009, at 12:13, Rodney M. Bates wrote: > > > > > Mika Nystrom wrote: > > >> Hmm, ok, there's one big difference between what you're saying > and > > >> what Tony and I have been talking about. (I think your > understanding > > >> sounds pretty correct.) > > >> > > >> You want to do objects other than small integers. Like what? And > > >> why? > > >> I was thinking the trick would apply only to one specific type of > > >> integer. > > >> > > > > > > Yes, I want a language mechanism that can be used by various > > > modules to implement various abstract data types, each of which > > > can perform the sometimes dramatic space optimization of putting > > > values that are common and will fit directly in the word. > > > One module I spoke of implements general sets of integers with > > > dynamically variable and sometimes large range. This differs from > > > the builtin SET OF.., which must have a static (and probably > > > relatively > > > small) base subrange. Thus the general, heap-allocated values > contain > > > open arrays of Word.T, treated as sets, or if you prefer, packed > > > arrays > > > of booleans, although I manipulate them with bit-twiddling > operations > > > from Word. > > > There is another, static-sized, heap-allocated object in front of > > > each array, > > > containing biases on what bits correspond to what integers in the > > > abstract set, etc. It all works fine now, but the usage pattern of > > > some > > > clients has a high percentage very small sets that would fit in a > > > word, > > > and there would be an 11-to-1 space savings if that could be done. > > > BTW, there are also two different kinds of heap objects, one that > > > represents a range set by just its bounds. So I am TYPECASEing > > > these already. It would be very convenient if I could just add > > > another > > > alternative to the TYPECASE for in-word values. > > > > > > In another case, I need truly dynamically variable sized arrays of > > > integers in [0..15], and the great majority are 7 elements or > less, > > > which would fit directly in the word, but I still the need full > > > generality > > > to be available, so it's open arrays all the time, with three > > > additional > > > words each. > > > > > > If you can pack a union of a pointer and an integer into a word > and > > > can separate them with runtime checks, then you can use the > > > separated integer any way you want, with bit twiddling, type > > > conversions, > > > LOOPHOLE, or whatever. That is what I am trying to get, not just > > > Smalltalk-like integers. > > > Note that Smalltalk has zero static typing, so only one internal > > > representation must do for the union of all possible values in > > > the language. In Modula-3, it would be very inconsistent with > > > the language's philosophy to be this restricted. > > >> Hmm, so your idea is to statically determine what type the > references > > >> can have if they are non-references. So you are thinking to put > > >> various > > >> kinds of subranges into the "TAGGED" types. But you have to be > > >> able to > > >> determine, statically, which subrange it is... am I understanding > > >> this > > >> correctly? > > >> > > > > > > From the language, all I want is to be able to dynamically > determine > > > whether it is a true pointer to a heap object or a value stored > > > directly in the word, while preserving the safety principles and > > > the semantics of everything already there. So I want some new > > > types, different from any existing types, that statically are > known > > > to hold this kind of valueset union and can be converted/assigned > > > to a variable of existing type that is statically known to be > either a > > > pointer or an integer (but not both), with a suitable runtime > check. > > > It is also necessary to have a way to do this without risking a > > > runtime > > > error, if your code doesn't know yet which kind of value it has. > > > Various ADT modules can take it from there. > > >> Mika > > >> > > >> "Rodney M. Bates" writes: > > >> > > >>> Tony Hosking wrote: > > >>> > > >>>> On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: > > >>>> > > >>>> > > >>>>> Mika Nystrom wrote: > > >>>>> > > >>>>>> Hendrik, I think Tony's and my arguments that you can't > break any > > >>>>>> existing code by allowing the squirreling away of integers > into > > >>>>>> REFANYs are pretty solid. Pre-existing code simply can't do > > >>>>>> anything > > >>>>>> useful with unrevealed REFANYs. > > >>>>>> > > >>>>> This is only true of _unrevealed opaque subtypes_ of REFANY, > > >>>>> not of REFANY itself. There is lots of existing code that uses > > >>>>> REFANY, > > >>>>> and there, ISTYPE, NARROW, TYPECASE, and assigment can be and > > >>>>> regularly are used on it. It is essential not to alter the > > >>>>> semantics there. > > >>>>> > > >>>> Pre-existing code won't be able to do anything useful with > tagged > > >>>> REFANYs: > > >>>> > > >>>> Suppose we have > > >>>> > > >>>> VAR r: REFANY = SmallInteger.FromInt(0); > > >>>> > > >>>> then > > >>>> > > >>>> ISTYPE(r, REFANY) => TRUE > > >>>> ISTYPE(r, T) => FALSE for any T # REFANY > > >>>> > > >>>> Similarly, for TYPECASE, r will only trigger the REFANY branch. > > >>>> > > >>>> NARROW(r, REFANY) => r > > >>>> NARROW(r, T) => run-time error for any T #REFANY > > >>>> > > >>>> VAR x: REFANY => assignment succeeds > > >>>> VAR x: T := r => run-time error for any T # REFANY (because of > > >>>> implicit NARROW) > > >>>> > > >>> I think I am getting a bit lost in all the proposals, > variations, > > >>> counterproposals, etc., but > > >>> > > >> >from this argument I am inferring that your plan is that only > > >> variables > > >>> declared REFANY > > >>> and not any proper subtype of REFANY can ever have a value > with a > > >>> tag bit set? Then > > >>> the 4 narrowing operations, when and only when applied to an > > >>> expression of static > > >>> type REFANY, would change to make a runtime check for a tag bit > > >>> and fail if it's set? > > >>> It would take this to prevent a tagged value from getting into a > > >>> variable declared a > > >>> proper subtype of REFANY, which can be dereferenced. > > >>> > > >>> This would preclude making your abstract data type an opaque > > >>> subtype of REFANY, > > >>> and would mean all supposedly unrelated ADT modules that used > the > > >>> tag technique > > >>> could be broken by client code that mixed up the REFANY values > of > > >>> one of them with > > >>> those of another. I consider this a definite breach of > Modula-3's > > >>> otherwise bulletproof > > >>> type safety. > > >>>> It is impossible to dereference an expression statically > typed as > > >>>> REFANY, so there is no need for a "tagged" check on > dereference. > > >>>> Because a tagged REFANY cannot be assigned to anything other > than > > >>>> something typed REFANY, it can never propagate to a place where > > >>>> it can be dereferenced. > > >>>> > > >>>> > > >>>>> Aside from actual semantic changes, I agree with Tony that we > > >>>>> should > > >>>>> not burden any existing type with additional runtime work. > Even > > >>>>> though > > >>>>> I expect small objects to support big performance gains in > certain > > >>>>> important cases, non-tagged references will still greatly > > >>>>> predominate > > >>>>> in most code. Create new type(s) for tagged references. > > >>>>> > > >>>> I'm not sure that we are seeing any semantic changes at all. > And > > >>>> with Mika's definition of SmallInteger.T as a "boxed" INTEGER > > >>>> object (actually it would be a subrange for values that fit > into > > >>>> BITSIZE(Word.T)-1 bits), it is essentially transparent. It just > > >>>> happens to be a run-time optimization that unboxes the INTEGER > > >>>> value. > > >>>> > > >>>> > > >>>> I think I can implement the compiler and run-time support for > > >>>> this very quickly. > > >>>> > > >>>> > > >>>> > > >> > > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 9 07:36:49 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 9 Apr 2009 05:36:49 +0000 Subject: [M3devel] small objects In-Reply-To: <6DADF96B-7A17-45E8-8084-48A66372ED2D@cs.purdue.edu> References: <200904090038.n390cNsg097270@camembert.async.caltech.edu> <49DD59DB.4050404@cox.net> <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> <6DADF96B-7A17-45E8-8084-48A66372ED2D@cs.purdue.edu> Message-ID: The heap allocation and pressure on the garbage collector -- such a small struct is reasonably efficient to pass around by value. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Thu, 9 Apr 2009 14:22:52 +1000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] small objects I don't know what you are saving over just allocating: NEW(OBJECT i: INTEGER END) NEW(OBJECT r: REFANY END) Each is only 2 words: one for the object header and the other for the value. On 9 Apr 2009, at 13:59, Jay wrote: Um, what do folks think of, like: struct { void* Type; union { size_t Integer; void* Pointer; } Value; } Variant; ? You know -- something that is two pointers, one pointer for the type, one for the value or integer? void* Type would actually be a pointer to something actually defined and elaborate. Obviously this is twice as large, not as small as it could be, but much more general and portable. No need to determine how many of bits can be the tag. And hope/assume for perf that such a small struct is passed in registers. On x86/NT 4 and 8 byte structs I think are. Type could also be an integer, index into some table, with some predefined values. #define TYPE_INTEGER 0 #define TYPE_FLOAT 1 #define TYPE_DOUBLE 2 #define TYPE_ADDRESS 3 more generally the union would have a float, and maybe a double on 64bit platforms. OR, on 64bit platforms, you probably can, with some porting work, dedicate a whole 8 bits or so to a type index, and still the thing in one "word". How many bits of address space does any 64bit platform these days or forseeable future actually implement? But 32 bits doesn't seem big enough to afford that, and still this is a portability problem -- anything less than a full pointer. - Jay > From: hosking at cs.purdue.edu > To: rodney.m.bates at cox.net > Date: Thu, 9 Apr 2009 13:01:13 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] small objects > > Sounds like you want something like: > > TAGGED REFANY FOR T > > where T must be a type that fits into BITS(REFANY)-1? > > Branding could be used to prevent mixing otherwise structurally > equivalent TAGGED REFANY. > > TAGGED BRANDED REFANY FOR T > > Where this breaks down is what are the subtyping rules, since I assume > you'd like to store these in a REFANY and dynamically test for the > appropriate tagged type: > > TAGGED REFANY FOR T <: REFANY > > But then how do we distinguish all the different TAGGED REFANY from > each other at run-time? > > On 9 Apr 2009, at 12:13, Rodney M. Bates wrote: > > > Mika Nystrom wrote: > >> Hmm, ok, there's one big difference between what you're saying and > >> what Tony and I have been talking about. (I think your understanding > >> sounds pretty correct.) > >> > >> You want to do objects other than small integers. Like what? And > >> why? > >> I was thinking the trick would apply only to one specific type of > >> integer. > >> > > > > Yes, I want a language mechanism that can be used by various > > modules to implement various abstract data types, each of which > > can perform the sometimes dramatic space optimization of putting > > values that are common and will fit directly in the word. > > One module I spoke of implements general sets of integers with > > dynamically variable and sometimes large range. This differs from > > the builtin SET OF.., which must have a static (and probably > > relatively > > small) base subrange. Thus the general, heap-allocated values contain > > open arrays of Word.T, treated as sets, or if you prefer, packed > > arrays > > of booleans, although I manipulate them with bit-twiddling operations > > from Word. > > There is another, static-sized, heap-allocated object in front of > > each array, > > containing biases on what bits correspond to what integers in the > > abstract set, etc. It all works fine now, but the usage pattern of > > some > > clients has a high percentage very small sets that would fit in a > > word, > > and there would be an 11-to-1 space savings if that could be done. > > BTW, there are also two different kinds of heap objects, one that > > represents a range set by just its bounds. So I am TYPECASEing > > these already. It would be very convenient if I could just add > > another > > alternative to the TYPECASE for in-word values. > > > > In another case, I need truly dynamically variable sized arrays of > > integers in [0..15], and the great majority are 7 elements or less, > > which would fit directly in the word, but I still the need full > > generality > > to be available, so it's open arrays all the time, with three > > additional > > words each. > > > > If you can pack a union of a pointer and an integer into a word and > > can separate them with runtime checks, then you can use the > > separated integer any way you want, with bit twiddling, type > > conversions, > > LOOPHOLE, or whatever. That is what I am trying to get, not just > > Smalltalk-like integers. > > Note that Smalltalk has zero static typing, so only one internal > > representation must do for the union of all possible values in > > the language. In Modula-3, it would be very inconsistent with > > the language's philosophy to be this restricted. > >> Hmm, so your idea is to statically determine what type the references > >> can have if they are non-references. So you are thinking to put > >> various > >> kinds of subranges into the "TAGGED" types. But you have to be > >> able to > >> determine, statically, which subrange it is... am I understanding > >> this > >> correctly? > >> > > > > From the language, all I want is to be able to dynamically determine > > whether it is a true pointer to a heap object or a value stored > > directly in the word, while preserving the safety principles and > > the semantics of everything already there. So I want some new > > types, different from any existing types, that statically are known > > to hold this kind of valueset union and can be converted/assigned > > to a variable of existing type that is statically known to be either a > > pointer or an integer (but not both), with a suitable runtime check. > > It is also necessary to have a way to do this without risking a > > runtime > > error, if your code doesn't know yet which kind of value it has. > > Various ADT modules can take it from there. > >> Mika > >> > >> "Rodney M. Bates" writes: > >> > >>> Tony Hosking wrote: > >>> > >>>> On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: > >>>> > >>>> > >>>>> Mika Nystrom wrote: > >>>>> > >>>>>> Hendrik, I think Tony's and my arguments that you can't break any > >>>>>> existing code by allowing the squirreling away of integers into > >>>>>> REFANYs are pretty solid. Pre-existing code simply can't do > >>>>>> anything > >>>>>> useful with unrevealed REFANYs. > >>>>>> > >>>>> This is only true of _unrevealed opaque subtypes_ of REFANY, > >>>>> not of REFANY itself. There is lots of existing code that uses > >>>>> REFANY, > >>>>> and there, ISTYPE, NARROW, TYPECASE, and assigment can be and > >>>>> regularly are used on it. It is essential not to alter the > >>>>> semantics there. > >>>>> > >>>> Pre-existing code won't be able to do anything useful with tagged > >>>> REFANYs: > >>>> > >>>> Suppose we have > >>>> > >>>> VAR r: REFANY = SmallInteger.FromInt(0); > >>>> > >>>> then > >>>> > >>>> ISTYPE(r, REFANY) => TRUE > >>>> ISTYPE(r, T) => FALSE for any T # REFANY > >>>> > >>>> Similarly, for TYPECASE, r will only trigger the REFANY branch. > >>>> > >>>> NARROW(r, REFANY) => r > >>>> NARROW(r, T) => run-time error for any T #REFANY > >>>> > >>>> VAR x: REFANY => assignment succeeds > >>>> VAR x: T := r => run-time error for any T # REFANY (because of > >>>> implicit NARROW) > >>>> > >>> I think I am getting a bit lost in all the proposals, variations, > >>> counterproposals, etc., but > >>> > >> >from this argument I am inferring that your plan is that only > >> variables > >>> declared REFANY > >>> and not any proper subtype of REFANY can ever have a value with a > >>> tag bit set? Then > >>> the 4 narrowing operations, when and only when applied to an > >>> expression of static > >>> type REFANY, would change to make a runtime check for a tag bit > >>> and fail if it's set? > >>> It would take this to prevent a tagged value from getting into a > >>> variable declared a > >>> proper subtype of REFANY, which can be dereferenced. > >>> > >>> This would preclude making your abstract data type an opaque > >>> subtype of REFANY, > >>> and would mean all supposedly unrelated ADT modules that used the > >>> tag technique > >>> could be broken by client code that mixed up the REFANY values of > >>> one of them with > >>> those of another. I consider this a definite breach of Modula-3's > >>> otherwise bulletproof > >>> type safety. > >>>> It is impossible to dereference an expression statically typed as > >>>> REFANY, so there is no need for a "tagged" check on dereference. > >>>> Because a tagged REFANY cannot be assigned to anything other than > >>>> something typed REFANY, it can never propagate to a place where > >>>> it can be dereferenced. > >>>> > >>>> > >>>>> Aside from actual semantic changes, I agree with Tony that we > >>>>> should > >>>>> not burden any existing type with additional runtime work. Even > >>>>> though > >>>>> I expect small objects to support big performance gains in certain > >>>>> important cases, non-tagged references will still greatly > >>>>> predominate > >>>>> in most code. Create new type(s) for tagged references. > >>>>> > >>>> I'm not sure that we are seeing any semantic changes at all. And > >>>> with Mika's definition of SmallInteger.T as a "boxed" INTEGER > >>>> object (actually it would be a subrange for values that fit into > >>>> BITSIZE(Word.T)-1 bits), it is essentially transparent. It just > >>>> happens to be a run-time optimization that unboxes the INTEGER > >>>> value. > >>>> > >>>> > >>>> I think I can implement the compiler and run-time support for > >>>> this very quickly. > >>>> > >>>> > >>>> > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Apr 9 13:55:39 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 9 Apr 2009 07:55:39 -0400 Subject: [M3devel] small objects In-Reply-To: References: <200904090038.n390cNsg097270@camembert.async.caltech.edu> <49DD59DB.4050404@cox.net> <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> <6DADF96B-7A17-45E8-8084-48A66372ED2D@cs.purdue.edu> Message-ID: <20090409115539.GA12685@topoi.pooq.com> On Thu, Apr 09, 2009 at 05:36:49AM +0000, Jay wrote: > > The heap allocation and pressure on the garbage collector -- such a small struct is reasonably efficient to pass around by value. > Generalizing: So one thing wanted is disjoint unions, like the ones Algol 68 has. The advantage of this and types with multiple subtypes is the lack of reference overhead. This suggests that if I ever get around to data structure optimisation in my Algol 68 compiler, I should implement unions between small data types and references to aligned data by the low-order bit method. And this provided an implementation technique for compact pointer/integer punning that works on machines where all bit patterns are valid object pointers. (Are there still any of these around? The last one I used was a CDC CYBER in the 70's) -- hendrik > > > - Jay > > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Thu, 9 Apr 2009 14:22:52 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] small objects > > > > > I don't know what you are saving over just allocating: > > > NEW(OBJECT i: INTEGER END) > NEW(OBJECT r: REFANY END) > > > Each is only 2 words: one for the object header and the other for the value > > > - Jay From mika at async.caltech.edu Thu Apr 9 16:10:44 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 09 Apr 2009 07:10:44 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Thu, 09 Apr 2009 13:01:13 +1000." <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> Message-ID: <200904091410.n39EAiQ4028393@camembert.async.caltech.edu> I don't know why we're having such a tough time understanding each other here :-) I think that what Rodney says is that he wants (in pseudo-modula-2 syntax): T = CASE LSB OF 1 : SmallInt | 0 : U END; SmallInt = [SmallMin..SmallMax]; for any reference type U. That is what TAGGED U would mean, no? Maybe it should be called INTUNION U or INTVARIANT U And then he wants to be able to have just U as well (so it's optional). I.e., no type safety for the SmallInt (beyond the fact that it range checks etc), but the full range of Modula-3 reference types and type checking if it's a reference. The only problem I have with this (except for the changes necessary to Modula-3) is that it can't be held in a REFANY, and that's part of the design. Of course we could go halfway and let it be held in a REFANY, but then you get the runtime LSB check again, for all instances of REFANY, but maybe it doesn't break anything else. Although you do in any case get LSB checks all over the place (in safe code!) where the TAGGED U is revealed to be a TAGGED U. Note that, as we probably all know, the Modula-3 designers expressly considered, and rejected, full variant records. Mika Tony Hosking writes: >Sounds like you want something like: > >TAGGED REFANY FOR T > >where T must be a type that fits into BITS(REFANY)-1? > >Branding could be used to prevent mixing otherwise structurally >equivalent TAGGED REFANY. > >TAGGED BRANDED REFANY FOR T > >Where this breaks down is what are the subtyping rules, since I assume >you'd like to store these in a REFANY and dynamically test for the >appropriate tagged type: > >TAGGED REFANY FOR T <: REFANY > >But then how do we distinguish all the different TAGGED REFANY from >each other at run-time? > >On 9 Apr 2009, at 12:13, Rodney M. Bates wrote: > >> Mika Nystrom wrote: >>> Hmm, ok, there's one big difference between what you're saying and >>> what Tony and I have been talking about. (I think your understanding >>> sounds pretty correct.) >>> >>> You want to do objects other than small integers. Like what? And >>> why? >>> I was thinking the trick would apply only to one specific type of >>> integer. >> >> >> Yes, I want a language mechanism that can be used by various >> modules to implement various abstract data types, each of which >> can perform the sometimes dramatic space optimization of putting >> values that are common and will fit directly in the word. >> One module I spoke of implements general sets of integers with >> dynamically variable and sometimes large range. This differs from >> the builtin SET OF.., which must have a static (and probably >> relatively >> small) base subrange. Thus the general, heap-allocated values contain >> open arrays of Word.T, treated as sets, or if you prefer, packed >> arrays >> of booleans, although I manipulate them with bit-twiddling operations >> from Word. >> There is another, static-sized, heap-allocated object in front of >> each array, >> containing biases on what bits correspond to what integers in the >> abstract set, etc. It all works fine now, but the usage pattern of >> some >> clients has a high percentage very small sets that would fit in a >> word, >> and there would be an 11-to-1 space savings if that could be done. >> BTW, there are also two different kinds of heap objects, one that >> represents a range set by just its bounds. So I am TYPECASEing >> these already. It would be very convenient if I could just add >> another >> alternative to the TYPECASE for in-word values. >> >> In another case, I need truly dynamically variable sized arrays of >> integers in [0..15], and the great majority are 7 elements or less, >> which would fit directly in the word, but I still the need full >> generality >> to be available, so it's open arrays all the time, with three >> additional >> words each. >> >> If you can pack a union of a pointer and an integer into a word and >> can separate them with runtime checks, then you can use the >> separated integer any way you want, with bit twiddling, type >> conversions, >> LOOPHOLE, or whatever. That is what I am trying to get, not just >> Smalltalk-like integers. >> Note that Smalltalk has zero static typing, so only one internal >> representation must do for the union of all possible values in >> the language. In Modula-3, it would be very inconsistent with >> the language's philosophy to be this restricted. >>> Hmm, so your idea is to statically determine what type the references >>> can have if they are non-references. So you are thinking to put >>> various >>> kinds of subranges into the "TAGGED" types. But you have to be >>> able to >>> determine, statically, which subrange it is... am I understanding >>> this >>> correctly? >>> >> >> From the language, all I want is to be able to dynamically determine >> whether it is a true pointer to a heap object or a value stored >> directly in the word, while preserving the safety principles and >> the semantics of everything already there. So I want some new >> types, different from any existing types, that statically are known >> to hold this kind of valueset union and can be converted/assigned >> to a variable of existing type that is statically known to be either a >> pointer or an integer (but not both), with a suitable runtime check. >> It is also necessary to have a way to do this without risking a >> runtime >> error, if your code doesn't know yet which kind of value it has. >> Various ADT modules can take it from there. >>> Mika >>> >>> "Rodney M. Bates" writes: >>> >>>> Tony Hosking wrote: >>>> >>>>> On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: >>>>> >>>>> >>>>>> Mika Nystrom wrote: >>>>>> >>>>>>> Hendrik, I think Tony's and my arguments that you can't break any >>>>>>> existing code by allowing the squirreling away of integers into >>>>>>> REFANYs are pretty solid. Pre-existing code simply can't do >>>>>>> anything >>>>>>> useful with unrevealed REFANYs. >>>>>>> >>>>>> This is only true of _unrevealed opaque subtypes_ of REFANY, >>>>>> not of REFANY itself. There is lots of existing code that uses >>>>>> REFANY, >>>>>> and there, ISTYPE, NARROW, TYPECASE, and assigment can be and >>>>>> regularly are used on it. It is essential not to alter the >>>>>> semantics there. >>>>>> >>>>> Pre-existing code won't be able to do anything useful with tagged >>>>> REFANYs: >>>>> >>>>> Suppose we have >>>>> >>>>> VAR r: REFANY = SmallInteger.FromInt(0); >>>>> >>>>> then >>>>> >>>>> ISTYPE(r, REFANY) => TRUE >>>>> ISTYPE(r, T) => FALSE for any T # REFANY >>>>> >>>>> Similarly, for TYPECASE, r will only trigger the REFANY branch. >>>>> >>>>> NARROW(r, REFANY) => r >>>>> NARROW(r, T) => run-time error for any T #REFANY >>>>> >>>>> VAR x: REFANY => assignment succeeds >>>>> VAR x: T := r => run-time error for any T # REFANY (because of >>>> implicit NARROW) >>>>> >>>> I think I am getting a bit lost in all the proposals, variations, >>>> counterproposals, etc., but >>>> >>> >from this argument I am inferring that your plan is that only >>> variables >>>> declared REFANY >>>> and not any proper subtype of REFANY can ever have a value with a >>>> tag bit set? Then >>>> the 4 narrowing operations, when and only when applied to an >>>> expression of static >>>> type REFANY, would change to make a runtime check for a tag bit >>>> and fail if it's set? >>>> It would take this to prevent a tagged value from getting into a >>>> variable declared a >>>> proper subtype of REFANY, which can be dereferenced. >>>> >>>> This would preclude making your abstract data type an opaque >>>> subtype of REFANY, >>>> and would mean all supposedly unrelated ADT modules that used the >>>> tag technique >>>> could be broken by client code that mixed up the REFANY values of >>>> one of them with >>>> those of another. I consider this a definite breach of Modula-3's >>>> otherwise bulletproof >>>> type safety. >>>>> It is impossible to dereference an expression statically typed as >>>>> REFANY, so there is no need for a "tagged" check on dereference. >>>>> Because a tagged REFANY cannot be assigned to anything other than >>>>> something typed REFANY, it can never propagate to a place where >>>>> it can be dereferenced. >>>>> >>>>> >>>>>> Aside from actual semantic changes, I agree with Tony that we >>>>>> should >>>>>> not burden any existing type with additional runtime work. Even >>>>>> though >>>>>> I expect small objects to support big performance gains in certain >>>>>> important cases, non-tagged references will still greatly >>>>>> predominate >>>>>> in most code. Create new type(s) for tagged references. >>>>>> >>>>> I'm not sure that we are seeing any semantic changes at all. And >>>>> with Mika's definition of SmallInteger.T as a "boxed" INTEGER >>>>> object (actually it would be a subrange for values that fit into >>>>> BITSIZE(Word.T)-1 bits), it is essentially transparent. It just >>>>> happens to be a run-time optimization that unboxes the INTEGER >>>>> value. >>>>> >>>>> >>>>> I think I can implement the compiler and run-time support for >>>>> this very quickly. >>>>> >>>>> >>>>> >>> >>> From mika at async.caltech.edu Thu Apr 9 16:13:38 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 09 Apr 2009 07:13:38 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Thu, 09 Apr 2009 03:59:02 -0000." Message-ID: <200904091413.n39EDcjV028497@camembert.async.caltech.edu> Well the point of what I was suggesting, anyhow, was that it would be very nice to store an integer in a REFANY. A REFANY is only a single word, and I don't think it's practical to expand it to two words. Certainly no more so than requiring an LSB check for certain (hopefully relatively rare) operations on REFANY... Mika Jay writes: >--_a0534b8e-9f94-40d7-a78a-5bfcfeb668e5_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Um=2C what do folks think of=2C like: > >=20 > >struct > >{ > void* Type=3B > > union > > { > size_t Integer=3B > > void* Pointer=3B > > } Value=3B > >} Variant=3B > >=20 > >? > >You know -- something that is two pointers=2C one pointer for the type=2C o= >ne for the value or integer? > >void* Type would actually be a pointer to something actually defined and el= >aborate. > >=20 > >Obviously this is twice as large=2C not as small as it could be=2C but much= > more general and portable. No need to determine how many of bits can be th= >e tag. > >=20 > >And hope/assume for perf that such a small struct is passed in registers. > >On x86/NT 4 and 8 byte structs I think are. > >=20 > >Type could also be an integer=2C index into some table=2C with some predefi= >ned values. > >#define TYPE_INTEGER 0 > >#define TYPE_FLOAT 1 > >#define TYPE_DOUBLE 2 > >#define TYPE_ADDRESS 3 > >=20 > >more generally the union would have a float=2C and maybe a double on 64bit = >platforms. > >=20 > >OR=2C on 64bit platforms=2C you probably can=2C with some porting work=2C d= >edicate a whole 8 bits or so to a type index=2C and still the thing in one = >"word". How many bits of address space does any 64bit platform these days o= >r forseeable future actually implement? > >=20 > >But 32 bits doesn't seem big enough to afford that=2C and still this is a p= >ortability problem -- anything less than a full pointer. > >=20 > > - Jay > >=20 >> From: hosking at cs.purdue.edu >> To: rodney.m.bates at cox.net >> Date: Thu=2C 9 Apr 2009 13:01:13 +1000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] small objects >>=20 >> Sounds like you want something like: >>=20 >> TAGGED REFANY FOR T >>=20 >> where T must be a type that fits into BITS(REFANY)-1? >>=20 >> Branding could be used to prevent mixing otherwise structurally=20 >> equivalent TAGGED REFANY. >>=20 >> TAGGED BRANDED REFANY FOR T >>=20 >> Where this breaks down is what are the subtyping rules=2C since I assume= >=20 >> you'd like to store these in a REFANY and dynamically test for the=20 >> appropriate tagged type: >>=20 >> TAGGED REFANY FOR T <: REFANY >>=20 >> But then how do we distinguish all the different TAGGED REFANY from=20 >> each other at run-time? >>=20 >> On 9 Apr 2009=2C at 12:13=2C Rodney M. Bates wrote: >>=20 >> > Mika Nystrom wrote: >> >> Hmm=2C ok=2C there's one big difference between what you're saying and >> >> what Tony and I have been talking about. (I think your understanding >> >> sounds pretty correct.) >> >> >> >> You want to do objects other than small integers. Like what? And=20 >> >> why? >> >> I was thinking the trick would apply only to one specific type of=20 >> >> integer. >> >> >> > >> > Yes=2C I want a language mechanism that can be used by various >> > modules to implement various abstract data types=2C each of which >> > can perform the sometimes dramatic space optimization of putting >> > values that are common and will fit directly in the word. >> > One module I spoke of implements general sets of integers with >> > dynamically variable and sometimes large range. This differs from >> > the builtin SET OF..=2C which must have a static (and probably=20 >> > relatively >> > small) base subrange. Thus the general=2C heap-allocated values contain >> > open arrays of Word.T=2C treated as sets=2C or if you prefer=2C packed= >=20 >> > arrays >> > of booleans=2C although I manipulate them with bit-twiddling operations >> > from Word. >> > There is another=2C static-sized=2C heap-allocated object in front of=20 >> > each array=2C >> > containing biases on what bits correspond to what integers in the >> > abstract set=2C etc. It all works fine now=2C but the usage pattern of= >=20 >> > some >> > clients has a high percentage very small sets that would fit in a=20 >> > word=2C >> > and there would be an 11-to-1 space savings if that could be done. >> > BTW=2C there are also two different kinds of heap objects=2C one that >> > represents a range set by just its bounds. So I am TYPECASEing >> > these already. It would be very convenient if I could just add=20 >> > another >> > alternative to the TYPECASE for in-word values. >> > >> > In another case=2C I need truly dynamically variable sized arrays of >> > integers in [0..15]=2C and the great majority are 7 elements or less=2C >> > which would fit directly in the word=2C but I still the need full=20 >> > generality >> > to be available=2C so it's open arrays all the time=2C with three=20 >> > additional >> > words each. >> > >> > If you can pack a union of a pointer and an integer into a word and >> > can separate them with runtime checks=2C then you can use the >> > separated integer any way you want=2C with bit twiddling=2C type=20 >> > conversions=2C >> > LOOPHOLE=2C or whatever. That is what I am trying to get=2C not just >> > Smalltalk-like integers. >> > Note that Smalltalk has zero static typing=2C so only one internal >> > representation must do for the union of all possible values in >> > the language. In Modula-3=2C it would be very inconsistent with >> > the language's philosophy to be this restricted. >> >> Hmm=2C so your idea is to statically determine what type the reference= >s >> >> can have if they are non-references. So you are thinking to put=20 >> >> various >> >> kinds of subranges into the "TAGGED" types. But you have to be=20 >> >> able to >> >> determine=2C statically=2C which subrange it is... am I understanding= >=20 >> >> this >> >> correctly? >> >> >> > >> > From the language=2C all I want is to be able to dynamically determine >> > whether it is a true pointer to a heap object or a value stored >> > directly in the word=2C while preserving the safety principles and >> > the semantics of everything already there. So I want some new >> > types=2C different from any existing types=2C that statically are known >> > to hold this kind of valueset union and can be converted/assigned >> > to a variable of existing type that is statically known to be either a >> > pointer or an integer (but not both)=2C with a suitable runtime check. >> > It is also necessary to have a way to do this without risking a=20 >> > runtime >> > error=2C if your code doesn't know yet which kind of value it has. >> > Various ADT modules can take it from there. >> >> Mika >> >> >> >> "Rodney M. Bates" writes: >> >> >> >>> Tony Hosking wrote: >> >>> >> >>>> On 8 Apr 2009=2C at 11:49=2C Rodney M. Bates wrote: >> >>>> >> >>>> >> >>>>> Mika Nystrom wrote: >> >>>>> >> >>>>>> Hendrik=2C I think Tony's and my arguments that you can't break an= >y >> >>>>>> existing code by allowing the squirreling away of integers into >> >>>>>> REFANYs are pretty solid. Pre-existing code simply can't do=20 >> >>>>>> anything >> >>>>>> useful with unrevealed REFANYs. >> >>>>>> >> >>>>> This is only true of _unrevealed opaque subtypes_ of REFANY=2C >> >>>>> not of REFANY itself. There is lots of existing code that uses=20 >> >>>>> REFANY=2C >> >>>>> and there=2C ISTYPE=2C NARROW=2C TYPECASE=2C and assigment can be a= >nd >> >>>>> regularly are used on it. It is essential not to alter the=20 >> >>>>> semantics there. >> >>>>> >> >>>> Pre-existing code won't be able to do anything useful with tagged=20 >> >>>> REFANYs: >> >>>> >> >>>> Suppose we have >> >>>> >> >>>> VAR r: REFANY =3D SmallInteger.FromInt(0)=3B >> >>>> >> >>>> then >> >>>> >> >>>> ISTYPE(r=2C REFANY) =3D> TRUE >> >>>> ISTYPE(r=2C T) =3D> FALSE for any T # REFANY >> >>>> >> >>>> Similarly=2C for TYPECASE=2C r will only trigger the REFANY branch. >> >>>> >> >>>> NARROW(r=2C REFANY) =3D> r >> >>>> NARROW(r=2C T) =3D> run-time error for any T #REFANY >> >>>> >> >>>> VAR x: REFANY =3D> assignment succeeds >> >>>> VAR x: T :=3D r =3D> run-time error for any T # REFANY (because of=20 >> >>>> implicit NARROW) >> >>>> >> >>> I think I am getting a bit lost in all the proposals=2C variations=2C= >=20 >> >>> counterproposals=2C etc.=2C but >> >>> >> >> >from this argument I am inferring that your plan is that only=20 >> >> variables >> >>> declared REFANY >> >>> and not any proper subtype of REFANY can ever have a value with a=20 >> >>> tag bit set? Then >> >>> the 4 narrowing operations=2C when and only when applied to an=20 >> >>> expression of static >> >>> type REFANY=2C would change to make a runtime check for a tag bit=20 >> >>> and fail if it's set? >> >>> It would take this to prevent a tagged value from getting into a=20 >> >>> variable declared a >> >>> proper subtype of REFANY=2C which can be dereferenced. >> >>> >> >>> This would preclude making your abstract data type an opaque=20 >> >>> subtype of REFANY=2C >> >>> and would mean all supposedly unrelated ADT modules that used the=20 >> >>> tag technique >> >>> could be broken by client code that mixed up the REFANY values of=20 >> >>> one of them with >> >>> those of another. I consider this a definite breach of Modula-3's=20 >> >>> otherwise bulletproof >> >>> type safety. >> >>>> It is impossible to dereference an expression statically typed as=20 >> >>>> REFANY=2C so there is no need for a "tagged" check on dereference. >> >>>> Because a tagged REFANY cannot be assigned to anything other than=20 >> >>>> something typed REFANY=2C it can never propagate to a place where=20 >> >>>> it can be dereferenced. >> >>>> >> >>>> >> >>>>> Aside from actual semantic changes=2C I agree with Tony that we=20 >> >>>>> should >> >>>>> not burden any existing type with additional runtime work. Even=20 >> >>>>> though >> >>>>> I expect small objects to support big performance gains in certain >> >>>>> important cases=2C non-tagged references will still greatly=20 >> >>>>> predominate >> >>>>> in most code. Create new type(s) for tagged references. >> >>>>> >> >>>> I'm not sure that we are seeing any semantic changes at all. And=20 >> >>>> with Mika's definition of SmallInteger.T as a "boxed" INTEGER=20 >> >>>> object (actually it would be a subrange for values that fit into=20 >> >>>> BITSIZE(Word.T)-1 bits)=2C it is essentially transparent. It just=20 >> >>>> happens to be a run-time optimization that unboxes the INTEGER=20 >> >>>> value. >> >>>> >> >>>> >> >>>> I think I can implement the compiler and run-time support for=20 >> >>>> this very quickly. >> >>>> >> >>>> >> >>>> >> >> >> >> >>=20 > >--_a0534b8e-9f94-40d7-a78a-5bfcfeb668e5_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Um=2C what do folks think of=2C like:
> =3B
>struct
>{
 =3B =3B =3B void* Type=3B
> =3B =3B =3B union
> =3B =3B =3B {
 =3B =3B =3B =3B =3B = >=3B size_t =3BInteger=3B
> =3B =3B =3B =3B =3B =3B void* Pointer=3B
> =3B =3B =3B =3B } Value=3B
>} =3BVariant=3B
> =3B
>?
>You know -- something that is two pointers=2C one pointer for the type=2C o= >ne for the value or integer?
>void* Type would actually be a pointer to something actually defined and el= >aborate.
> =3B
>Obviously this is twice as large=2C not as small as it could be=2C but much= > more general and portable. No need to determine how many of bits can be th= >e tag.
> =3B
>And hope/assume for perf that such a small struct is passed in registers.R> >On x86/NT 4 and 8 byte structs I think are.
> =3B
>Type could also be an integer=2C index into some table=2C with some predefi= >ned values.
>#define TYPE_INTEGER 0
>#define TYPE_FLOAT 1
>#define TYPE_DOUBLE 2
>#define TYPE_ADDRESS 3
> =3B
>more generally the union would have a float=2C and maybe a double on 64bit = >platforms.
> =3B
>OR=2C on 64bit platforms=2C you probably can=2C with some porting work=2C d= >edicate a whole 8 bits or so to a type index=2C and still the thing in one = >"word". How many bits of address space does any 64bit platform these days o= >r forseeable future actually implement?
> =3B
>But 32 bits doesn't seem big enough to afford that=2C and still this is a p= >ortability problem -- anything less than a full pointer.
> =3B
> =3B- Jay

 =3B
>=3B From: hosking at cs.purdue.edu
>= >=3B To: rodney.m.bates at cox.net
>=3B Date: Thu=2C 9 Apr 2009 13:01:13 += >1000
>=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] s= >mall objects
>=3B
>=3B Sounds like you want something like:
&= >gt=3B
>=3B TAGGED REFANY FOR T
>=3B
>=3B where T must be a= > type that fits into BITS(REFANY)-1?
>=3B
>=3B Branding could be= > used to prevent mixing otherwise structurally
>=3B equivalent TAGGED= > REFANY.
>=3B
>=3B TAGGED BRANDED REFANY FOR T
>=3B
>= >=3B Where this breaks down is what are the subtyping rules=2C since I assum= >e
>=3B you'd like to store these in a REFANY and dynamically test for= > the
>=3B appropriate tagged type:
>=3B
>=3B TAGGED REFANY= > FOR T <=3B: REFANY
>=3B
>=3B But then how do we distinguish a= >ll the different TAGGED REFANY from
>=3B each other at run-time?
&= >gt=3B
>=3B On 9 Apr 2009=2C at 12:13=2C Rodney M. Bates wrote:
>= >=3B
>=3B >=3B Mika Nystrom wrote:
>=3B >=3B>=3B Hmm=2C ok= >=2C there's one big difference between what you're saying and
>=3B >= >=3B>=3B what Tony and I have been talking about. (I think your understand= >ing
>=3B >=3B>=3B sounds pretty correct.)
>=3B >=3B>=3BR>>=3B >=3B>=3B You want to do objects other than small integers. Lik= >e what? And
>=3B >=3B>=3B why?
>=3B >=3B>=3B I was think= >ing the trick would apply only to one specific type of
>=3B >=3B>= >=3B integer.
>=3B >=3B>=3B
>=3B >=3B
>=3B >=3B Yes= >=2C I want a language mechanism that can be used by various
>=3B >= >=3B modules to implement various abstract data types=2C each of which
&g= >t=3B >=3B can perform the sometimes dramatic space optimization of puttin= >g
>=3B >=3B values that are common and will fit directly in the word= >.
>=3B >=3B One module I spoke of implements general sets of integer= >s with
>=3B >=3B dynamically variable and sometimes large range. Thi= >s differs from
>=3B >=3B the builtin SET OF..=2C which must have a s= >tatic (and probably
>=3B >=3B relatively
>=3B >=3B small) ba= >se subrange. Thus the general=2C heap-allocated values contain
>=3B &g= >t=3B open arrays of Word.T=2C treated as sets=2C or if you prefer=2C packed= >
>=3B >=3B arrays
>=3B >=3B of booleans=2C although I manipu= >late them with bit-twiddling operations
>=3B >=3B from Word.
>= >=3B >=3B There is another=2C static-sized=2C heap-allocated object in fro= >nt of
>=3B >=3B each array=2C
>=3B >=3B containing biases on= > what bits correspond to what integers in the
>=3B >=3B abstract set= >=2C etc. It all works fine now=2C but the usage pattern of
>=3B >= >=3B some
>=3B >=3B clients has a high percentage very small sets tha= >t would fit in a
>=3B >=3B word=2C
>=3B >=3B and there would= > be an 11-to-1 space savings if that could be done.
>=3B >=3B BTW=2C= > there are also two different kinds of heap objects=2C one that
>=3B &= >gt=3B represents a range set by just its bounds. So I am TYPECASEing
>= >=3B >=3B these already. It would be very convenient if I could just add <= >BR>>=3B >=3B another
>=3B >=3B alternative to the TYPECASE for i= >n-word values.
>=3B >=3B
>=3B >=3B In another case=2C I need = >truly dynamically variable sized arrays of
>=3B >=3B integers in [0.= >.15]=2C and the great majority are 7 elements or less=2C
>=3B >=3B w= >hich would fit directly in the word=2C but I still the need full
>=3B= > >=3B generality
>=3B >=3B to be available=2C so it's open arrays = >all the time=2C with three
>=3B >=3B additional
>=3B >=3B wo= >rds each.
>=3B >=3B
>=3B >=3B If you can pack a union of a po= >inter and an integer into a word and
>=3B >=3B can separate them wit= >h runtime checks=2C then you can use the
>=3B >=3B separated integer= > any way you want=2C with bit twiddling=2C type
>=3B >=3B conversio= >ns=2C
>=3B >=3B LOOPHOLE=2C or whatever. That is what I am trying to= > get=2C not just
>=3B >=3B Smalltalk-like integers.
>=3B >=3B= > Note that Smalltalk has zero static typing=2C so only one internal
>= >=3B >=3B representation must do for the union of all possible values inR>>=3B >=3B the language. In Modula-3=2C it would be very inconsistent = >with
>=3B >=3B the language's philosophy to be this restricted.
&= >gt=3B >=3B>=3B Hmm=2C so your idea is to statically determine what type= > the references
>=3B >=3B>=3B can have if they are non-references.= > So you are thinking to put
>=3B >=3B>=3B various
>=3B >= >=3B>=3B kinds of subranges into the "TAGGED" types. But you have to be R>>=3B >=3B>=3B able to
>=3B >=3B>=3B determine=2C staticall= >y=2C which subrange it is... am I understanding
>=3B >=3B>=3B thi= >s
>=3B >=3B>=3B correctly?
>=3B >=3B>=3B
>=3B >=3B= >
>=3B >=3B From the language=2C all I want is to be able to dynamica= >lly determine
>=3B >=3B whether it is a true pointer to a heap objec= >t or a value stored
>=3B >=3B directly in the word=2C while preservi= >ng the safety principles and
>=3B >=3B the semantics of everything a= >lready there. So I want some new
>=3B >=3B types=2C different from a= >ny existing types=2C that statically are known
>=3B >=3B to hold thi= >s kind of valueset union and can be converted/assigned
>=3B >=3B to = >a variable of existing type that is statically known to be either a
>= >=3B >=3B pointer or an integer (but not both)=2C with a suitable runtime = >check.
>=3B >=3B It is also necessary to have a way to do this witho= >ut risking a
>=3B >=3B runtime
>=3B >=3B error=2C if your co= >de doesn't know yet which kind of value it has.
>=3B >=3B Various AD= >T modules can take it from there.
>=3B >=3B>=3B Mika
>=3B >= >=3B>=3B
>=3B >=3B>=3B "Rodney M. Bates" writes:
>=3B >=3B= >>=3B
>=3B >=3B>=3B>=3B Tony Hosking wrote:
>=3B >=3B>= >=3B>=3B
>=3B >=3B>=3B>=3B>=3B On 8 Apr 2009=2C at 11:49=2C R= >odney M. Bates wrote:
>=3B >=3B>=3B>=3B>=3B
>=3B >=3B&g= >t=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B>=3B Mika Nystrom wrot= >e:
>=3B >=3B>=3B>=3B>=3B>=3B
>=3B >=3B>=3B>=3B>= >=3B>=3B>=3B Hendrik=2C I think Tony's and my arguments that you can't b= >reak any
>=3B >=3B>=3B>=3B>=3B>=3B>=3B existing code by al= >lowing the squirreling away of integers into
>=3B >=3B>=3B>=3B&g= >t=3B>=3B>=3B REFANYs are pretty solid. Pre-existing code simply can't d= >o
>=3B >=3B>=3B>=3B>=3B>=3B>=3B anything
>=3B >=3B= >>=3B>=3B>=3B>=3B>=3B useful with unrevealed REFANYs.
>=3B &g= >t=3B>=3B>=3B>=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B>=3B= > This is only true of _unrevealed opaque subtypes_ of REFANY=2C
>=3B &= >gt=3B>=3B>=3B>=3B>=3B not of REFANY itself. There is lots of existi= >ng code that uses
>=3B >=3B>=3B>=3B>=3B>=3B REFANY=2C
&g= >t=3B >=3B>=3B>=3B>=3B>=3B and there=2C ISTYPE=2C NARROW=2C TYPECA= >SE=2C and assigment can be and
>=3B >=3B>=3B>=3B>=3B>=3B reg= >ularly are used on it. It is essential not to alter the
>=3B >=3B&g= >t=3B>=3B>=3B>=3B semantics there.
>=3B >=3B>=3B>=3B>=3B&= >gt=3B
>=3B >=3B>=3B>=3B>=3B Pre-existing code won't be able to= > do anything useful with tagged
>=3B >=3B>=3B>=3B>=3B REFANYs= >:
>=3B >=3B>=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B Sup= >pose we have
>=3B >=3B>=3B>=3B>=3B
>=3B >=3B>=3B>= >=3B>=3B VAR r: REFANY =3D SmallInteger.FromInt(0)=3B
>=3B >=3B>= >=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B then
>=3B >=3B>= >=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B ISTYPE(r=2C REFANY) =3D&= >gt=3B TRUE
>=3B >=3B>=3B>=3B>=3B ISTYPE(r=2C T) =3D>=3B FALS= >E for any T # REFANY
>=3B >=3B>=3B>=3B>=3B
>=3B >=3B>= >=3B>=3B>=3B Similarly=2C for TYPECASE=2C r will only trigger the REFANY= > branch.
>=3B >=3B>=3B>=3B>=3B
>=3B >=3B>=3B>=3B>= >=3B NARROW(r=2C REFANY) =3D>=3B r
>=3B >=3B>=3B>=3B>=3B NARR= >OW(r=2C T) =3D>=3B run-time error for any T #REFANY
>=3B >=3B>= >=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B VAR x: REFANY =3D>=3B = >assignment succeeds
>=3B >=3B>=3B>=3B>=3B VAR x: T :=3D r =3D&= >gt=3B run-time error for any T # REFANY (because of
>=3B >=3B>=3B= >>=3B>=3B implicit NARROW)
>=3B >=3B>=3B>=3B>=3B
>=3B = >>=3B>=3B>=3B I think I am getting a bit lost in all the proposals=2C = >variations=2C
>=3B >=3B>=3B>=3B counterproposals=2C etc.=2C but= >
>=3B >=3B>=3B>=3B
>=3B >=3B>=3B >=3Bfrom this argume= >nt I am inferring that your plan is that only
>=3B >=3B>=3B varia= >bles
>=3B >=3B>=3B>=3B declared REFANY
>=3B >=3B>=3B>= >=3B and not any proper subtype of REFANY can ever have a value with a
&= >gt=3B >=3B>=3B>=3B tag bit set? Then
>=3B >=3B>=3B>=3B the= > 4 narrowing operations=2C when and only when applied to an
>=3B >= >=3B>=3B>=3B expression of static
>=3B >=3B>=3B>=3B type REFA= >NY=2C would change to make a runtime check for a tag bit
>=3B >=3B&= >gt=3B>=3B and fail if it's set?
>=3B >=3B>=3B>=3B It would tak= >e this to prevent a tagged value from getting into a
>=3B >=3B>= >=3B>=3B variable declared a
>=3B >=3B>=3B>=3B proper subtype o= >f REFANY=2C which can be dereferenced.
>=3B >=3B>=3B>=3B
>= >=3B >=3B>=3B>=3B This would preclude making your abstract data type a= >n opaque
>=3B >=3B>=3B>=3B subtype of REFANY=2C
>=3B >= >=3B>=3B>=3B and would mean all supposedly unrelated ADT modules that us= >ed the
>=3B >=3B>=3B>=3B tag technique
>=3B >=3B>=3B&g= >t=3B could be broken by client code that mixed up the REFANY values of
= >>=3B >=3B>=3B>=3B one of them with
>=3B >=3B>=3B>=3B tho= >se of another. I consider this a definite breach of Modula-3's
>=3B &= >gt=3B>=3B>=3B otherwise bulletproof
>=3B >=3B>=3B>=3B type s= >afety.
>=3B >=3B>=3B>=3B>=3B It is impossible to dereference a= >n expression statically typed as
>=3B >=3B>=3B>=3B>=3B REFANY= >=2C so there is no need for a "tagged" check on dereference.
>=3B >= >=3B>=3B>=3B>=3B Because a tagged REFANY cannot be assigned to anythin= >g other than
>=3B >=3B>=3B>=3B>=3B something typed REFANY=2C = >it can never propagate to a place where
>=3B >=3B>=3B>=3B>=3B= > it can be dereferenced.
>=3B >=3B>=3B>=3B>=3B
>=3B >= >=3B>=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B>=3B Aside from a= >ctual semantic changes=2C I agree with Tony that we
>=3B >=3B>=3B= >>=3B>=3B>=3B should
>=3B >=3B>=3B>=3B>=3B>=3B not burd= >en any existing type with additional runtime work. Even
>=3B >=3B&g= >t=3B>=3B>=3B>=3B though
>=3B >=3B>=3B>=3B>=3B>=3B I ex= >pect small objects to support big performance gains in certain
>=3B &g= >t=3B>=3B>=3B>=3B>=3B important cases=2C non-tagged references will = >still greatly
>=3B >=3B>=3B>=3B>=3B>=3B predominate
>= >=3B >=3B>=3B>=3B>=3B>=3B in most code. Create new type(s) for tag= >ged references.
>=3B >=3B>=3B>=3B>=3B>=3B
>=3B >=3B&g= >t=3B>=3B>=3B I'm not sure that we are seeing any semantic changes at al= >l. And
>=3B >=3B>=3B>=3B>=3B with Mika's definition of SmallI= >nteger.T as a "boxed" INTEGER
>=3B >=3B>=3B>=3B>=3B object (a= >ctually it would be a subrange for values that fit into
>=3B >=3B&g= >t=3B>=3B>=3B BITSIZE(Word.T)-1 bits)=2C it is essentially transparent. = >It just
>=3B >=3B>=3B>=3B>=3B happens to be a run-time optimi= >zation that unboxes the INTEGER
>=3B >=3B>=3B>=3B>=3B value.<= >BR>>=3B >=3B>=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B
&g= >t=3B >=3B>=3B>=3B>=3B I think I can implement the compiler and run-= >time support for
>=3B >=3B>=3B>=3B>=3B this very quickly.
= >>=3B >=3B>=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B
>= >=3B >=3B>=3B>=3B>=3B
>=3B >=3B>=3B
>=3B >=3B>=3B<= >BR>>=3B
>= > >--_a0534b8e-9f94-40d7-a78a-5bfcfeb668e5_-- From hendrik at topoi.pooq.com Thu Apr 9 16:34:40 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 9 Apr 2009 10:34:40 -0400 Subject: [M3devel] small objects In-Reply-To: <200904091410.n39EAiQ4028393@camembert.async.caltech.edu> References: <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> <200904091410.n39EAiQ4028393@camembert.async.caltech.edu> Message-ID: <20090409143440.GA13374@topoi.pooq.com> On Thu, Apr 09, 2009 at 07:10:44AM -0700, Mika Nystrom wrote: > I don't know why we're having such a tough time understanding each > other here :-) > > I think that what Rodney says is that he wants (in pseudo-modula-2 > syntax): > > T = CASE LSB OF > 1 : SmallInt > | > 0 : U > END; > > SmallInt = [SmallMin..SmallMax]; > > for any reference type U. Yes. That's what I wanted too, originally. I can accept the restriction that the reference type U might be restricted to be REFANY. > > That is what TAGGED U would mean, no? Maybe it should be called > INTUNION U or INTVARIANT U Or even UNION(SmallInt, U)? This would allow several variations on the theme if we were ever to want to go further along this route. But it would not require us to do so. > > And then he wants to be able to have just U as well (so it's > optional). > > I.e., no type safety for the SmallInt (beyond the fact that it > range checks etc), but the full range of Modula-3 reference > types and type checking if it's a reference. > > The only problem I have with this (except for the changes necessary > to Modula-3) is that it can't be held in a REFANY, and that's part > of the design. Much better not to pervert REFANY, but use a new type instead. > > Of course we could go halfway and let it be held in a REFANY, but > then you get the runtime LSB check again, for all instances of > REFANY, I really don't like requiriny a run-time check on REFANY. That's why I want it to be a separate type. > but maybe it doesn't break anything else. Although you do > in any case get LSB checks all over the place (in safe code!) where > the TAGGED U is revealed to be a TAGGED U. > > Note that, as we probably all know, the Modula-3 designers expressly > considered, and rejected, full variant records. Are these the factors they based their decision on? (1) The ones in Pascal are insecure without a lot of run-time checking. (2) Objects and inheritance take care of much of the functionality. (3) The ones in Algol 68 involve copying entire records when construction and deconstructing unions of records. What we're considering not is the case in which (2) provides excessive indirection and garbage-collector load, and in which the copying in (3) is really cheap. There are applications for which this feature could have major effects on efficiency. I have some I'd consider rewriting from C/C++ to Modula 3 if this feature were available. -- hendrik > > Mika > > > Tony Hosking writes: > >Sounds like you want something like: > > > >TAGGED REFANY FOR T > > > >where T must be a type that fits into BITS(REFANY)-1? > > > >Branding could be used to prevent mixing otherwise structurally > >equivalent TAGGED REFANY. > > > >TAGGED BRANDED REFANY FOR T > > > >Where this breaks down is what are the subtyping rules, since I assume > >you'd like to store these in a REFANY and dynamically test for the > >appropriate tagged type: > > > >TAGGED REFANY FOR T <: REFANY > > > >But then how do we distinguish all the different TAGGED REFANY from > >each other at run-time? > > > >On 9 Apr 2009, at 12:13, Rodney M. Bates wrote: > > > >> Mika Nystrom wrote: > >>> Hmm, ok, there's one big difference between what you're saying and > >>> what Tony and I have been talking about. (I think your understanding > >>> sounds pretty correct.) > >>> > >>> You want to do objects other than small integers. Like what? And > >>> why? > >>> I was thinking the trick would apply only to one specific type of > >>> integer. > >> > >> > >> Yes, I want a language mechanism that can be used by various > >> modules to implement various abstract data types, each of which > >> can perform the sometimes dramatic space optimization of putting > >> values that are common and will fit directly in the word. > >> One module I spoke of implements general sets of integers with > >> dynamically variable and sometimes large range. This differs from > >> the builtin SET OF.., which must have a static (and probably > >> relatively > >> small) base subrange. Thus the general, heap-allocated values contain > >> open arrays of Word.T, treated as sets, or if you prefer, packed > >> arrays > >> of booleans, although I manipulate them with bit-twiddling operations > >> from Word. > >> There is another, static-sized, heap-allocated object in front of > >> each array, > >> containing biases on what bits correspond to what integers in the > >> abstract set, etc. It all works fine now, but the usage pattern of > >> some > >> clients has a high percentage very small sets that would fit in a > >> word, > >> and there would be an 11-to-1 space savings if that could be done. > >> BTW, there are also two different kinds of heap objects, one that > >> represents a range set by just its bounds. So I am TYPECASEing > >> these already. It would be very convenient if I could just add > >> another > >> alternative to the TYPECASE for in-word values. > >> > >> In another case, I need truly dynamically variable sized arrays of > >> integers in [0..15], and the great majority are 7 elements or less, > >> which would fit directly in the word, but I still the need full > >> generality > >> to be available, so it's open arrays all the time, with three > >> additional > >> words each. > >> > >> If you can pack a union of a pointer and an integer into a word and > >> can separate them with runtime checks, then you can use the > >> separated integer any way you want, with bit twiddling, type > >> conversions, > >> LOOPHOLE, or whatever. That is what I am trying to get, not just > >> Smalltalk-like integers. > >> Note that Smalltalk has zero static typing, so only one internal > >> representation must do for the union of all possible values in > >> the language. In Modula-3, it would be very inconsistent with > >> the language's philosophy to be this restricted. > >>> Hmm, so your idea is to statically determine what type the references > >>> can have if they are non-references. So you are thinking to put > >>> various > >>> kinds of subranges into the "TAGGED" types. But you have to be > >>> able to > >>> determine, statically, which subrange it is... am I understanding > >>> this > >>> correctly? > >>> > >> > >> From the language, all I want is to be able to dynamically determine > >> whether it is a true pointer to a heap object or a value stored > >> directly in the word, while preserving the safety principles and > >> the semantics of everything already there. So I want some new > >> types, different from any existing types, that statically are known > >> to hold this kind of valueset union and can be converted/assigned > >> to a variable of existing type that is statically known to be either a > >> pointer or an integer (but not both), with a suitable runtime check. > >> It is also necessary to have a way to do this without risking a > >> runtime > >> error, if your code doesn't know yet which kind of value it has. > >> Various ADT modules can take it from there. > >>> Mika > >>> > >>> "Rodney M. Bates" writes: > >>> > >>>> Tony Hosking wrote: > >>>> > >>>>> On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: > >>>>> > >>>>> > >>>>>> Mika Nystrom wrote: > >>>>>> > >>>>>>> Hendrik, I think Tony's and my arguments that you can't break any > >>>>>>> existing code by allowing the squirreling away of integers into > >>>>>>> REFANYs are pretty solid. Pre-existing code simply can't do > >>>>>>> anything > >>>>>>> useful with unrevealed REFANYs. > >>>>>>> > >>>>>> This is only true of _unrevealed opaque subtypes_ of REFANY, > >>>>>> not of REFANY itself. There is lots of existing code that uses > >>>>>> REFANY, > >>>>>> and there, ISTYPE, NARROW, TYPECASE, and assigment can be and > >>>>>> regularly are used on it. It is essential not to alter the > >>>>>> semantics there. > >>>>>> > >>>>> Pre-existing code won't be able to do anything useful with tagged > >>>>> REFANYs: > >>>>> > >>>>> Suppose we have > >>>>> > >>>>> VAR r: REFANY = SmallInteger.FromInt(0); > >>>>> > >>>>> then > >>>>> > >>>>> ISTYPE(r, REFANY) => TRUE > >>>>> ISTYPE(r, T) => FALSE for any T # REFANY > >>>>> > >>>>> Similarly, for TYPECASE, r will only trigger the REFANY branch. > >>>>> > >>>>> NARROW(r, REFANY) => r > >>>>> NARROW(r, T) => run-time error for any T #REFANY > >>>>> > >>>>> VAR x: REFANY => assignment succeeds > >>>>> VAR x: T := r => run-time error for any T # REFANY (because of > >>>> implicit NARROW) > >>>>> > >>>> I think I am getting a bit lost in all the proposals, variations, > >>>> counterproposals, etc., but > >>>> > >>> >from this argument I am inferring that your plan is that only > >>> variables > >>>> declared REFANY > >>>> and not any proper subtype of REFANY can ever have a value with a > >>>> tag bit set? Then > >>>> the 4 narrowing operations, when and only when applied to an > >>>> expression of static > >>>> type REFANY, would change to make a runtime check for a tag bit > >>>> and fail if it's set? > >>>> It would take this to prevent a tagged value from getting into a > >>>> variable declared a > >>>> proper subtype of REFANY, which can be dereferenced. > >>>> > >>>> This would preclude making your abstract data type an opaque > >>>> subtype of REFANY, > >>>> and would mean all supposedly unrelated ADT modules that used the > >>>> tag technique > >>>> could be broken by client code that mixed up the REFANY values of > >>>> one of them with > >>>> those of another. I consider this a definite breach of Modula-3's > >>>> otherwise bulletproof > >>>> type safety. > >>>>> It is impossible to dereference an expression statically typed as > >>>>> REFANY, so there is no need for a "tagged" check on dereference. > >>>>> Because a tagged REFANY cannot be assigned to anything other than > >>>>> something typed REFANY, it can never propagate to a place where > >>>>> it can be dereferenced. > >>>>> > >>>>> > >>>>>> Aside from actual semantic changes, I agree with Tony that we > >>>>>> should > >>>>>> not burden any existing type with additional runtime work. Even > >>>>>> though > >>>>>> I expect small objects to support big performance gains in certain > >>>>>> important cases, non-tagged references will still greatly > >>>>>> predominate > >>>>>> in most code. Create new type(s) for tagged references. > >>>>>> > >>>>> I'm not sure that we are seeing any semantic changes at all. And > >>>>> with Mika's definition of SmallInteger.T as a "boxed" INTEGER > >>>>> object (actually it would be a subrange for values that fit into > >>>>> BITSIZE(Word.T)-1 bits), it is essentially transparent. It just > >>>>> happens to be a run-time optimization that unboxes the INTEGER > >>>>> value. > >>>>> > >>>>> > >>>>> I think I can implement the compiler and run-time support for > >>>>> this very quickly. > >>>>> > >>>>> > >>>>> > >>> > >>> From mika at async.caltech.edu Thu Apr 9 17:27:11 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 09 Apr 2009 08:27:11 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Thu, 09 Apr 2009 10:34:40 EDT." <20090409143440.GA13374@topoi.pooq.com> Message-ID: <200904091527.n39FRBF0031475@camembert.async.caltech.edu> hendrik at topoi.pooq.com writes: >On Thu, Apr 09, 2009 at 07:10:44AM -0700, Mika Nystrom wrote: >> I don't know why we're having such a tough time understanding each >> other here :-) >> >> I think that what Rodney says is that he wants (in pseudo-modula-2 >> syntax): >> >> T = CASE LSB OF >> 1 : SmallInt >> | >> 0 : U >> END; >> >> SmallInt = [SmallMin..SmallMax]; >> >> for any reference type U. > >Yes. That's what I wanted too, originally. I can accept the >restriction that the reference type U might be restricted to be >REFANY. I think this is what Tony says he's implemented, essentially... ... >> >> The only problem I have with this (except for the changes necessary >> to Modula-3) is that it can't be held in a REFANY, and that's part >> of the design. > >Much better not to pervert REFANY, but use a new type instead. Are you sure? I want a type---some type---that can hold "any reference, even a tagged one", and I would rewrite most library code that today takes REFANY to take that instead. Why not? Why would I want to limit it to REFANY when it performs no operations that couldn't legally be performed on TAGGED REFANY. > >> >> Of course we could go halfway and let it be held in a REFANY, but >> then you get the runtime LSB check again, for all instances of >> REFANY, > >I really don't like requiriny a run-time check on REFANY. That's why >I want it to be a separate type. All the operations in question already require (*much* more complicated) run-time checks on REFANY.... and most uses of REFANY still wouldn't require the LSB check. I really think the runtime issue is a non-issue, and as I said above, if it turns out to be a real issue, one can either abandon the change (since the whole thing can be implemented transparently with a library) or else re-root ROOT and all the REF types in a new NOTQUITEREFANY type. This would be a backward-compatible change (in every sense) with Tony's runtime changes: REFANY ; (* Tony's, with the LSB trick *) NOTQUITEREFANY <: REFANY; ROOT <: NOTQUITEREFANY; REF T <: NOTQUITEREFANY; (* for all T *) After that, future, change, people who want to avoid the LSB check on REFANY can instead use NOTQUITEREFANY. I think barely anyone will bother. Come to think of it, Modula-3 doesn't specify that there's no intermediate type between REFANY and ROOT and the other REF T's, so there's no way it could break the current language. In fact you don't have to "reveal" this new type in the language specification at all. It could just be a library type NotQuiteRefany.T. You could then introduce separately, a la Rodney, TAGGED T <: REFANY; (* for all T *) (* but *not* TAGGED T <: NOTQUITEREFANY *) > >> but maybe it doesn't break anything else. Although you do >> in any case get LSB checks all over the place (in safe code!) where >> the TAGGED U is revealed to be a TAGGED U. >> >> Note that, as we probably all know, the Modula-3 designers expressly >> considered, and rejected, full variant records. > >Are these the factors they based their decision on? > >(1) The ones in Pascal are insecure without a lot of run-time checking. > >(2) Objects and inheritance take care of much of the functionality. > >(3) The ones in Algol 68 involve copying entire records when >construction and deconstructing unions of records. (1) and (2) at least. I'll quote: "[talk about runtime errors due to freeing still-used references] Another well-known runtime error is to assign to the tag of a variant record in a way that subverts the type system. Distinguishing subversive assignments from benign assignments in the language definition is error-prone and arbitrary. The objects and classes first introduced in Simula and adopted in Oberon and Object Pascal are more general than variant records, and they are safe, so we have discarded variant records and adopted objects. [talk about objects]" (See Cardelli et al., "The Modula-3 Type System" (c) 1989 ACM.) Mika > >What we're considering not is the case in which (2) provides >excessive indirection and garbage-collector load, and in which >the copying in (3) is really cheap. There are applications >for which this feature could have major effects on efficiency. >I have some I'd consider rewriting from C/C++ to Modula 3 >if this feature were available. > >-- hendrik .... From jay.krell at cornell.edu Thu Apr 9 19:06:21 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 9 Apr 2009 17:06:21 +0000 Subject: [M3devel] FW: cvsup In-Reply-To: <20090409170205.0D1CF60C150@birch.elegosoft.com> References: <20090409170205.0D1CF60C150@birch.elegosoft.com> Message-ID: This is the first time I've used cvs import. Hopefully I don't mess it up much. This is just an initial import with no changes, no attempt to build it, etc. I think that's the right approach. Thanks, - Jay ---------------------------------------- > Date: Thu, 9 Apr 2009 19:02:04 +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/04/09 19:02:04 > > cm3/m3-tools/cvsup > > Update of /usr/cvs/cm3/m3-tools/cvsup > In directory birch:/tmp/cvs-serv5883 > > Log Message: > import cvsup-snap-16.1h > > Status: > > Vendor Tag: cvsup > Release Tags: cvsup-snap-16_1h > > N cm3/m3-tools/cvsup/Blurb > N cm3/m3-tools/cvsup/Install > N cm3/m3-tools/cvsup/License > N cm3/m3-tools/cvsup/Announce > N cm3/m3-tools/cvsup/Makefile > N cm3/m3-tools/cvsup/ChangeLog > N cm3/m3-tools/cvsup/Acknowledgments > N cm3/m3-tools/cvsup/doc/faq_ru.tail > N cm3/m3-tools/cvsup/doc/faq.tail > N cm3/m3-tools/cvsup/doc/faq_ru.faq > N cm3/m3-tools/cvsup/doc/faq.faq > N cm3/m3-tools/cvsup/doc/Protocol > N cm3/m3-tools/cvsup/doc/faqgen.awk > N cm3/m3-tools/cvsup/doc/Makefile > N cm3/m3-tools/cvsup/doc/faq.head > N cm3/m3-tools/cvsup/doc/Checkouts > N cm3/m3-tools/cvsup/doc/Attributes > N cm3/m3-tools/cvsup/doc/faq_ru.head > N cm3/m3-tools/cvsup/doc/images/yelnew.gif > N cm3/m3-tools/cvsup/doc/images/cvsup128.gif > N cm3/m3-tools/cvsup/client/Makefile > N cm3/m3-tools/cvsup/client/src/RegularUpdater.i3 > N cm3/m3-tools/cvsup/client/src/RegularUpdater.m3 > N cm3/m3-tools/cvsup/client/src/exit.pbm > N cm3/m3-tools/cvsup/client/src/TextPortLogger.i3 > N cm3/m3-tools/cvsup/client/src/Receive.i3 > N cm3/m3-tools/cvsup/client/src/TreeList.i3 > N cm3/m3-tools/cvsup/client/src/RsyncUpdater.m3 > N cm3/m3-tools/cvsup/client/src/Auth.i3 > N cm3/m3-tools/cvsup/client/src/SyncQueue.mg > N cm3/m3-tools/cvsup/client/src/SupGUI.m3 > N cm3/m3-tools/cvsup/client/src/tape_play.pbm > N cm3/m3-tools/cvsup/client/src/Version.i3 > N cm3/m3-tools/cvsup/client/src/SupFile.m3 > N cm3/m3-tools/cvsup/client/src/CheckoutUpdater.i3 > N cm3/m3-tools/cvsup/client/src/EventSync.m3 > N cm3/m3-tools/cvsup/client/src/SupFile.i3 > N cm3/m3-tools/cvsup/client/src/CheckoutUpdater.m3 > N cm3/m3-tools/cvsup/client/src/TreeList.m3 > N cm3/m3-tools/cvsup/client/src/Auth.m3 > N cm3/m3-tools/cvsup/client/src/FSClient.i3 > N cm3/m3-tools/cvsup/client/src/TextVBTLogger.i3 > N cm3/m3-tools/cvsup/client/src/CheckoutCreator.m3 > N cm3/m3-tools/cvsup/client/src/cvsup.1 > N cm3/m3-tools/cvsup/client/src/Updater.m3 > N cm3/m3-tools/cvsup/client/src/BackoffTimer.m3 > N cm3/m3-tools/cvsup/client/src/FSClient.m3 > N cm3/m3-tools/cvsup/client/src/disk.pbm > N cm3/m3-tools/cvsup/client/src/RCSUpdater.m3 > N cm3/m3-tools/cvsup/client/src/EventSync.i3 > N cm3/m3-tools/cvsup/client/src/Detailer.i3 > N cm3/m3-tools/cvsup/client/src/cvsup.cat > N cm3/m3-tools/cvsup/client/src/CheckoutCreator.i3 > N cm3/m3-tools/cvsup/client/src/Receive.m3 > N cm3/m3-tools/cvsup/client/src/Main.m3 > N cm3/m3-tools/cvsup/client/src/RegularCreator.i3 > N cm3/m3-tools/cvsup/client/src/FileUpdater.i3 > N cm3/m3-tools/cvsup/client/src/RsyncUpdater.i3 > N cm3/m3-tools/cvsup/client/src/syncqueue.tmpl > N cm3/m3-tools/cvsup/client/src/stop.pbm > N cm3/m3-tools/cvsup/client/src/FileUpdater.m3 > N cm3/m3-tools/cvsup/client/src/TextVBTLogger.m3 > N cm3/m3-tools/cvsup/client/src/SupGUIFake.m3 > N cm3/m3-tools/cvsup/client/src/m3makefile > N cm3/m3-tools/cvsup/client/src/BackoffTimer.i3 > N cm3/m3-tools/cvsup/client/src/RegularCreator.m3 > N cm3/m3-tools/cvsup/client/src/TextPortLogger.m3 > N cm3/m3-tools/cvsup/client/src/SupGUI.i3 > N cm3/m3-tools/cvsup/client/src/Copyright.txt > N cm3/m3-tools/cvsup/client/src/SyncQueue.ig > N cm3/m3-tools/cvsup/client/src/RCSUpdater.i3 > N cm3/m3-tools/cvsup/client/src/Detailer.m3 > N cm3/m3-tools/cvsup/client/src/Updater.i3 > N cm3/m3-tools/cvsup/client/src/info.pbm > N cm3/m3-tools/cvsup/client/src/Fixup.i3 > N cm3/m3-tools/cvsup/client/src/SupGUI.fv > N cm3/m3-tools/cvsup/cvpasswd/Makefile > N cm3/m3-tools/cvsup/cvpasswd/src/Secret.i3 > N cm3/m3-tools/cvsup/cvpasswd/src/Secret.m3 > N cm3/m3-tools/cvsup/cvpasswd/src/Main.m3 > N cm3/m3-tools/cvsup/cvpasswd/src/m3makefile > N cm3/m3-tools/cvsup/cvpasswd/src/Upass.i3 > N cm3/m3-tools/cvsup/cvpasswd/src/cvpasswd.cat > N cm3/m3-tools/cvsup/cvpasswd/src/cvpasswd.1 > N cm3/m3-tools/cvsup/examples/supfile.cvs > N cm3/m3-tools/cvsup/examples/README > N cm3/m3-tools/cvsup/contrib/README > N cm3/m3-tools/cvsup/contrib/cvsup2httplog/cvsup2httplog > N cm3/m3-tools/cvsup/contrib/cvsup2httplog/README > N cm3/m3-tools/cvsup/contrib/cvsupwho/README > N cm3/m3-tools/cvsup/contrib/cvsupwho/cvsupwho > N cm3/m3-tools/cvsup/contrib/cvsupchk/README > N cm3/m3-tools/cvsup/contrib/cvsupchk/cvsupchk > N cm3/m3-tools/cvsup/contrib/cvsup2html/cvsup2html.awk > N cm3/m3-tools/cvsup/contrib/cvsup2html/README > N cm3/m3-tools/cvsup/contrib/cvsuplog2html/README > N cm3/m3-tools/cvsup/contrib/cvsuplog2html/cvsuplog2html > N cm3/m3-tools/cvsup/suplib/Makefile > N cm3/m3-tools/cvsup/suplib/src/RsyncFile.i3 > N cm3/m3-tools/cvsup/suplib/src/RsyncBlock.m3 > N cm3/m3-tools/cvsup/suplib/src/IOWatchDog.m3 > N cm3/m3-tools/cvsup/suplib/src/RCSRevNum.i3 > N cm3/m3-tools/cvsup/suplib/src/FileAttrRep.i3 > N cm3/m3-tools/cvsup/suplib/src/EscapedRd.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSError.i3 > N cm3/m3-tools/cvsup/suplib/src/Merger.ig > N cm3/m3-tools/cvsup/suplib/src/merger.tmpl > N cm3/m3-tools/cvsup/suplib/src/UgzipP.i3 > N cm3/m3-tools/cvsup/suplib/src/GzipRd.m3 > N cm3/m3-tools/cvsup/suplib/src/WatchDog.m3 > N cm3/m3-tools/cvsup/suplib/src/RCSString.m3 > N cm3/m3-tools/cvsup/suplib/src/ErrMsg.m3 > N cm3/m3-tools/cvsup/suplib/src/AuthMD5.i3 > N cm3/m3-tools/cvsup/suplib/src/SplitLogger.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSPhrase.i3 > N cm3/m3-tools/cvsup/suplib/src/MD5.i3 > N cm3/m3-tools/cvsup/suplib/src/DirEntry.i3 > N cm3/m3-tools/cvsup/suplib/src/SupMisc.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSString.i3 > N cm3/m3-tools/cvsup/suplib/src/SupMisc.m3 > N cm3/m3-tools/cvsup/suplib/src/IOWatchDog.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSEdit.i3 > N cm3/m3-tools/cvsup/suplib/src/FileAttr.i3 > N cm3/m3-tools/cvsup/suplib/src/ExecRec.i3 > N cm3/m3-tools/cvsup/suplib/src/Merger.mg > N cm3/m3-tools/cvsup/suplib/src/MySyslog.i3 > N cm3/m3-tools/cvsup/suplib/src/FileStatus.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSAccess.i3 > N cm3/m3-tools/cvsup/suplib/src/TimeStampLogger.i3 > N cm3/m3-tools/cvsup/suplib/src/SysLogger.m3 > N cm3/m3-tools/cvsup/suplib/src/GzipWr.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSDelta.m3 > N cm3/m3-tools/cvsup/suplib/src/DevT.i3 > N cm3/m3-tools/cvsup/suplib/src/TokScan.m3 > N cm3/m3-tools/cvsup/suplib/src/UnixMisc.m3 > N cm3/m3-tools/cvsup/suplib/src/Attic.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSAccess.m3 > N cm3/m3-tools/cvsup/suplib/src/CVTree.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSFile.m3 > N cm3/m3-tools/cvsup/suplib/src/WatchDog.i3 > N cm3/m3-tools/cvsup/suplib/src/RegEx.m3 > N cm3/m3-tools/cvsup/suplib/src/SplitLogger.m3 > N cm3/m3-tools/cvsup/suplib/src/MD5Digest.m3 > N cm3/m3-tools/cvsup/suplib/src/StatusFile.i3 > N cm3/m3-tools/cvsup/suplib/src/Reaper.i3 > N cm3/m3-tools/cvsup/suplib/src/DirEntry.m3 > N cm3/m3-tools/cvsup/suplib/src/Umd5.i3 > N cm3/m3-tools/cvsup/suplib/src/TimeStampLogger.m3 > N cm3/m3-tools/cvsup/suplib/src/FileStatusRaw.i3 > N cm3/m3-tools/cvsup/suplib/src/Attic.m3 > N cm3/m3-tools/cvsup/suplib/src/SupFileRec.m3 > N cm3/m3-tools/cvsup/suplib/src/GzipRd.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSTag.m3 > N cm3/m3-tools/cvsup/suplib/src/FileAttr.m3 > N cm3/m3-tools/cvsup/suplib/src/Ugzip.i3 > N cm3/m3-tools/cvsup/suplib/src/StatusFile.m3 > N cm3/m3-tools/cvsup/suplib/src/MD5Wr.m3 > N cm3/m3-tools/cvsup/suplib/src/ProcTitle.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSDelta.i3 > N cm3/m3-tools/cvsup/suplib/src/RsyncFile.m3 > N cm3/m3-tools/cvsup/suplib/src/EscapedWr.m3 > N cm3/m3-tools/cvsup/suplib/src/RCSDate.m3 > N cm3/m3-tools/cvsup/suplib/src/RCSPhrases.i3 > N cm3/m3-tools/cvsup/suplib/src/CText.i3 > N cm3/m3-tools/cvsup/suplib/src/AuthMD5.m3 > N cm3/m3-tools/cvsup/suplib/src/EscapedWr.i3 > N cm3/m3-tools/cvsup/suplib/src/CVProto.m3 > N cm3/m3-tools/cvsup/suplib/src/Glob.m3 > N cm3/m3-tools/cvsup/suplib/src/EscapedRd.m3 > N cm3/m3-tools/cvsup/suplib/src/RCSPhrases.m3 > N cm3/m3-tools/cvsup/suplib/src/SigHandler.i3 > N cm3/m3-tools/cvsup/suplib/src/UnixMiscC.c > N cm3/m3-tools/cvsup/suplib/src/Uglob.i3 > N cm3/m3-tools/cvsup/suplib/src/LoggerClass.i3 > N cm3/m3-tools/cvsup/suplib/src/Logger.i3 > N cm3/m3-tools/cvsup/suplib/src/GlobTree.i3 > N cm3/m3-tools/cvsup/suplib/src/GlobTree.m3 > N cm3/m3-tools/cvsup/suplib/src/Reaper.m3 > N cm3/m3-tools/cvsup/suplib/src/Logger.m3 > N cm3/m3-tools/cvsup/suplib/src/SigHandler.m3 > N cm3/m3-tools/cvsup/suplib/src/RCSDate.i3 > N cm3/m3-tools/cvsup/suplib/src/UnixMisc.i3 > N cm3/m3-tools/cvsup/suplib/src/CVTree.m3 > N cm3/m3-tools/cvsup/suplib/src/WrLogger.m3 > N cm3/m3-tools/cvsup/suplib/src/LockFile.m3 > N cm3/m3-tools/cvsup/suplib/src/m3makefile > N cm3/m3-tools/cvsup/suplib/src/ChannelMux.i3 > N cm3/m3-tools/cvsup/suplib/src/TokScan.i3 > N cm3/m3-tools/cvsup/suplib/src/ErrMsg.i3 > N cm3/m3-tools/cvsup/suplib/src/ChannelMux.m3 > N cm3/m3-tools/cvsup/suplib/src/FileStatus.m3 > N cm3/m3-tools/cvsup/suplib/src/PathComp.i3 > N cm3/m3-tools/cvsup/suplib/src/MD5Digest.i3 > N cm3/m3-tools/cvsup/suplib/src/GzipError.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSKeyword.i3 > N cm3/m3-tools/cvsup/suplib/src/MD5.m3 > N cm3/m3-tools/cvsup/suplib/src/PathComp.m3 > N cm3/m3-tools/cvsup/suplib/src/GzipError.m3 > N cm3/m3-tools/cvsup/suplib/src/SysLogger.i3 > N cm3/m3-tools/cvsup/suplib/src/FileID.m3 > N cm3/m3-tools/cvsup/suplib/src/MD5Wr.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSPhrase.m3 > N cm3/m3-tools/cvsup/suplib/src/RegEx.i3 > N cm3/m3-tools/cvsup/suplib/src/Glob.i3 > N cm3/m3-tools/cvsup/suplib/src/FileID.i3 > N cm3/m3-tools/cvsup/suplib/src/SupFileRec.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSTag.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSKeyword.m3 > N cm3/m3-tools/cvsup/suplib/src/WrLogger.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSDeltaClass.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSRevNum.m3 > N cm3/m3-tools/cvsup/suplib/src/CVProto.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSFile.i3 > N cm3/m3-tools/cvsup/suplib/src/LockFile.i3 > N cm3/m3-tools/cvsup/suplib/src/Ugzip.m3 > N cm3/m3-tools/cvsup/suplib/src/RsyncBlock.i3 > N cm3/m3-tools/cvsup/suplib/src/GzipWr.m3 > N cm3/m3-tools/cvsup/suplib/src/libmd/md5hl.c > N cm3/m3-tools/cvsup/suplib/src/libmd/md5.h > N cm3/m3-tools/cvsup/suplib/src/libmd/md5c.c > N cm3/m3-tools/cvsup/suplib/src/libmd/m3makefile > N cm3/m3-tools/cvsup/suplib/src/libmd/md5.copyright > N cm3/m3-tools/cvsup/suplib/src/libglob/fnmatch.h > N cm3/m3-tools/cvsup/suplib/src/libglob/fnmatch.c > N cm3/m3-tools/cvsup/suplib/src/libglob/m3makefile > N cm3/m3-tools/cvsup/suplib/src/dev_t_linux/DevTLinux.i3 > N cm3/m3-tools/cvsup/suplib/src/dev_t_linux/m3makefile > N cm3/m3-tools/cvsup/suplib/src/dev_t_linux/DevT.m3 > N cm3/m3-tools/cvsup/suplib/src/POSIX/ProcTitle.m3 > N cm3/m3-tools/cvsup/suplib/src/POSIX/m3makefile > N cm3/m3-tools/cvsup/suplib/src/POSIX/FileAttrOS.m3 > N cm3/m3-tools/cvsup/suplib/src/text_cm3/SupMiscText.m3 > N cm3/m3-tools/cvsup/suplib/src/text_cm3/CText.m3 > N cm3/m3-tools/cvsup/suplib/src/text_cm3/m3makefile > N cm3/m3-tools/cvsup/suplib/src/text_pm3/SupMiscText.m3 > N cm3/m3-tools/cvsup/suplib/src/text_pm3/CText.m3 > N cm3/m3-tools/cvsup/suplib/src/text_pm3/m3makefile > N cm3/m3-tools/cvsup/suplib/src/FreeBSD/UProcTitle.c > N cm3/m3-tools/cvsup/suplib/src/FreeBSD/FileAttrOS.i3 > N cm3/m3-tools/cvsup/suplib/src/FreeBSD/ProcTitle.m3 > N cm3/m3-tools/cvsup/suplib/src/FreeBSD/m3makefile > N cm3/m3-tools/cvsup/suplib/src/FreeBSD/UProcTitle.i3 > N cm3/m3-tools/cvsup/suplib/src/FreeBSD/FileAttrOS.m3 > N cm3/m3-tools/cvsup/suplib/src/dev_t_posix/m3makefile > N cm3/m3-tools/cvsup/suplib/src/dev_t_posix/DevT.m3 > N cm3/m3-tools/cvsup/config/src/m3makefile > N cm3/m3-tools/cvsup/suptcp/Makefile > N cm3/m3-tools/cvsup/suptcp/src/COPYRIGHT > N cm3/m3-tools/cvsup/suptcp/src/README > N cm3/m3-tools/cvsup/suptcp/src/m3makefile > N cm3/m3-tools/cvsup/suptcp/src/POSIX/COPYRIGHT > N cm3/m3-tools/cvsup/suptcp/src/POSIX/SupTCPHackNull.m3 > N cm3/m3-tools/cvsup/suptcp/src/POSIX/SupTCPHack.i3 > N cm3/m3-tools/cvsup/suptcp/src/POSIX/SupTCP.m3 > N cm3/m3-tools/cvsup/suptcp/src/POSIX/SockOptOther.m3 > N cm3/m3-tools/cvsup/suptcp/src/POSIX/SockOpt.i3 > N cm3/m3-tools/cvsup/suptcp/src/POSIX/SupTCPHack.m3 > N cm3/m3-tools/cvsup/suptcp/src/POSIX/SupTCPPosix.i3 > N cm3/m3-tools/cvsup/suptcp/src/POSIX/m3makefile > N cm3/m3-tools/cvsup/suptcp/src/POSIX/SockOptFBSD.m3 > N cm3/m3-tools/cvsup/suptcp/src/common/StreamWrClass.m3 > N cm3/m3-tools/cvsup/suptcp/src/common/COPYRIGHT > N cm3/m3-tools/cvsup/suptcp/src/common/StreamRdClass.m3 > N cm3/m3-tools/cvsup/suptcp/src/common/TCPMisc.i3 > N cm3/m3-tools/cvsup/suptcp/src/common/StreamRd.i3 > N cm3/m3-tools/cvsup/suptcp/src/common/SupConnRW.i3 > N cm3/m3-tools/cvsup/suptcp/src/common/SupConnFD.i3 > N cm3/m3-tools/cvsup/suptcp/src/common/SupErrno.i3 > N cm3/m3-tools/cvsup/suptcp/src/common/m3makefile > N cm3/m3-tools/cvsup/suptcp/src/common/SupTCP.i3 > N cm3/m3-tools/cvsup/suptcp/src/common/StreamWrClass.i3 > N cm3/m3-tools/cvsup/suptcp/src/common/SupErrnoC.c > N cm3/m3-tools/cvsup/suptcp/src/common/StreamWr.i3 > N cm3/m3-tools/cvsup/suptcp/src/common/SupConnRW.m3 > N cm3/m3-tools/cvsup/suptcp/src/common/StreamRdClass.i3 > N cm3/m3-tools/cvsup/quake/cvsup.quake > N cm3/m3-tools/cvsup/server/Makefile > N cm3/m3-tools/cvsup/server/src/ClassDB.m3 > N cm3/m3-tools/cvsup/server/src/ClientClass.i3 > N cm3/m3-tools/cvsup/server/src/FSServer.m3 > N cm3/m3-tools/cvsup/server/src/cvsupd.cat > N cm3/m3-tools/cvsup/server/src/Passwd.i3 > N cm3/m3-tools/cvsup/server/src/Version.i3 > N cm3/m3-tools/cvsup/server/src/ClientClass.m3 > N cm3/m3-tools/cvsup/server/src/cvsupd.class.cat > N cm3/m3-tools/cvsup/server/src/FSServerU.m3 > N cm3/m3-tools/cvsup/server/src/FSServer.i3 > N cm3/m3-tools/cvsup/server/src/AccessRules.i3 > N cm3/m3-tools/cvsup/server/src/ParsedDelta.m3 > N cm3/m3-tools/cvsup/server/src/Main.m3 > N cm3/m3-tools/cvsup/server/src/cvsupd.8 > N cm3/m3-tools/cvsup/server/src/AccessRules.m3 > N cm3/m3-tools/cvsup/server/src/TreeComp.i3 > N cm3/m3-tools/cvsup/server/src/ClassDB.i3 > N cm3/m3-tools/cvsup/server/src/FileInfo.i3 > N cm3/m3-tools/cvsup/server/src/Passwd.m3 > N cm3/m3-tools/cvsup/server/src/m3makefile > N cm3/m3-tools/cvsup/server/src/FileInfo.m3 > N cm3/m3-tools/cvsup/server/src/RCSComp.i3 > N cm3/m3-tools/cvsup/server/src/ParsedDelta.i3 > N cm3/m3-tools/cvsup/server/src/cvsupd.class.5 > N cm3/m3-tools/cvsup/server/src/TreeComp.m3 > N cm3/m3-tools/cvsup/server/src/RCSComp.m3 > N cm3/m3-tools/cvsup/server/src/FSServerRep.i3 > > No conflicts created by this import > From hendrik at topoi.pooq.com Thu Apr 9 21:43:37 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 9 Apr 2009 15:43:37 -0400 Subject: [M3devel] small objects In-Reply-To: <200904091527.n39FRBF0031475@camembert.async.caltech.edu> References: <20090409143440.GA13374@topoi.pooq.com> <200904091527.n39FRBF0031475@camembert.async.caltech.edu> Message-ID: <20090409194337.GA14441@topoi.pooq.com> On Thu, Apr 09, 2009 at 08:27:11AM -0700, Mika Nystrom wrote: > > hendrik at topoi.pooq.com writes: > >> > >> Note that, as we probably all know, the Modula-3 designers expressly > >> considered, and rejected, full variant records. > > > >Are these the factors they based their decision on? > > > >(1) The ones in Pascal are insecure without a lot of run-time checking. > > > >(2) Objects and inheritance take care of much of the functionality. > > > >(3) The ones in Algol 68 involve copying entire records when > >construction and deconstructing unions of records. > > (1) and (2) at least. I'll quote: > > "[talk about runtime errors due to freeing still-used references] > > Another well-known runtime error is to assign to the tag of a variant > record in a way that subverts the type system. Distinguishing > subversive assignments from benign assignments in the language > definition is error-prone and arbitrary. If I recall the Pascal definition correctly, the only assignment that was allowed to the tag of a variant was to assign the entire record, including the tag and the variant. I don't know of any Pascal compiler that even tries to check this. > The objects and classes > first introduced in Simula and adopted in Oberon and Object Pascal > are more general than variant records, and they are safe, so we > have discarded variant records and adopted objects. > > [talk about objects]" > > (See Cardelli et al., "The Modula-3 Type System" (c) 1989 ACM.) > > Mika > > > > >What we're considering not is the case in which (2) provides > >excessive indirection and garbage-collector load, and in which > >the copying in (3) is really cheap. There are applications > >for which this feature could have major effects on efficiency. > >I have some I'd consider rewriting from C/C++ to Modula 3 > >if this feature were available. > > > >-- hendrik > .... From martinbishop at bellsouth.net Thu Apr 9 22:28:58 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Thu, 09 Apr 2009 15:28:58 -0500 Subject: [M3devel] CM3 Release Message-ID: <49DE5A8A.5070307@bellsouth.net> A few days ago there was more talk of a proper "release" for CM3. I think this is very important. Even if this proper release is just full binary versions, I think it would make a big difference. These could then be used to make .deb packages for Debian/Ubuntu, and hopefully other Linux/BSD distributions. Does the Windows version come with an installer? If not, I think it should. Also, along with easy to install releases, I think a good book/tutorial should be available online for Modula-3. We already know Nelson's book is caught up with copyright stuff, but I wonder if the same is true for Harbison's book? If neither can be released online, perhaps we should try to improve the existing tutorial? (http://www.opencm3.net/doc/tutorial/m3/m3_toc.html) A lot of people right off Modula-3 as being dead because they don't even know that a good, free implementation like CM3 exists. I think the above ideas would help. From jay.krell at cornell.edu Thu Apr 9 23:53:20 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 9 Apr 2009 21:53:20 +0000 Subject: [M3devel] CM3 Release In-Reply-To: <49DE5A8A.5070307@bellsouth.net> References: <49DE5A8A.5070307@bellsouth.net> Message-ID: Historically the Windows version came with the command line cminstall. It also looked in the registry for stuff. A GUI installer that is just a glorofied unzipper is easy enough and I agree has some value. I put one together a few weeks ago. Something that does a little more to find the compiler/linker or setup a "shortcut" to a command line with environment variables might be nice. >> Even if this proper release is just full binary versions, I think it >> would make a big difference. These could then be used to make .deb Uploaded-archives already exists, with a bunch of fairly current archives.. Try them? (Thanks to Carson for trying them, wrt cvsup; I'm addressing that.) >>>>>> Just does qualifies as a release anyway? <<<<<<< More testing?? What are people's thoughts/abilities/experience on getting into: *BSD ports -- well, FreeBSD already has ezm3, that counts for something Debian, Ubuntu, Suse, Fedora, etc. repositories? You need to wrangle an approved developer into submitting the package? Olaf is clearly working on something here -- improving cminstall. I'm working on: get cvsup building, this won't take long Debugging the formsedit crash; this might take long. Moving FreeBSD/x86 to new smaller Unix/*.i3 files. This shouldn't take long. Bootstrapping from whatever platform I first did yielded invalid assembly. I'm going to try from Cygwin instead before I debug further -- something simple about how the PIC "get PC" stub's section is generated..linkonce or not, I tried editing it with Perl to match C compiler output but got it wrong. This will leave I386_DARWIN, AMD64_DARWIN as the main holdouts -- I don't have hardware for them (yet). Fixing up issues around paths to shared libraries, $ORIGIN, etc. - Like, restore buildlocal to old behavior; keep buildglobal with new behavior - move FreeBSD/x86 to use $ORIGIN with buildglobal After that, I'll probably introduce new platforms I386_LINUX, I386_FREEBSD, SPARC32_SOLARIS, I386_NT, I386_CYGWIN, I386_MINGW that are equivalent to today's LINUXLIBC6, FreeBSD4, SOLgnu/SOLsun, NT386, NT386GNU, NT386MINGNU. And put together some "boot" archives that factor out C ABI issues, OS major version variants, are very cross buildable, and produce not just cm3, but "everything" -- you compile the C and link on the target system. This way, perhaps, a lot of producing a release can fully automated on one build host. (And after all that, maybe get back to ARM_LINUX_OLDABI_UCLIBC or whatever it should be called...but a new ARM device is en route, maybe ARM_LINUX_NEWABI_GLIBC. :)) I also need to get m3gdb and cm3ide into my releases, that's comes before introducing new platform names. This entire list is not required for making a release, but m3gdb and cm3ide probably are. Some of the uploaded archives should be updated too, such as SPARC32_{LINUX,OPENBSD}. There's also a bunch of other ports I'd like to get through but they don't block a release. We should maybe split platforms into "tier 1" and "tier 2". Just because I released something, doesn't make it to tier 1. :) Tier 2 can be missing from a release or having bugs, without holding up other releases. - Jay > Date: Thu, 9 Apr 2009 15:28:58 -0500 > From: martinbishop at bellsouth.net > To: m3devel at elegosoft.com > Subject: [M3devel] CM3 Release > > A few days ago there was more talk of a proper "release" for CM3. I > think this is very important. > > Even if this proper release is just full binary versions, I think it > would make a big difference. These could then be used to make .deb > packages for Debian/Ubuntu, and hopefully other Linux/BSD distributions. > > Does the Windows version come with an installer? If not, I think it should. > > Also, along with easy to install releases, I think a good book/tutorial > should be available online for Modula-3. We already know Nelson's book > is caught up with copyright stuff, but I wonder if the same is true for > Harbison's book? > > If neither can be released online, perhaps we should try to improve the > existing tutorial? (http://www.opencm3.net/doc/tutorial/m3/m3_toc.html) > > A lot of people right off Modula-3 as being dead because they don't even > know that a good, free implementation like CM3 exists. I think the > above ideas would help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.m.bates at cox.net Fri Apr 10 00:13:52 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Thu, 09 Apr 2009 17:13:52 -0500 Subject: [M3devel] small objects In-Reply-To: <200904091527.n39FRBF0031475@camembert.async.caltech.edu> References: <200904091527.n39FRBF0031475@camembert.async.caltech.edu> Message-ID: <49DE7320.6090506@cox.net> Mika Nystrom wrote: > hendrik at topoi.pooq.com writes: > >> On Thu, Apr 09, 2009 at 07:10:44AM -0700, Mika Nystrom wrote: >> >>> I don't know why we're having such a tough time understanding each >>> other here :-) >>> >>> I think that what Rodney says is that he wants (in pseudo-modula-2 >>> syntax): >>> >>> T = CASE LSB OF >>> 1 : SmallInt >>> | >>> 0 : U >>> END; >>> >>> SmallInt = [SmallMin..SmallMax]; >>> >>> for any reference type U. >>> >> Yes. That's what I wanted too, originally. I can accept the >> restriction that the reference type U might be restricted to be >> REFANY. >> > > I think this is what Tony says he's implemented, essentially... > > ... > >>> The only problem I have with this (except for the changes necessary >>> to Modula-3) is that it can't be held in a REFANY, and that's part >>> of the design. >>> >> Much better not to pervert REFANY, but use a new type instead. >> > > Are you sure? I want a type---some type---that can hold "any > reference, even a tagged one", and I would rewrite most library > code that today takes REFANY to take that instead. Why not? Why > would I want to limit it to REFANY when it performs no operations > that couldn't legally be performed on TAGGED REFANY. > I believe my "safe" proposal would make this very simple, if I am thinking of the kind of library code you are. I envision a container data structure that takes in things and returns them without performing operations on them other than moving them around and storing them, e.g. the ever belabored stack. The values going in and out are declared REFANY, and the client passes in values of some proper subtype of REFANY, which get assigned to the REFANY parameters. When it gets them back, it narrows them to this type. In this pattern, just changing the declared type of the container values from REFANY to TAGGED REFANY would do it. The library code's storage and copying of the values would all work as before, and the client's passing to TAGGED REFANY and later narrowing it to whatever reference type it put in would also work as before, using the extended semantics of assignments and narrowing operations. > >>> Of course we could go halfway and let it be held in a REFANY, but >>> then you get the runtime LSB check again, for all instances of >>> REFANY, >>> >> I really don't like requiriny a run-time check on REFANY. That's why >> I want it to be a separate type. >> > > All the operations in question already require (*much* more > complicated) run-time checks on REFANY.... and most uses of REFANY > still wouldn't require the LSB check. > > I really think the runtime issue is a non-issue, and as I said > above, if it turns out to be a real issue, one can either abandon > the change (since the whole thing can be implemented transparently > with a library) or else re-root ROOT and all the REF types in a new > NOTQUITEREFANY type. This would be a backward-compatible change > (in every sense) with Tony's runtime changes: > > REFANY ; (* Tony's, with the LSB trick *) > > NOTQUITEREFANY <: REFANY; > > ROOT <: NOTQUITEREFANY; > > REF T <: NOTQUITEREFANY; (* for all T *) > > After that, future, change, people who want to avoid the LSB check > on REFANY can instead use NOTQUITEREFANY. I think barely anyone > will bother. > > Come to think of it, Modula-3 doesn't specify that there's no > intermediate type between REFANY and ROOT and the other REF T's, > so there's no way it could break the current language. In > fact you don't have to "reveal" this new type in the language > specification at all. It could just be a library type > NotQuiteRefany.T. > > You could then introduce separately, a la Rodney, > > TAGGED T <: REFANY; (* for all T *) > > (* but *not* TAGGED T <: NOTQUITEREFANY *) > > > >>> but maybe it doesn't break anything else. Although you do >>> in any case get LSB checks all over the place (in safe code!) where >>> the TAGGED U is revealed to be a TAGGED U. >>> >>> Note that, as we probably all know, the Modula-3 designers expressly >>> considered, and rejected, full variant records. >>> >> Are these the factors they based their decision on? >> >> (1) The ones in Pascal are insecure without a lot of run-time checking. >> >> (2) Objects and inheritance take care of much of the functionality. >> >> (3) The ones in Algol 68 involve copying entire records when >> construction and deconstructing unions of records. >> > > (1) and (2) at least. I'll quote: > > "[talk about runtime errors due to freeing still-used references] > > Another well-known runtime error is to assign to the tag of a variant > record in a way that subverts the type system. Distinguishing > subversive assignments from benign assignments in the language > definition is error-prone and arbitrary. The objects and classes > first introduced in Simula and adopted in Oberon and Object Pascal > are more general than variant records, and they are safe, so we > have discarded variant records and adopted objects. > > [talk about objects]" > > (See Cardelli et al., "The Modula-3 Type System" (c) 1989 ACM.) > > Mika > > >> What we're considering not is the case in which (2) provides >> excessive indirection and garbage-collector load, and in which >> the copying in (3) is really cheap. There are applications >> for which this feature could have major effects on efficiency. >> I have some I'd consider rewriting from C/C++ to Modula 3 >> if this feature were available. >> >> -- hendrik >> > .... > > From rodney.m.bates at cox.net Fri Apr 10 00:00:55 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Thu, 09 Apr 2009 17:00:55 -0500 Subject: [M3devel] small objects In-Reply-To: References: <200904090038.n390cNsg097270@camembert.async.caltech.edu> <49DD59DB.4050404@cox.net> <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> Message-ID: <49DE7017.1010902@cox.net> Without language changes, this could be useful. It does use two words instead of one, with always one or the other being wasted. But in my 11-to-1 example, it would give 11-to-2 savings--not to be sneezed at. One limitation it has is, to get the benefit, you have to stored the two-word record itself embedded wherever the pointer would have been, not out in the heap. So it's not a reference type and thus can't be opaque. No type unsafely here, but client code can not be prevented from breaking the abstraction. There are places in the M3 distribution where a non-reference type has a comment (* Treat as opaque *). Jay wrote: > Um, what do folks think of, like: > > struct > { > void* Type; > union > { > size_t Integer; > void* Pointer; > } Value; > } Variant; > > ? > You know -- something that is two pointers, one pointer for the type, > one for the value or integer? > void* Type would actually be a pointer to something actually defined > and elaborate. > > Obviously this is twice as large, not as small as it could be, but > much more general and portable. No need to determine how many of bits > can be the tag. > > And hope/assume for perf that such a small struct is passed in registers. > On x86/NT 4 and 8 byte structs I think are. > > Type could also be an integer, index into some table, with some > predefined values. > #define TYPE_INTEGER 0 > #define TYPE_FLOAT 1 > #define TYPE_DOUBLE 2 > #define TYPE_ADDRESS 3 > > more generally the union would have a float, and maybe a double on > 64bit platforms. > > OR, on 64bit platforms, you probably can, with some porting work, > dedicate a whole 8 bits or so to a type index, and still the thing in > one "word". How many bits of address space does any 64bit platform > these days or forseeable future actually implement? > > But 32 bits doesn't seem big enough to afford that, and still this is > a portability problem -- anything less than a full pointer. > > - Jay From rodney.m.bates at cox.net Thu Apr 9 23:50:45 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Thu, 09 Apr 2009 16:50:45 -0500 Subject: [M3devel] small objects In-Reply-To: <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> References: <200904090038.n390cNsg097270@camembert.async.caltech.edu> <49DD59DB.4050404@cox.net> <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> Message-ID: <49DE6DB5.7080807@cox.net> Tony Hosking wrote: > Sounds like you want something like: > > TAGGED REFANY FOR T > > where T must be a type that fits into BITS(REFANY)-1? Almost. But instead of a union of an arbitrary ordinal type with just REFANY, I want a union of just one ordinal type (TAG, a new language-defined subrange of INTEGER, with implementation-defined bounds) and an arbitrary traced reference or object type. I think just one ordinal type is adequate, but there are advantages to not having it restricted to REFANY, see below. Two tagged types constructed from different reference types are not the same type, have no subtype relation between them, and no assignability between them. This despite the fact that they will have overlapping value sets. There are other places in the language where this happens already. But RefType <: TAGGED RefType and TAG <: TAGGED RefType, so you can assign between a tagged type and either the reference type it is built from, or TAG. When going from the tagged type, these assignments require narrowing operations. Going to a tagged type is allowed by existing assignability rules, and the implementation can simply copy the bits at runtime. > > Branding could be used to prevent mixing otherwise structurally > equivalent TAGGED REFANY. Yes, some kind of branding is essential to allow otherwise structurally equivalent tagged types to be made unique. In my "safe" proposal, you can build a tagged type from a branded reference type, and it will inherit the uniqueness of the branded reference type. This simplifies the implementation, because BRANDED does not need to be extended to a non-reference type. Allowing a tagged type to be constructed from any reference type also means you can construct it from an opaque type if this is what you want, and it will inherit the opaqueness, as well as what's visible, from the opaque type. In unrevealed contexts, you can still narrow it to an integer and you can narrow it to the opaque type, then do whatever operations are visible in the opaque type. Example: TYPE Public = OBJECT METHODS m() END; TYPE Op <: Public; TYPE T = TAGGED Op; VAR VT: T := ... Here, without a revelation, you can do TYPECASE VT OF Op (o) => o.m() ... > > TAGGED BRANDED REFANY FOR T > > Where this breaks down is what are the subtyping rules, since I assume > you'd like to store these in a REFANY and dynamically test for the > appropriate tagged type: No, I do not want to store these in a variable of type REFANY or any other existing type. In fact, I want to forbid it. I want to store them only in a variable declared of a TAGGED type. To get the reference value out of a tagged type, do a NARROW or one of its equivalents and store the result in a REFANY. All the existing reference types and the allowable operations on them are unchanged. Only the narrowing operations make a runtime check of the tag bit. Similarly, for an integer value, narrow it and assign to an INTEGER variable. > > TAGGED REFANY FOR T <: REFANY > > But then how do we distinguish all the different TAGGED REFANY from > each other at run-time? All the tagged types are statically distinct and thus no runtime distinction is needed. The only new RT distinction is whether the value of a single tagged type is a member of TAG or of the underlying RefType. > > On 9 Apr 2009, at 12:13, Rodney M. Bates wrote: > >> Mika Nystrom wrote: >>> Hmm, ok, there's one big difference between what you're saying and >>> what Tony and I have been talking about. (I think your understanding >>> sounds pretty correct.) >>> >>> You want to do objects other than small integers. Like what? And why? >>> I was thinking the trick would apply only to one specific type of >>> integer. >>> >> >> Yes, I want a language mechanism that can be used by various >> modules to implement various abstract data types, each of which >> can perform the sometimes dramatic space optimization of putting >> values that are common and will fit directly in the word. >> One module I spoke of implements general sets of integers with >> dynamically variable and sometimes large range. This differs from >> the builtin SET OF.., which must have a static (and probably relatively >> small) base subrange. Thus the general, heap-allocated values contain >> open arrays of Word.T, treated as sets, or if you prefer, packed arrays >> of booleans, although I manipulate them with bit-twiddling operations >> from Word. >> There is another, static-sized, heap-allocated object in front of >> each array, >> containing biases on what bits correspond to what integers in the >> abstract set, etc. It all works fine now, but the usage pattern of >> some >> clients has a high percentage very small sets that would fit in a word, >> and there would be an 11-to-1 space savings if that could be done. >> BTW, there are also two different kinds of heap objects, one that >> represents a range set by just its bounds. So I am TYPECASEing >> these already. It would be very convenient if I could just add another >> alternative to the TYPECASE for in-word values. >> >> In another case, I need truly dynamically variable sized arrays of >> integers in [0..15], and the great majority are 7 elements or less, >> which would fit directly in the word, but I still the need full >> generality >> to be available, so it's open arrays all the time, with three additional >> words each. >> >> If you can pack a union of a pointer and an integer into a word and >> can separate them with runtime checks, then you can use the >> separated integer any way you want, with bit twiddling, type >> conversions, >> LOOPHOLE, or whatever. That is what I am trying to get, not just >> Smalltalk-like integers. >> Note that Smalltalk has zero static typing, so only one internal >> representation must do for the union of all possible values in >> the language. In Modula-3, it would be very inconsistent with >> the language's philosophy to be this restricted. >>> Hmm, so your idea is to statically determine what type the references >>> can have if they are non-references. So you are thinking to put >>> various >>> kinds of subranges into the "TAGGED" types. But you have to be able to >>> determine, statically, which subrange it is... am I understanding this >>> correctly? >>> >> >> From the language, all I want is to be able to dynamically determine >> whether it is a true pointer to a heap object or a value stored >> directly in the word, while preserving the safety principles and >> the semantics of everything already there. So I want some new >> types, different from any existing types, that statically are known >> to hold this kind of valueset union and can be converted/assigned >> to a variable of existing type that is statically known to be either a >> pointer or an integer (but not both), with a suitable runtime check. >> It is also necessary to have a way to do this without risking a runtime >> error, if your code doesn't know yet which kind of value it has. >> Various ADT modules can take it from there. >>> Mika >>> >>> "Rodney M. Bates" writes: >>> >>>> Tony Hosking wrote: >>>> >>>>> On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: >>>>> >>>>> >>>>>> Mika Nystrom wrote: >>>>>> >>>>>>> Hendrik, I think Tony's and my arguments that you can't break any >>>>>>> existing code by allowing the squirreling away of integers into >>>>>>> REFANYs are pretty solid. Pre-existing code simply can't do >>>>>>> anything >>>>>>> useful with unrevealed REFANYs. >>>>>>> >>>>>> This is only true of _unrevealed opaque subtypes_ of REFANY, >>>>>> not of REFANY itself. There is lots of existing code that uses >>>>>> REFANY, >>>>>> and there, ISTYPE, NARROW, TYPECASE, and assigment can be and >>>>>> regularly are used on it. It is essential not to alter the >>>>>> semantics there. >>>>>> >>>>> Pre-existing code won't be able to do anything useful with tagged >>>>> REFANYs: >>>>> >>>>> Suppose we have >>>>> >>>>> VAR r: REFANY = SmallInteger.FromInt(0); >>>>> >>>>> then >>>>> >>>>> ISTYPE(r, REFANY) => TRUE >>>>> ISTYPE(r, T) => FALSE for any T # REFANY >>>>> >>>>> Similarly, for TYPECASE, r will only trigger the REFANY branch. >>>>> >>>>> NARROW(r, REFANY) => r >>>>> NARROW(r, T) => run-time error for any T #REFANY >>>>> >>>>> VAR x: REFANY => assignment succeeds >>>>> VAR x: T := r => run-time error for any T # REFANY (because of >>>>> implicit NARROW) >>>>> >>>> I think I am getting a bit lost in all the proposals, variations, >>>> counterproposals, etc., but >>>> >>> >from this argument I am inferring that your plan is that only >>> variables >>>> declared REFANY >>>> and not any proper subtype of REFANY can ever have a value with a >>>> tag bit set? Then >>>> the 4 narrowing operations, when and only when applied to an >>>> expression of static >>>> type REFANY, would change to make a runtime check for a tag bit and >>>> fail if it's set? >>>> It would take this to prevent a tagged value from getting into a >>>> variable declared a >>>> proper subtype of REFANY, which can be dereferenced. >>>> >>>> This would preclude making your abstract data type an opaque >>>> subtype of REFANY, >>>> and would mean all supposedly unrelated ADT modules that used the >>>> tag technique >>>> could be broken by client code that mixed up the REFANY values of >>>> one of them with >>>> those of another. I consider this a definite breach of Modula-3's >>>> otherwise bulletproof >>>> type safety. >>>>> It is impossible to dereference an expression statically typed as >>>>> REFANY, so there is no need for a "tagged" check on dereference. >>>>> Because a tagged REFANY cannot be assigned to anything other than >>>>> something typed REFANY, it can never propagate to a place where it >>>>> can be dereferenced. >>>>> >>>>> >>>>>> Aside from actual semantic changes, I agree with Tony that we should >>>>>> not burden any existing type with additional runtime work. Even >>>>>> though >>>>>> I expect small objects to support big performance gains in certain >>>>>> important cases, non-tagged references will still greatly >>>>>> predominate >>>>>> in most code. Create new type(s) for tagged references. >>>>>> >>>>> I'm not sure that we are seeing any semantic changes at all. And >>>>> with Mika's definition of SmallInteger.T as a "boxed" INTEGER >>>>> object (actually it would be a subrange for values that fit into >>>>> BITSIZE(Word.T)-1 bits), it is essentially transparent. It just >>>>> happens to be a run-time optimization that unboxes the INTEGER value. >>>>> >>>>> >>>>> I think I can implement the compiler and run-time support for this >>>>> very quickly. >>>>> >>>>> >>>>> >>> >>> > > From mika at async.caltech.edu Fri Apr 10 02:04:23 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 09 Apr 2009 17:04:23 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Thu, 09 Apr 2009 16:50:45 CDT." <49DE6DB5.7080807@cox.net> Message-ID: <200904100004.n3A04NlY051431@camembert.async.caltech.edu> Sorry to splice together two emails from you, but I feel I've already used up my m3devel quota this week: "Rodney M. Bates" writes: >> Are you sure? I want a type---some type---that can hold "any >> reference, even a tagged one", and I would rewrite most library >> code that today takes REFANY to take that instead. Why not? Why >> would I want to limit it to REFANY when it performs no operations >> that couldn't legally be performed on TAGGED REFANY. >> > >I believe my "safe" proposal would make this very simple, if I am >thinking of the kind of library code you are. > >I envision a container data structure that takes in things and returns >them without performing operations on them other than moving them around >and storing them, e.g. the ever belabored stack. The values going in >and out are declared REFANY, and the client passes in values of >some proper subtype of REFANY, which get assigned to the REFANY >parameters. When it gets them back, it narrows them to this type. > >In this pattern, just changing the declared type of the container values >from REFANY to TAGGED REFANY would do it. The library code's storage ... >> you'd like to store these in a REFANY and dynamically test for the >> appropriate tagged type: > >No, I do not want to store these in a variable of type REFANY or any >other existing type. >In fact, I want to forbid it. I think you are thinking of exactly the same kind of library code. TextRefTbl.T, RefList.T, etc. After the introduction of TAGGED REFANY, what use is there for REFANY? What piece of code can you think of where the cost of the 1-LSB check of TAGGED REFANY outweighs the convenience of being able to process objects of type TAGGED T (for all ref types T) as well as objects of type T? Mika From rodney.m.bates at cox.net Fri Apr 10 19:24:49 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Fri, 10 Apr 2009 12:24:49 -0500 Subject: [M3devel] small objects In-Reply-To: <200904100004.n3A04NlY051431@camembert.async.caltech.edu> References: <200904100004.n3A04NlY051431@camembert.async.caltech.edu> Message-ID: <49DF80E1.10709@cox.net> Mika Nystrom wrote: > Sorry to splice together two emails from you, but I feel I've already > used up my m3devel quota this week: > > "Rodney M. Bates" writes: > >>> Are you sure? I want a type---some type---that can hold "any >>> reference, even a tagged one", and I would rewrite most library >>> code that today takes REFANY to take that instead. Why not? Why >>> would I want to limit it to REFANY when it performs no operations >>> that couldn't legally be performed on TAGGED REFANY. >>> >>> >> I believe my "safe" proposal would make this very simple, if I am >> thinking of the kind of library code you are. >> >> I envision a container data structure that takes in things and returns >> them without performing operations on them other than moving them around >> and storing them, e.g. the ever belabored stack. The values going in >> and out are declared REFANY, and the client passes in values of >> some proper subtype of REFANY, which get assigned to the REFANY >> parameters. When it gets them back, it narrows them to this type. >> >> In this pattern, just changing the declared type of the container values >> > >from REFANY to TAGGED REFANY would do it. The library code's storage > ... > There are two very different kinds of uses of reference and tagged types. The one I speak of above is for the type of the elements inside a container data structure. In this case, it is the client that knows what type the value really is, and will declare it as such. The library ADT module should know as little as possible about it, so it will declare it as REFANY or TAGGED REFANY. Here, you want the most general type possible, just to make the abstraction more versatile. And TAGGED REFANY generalizes it from REFANY. But... > >>> you'd like to store these in a REFANY and dynamically test for the >>> appropriate tagged type: >>> >> No, I do not want to store these in a variable of type REFANY or any >> other existing type. >> In fact, I want to forbid it. >> > > I think you are thinking of exactly the same kind of library code. > TextRefTbl.T, RefList.T, etc. > > After the introduction of TAGGED REFANY, what use is there for > REFANY? What piece of code can you think of where the cost of the > 1-LSB check of TAGGED REFANY outweighs the convenience of being > able to process objects of type TAGGED T (for all ref types T) as > well as objects of type T? > The other use is for the abstract type itself. Forgetting tagged types for a moment, I have never seen an interface/module that uses REFANY for this. Instead, the modules declare their abstract type as some proper subtype of REFANY, usually an opaque type. It would be possible to use just REFANY here of course, but that would require an otherwise unnecessary RT check on the allocated type, every time an operation of the module is called. This is a much more expensive check than a tag check, as has been pointed out in this discussion. But worse, it would sacrifice the static checking that we now have that prevents, at compile time, clients from passing, say a Text.T to some procedure in Atom that expects an Atom.T. If these modules ever wanted to use a tagged type, but the only tagged type were REFANY, we would lose this static checking, because Text.T would have to become equal to Atom.T. In cases where your algorithms don't specifically need dynamic typing, static typing is always much better, because one run of the compiler on the source code will do it. Bugs checked only at runtime require a massive test suit to be coded and then regularly rerun to get even close to the same confidence they've been found. So when using tagged types as the ADT itself,, we need to be able to have a tagged version of whatever proper subtype of REFANY the abstraction needs, including an opaque subtype of REFANY or an opaque subtype of some Public subtype of REFANY. This is why I am adamant that we need to be able to build a tagged type from any traced or object type. And once you do this, keeping REFANY itself unchanged and allowing TAGGED REFANY as one case of a tagged type falls out of the system for free _and_ saves a lot of cases that would otherwise need a new RT check that can never fail, but the language can't know that, because the type system has lost the distinction. I really feel that the fad of all dynamic typing in languages is a huge mistake and that it will someday be recognized as such. In the meantime, we have a language that provides a very extensive set of statically-typed alternatives, while also allowing dynamic typing when you really need it. This is one of Modula-3's best principles. Let's don't erode the static alternatives unnecessarily. > Mika > > From wagner at elegosoft.com Fri Apr 10 20:07:31 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 10 Apr 2009 20:07:31 +0200 Subject: [M3devel] FW: cvsup In-Reply-To: References: <20090409170205.0D1CF60C150@birch.elegosoft.com> Message-ID: <20090410200731.nho013ykaowwc4s0@mail.elegosoft.com> Quoting Jay : > > This is the first time I've used cvs import. > Hopefully I don't mess it up much. > > This is just an initial import with no changes, no attempt to build it, etc. > I think that's the right approach. You should use the latest version from the DCVS repository; it should be much more compatible with the recent CM3. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mika at async.caltech.edu Fri Apr 10 20:35:10 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 10 Apr 2009 11:35:10 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Fri, 10 Apr 2009 12:24:49 CDT." <49DF80E1.10709@cox.net> Message-ID: <200904101835.n3AIZACW001487@camembert.async.caltech.edu> Ahhhh!!!!! Now I get it, Rodney! You're talking about using tagged types "within" Modula-3. I've just been asking for tagged types to do something "that's not Modula-3". I'm completely aware that passing REFANY around is not the "Modula-3 way", and had no intention of making it so. (That's why I keep saying that only lazy people do it, so it doesn't matter.) My desire for storing integers and pointers in the same machine word is not something I thought would ever be useful in Modula-3 itself. But now what you say makes sense to me... you want to build your ADTs with this. Then you do need the full M3 type system "above" your tagged reference. I agree with you on MOST of the following: >I really feel that the fad of all dynamic typing in languages is a huge >mistake and that it will someday be recognized as such. In the >meantime, we have a language that provides a very extensive set >of statically-typed alternatives, while also allowing dynamic typing >when you really need it. This is one of Modula-3's best principles. >Let's don't erode the static alternatives unnecessarily. I program, currently, mostly in Scheme and in Modula-3, (mostly M3) and I am constantly amazed by: 1. The way that Modula-3 programs often are correct the first time they are compiled, even if they haven't been carefully designed. Using the M3 type system can really make your code obviously correct. 2. The way that Scheme programs can sometimes abstract away all sorts of type irrelevancies. In M3 you'd have to have many versions of the same code, or at least many generic instances. This is especially true for "higher-higher order" types, where one type is made from another and that was made from another, etc. (Interpret "type" liberally, please. It's probably just some sort of lambda expression.) Now I agree that untyped languages are probably a fad, and they have set computing back by years or decades(?). Too easy to make mistakes. But there is something of value there, and my feeling is that the best way to take advantage of it is to *combine* the two worlds, rather than trying to come up with some sort of "super language" that incorporates the best of both worlds and somehow manages to step on no one's toes. I'm presenting this as an alternative to type inferencing schemes in environments such as ML. So my idea, my "vision" if you like, is that we embed untyped languages in Modula-3. The parts of the system that need performance or are more convenient to program in the "bondage and discipline" world of Algol get written in Modula-3, and the parts of the system that it is more convenient (all things considered) to program in a typeless environment can be programmed in Scheme (currently, other interpreted languages can be added later if this turns out to be a good idea). But it is clear that the typeless approach of REFANY (REALLYREFANY, including the tagged types) is necessary to implement this layer of the system---if you want to be able to pass data structures seamlessly between the two layers. Maybe that explains better where I'm coming from. I have no intention of using these types for Modula-3 programming :-) However, I do see your point. A facility provided is a facility used, so if there's a very compact way of storing data in pointers, other applications than the ones I have in mind will use them, too, and perhaps lead to an abuse of Modula-3. But I'm not sure if this isn't over the line of legislating programming *style*---if we go down that route, we can do it the Java way and ban UNSAFE as well, so people won't be tempted to program C in Modula-3. In any case, the particular feature that one can hide 31 bits of information in a REFANY (and only a REFANY) can't hurt you if you don't choose to avail yourself of it---in fact it's transparent to people who don't care about it. Ok, an added 2 instructions out of 1,000 on an ISTYPE or TYPECASE of r : REFANY, but come on, that's not really an argument! So I am supportive of making a new type hierarchy TAGGED T for any T. And yes I understand that now---once you have TAGGED T---it is trivial to add a TAGGED REFANY, which you can distinguish from REFANY. I think your arguments for the TAGGED hierarchy are very good. However, I still don't think you have made a good argument *against* being able to hide 31 bits of information in a REFANY. You don't have to use the facility if it doesn't meet your requirements! Please remember that what I've been proposing is not a language change at all but a request that the runtime system and compiler respect a couple of not-difficult-to-ensure properties, so that we may do some new tricks in UNSAFE code. Nothing more than that. Mika P.S. You didn't actually give any examples of code where you would, after *your* proposed change, still use REFANY instead of switching the code to TAGGED REFANY. You said that: >And TAGGED REFANY generalizes it from REFANY. i.e., container code would switch to TAGGED REFANY >The other use is for the abstract type itself. Forgetting tagged >types for a moment, I have never seen an interface/module that >uses REFANY for this. Instead, the modules declare their abstract >type as some proper subtype of REFANY, usually an opaque type. i.e., other code doesn't actually use REFANY! (For what it's worth, your experience here matches mine. Container types (may) use REFANY and ADTs (almost) never do.) So back to my question: where would you use REFANY???? If never, then why bother having the two roots? What you're saying is that after *my* proposed runtime change, *you* will be tempted to abuse REFANY for ADTs. I don't think this is a very good argument against my proposal (but it is a good argument for yours, which is not incompatible with mine but instead expands it). The only thing that makes your proposal slightly incompatible with mine is that you're insisting on having a new distinction between REFANY and TAGGED REFANY, which I am saying will never be used in practice. And both your experience with Modula-3 and mine seem to back up this assertion. "Rodney M. Bates" writes: >Mika Nystrom wrote: >> Sorry to splice together two emails from you, but I feel I've already >> used up my m3devel quota this week: >> >> "Rodney M. Bates" writes: >> >>>> Are you sure? I want a type---some type---that can hold "any >>>> reference, even a tagged one", and I would rewrite most library >>>> code that today takes REFANY to take that instead. Why not? Why >>>> would I want to limit it to REFANY when it performs no operations >>>> that couldn't legally be performed on TAGGED REFANY. >>>> >>>> >>> I believe my "safe" proposal would make this very simple, if I am >>> thinking of the kind of library code you are. >>> >>> I envision a container data structure that takes in things and returns >>> them without performing operations on them other than moving them around >>> and storing them, e.g. the ever belabored stack. The values going in >>> and out are declared REFANY, and the client passes in values of >>> some proper subtype of REFANY, which get assigned to the REFANY >>> parameters. When it gets them back, it narrows them to this type. >>> >>> In this pattern, just changing the declared type of the container values >>> >> >from REFANY to TAGGED REFANY would do it. The library code's storage >> ... >> >There are two very different kinds of uses of reference and >tagged types. The one I speak of above is for the type of the >elements inside a container data structure. In this case, it >is the client that knows what type the value really is, and will >declare it as such. The library ADT module should know as little >as possible about it, so it will declare it as REFANY or >TAGGED REFANY. Here, you want the most general type >possible, just to make the abstraction more versatile. >And TAGGED REFANY generalizes it from REFANY. > >But... >> > > >>>> you'd like to store these in a REFANY and dynamically test for the >>>> appropriate tagged type: >>>> >>> No, I do not want to store these in a variable of type REFANY or any >>> other existing type. >>> In fact, I want to forbid it. >>> >> >> I think you are thinking of exactly the same kind of library code. >> TextRefTbl.T, RefList.T, etc. >> >> After the introduction of TAGGED REFANY, what use is there for >> REFANY? What piece of code can you think of where the cost of the >> 1-LSB check of TAGGED REFANY outweighs the convenience of being >> able to process objects of type TAGGED T (for all ref types T) as >> well as objects of type T? >> >The other use is for the abstract type itself. Forgetting tagged >types for a moment, I have never seen an interface/module that >uses REFANY for this. Instead, the modules declare their abstract >type as some proper subtype of REFANY, usually an opaque type. > >It would be possible to use just REFANY here of course, but that would >require an otherwise unnecessary RT check on the allocated type, >every time an operation of the module is called. This is a much >more expensive check than a tag check, as has been pointed out >in this discussion. > >But worse, it would sacrifice the static checking that we now have >that prevents, at compile time, clients from passing, say a Text.T >to some procedure in Atom that expects an Atom.T. If these modules >ever wanted to use a tagged type, but the only tagged type were >REFANY, we would lose this static checking, because Text.T would >have to become equal to Atom.T. > >In cases where your algorithms don't specifically need dynamic >typing, static typing is always much better, because one run of >the compiler on the source code will do it. Bugs checked >only at runtime require a massive test suit to be coded and then >regularly rerun to get even close to the same confidence they've >been found. > >So when using tagged types as the ADT itself,, we need to be able >to have a tagged version of whatever proper subtype of REFANY >the abstraction needs, including an opaque subtype of REFANY >or an opaque subtype of some Public subtype of REFANY. This is >why I am adamant that we need to be able to build a tagged type >from any traced or object type. > >And once you do this, keeping REFANY itself unchanged and allowing >TAGGED REFANY as one case of a tagged type falls out of the system >for free _and_ saves a lot of cases that would otherwise need a new RT >check that can never fail, but the language can't know that, because >the type system has lost the distinction. > >I really feel that the fad of all dynamic typing in languages is a huge >mistake and that it will someday be recognized as such. In the >meantime, we have a language that provides a very extensive set >of statically-typed alternatives, while also allowing dynamic typing >when you really need it. This is one of Modula-3's best principles. >Let's don't erode the static alternatives unnecessarily. > >> Mika >> >> From mika at async.caltech.edu Fri Apr 10 21:02:07 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 10 Apr 2009 12:02:07 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Fri, 10 Apr 2009 12:24:49 CDT." <49DF80E1.10709@cox.net> Message-ID: <200904101902.n3AJ27UI002559@camembert.async.caltech.edu> Specific proposal. What Rodney said, *except* make REFANY the root of everything. Insert an untagged root with a new name. Rodney himself has said that the uses of REFANY he knows about would be changed to accept the TAGGED type, so I simply propose allowing REFANY to handle the TAGGED type by default, and insert a new root for the untagged types. The structure of the type hierarchy is exactly the same as in Rodney's proposal, but the different naming makes it more backward-compatible. ROOT <: UNTAGGEDREFANY T <: UNTAGGEDREFANY UNTAGGEDREFANY <: REFANY and finally. TAGGED T <: REFANY (* for all T *) The advantages with this proposal are that it does precisely what Rodney is asking for (typesafe ADTs), but it's compatible with Tony's runtime changes in the *current* M3 implementation and it won't require anyone to do a massive search and replace, replacing REFANY with "TAGGED REFANY" in every existing Modula-3 program. Supposed disadvantage: every TYPECASE, NARROW, etc., of REFANY will cost an extra LSB check. Those who feel strongly about that and for some reason *know* that they don't want to process TAGGED types (which may be the empty set), can modify their code to use UNTAGGEDREFANY instead of REFANY. Mika "Rodney M. Bates" writes: >Mika Nystrom wrote: >> Sorry to splice together two emails from you, but I feel I've already >> used up my m3devel quota this week: >> >> "Rodney M. Bates" writes: >> >>>> Are you sure? I want a type---some type---that can hold "any >>>> reference, even a tagged one", and I would rewrite most library >>>> code that today takes REFANY to take that instead. Why not? Why >>>> would I want to limit it to REFANY when it performs no operations >>>> that couldn't legally be performed on TAGGED REFANY. >>>> >>>> >>> I believe my "safe" proposal would make this very simple, if I am >>> thinking of the kind of library code you are. >>> >>> I envision a container data structure that takes in things and returns >>> them without performing operations on them other than moving them around >>> and storing them, e.g. the ever belabored stack. The values going in >>> and out are declared REFANY, and the client passes in values of >>> some proper subtype of REFANY, which get assigned to the REFANY >>> parameters. When it gets them back, it narrows them to this type. >>> >>> In this pattern, just changing the declared type of the container values >>> >> >from REFANY to TAGGED REFANY would do it. The library code's storage >> ... >> >There are two very different kinds of uses of reference and >tagged types. The one I speak of above is for the type of the >elements inside a container data structure. In this case, it >is the client that knows what type the value really is, and will >declare it as such. The library ADT module should know as little >as possible about it, so it will declare it as REFANY or >TAGGED REFANY. Here, you want the most general type >possible, just to make the abstraction more versatile. >And TAGGED REFANY generalizes it from REFANY. > >But... >> > > >>>> you'd like to store these in a REFANY and dynamically test for the >>>> appropriate tagged type: >>>> >>> No, I do not want to store these in a variable of type REFANY or any >>> other existing type. >>> In fact, I want to forbid it. >>> >> >> I think you are thinking of exactly the same kind of library code. >> TextRefTbl.T, RefList.T, etc. >> >> After the introduction of TAGGED REFANY, what use is there for >> REFANY? What piece of code can you think of where the cost of the >> 1-LSB check of TAGGED REFANY outweighs the convenience of being >> able to process objects of type TAGGED T (for all ref types T) as >> well as objects of type T? >> >The other use is for the abstract type itself. Forgetting tagged >types for a moment, I have never seen an interface/module that >uses REFANY for this. Instead, the modules declare their abstract >type as some proper subtype of REFANY, usually an opaque type. > >It would be possible to use just REFANY here of course, but that would >require an otherwise unnecessary RT check on the allocated type, >every time an operation of the module is called. This is a much >more expensive check than a tag check, as has been pointed out >in this discussion. > >But worse, it would sacrifice the static checking that we now have >that prevents, at compile time, clients from passing, say a Text.T >to some procedure in Atom that expects an Atom.T. If these modules >ever wanted to use a tagged type, but the only tagged type were >REFANY, we would lose this static checking, because Text.T would >have to become equal to Atom.T. > >In cases where your algorithms don't specifically need dynamic >typing, static typing is always much better, because one run of >the compiler on the source code will do it. Bugs checked >only at runtime require a massive test suit to be coded and then >regularly rerun to get even close to the same confidence they've >been found. > >So when using tagged types as the ADT itself,, we need to be able >to have a tagged version of whatever proper subtype of REFANY >the abstraction needs, including an opaque subtype of REFANY >or an opaque subtype of some Public subtype of REFANY. This is >why I am adamant that we need to be able to build a tagged type >from any traced or object type. > >And once you do this, keeping REFANY itself unchanged and allowing >TAGGED REFANY as one case of a tagged type falls out of the system >for free _and_ saves a lot of cases that would otherwise need a new RT >check that can never fail, but the language can't know that, because >the type system has lost the distinction. > >I really feel that the fad of all dynamic typing in languages is a huge >mistake and that it will someday be recognized as such. In the >meantime, we have a language that provides a very extensive set >of statically-typed alternatives, while also allowing dynamic typing >when you really need it. This is one of Modula-3's best principles. >Let's don't erode the static alternatives unnecessarily. > >> Mika >> >> From mika at async.caltech.edu Fri Apr 10 21:18:38 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 10 Apr 2009 12:18:38 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Fri, 10 Apr 2009 12:24:49 CDT." <49DF80E1.10709@cox.net> Message-ID: <200904101918.n3AJIcLj003231@camembert.async.caltech.edu> Sigh, I hate sending so many emails to a mailing list. Sorry about the inboxes I'm clogging of people with no interest in this. But I just realized something important, which I think may be decisive in deciding the fate of the name "REFANY" in the addition of new types. Rodney proposes TAGGED T <: TAGGED REFANY T <: REFANY <: TAGGED REFANY I propose TAGGED T <: REFANY T <: UNTAGGEDREFANY <: REFANY Both proposals are identical in the power of the language that results, because they differ merely in naming. Both proposals are also backward-compatible: all existing Modula-3 programs are unchanged by them. However, UNTAGGEDREFANY (mine), is *forward*-compatible as well as backward-compatible. Think about it. The TAGGED REFANY proposal will have the following effect: people will go through all the M3 libraries and replace every or almost every occurrence of REFANY with TAGGED REFANY. The resulting code will not compile with an older compiler! In my proposal, it is the user of the TAGGED types who is responsible for---in new code only!---deciding whether he wants his code to compile both on older and newer M3 systems. If he does, then he can add appropriate implementations for compilers that don't support the TAGGED types (which will be trivial since he has to have those anyway!) The burden of handling change is on the programmer of the special new feature rather than on everyone who has a container module. I'll try to refrain from posting any more messages on this topic now. Mika "Rodney M. Bates" writes: >Mika Nystrom wrote: >> Sorry to splice together two emails from you, but I feel I've already >> used up my m3devel quota this week: >> >> "Rodney M. Bates" writes: >> >>>> Are you sure? I want a type---some type---that can hold "any >>>> reference, even a tagged one", and I would rewrite most library >>>> code that today takes REFANY to take that instead. Why not? Why >>>> would I want to limit it to REFANY when it performs no operations >>>> that couldn't legally be performed on TAGGED REFANY. >>>> >>>> >>> I believe my "safe" proposal would make this very simple, if I am >>> thinking of the kind of library code you are. >>> >>> I envision a container data structure that takes in things and returns >>> them without performing operations on them other than moving them around >>> and storing them, e.g. the ever belabored stack. The values going in >>> and out are declared REFANY, and the client passes in values of >>> some proper subtype of REFANY, which get assigned to the REFANY >>> parameters. When it gets them back, it narrows them to this type. >>> >>> In this pattern, just changing the declared type of the container values >>> >> >from REFANY to TAGGED REFANY would do it. The library code's storage >> ... >> >There are two very different kinds of uses of reference and >tagged types. The one I speak of above is for the type of the >elements inside a container data structure. In this case, it >is the client that knows what type the value really is, and will >declare it as such. The library ADT module should know as little >as possible about it, so it will declare it as REFANY or >TAGGED REFANY. Here, you want the most general type >possible, just to make the abstraction more versatile. >And TAGGED REFANY generalizes it from REFANY. > >But... >> > > >>>> you'd like to store these in a REFANY and dynamically test for the >>>> appropriate tagged type: >>>> >>> No, I do not want to store these in a variable of type REFANY or any >>> other existing type. >>> In fact, I want to forbid it. >>> >> >> I think you are thinking of exactly the same kind of library code. >> TextRefTbl.T, RefList.T, etc. >> >> After the introduction of TAGGED REFANY, what use is there for >> REFANY? What piece of code can you think of where the cost of the >> 1-LSB check of TAGGED REFANY outweighs the convenience of being >> able to process objects of type TAGGED T (for all ref types T) as >> well as objects of type T? >> >The other use is for the abstract type itself. Forgetting tagged >types for a moment, I have never seen an interface/module that >uses REFANY for this. Instead, the modules declare their abstract >type as some proper subtype of REFANY, usually an opaque type. > >It would be possible to use just REFANY here of course, but that would >require an otherwise unnecessary RT check on the allocated type, >every time an operation of the module is called. This is a much >more expensive check than a tag check, as has been pointed out >in this discussion. > >But worse, it would sacrifice the static checking that we now have >that prevents, at compile time, clients from passing, say a Text.T >to some procedure in Atom that expects an Atom.T. If these modules >ever wanted to use a tagged type, but the only tagged type were >REFANY, we would lose this static checking, because Text.T would >have to become equal to Atom.T. > >In cases where your algorithms don't specifically need dynamic >typing, static typing is always much better, because one run of >the compiler on the source code will do it. Bugs checked >only at runtime require a massive test suit to be coded and then >regularly rerun to get even close to the same confidence they've >been found. > >So when using tagged types as the ADT itself,, we need to be able >to have a tagged version of whatever proper subtype of REFANY >the abstraction needs, including an opaque subtype of REFANY >or an opaque subtype of some Public subtype of REFANY. This is >why I am adamant that we need to be able to build a tagged type >from any traced or object type. > >And once you do this, keeping REFANY itself unchanged and allowing >TAGGED REFANY as one case of a tagged type falls out of the system >for free _and_ saves a lot of cases that would otherwise need a new RT >check that can never fail, but the language can't know that, because >the type system has lost the distinction. > >I really feel that the fad of all dynamic typing in languages is a huge >mistake and that it will someday be recognized as such. In the >meantime, we have a language that provides a very extensive set >of statically-typed alternatives, while also allowing dynamic typing >when you really need it. This is one of Modula-3's best principles. >Let's don't erode the static alternatives unnecessarily. > >> Mika >> >> From hosking at cs.purdue.edu Sat Apr 11 00:16:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Apr 2009 08:16:07 +1000 Subject: [M3devel] Fwd: Output from "cron" command References: <200904101323.n3ADNfb4028603@niagara.cs.purdue.edu> Message-ID: <4F3FB486-EE62-4E46-BD8A-8D914710E3BF@cs.purdue.edu> SOLgnu failed again. Begin forwarded message: > From: Tony Hosking > Date: 10 April 2009 23:23:41 GMT+10:00 > To: hosking at cs.purdue.edu > Subject: Output from "cron" command > > Your "cron" job on niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/cron.sh > > produced the following output: > > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-04-10-10-30-04 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara release-build" > > creating log file /tmp/build-cm3-20090410-063006-Rbai0T/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.04.10 06:30:06 -- checkout in progress. > [start checkout 2009.04.10 06:30:09] > cd /tmp/build-cm3-20090410-063006-Rbai0T/build > cvs return value: 0 > [end checkout 2009.04.10 06:50:44] > CHECKOUT_RETURN = 0 > -- > 2009.04.10 06:50:46 -- compile in progress. > [start compile 2009.04.10 06:50:47] > compile return value: 0 > [end compile 2009.04.10 08:11:42] > COMPILE_RETURN = 1 > *** COMPILE FAILED > removing build tree /tmp/build-cm3-20090410-063006-Rbai0T ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-04-10-12-13-48 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" > > creating log file /tmp/build-cm3-20090410-081351-rXaGeZ/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.04.10 08:13:51 -- checkout in progress. > [start checkout 2009.04.10 08:13:53] > cd /tmp/build-cm3-20090410-081351-rXaGeZ/build > cvs return value: 0 > [end checkout 2009.04.10 08:35:16] > CHECKOUT_RETURN = 0 > -- > 2009.04.10 08:35:18 -- compile in progress. > [start compile 2009.04.10 08:35:18] > compile return value: 0 > [end compile 2009.04.10 09:21:41] > COMPILE_RETURN = 0 > 2009.04.10 09:21:45 -- tests in progress. > [start run-tests 2009.04.10 09:21:45] > cd /tmp/build-cm3-20090410-081351-rXaGeZ/build > [end run-tests 2009.04.10 09:21:45] > TESTS_RETURN = 0 > 2009.04.10 09:21:45 -- checkout, compile and test run done. > > --- > > removing build tree /tmp/build-cm3-20090410-081351-rXaGeZ ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > done. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 11 00:20:28 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 10 Apr 2009 22:20:28 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <4F3FB486-EE62-4E46-BD8A-8D914710E3BF@cs.purdue.edu> References: <200904101323.n3ADNfb4028603@niagara.cs.purdue.edu> <4F3FB486-EE62-4E46-BD8A-8D914710E3BF@cs.purdue.edu> Message-ID: Yes, sorry, I made a few slightly bad changes. Like three. All fixed. sizeof short, schedulerposix, ugrp (ugrp not a problem on this platform). Let's wait again, sorry. The config file/cminstall thing I didn't do anything with (before or after). So if that's still broken for you, still needs attention. - Jay ________________________________ > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Sat, 11 Apr 2009 08:16:07 +1000 > Subject: [M3devel] Fwd: Output from "cron" command > > SOLgnu failed again. > > Begin forwarded message: > > From: Tony Hosking> > Date: 10 April 2009 23:23:41 GMT+10:00 > To: hosking at cs.purdue.edu > Subject: Output from "cron" command > > Your "cron" job on niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/cron.sh > > produced the following output: > > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-04-10-10-30-04 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara release-build" > > creating log file /tmp/build-cm3-20090410-063006-Rbai0T/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.04.10 06:30:06 -- checkout in progress. > [start checkout 2009.04.10 06:30:09] > cd /tmp/build-cm3-20090410-063006-Rbai0T/build > cvs return value: 0 > [end checkout 2009.04.10 06:50:44] > CHECKOUT_RETURN = 0 > -- > 2009.04.10 06:50:46 -- compile in progress. > [start compile 2009.04.10 06:50:47] > compile return value: 0 > [end compile 2009.04.10 08:11:42] > COMPILE_RETURN = 1 > *** COMPILE FAILED > removing build tree /tmp/build-cm3-20090410-063006-Rbai0T ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-04-10-12-13-48 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" > > creating log file /tmp/build-cm3-20090410-081351-rXaGeZ/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.04.10 08:13:51 -- checkout in progress. > [start checkout 2009.04.10 08:13:53] > cd /tmp/build-cm3-20090410-081351-rXaGeZ/build > cvs return value: 0 > [end checkout 2009.04.10 08:35:16] > CHECKOUT_RETURN = 0 > -- > 2009.04.10 08:35:18 -- compile in progress. > [start compile 2009.04.10 08:35:18] > compile return value: 0 > [end compile 2009.04.10 09:21:41] > COMPILE_RETURN = 0 > 2009.04.10 09:21:45 -- tests in progress. > [start run-tests 2009.04.10 09:21:45] > cd /tmp/build-cm3-20090410-081351-rXaGeZ/build > [end run-tests 2009.04.10 09:21:45] > TESTS_RETURN = 0 > 2009.04.10 09:21:45 -- checkout, compile and test run done. > > --- > > removing build tree /tmp/build-cm3-20090410-081351-rXaGeZ ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > done. > From jay.krell at cornell.edu Sat Apr 11 00:25:11 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 10 Apr 2009 22:25:11 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <4F3FB486-EE62-4E46-BD8A-8D914710E3BF@cs.purdue.edu> References: <200904101323.n3ADNfb4028603@niagara.cs.purdue.edu> <4F3FB486-EE62-4E46-BD8A-8D914710E3BF@cs.purdue.edu> Message-ID: [was slightly truncated] ---------------------------------------- > From: jay.krell at cornell.edu > The config file/cminstall thing I didn't do anything with (before or after). > So if that's still broken for you, still needs attention. > > > - Jay From hosking at cs.purdue.edu Sat Apr 11 00:25:32 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Apr 2009 08:25:32 +1000 Subject: [M3devel] small objects In-Reply-To: <200904101918.n3AJIcLj003231@camembert.async.caltech.edu> References: <200904101918.n3AJIcLj003231@camembert.async.caltech.edu> Message-ID: <305809AF-0615-4D4F-BCA9-D801991D76ED@cs.purdue.edu> Too many e-mails to digest lately. I take it that Mika's is now definitive. Let me think it through. On 11 Apr 2009, at 05:18, Mika Nystrom wrote: > > Sigh, I hate sending so many emails to a mailing list. Sorry about > the inboxes I'm clogging of people with no interest in this. > > But I just realized something important, which I think may be > decisive in deciding the fate of the name "REFANY" in the addition > of new types. > > Rodney proposes > > TAGGED T <: TAGGED REFANY > T <: REFANY <: TAGGED REFANY > > I propose > > TAGGED T <: REFANY > T <: UNTAGGEDREFANY <: REFANY > > Both proposals are identical in the power of the language that > results, because they differ merely in naming. > > Both proposals are also backward-compatible: all existing Modula-3 > programs are unchanged by them. > > However, UNTAGGEDREFANY (mine), is *forward*-compatible as well > as backward-compatible. > > Think about it. The TAGGED REFANY proposal will have the following > effect: people will go through all the M3 libraries and replace > every or almost every occurrence of REFANY with TAGGED REFANY. The > resulting code will not compile with an older compiler! > > In my proposal, it is the user of the TAGGED types who is responsible > for---in new code only!---deciding whether he wants his code to > compile both on older and newer M3 systems. If he does, then he > can add appropriate implementations for compilers that don't support > the TAGGED types (which will be trivial since he has to have those > anyway!) The burden of handling change is on the programmer of the > special new feature rather than on everyone who has a container > module. > > I'll try to refrain from posting any more messages on this topic now. > > Mika > > "Rodney M. Bates" writes: >> Mika Nystrom wrote: >>> Sorry to splice together two emails from you, but I feel I've >>> already >>> used up my m3devel quota this week: >>> >>> "Rodney M. Bates" writes: >>> >>>>> Are you sure? I want a type---some type---that can hold "any >>>>> reference, even a tagged one", and I would rewrite most library >>>>> code that today takes REFANY to take that instead. Why not? Why >>>>> would I want to limit it to REFANY when it performs no operations >>>>> that couldn't legally be performed on TAGGED REFANY. >>>>> >>>>> >>>> I believe my "safe" proposal would make this very simple, if I am >>>> thinking of the kind of library code you are. >>>> >>>> I envision a container data structure that takes in things and >>>> returns >>>> them without performing operations on them other than moving them >>>> around >>>> and storing them, e.g. the ever belabored stack. The values >>>> going in >>>> and out are declared REFANY, and the client passes in values of >>>> some proper subtype of REFANY, which get assigned to the REFANY >>>> parameters. When it gets them back, it narrows them to this type. >>>> >>>> In this pattern, just changing the declared type of the container >>>> values >>>> >>>> from REFANY to TAGGED REFANY would do it. The library code's >>>> storage >>> ... >>> >> There are two very different kinds of uses of reference and >> tagged types. The one I speak of above is for the type of the >> elements inside a container data structure. In this case, it >> is the client that knows what type the value really is, and will >> declare it as such. The library ADT module should know as little >> as possible about it, so it will declare it as REFANY or >> TAGGED REFANY. Here, you want the most general type >> possible, just to make the abstraction more versatile. >> And TAGGED REFANY generalizes it from REFANY. >> >> But... >>> >> >> >>>>> you'd like to store these in a REFANY and dynamically test for the >>>>> appropriate tagged type: >>>>> >>>> No, I do not want to store these in a variable of type REFANY or >>>> any >>>> other existing type. >>>> In fact, I want to forbid it. >>>> >>> >>> I think you are thinking of exactly the same kind of library code. >>> TextRefTbl.T, RefList.T, etc. >>> >>> After the introduction of TAGGED REFANY, what use is there for >>> REFANY? What piece of code can you think of where the cost of the >>> 1-LSB check of TAGGED REFANY outweighs the convenience of being >>> able to process objects of type TAGGED T (for all ref types T) as >>> well as objects of type T? >>> >> The other use is for the abstract type itself. Forgetting tagged >> types for a moment, I have never seen an interface/module that >> uses REFANY for this. Instead, the modules declare their abstract >> type as some proper subtype of REFANY, usually an opaque type. >> >> It would be possible to use just REFANY here of course, but that >> would >> require an otherwise unnecessary RT check on the allocated type, >> every time an operation of the module is called. This is a much >> more expensive check than a tag check, as has been pointed out >> in this discussion. >> >> But worse, it would sacrifice the static checking that we now have >> that prevents, at compile time, clients from passing, say a Text.T >> to some procedure in Atom that expects an Atom.T. If these modules >> ever wanted to use a tagged type, but the only tagged type were >> REFANY, we would lose this static checking, because Text.T would >> have to become equal to Atom.T. >> >> In cases where your algorithms don't specifically need dynamic >> typing, static typing is always much better, because one run of >> the compiler on the source code will do it. Bugs checked >> only at runtime require a massive test suit to be coded and then >> regularly rerun to get even close to the same confidence they've >> been found. >> >> So when using tagged types as the ADT itself,, we need to be able >> to have a tagged version of whatever proper subtype of REFANY >> the abstraction needs, including an opaque subtype of REFANY >> or an opaque subtype of some Public subtype of REFANY. This is >> why I am adamant that we need to be able to build a tagged type >> from any traced or object type. >> >> And once you do this, keeping REFANY itself unchanged and allowing >> TAGGED REFANY as one case of a tagged type falls out of the system >> for free _and_ saves a lot of cases that would otherwise need a new >> RT >> check that can never fail, but the language can't know that, because >> the type system has lost the distinction. >> >> I really feel that the fad of all dynamic typing in languages is a >> huge >> mistake and that it will someday be recognized as such. In the >> meantime, we have a language that provides a very extensive set >> of statically-typed alternatives, while also allowing dynamic typing >> when you really need it. This is one of Modula-3's best principles. >> Let's don't erode the static alternatives unnecessarily. >> >>> Mika >>> >>> From jay.krell at cornell.edu Sat Apr 11 00:24:28 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 10 Apr 2009 22:24:28 +0000 Subject: [M3devel] "cvsup compat"? (really, general source compat) Message-ID: The subject isn't really the whole subject. cvsup compat? I could make the cvsup source highly compatible with "all" Modula-3 distributions by giving it its own "SupUnix.i3", implemented mostly in C, using INTEGER more and LONGINT less. Even its own SchedulerPosix with Enable/DisableSwitching. It would just, like, IMPORT SupUnix as Unix, IMPORT SupScheduler as SchedulerPosix, leading to the overall source changes being small. Or I could adapt it to current cm3, not compatible with any other older versions or forks (ezm3, pm3, old cm3, etc.) Use LONGINT. Use some of the slightly copying wrappers (Ugrp, Unetdb). Thoughts? Maintaining full source compat in cm3 itself I think is not an option. But almost. At least stat should always return 64bit file sizes. Or at least a 53bit double..I doubt that helps though. Most of the rest of "problems" could be "fixed". Such as by restoring a little bit of header cloning -- more for Ugrp and Unetdb, not Ustat, and verify the correctness in the C code. (because Ustat already has a place to copy an idealized type to, whereas Ugrp and Unetdb don't, unless interfaces altered like I did.) And using INTEGER more and LONGINT less. Not just because older compilers don't support LONGINT, but because code that uses one is not compatible with interfaces that use the other, even on 64bit platforms where they are "the same". (like on 32bit platforms, in C, int* and long* are compatible). I'd have to do more research though, like on ino_t and dev_t. They are 64bits on Linux/AMD64, I don't know if they ever are on any 32bit platforms, in which case LONGINT comes back. (other point here is LONGINT or, really, my preference, INT64 and UINT64 should have been added to the language over 10 years ago, then these would have been smoothed out by now..oh well..or possibly INTEGER and LONGINT should be more source compatible, but I realize there are arguments against some of that -- you could make it so on 64bit, but then a bunch of code would be produced that only compiled on 64bit platforms.) I'll probably go ahead and adapt it to current cm3. The other option can be explored later independently. Could be that nothing but current cm3 matters much. - Jay From jay.krell at cornell.edu Sat Apr 11 00:27:17 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 10 Apr 2009 22:27:17 +0000 Subject: [M3devel] tinderbox summary log Message-ID: This is very minor. The tinderbox summary log doesn't show stuff like: "../src/thread/PTHREAD/ThreadPThread.m3", line 7: symbol redefined (DisableSwitching) 4402 "../src/thread/PTHREAD/ThreadPThread.m3", line 7: symbol redefined (EnableSwitching) 4403 2 errors encountered Or at least the first two lines. If it does find the last, fix is to always show a few lines of "context". But the full log works well enough, the errors occur near the end. Not a big deal. (One might say -- but don't make such errors..but hey, tinderbox is all about catching errors...) - Jay From wagner at elegosoft.com Sat Apr 11 10:46:40 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 11 Apr 2009 10:46:40 +0200 Subject: [M3devel] tinderbox summary log In-Reply-To: References: Message-ID: <20090411104640.7cm9u7utc40oscoc@mail.elegosoft.com> Quoting Jay : > > This is very minor. > > The tinderbox summary log doesn't show stuff like: > > "../src/thread/PTHREAD/ThreadPThread.m3", line 7: symbol > redefined (DisableSwitching) > 4402 "../src/thread/PTHREAD/ThreadPThread.m3", line 7: > symbol redefined (EnableSwitching) > 4403 2 errors encountered > > > Or at least the first two lines. > If it does find the last, fix is to always show a few lines of "context". > > But the full log works well enough, the errors occur near the end. > > Not a big deal. > (One might say -- but don't make such errors..but hey, tinderbox is > all about catching errors...) Anybody here who would like to work on improving and fixing our tinderbox installation on birch again? Michael Anderson has not too much time to spend for cm3, and Ronny, who made the last installation, doesn't work for us anymore. So if you like perl scripting, this would be a great opportunity ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 11 10:55:12 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 11 Apr 2009 10:55:12 +0200 Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN Message-ID: <20090411105512.92784fp7cc0o448k@mail.elegosoft.com> After trying to upgrade cm3 on my notebook to the latest version, I get lots of internal compiler errors.This is on % uname -a Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power Macintosh powerpc ... new source -> compiling RuntimeError.m3 ../src/runtime/common/RuntimeError.m3: In function 'RuntimeError__Tag': ../src/runtime/common/RuntimeError.m3:56: error: type mismatch in binary expression int_32 int_32 word_32 D.252 = D.251 * 4 ../src/runtime/common/RuntimeError.m3:56: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. ... Full log attached. Before you ask, it won't be easy to upgrade Darwin on this notebook, and I surely cannot do this within the next two weeks :-/ Any ideas? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 -------------- /Users/wagner/work/cm3/scripts/do-pkg.sh buildship sysutils m3bundle m3middle m3quake patternmatching cminstall /Users/wagner/work/cm3/scripts/pkgmap.sh -c "cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' " sysutils m3bundle m3middle m3quake patternmatching cminstall === package m3-libs/sysutils === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/sysutils/PPC_DARWIN .M3EXPORTS libsysutils.5.2.dylib libsysutils.5.dylib libsysutils.dylib libsysutils.a libsysutils.m3x .M3WEB ../PPC_DARWIN => /usr/local/cm3/pkg/sysutils/PPC_DARWIN TextTextSeqTbl.i3 TextTextSeqTbl.m3 ../src => /usr/local/cm3/pkg/sysutils/src EnvUtils.i3 EnvUtils.m3 FingerprintFmt.i3 FingerprintFmt.m3 FSUtils.i3 FSUtils.m3 SMsg.i3 SMsg.m3 MsgIF.m3 MsgIF.i3 MsgX.m3 MsgX.i3 ProcessEnv.i3 ProcessEnv.m3 System.i3 System.m3 PathRepr.i3 PathReprCommon.m3 TextUtils.i3 TextReadingUtils.m3 TextReadingUtils.i3 OSSpecials.i3 FastLex.i3 FastLex.m3 Confirmation.i3 Confirmation.m3 DirStack.i3 DirStack.m3 ConnectRdWr.m3 ConnectRdWr.i3 ../src/POSIX => /usr/local/cm3/pkg/sysutils/src/POSIX OSSpecialsPosix.m3 PathReprPosix.m3 SystemPosix.m3 FSUnix_cm3.m3 ../src/cm3 => /usr/local/cm3/pkg/sysutils/src/cm3 TextUtils.m3 ==> m3-libs/sysutils done === package m3-tools/m3bundle === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/m3bundle/PPC_DARWIN .M3EXPORTS .M3WEB ../src => /usr/local/cm3/pkg/m3bundle/src m3bundle.m3 . => /usr/local/cm3/bin m3bundle . => /usr/local/cm3/man/man1 m3bundle.1 ==> m3-tools/m3bundle done === package m3-sys/m3middle === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/m3middle/PPC_DARWIN .M3EXPORTS libm3middle.a libm3middle.m3x .M3WEB ../src/POSIX => /usr/local/cm3/pkg/m3middle/src/POSIX M3Process.m3 CoffTime.i3 CoffTime.m3 ../src => /usr/local/cm3/pkg/m3middle/src Target.i3 Target.m3 TargetMap.i3 TargetMap.m3 TInt.i3 TInt.m3 TWord.m3 TWord.i3 TFloat.i3 TFloat.m3 M3FP.i3 M3FP.m3 M3Buf.i3 M3Buf.m3 M3ID.i3 M3ID.m3 M3Timers.m3 M3Timers.i3 M3File.i3 M3File.m3 M3Process.i3 M3CG.i3 M3CG.m3 M3CG_Ops.i3 M3CG_Check.i3 M3CG_Check.m3 M3CG_Rd.m3 M3CG_Rd.i3 M3CG_Wr.i3 M3CG_Wr.m3 M3CG_Binary.i3 M3CG_Binary.m3 M3CG_BinRd.m3 M3CG_BinRd.i3 M3CG_BinWr.i3 M3CG_BinWr.m3 M3RT.i3 M3RT.m3 ==> m3-sys/m3middle done === package m3-sys/m3quake === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/m3quake/PPC_DARWIN .M3EXPORTS libm3quake.a libm3quake.m3x .M3WEB ../PPC_DARWIN => /usr/local/cm3/pkg/m3quake/PPC_DARWIN QVTbl.m3 QVTbl.i3 QVSeq.i3 QVSeq.m3 QVSeqRep.i3 ../src => /usr/local/cm3/pkg/m3quake/src Quake.i3 Quake.m3 QToken.i3 QToken.m3 QIdent.m3 QIdent.i3 QScanner.i3 QScanner.m3 QCode.i3 QCode.m3 QCompiler.m3 QCompiler.i3 QValue.m3 QValue.i3 QMachine.i3 QMachine.m3 QVal.i3 QVal.m3 MxConfig.i3 MxConfig.m3 ==> m3-sys/m3quake done === package m3-libs/patternmatching === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/patternmatching/PPC_DARWIN .M3EXPORTS libpatternmatching.5.2.dylib libpatternmatching.5.dylib libpatternmatching.dylib libpatternmatching.a libpatternmatching.m3x .M3WEB ../src/libglob => /usr/local/cm3/pkg/patternmatching/src/libglob fnmatch.c ../src => /usr/local/cm3/pkg/patternmatching/src RegEx.i3 RegEx.m3 Uglob.i3 Glob.i3 Glob.m3 GlobTree.i3 GlobTree.m3 ==> m3-libs/patternmatching done === package m3-sys/cminstall === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/cminstall/PPC_DARWIN .M3EXPORTS .M3WEB ../PPC_DARWIN => /usr/local/cm3/pkg/cminstall/PPC_DARWIN Setup.i3 Setup.m3 InstallTarget.i3 ../src => /usr/local/cm3/pkg/cminstall/src Msg.m3 Msg.i3 Text2.i3 Text2.m3 OS.i3 OS.m3 Registry.i3 Main.m3 OSPOSIX.m3 RegistryPOSIX.m3 . => /usr/local/cm3/pkg/cminstall/PPC_DARWIN cminstall ==> m3-sys/cminstall done /Users/wagner/work/cm3/scripts/do-pkg.sh buildship sysutils m3middle m3objfile m3linker m3back m3front m3quake cm3 /Users/wagner/work/cm3/scripts/pkgmap.sh -c "cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' " sysutils m3middle m3objfile m3linker m3back m3front m3quake cm3 === package m3-libs/sysutils === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/sysutils/PPC_DARWIN .M3EXPORTS libsysutils.5.2.dylib libsysutils.5.dylib libsysutils.dylib libsysutils.a libsysutils.m3x .M3WEB ../PPC_DARWIN => /usr/local/cm3/pkg/sysutils/PPC_DARWIN TextTextSeqTbl.i3 TextTextSeqTbl.m3 ../src => /usr/local/cm3/pkg/sysutils/src EnvUtils.i3 EnvUtils.m3 FingerprintFmt.i3 FingerprintFmt.m3 FSUtils.i3 FSUtils.m3 SMsg.i3 SMsg.m3 MsgIF.m3 MsgIF.i3 MsgX.m3 MsgX.i3 ProcessEnv.i3 ProcessEnv.m3 System.i3 System.m3 PathRepr.i3 PathReprCommon.m3 TextUtils.i3 TextReadingUtils.m3 TextReadingUtils.i3 OSSpecials.i3 FastLex.i3 FastLex.m3 Confirmation.i3 Confirmation.m3 DirStack.i3 DirStack.m3 ConnectRdWr.m3 ConnectRdWr.i3 ../src/POSIX => /usr/local/cm3/pkg/sysutils/src/POSIX OSSpecialsPosix.m3 PathReprPosix.m3 SystemPosix.m3 FSUnix_cm3.m3 ../src/cm3 => /usr/local/cm3/pkg/sysutils/src/cm3 TextUtils.m3 ==> m3-libs/sysutils done === package m3-sys/m3middle === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/m3middle/PPC_DARWIN .M3EXPORTS libm3middle.a libm3middle.m3x .M3WEB ../src/POSIX => /usr/local/cm3/pkg/m3middle/src/POSIX M3Process.m3 CoffTime.i3 CoffTime.m3 ../src => /usr/local/cm3/pkg/m3middle/src Target.i3 Target.m3 TargetMap.i3 TargetMap.m3 TInt.i3 TInt.m3 TWord.m3 TWord.i3 TFloat.i3 TFloat.m3 M3FP.i3 M3FP.m3 M3Buf.i3 M3Buf.m3 M3ID.i3 M3ID.m3 M3Timers.m3 M3Timers.i3 M3File.i3 M3File.m3 M3Process.i3 M3CG.i3 M3CG.m3 M3CG_Ops.i3 M3CG_Check.i3 M3CG_Check.m3 M3CG_Rd.m3 M3CG_Rd.i3 M3CG_Wr.i3 M3CG_Wr.m3 M3CG_Binary.i3 M3CG_Binary.m3 M3CG_BinRd.m3 M3CG_BinRd.i3 M3CG_BinWr.i3 M3CG_BinWr.m3 M3RT.i3 M3RT.m3 ==> m3-sys/m3middle done === package m3-sys/m3objfile === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/m3objfile/PPC_DARWIN .M3EXPORTS libm3objfile.a libm3objfile.m3x .M3WEB ../src => /usr/local/cm3/pkg/m3objfile/src Coff.i3 Coff.m3 M3ObjFile.i3 M3ObjFile.m3 MasmObjFile.i3 MasmObjFile.m3 NTObjFile.i3 NTObjFile.m3 ==> m3-sys/m3objfile done === package m3-sys/m3linker === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/m3linker/PPC_DARWIN .M3EXPORTS libm3link.a libm3link.m3x .M3WEB ../src => /usr/local/cm3/pkg/m3linker/src Mx.i3 Mx.m3 MxIn.i3 MxIn.m3 MxOut.i3 MxOut.m3 MxMerge.m3 MxMerge.i3 MxCheck.i3 MxCheck.m3 MxGen.i3 MxGen.m3 MxVS.m3 MxVS.i3 MxRep.i3 MxRep.m3 MxMap.i3 MxMap.m3 MxSet.m3 MxSet.i3 MxVSSet.i3 MxVSSet.m3 MxIO.i3 MxIO.m3 ==> m3-sys/m3linker done === package m3-sys/m3back === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/m3back/PPC_DARWIN .M3EXPORTS libm3back.a libm3back.m3x .M3WEB ../src => /usr/local/cm3/pkg/m3back/src M3x86.i3 M3x86.m3 M3x86Rep.i3 Wrx86.i3 Wrx86.m3 Stackx86.i3 Stackx86.m3 Codex86.i3 Codex86.m3 ==> m3-sys/m3back done === package m3-sys/m3front === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/m3front/PPC_DARWIN .M3EXPORTS libm3front.a libm3front.m3x .M3WEB ../src/types => /usr/local/cm3/pkg/m3front/src/types Type.i3 Type.m3 TypeRep.i3 ArrayType.i3 ArrayType.m3 Brand.i3 Brand.m3 EnumType.i3 EnumType.m3 NamedType.m3 NamedType.i3 ObjectType.i3 ObjectType.m3 OpaqueType.i3 OpaqueType.m3 OpenArrayType.i3 OpenArrayType.m3 PackedType.m3 PackedType.i3 ProcType.i3 ProcType.m3 RecordType.i3 RecordType.m3 RefType.i3 RefType.m3 SetType.m3 SetType.i3 SubrangeType.i3 SubrangeType.m3 TypeFP.i3 TypeFP.m3 TypeTbl.i3 TypeTbl.m3 UserProc.i3 UserProc.m3 ../src/builtinOps => /usr/local/cm3/pkg/m3front/src/builtinOps Abs.i3 Abs.m3 Adr.m3 Adr.i3 AdrSize.i3 AdrSize.m3 BitSize.i3 BitSize.m3 BuiltinOps.i3 BuiltinOps.m3 ByteSize.i3 ByteSize.m3 Cas.m3 Cas.i3 CasP.i3 CasP.m3 Ceiling.m3 Ceiling.i3 Dec.i3 Dec.m3 Dispose.m3 Dispose.i3 First.i3 First.m3 Floatt.i3 Floatt.m3 Floor.i3 Floor.m3 Inc.i3 Inc.m3 IsType.i3 IsType.m3 Last.m3 Last.i3 Loophole.i3 Loophole.m3 Max.m3 Max.i3 Min.i3 Min.m3 Narrow.m3 Narrow.i3 New.m3 New.i3 Number.i3 Number.m3 Ord.m3 Ord.i3 Round.m3 Round.i3 Subarray.i3 Subarray.m3 Trunc.i3 Trunc.m3 Typecode.m3 Typecode.i3 Val.i3 Val.m3 ../src/builtinWord => /usr/local/cm3/pkg/m3front/src/builtinWord WordAnd.m3 WordAnd.i3 WordDivide.i3 WordDivide.m3 WordExtract.i3 WordExtract.m3 WordGE.m3 WordGE.i3 WordGT.i3 WordGT.m3 WordInsert.m3 WordInsert.i3 WordLE.m3 WordLE.i3 WordLT.i3 WordLT.m3 WordMinus.m3 WordMinus.i3 WordMod.i3 WordMod.m3 WordModule.i3 WordModule.m3 WordNot.i3 WordNot.m3 WordOr.i3 WordOr.m3 WordPlus.i3 WordPlus.m3 WordRotate.i3 WordRotate.m3 WordShift.i3 WordShift.m3 WordTimes.i3 WordTimes.m3 WordXor.m3 WordXor.i3 ../src/builtinLong => /usr/local/cm3/pkg/m3front/src/builtinLong LongAnd.i3 LongAnd.m3 LongDivide.i3 LongDivide.m3 LongExtract.i3 LongExtract.m3 LongGE.i3 LongGE.m3 LongGT.m3 LongGT.i3 LongInsert.m3 LongInsert.i3 LongLE.i3 LongLE.m3 LongLT.i3 LongLT.m3 LongMinus.i3 LongMinus.m3 LongMod.i3 LongMod.m3 LongModule.i3 LongModule.m3 LongNot.i3 LongNot.m3 LongOr.m3 LongOr.i3 LongPlus.i3 LongPlus.m3 LongRotate.i3 LongRotate.m3 LongShift.i3 LongShift.m3 LongTimes.i3 LongTimes.m3 LongXor.i3 LongXor.m3 ../src/builtinInfo => /usr/local/cm3/pkg/m3front/src/builtinInfo InfoModule.i3 InfoModule.m3 InfoThisFile.m3 InfoThisFile.i3 InfoThisPath.i3 InfoThisPath.m3 InfoThisLine.i3 InfoThisLine.m3 InfoThisException.i3 InfoThisException.m3 ../src/builtinTypes => /usr/local/cm3/pkg/m3front/src/builtinTypes Addr.i3 Addr.m3 Bool.i3 Bool.m3 BuiltinTypes.m3 BuiltinTypes.i3 Charr.i3 Charr.m3 Card.i3 Card.m3 EReel.i3 EReel.m3 ErrType.i3 ErrType.m3 Int.i3 Int.m3 LInt.i3 LInt.m3 LReel.m3 LReel.i3 Mutex.i3 Mutex.m3 Null.i3 Null.m3 ObjectAdr.m3 ObjectAdr.i3 ObjectRef.m3 ObjectRef.i3 Reel.m3 Reel.i3 Reff.i3 Reff.m3 Textt.m3 Textt.i3 WCharr.i3 WCharr.m3 ../src/exprs => /usr/local/cm3/pkg/m3front/src/exprs Expr.i3 Expr.m3 ExprRep.i3 AddExpr.i3 AddExpr.m3 AddressExpr.i3 AddressExpr.m3 AndExpr.i3 AndExpr.m3 ArrayExpr.m3 ArrayExpr.i3 CallExpr.i3 CallExpr.m3 CastExpr.i3 CastExpr.m3 CheckExpr.i3 CheckExpr.m3 CompareExpr.i3 CompareExpr.m3 ConcatExpr.i3 ConcatExpr.m3 ConsExpr.i3 ConsExpr.m3 DerefExpr.i3 DerefExpr.m3 DivExpr.i3 DivExpr.m3 DivideExpr.i3 DivideExpr.m3 EnumExpr.m3 EnumExpr.i3 EqualExpr.i3 EqualExpr.m3 ExprParse.i3 ExprParse.m3 InExpr.m3 InExpr.i3 IntegerExpr.m3 IntegerExpr.i3 KeywordExpr.m3 KeywordExpr.i3 MethodExpr.m3 MethodExpr.i3 ModExpr.i3 ModExpr.m3 MultiplyExpr.m3 MultiplyExpr.i3 NamedExpr.m3 NamedExpr.i3 NarrowExpr.m3 NarrowExpr.i3 NegateExpr.m3 NegateExpr.i3 NilChkExpr.i3 NilChkExpr.m3 NotExpr.i3 NotExpr.m3 OrExpr.i3 OrExpr.m3 PlusExpr.i3 PlusExpr.m3 ProcExpr.i3 ProcExpr.m3 QualifyExpr.i3 QualifyExpr.m3 RangeExpr.m3 RangeExpr.i3 RecordExpr.m3 RecordExpr.i3 ReelExpr.m3 ReelExpr.i3 SetExpr.m3 SetExpr.i3 SubscriptExpr.i3 SubscriptExpr.m3 SubtractExpr.i3 SubtractExpr.m3 TextExpr.i3 TextExpr.m3 TypeExpr.i3 TypeExpr.m3 VarExpr.i3 VarExpr.m3 ../src/misc => /usr/local/cm3/pkg/m3front/src/misc M3.i3 M3.m3 M3Front.i3 M3Front.m3 M3Compiler.m3 M3Compiler.i3 M3Header.m3 M3Header.i3 M3String.m3 M3String.i3 M3WString.i3 M3WString.m3 Token.i3 Token.m3 Error.m3 Error.i3 Host.m3 Host.i3 Marker.m3 Marker.i3 Scanner.i3 Scanner.m3 Scope.i3 Scope.m3 Coverage.i3 Coverage.m3 ESet.i3 ESet.m3 ProcBody.i3 ProcBody.m3 CG.i3 CG.m3 RunTyme.i3 RunTyme.m3 TipeMap.i3 TipeMap.m3 TipeDesc.i3 TipeDesc.m3 Tracer.i3 Tracer.m3 WebInfo.i3 WebInfo.m3 ../src/stmts => /usr/local/cm3/pkg/m3front/src/stmts Stmt.i3 Stmt.m3 StmtRep.i3 AssertStmt.m3 AssertStmt.i3 AssignStmt.i3 AssignStmt.m3 BlockStmt.i3 BlockStmt.m3 CallStmt.i3 CallStmt.m3 CaseStmt.i3 CaseStmt.m3 DebugStmt.i3 DebugStmt.m3 EvalStmt.i3 EvalStmt.m3 ExitStmt.i3 ExitStmt.m3 ForStmt.i3 ForStmt.m3 IfStmt.i3 IfStmt.m3 LockStmt.m3 LockStmt.i3 LoopStmt.m3 LoopStmt.i3 RaiseStmt.m3 RaiseStmt.i3 RepeatStmt.m3 RepeatStmt.i3 ReturnStmt.i3 ReturnStmt.m3 TryFinStmt.m3 TryFinStmt.i3 TryStmt.i3 TryStmt.m3 TypeCaseStmt.m3 TypeCaseStmt.i3 WhileStmt.i3 WhileStmt.m3 WithStmt.m3 WithStmt.i3 ../src/values => /usr/local/cm3/pkg/m3front/src/values Module.i3 Module.m3 Value.i3 Value.m3 ValueRep.i3 Constant.i3 Constant.m3 Decl.m3 Decl.i3 EnumElt.i3 EnumElt.m3 Exceptionz.i3 Exceptionz.m3 External.i3 External.m3 Field.i3 Field.m3 Formal.i3 Formal.m3 Ident.i3 Ident.m3 Method.m3 Method.i3 Procedure.i3 Procedure.m3 Revelation.m3 Revelation.i3 Tipe.i3 Tipe.m3 Variable.i3 Variable.m3 ==> m3-sys/m3front done === package m3-sys/m3quake === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/m3quake/PPC_DARWIN .M3EXPORTS libm3quake.a libm3quake.m3x .M3WEB ../PPC_DARWIN => /usr/local/cm3/pkg/m3quake/PPC_DARWIN QVTbl.m3 QVTbl.i3 QVSeq.i3 QVSeq.m3 QVSeqRep.i3 ../src => /usr/local/cm3/pkg/m3quake/src Quake.i3 Quake.m3 QToken.i3 QToken.m3 QIdent.m3 QIdent.i3 QScanner.i3 QScanner.m3 QCode.i3 QCode.m3 QCompiler.m3 QCompiler.i3 QValue.m3 QValue.i3 QMachine.i3 QMachine.m3 QVal.i3 QVal.m3 MxConfig.i3 MxConfig.m3 ==> m3-sys/m3quake done === package m3-sys/cm3 === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides new source -> compiling Version.i3 new source -> compiling M3Backend.i3 new source -> compiling Arg.i3 new source -> compiling Utils.i3 new source -> compiling Msg.i3 new source -> compiling M3Backend.m3 new source -> compiling UtilsPosix.m3 new source -> compiling Arg.m3 new source -> compiling M3Path.i3 new source -> compiling M3Loc.i3 new source -> compiling M3Unit.i3 new source -> compiling Builder.i3 new source -> compiling M3Options.i3 new source -> compiling WebFile.i3 new source -> compiling Dirs.i3 new source -> compiling Builder.m3 new source -> compiling Dirs.m3 new source -> compiling M3Build.i3 new source -> compiling M3Build.m3 new source -> compiling M3Loc.m3 new source -> compiling M3Options.m3 new source -> compiling M3Path.m3 new source -> compiling M3Unit.m3 new source -> compiling Makefile.i3 new source -> compiling Makefile.m3 new source -> compiling Msg.m3 new source -> compiling Utils.m3 new source -> compiling WebFile.m3 new source -> compiling Main.m3 new exporters -> recompiling Utils.i3 -> linking cm3 --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/cm3/PPC_DARWIN .M3EXPORTS .M3WEB ../PPC_DARWIN => /usr/local/cm3/pkg/cm3/PPC_DARWIN Version.i3 ../src => /usr/local/cm3/pkg/cm3/src M3Backend.i3 M3Backend.m3 UtilsPosix.m3 Arg.i3 Arg.m3 Builder.m3 Builder.i3 Dirs.i3 Dirs.m3 M3Build.i3 M3Build.m3 M3Loc.i3 M3Loc.m3 M3Options.m3 M3Options.i3 M3Path.i3 M3Path.m3 M3Unit.i3 M3Unit.m3 Makefile.i3 Makefile.m3 Msg.m3 Msg.i3 Utils.i3 Utils.m3 WebFile.i3 WebFile.m3 Main.m3 . => /usr/local/cm3/pkg/cm3/PPC_DARWIN cm3 ==> m3-sys/cm3 done /Users/wagner/work/cm3/scripts/do-pkg.sh build m3cc /Users/wagner/work/cm3/scripts/pkgmap.sh -c "cm3 -build -override -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' " m3cc === package m3-sys/m3cc === +++ cm3 -build -override -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- cd . && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: configure-host | tee -a _m3.log cd . && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: configure-host | tee -a _m3.log make all-recursive Making all in tests Making all in . make[4]: Nothing to be done for `all-am'. Making all in devel make[4]: Nothing to be done for `all'. Making all in mpn make[4]: Nothing to be done for `all'. Making all in mpz make[4]: Nothing to be done for `all'. Making all in mpq make[4]: Nothing to be done for `all'. Making all in mpf make[4]: Nothing to be done for `all'. Making all in rand make[4]: Nothing to be done for `all'. Making all in misc make[4]: Nothing to be done for `all'. Making all in cxx make[4]: Nothing to be done for `all'. Making all in mpbsd make[4]: Nothing to be done for `all'. Making all in mpn make[3]: Nothing to be done for `all'. Making all in mpz make[3]: Nothing to be done for `all'. Making all in mpq make[3]: Nothing to be done for `all'. Making all in mpf make[3]: Nothing to be done for `all'. Making all in printf make[3]: Nothing to be done for `all'. Making all in scanf make[3]: Nothing to be done for `all'. Making all in cxx make[3]: Nothing to be done for `all'. Making all in mpbsd make[3]: Nothing to be done for `all'. Making all in demos Making all in calc make all-am make[5]: Nothing to be done for `all-am'. Making all in expr make[4]: Nothing to be done for `all'. make[4]: Nothing to be done for `all-am'. Making all in tune make[3]: Nothing to be done for `all'. Making all in doc make[3]: Nothing to be done for `all'. make[3]: Nothing to be done for `all-am'. sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./gcc/Makefile > ./gcc/Makefile.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./gcc/Makefile > ./gcc/Makefile.1 ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./gcc/Makefile > ./gcc/Makefile.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./gcc/Makefile > ./gcc/Makefile.1 ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile sed -e 's/^#define HAVE_ICONV 1$//' < ./gcc/Makefile > ./gcc/Makefile.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./gcc/Makefile > ./gcc/Makefile.1 ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile sed -e 's/^#define HAVE_ICONV_H 1$//' < ./gcc/Makefile > ./gcc/Makefile.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./gcc/Makefile > ./gcc/Makefile.1 ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h sed -e 's/^#define HAVE_ICONV 1$//' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h sed -e 's/^#define HAVE_ICONV_H 1$//' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./gcc/config.h > ./gcc/config.h.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./gcc/config.h > ./gcc/config.h.1 ../gcc/move-if-change ./gcc/config.h.1 ./gcc/config.h ../gcc/move-if-change ./gcc/config.h.1 ./gcc/config.h sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./gcc/config.h > ./gcc/config.h.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./gcc/config.h > ./gcc/config.h.1 ../gcc/move-if-change ./gcc/config.h.1 ./gcc/config.h ../gcc/move-if-change ./gcc/config.h.1 ./gcc/config.h sed -e 's/^#define HAVE_ICONV 1$//' < ./gcc/config.h > ./gcc/config.h.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./gcc/config.h > ./gcc/config.h.1 ../gcc/move-if-change ./gcc/config.h.1 ./gcc/config.h ../gcc/move-if-change ./gcc/config.h.1 ./gcc/config.h sed -e 's/^#define HAVE_ICONV_H 1$//' < ./gcc/config.h > ./gcc/config.h.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./gcc/config.h > ./gcc/config.h.1 ../gcc/move-if-change ./gcc/config.h.1 ./gcc/config.h ../gcc/move-if-change ./gcc/config.h.1 ./gcc/config.h sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./libcpp/Makefile > ./libcpp/Makefile.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./libcpp/Makefile > ./libcpp/Makefile.1 ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./libcpp/Makefile > ./libcpp/Makefile.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./libcpp/Makefile > ./libcpp/Makefile.1 ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile sed -e 's/^#define HAVE_ICONV 1$//' < ./libcpp/Makefile > ./libcpp/Makefile.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./libcpp/Makefile > ./libcpp/Makefile.1 ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile sed -e 's/^#define HAVE_ICONV_H 1$//' < ./libcpp/Makefile > ./libcpp/Makefile.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./libcpp/Makefile > ./libcpp/Makefile.1 ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./libcpp/config.h > ./libcpp/config.h.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./libcpp/config.h > ./libcpp/config.h.1 ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./libcpp/config.h > ./libcpp/config.h.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./libcpp/config.h > ./libcpp/config.h.1 ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h sed -e 's/^#define HAVE_ICONV 1$//' < ./libcpp/config.h > ./libcpp/config.h.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./libcpp/config.h > ./libcpp/config.h.1 ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h sed -e 's/^#define HAVE_ICONV_H 1$//' < ./libcpp/config.h > ./libcpp/config.h.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./libcpp/config.h > ./libcpp/config.h.1 ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./mpfr/Makefile > ./mpfr/Makefile.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./mpfr/Makefile > ./mpfr/Makefile.1 ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./mpfr/Makefile > ./mpfr/Makefile.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./mpfr/Makefile > ./mpfr/Makefile.1 ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile sed -e 's/^#define HAVE_ICONV 1$//' < ./mpfr/Makefile > ./mpfr/Makefile.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./mpfr/Makefile > ./mpfr/Makefile.1 ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile sed -e 's/^#define HAVE_ICONV_H 1$//' < ./mpfr/Makefile > ./mpfr/Makefile.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./mpfr/Makefile > ./mpfr/Makefile.1 ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile sed -e 's/^#define HAVE_ICONV 1$//' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile sed -e 's/^#define HAVE_ICONV_H 1$//' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile cd . && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: all-gmp all-mpfr all-build-libiberty all-libiberty all-libdecnumber | tee -a _m3.log cd . && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: all-gmp all-mpfr all-build-libiberty all-libiberty all-libdecnumber | tee -a _m3.log make all-recursive Making all in tests Making all in . make[4]: Nothing to be done for `all-am'. Making all in devel make[4]: Nothing to be done for `all'. Making all in mpn make[4]: Nothing to be done for `all'. Making all in mpz make[4]: Nothing to be done for `all'. Making all in mpq make[4]: Nothing to be done for `all'. Making all in mpf make[4]: Nothing to be done for `all'. Making all in rand make[4]: Nothing to be done for `all'. Making all in misc make[4]: Nothing to be done for `all'. Making all in cxx make[4]: Nothing to be done for `all'. Making all in mpbsd make[4]: Nothing to be done for `all'. Making all in mpn make[3]: Nothing to be done for `all'. Making all in mpz make[3]: Nothing to be done for `all'. Making all in mpq make[3]: Nothing to be done for `all'. Making all in mpf make[3]: Nothing to be done for `all'. Making all in printf make[3]: Nothing to be done for `all'. Making all in scanf make[3]: Nothing to be done for `all'. Making all in cxx make[3]: Nothing to be done for `all'. Making all in mpbsd make[3]: Nothing to be done for `all'. Making all in demos Making all in calc make all-am make[5]: Nothing to be done for `all-am'. Making all in expr make[4]: Nothing to be done for `all'. make[4]: Nothing to be done for `all-am'. Making all in tune make[3]: Nothing to be done for `all'. Making all in doc make[3]: Nothing to be done for `all'. make[3]: Nothing to be done for `all-am'. Making all in tests make[2]: Nothing to be done for `all'. make[2]: Nothing to be done for `all-am'. make[2]: Nothing to be done for `all'. make[2]: Nothing to be done for `all'. make[1]: Nothing to be done for `all'. cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a _m3.log cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a _m3.log cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a _m3.log cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a _m3.log make: `s-modes' is up to date. ==> m3-sys/m3cc done /Users/wagner/work/cm3/scripts/install-cm3-compiler.sh upgrade cp /usr/local/cm3/bin/cm3 /usr/local/cm3/bin/cm3-d5.7.0 cp_if: /usr/local/cm3/bin/cm3cg and /usr/local/cm3/bin/cm3cg-d5.7.0 identical cp /Users/wagner/work/cm3/m3-sys/cm3/PPC_DARWIN/cm3 /usr/local/cm3/bin/cm3-d5.8.0 cp /Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/cm3cg /usr/local/cm3/bin/cm3cg-d5.8.0 cp /usr/local/cm3/bin/cm3-d5.8.0 /usr/local/cm3/bin/cm3 cp /usr/local/cm3/bin/cm3cg-d5.8.0 /usr/local/cm3/bin/cm3cg /Users/wagner/work/cm3/scripts/do-cm3-core.sh realclean /Users/wagner/work/cm3/scripts/pkgmap.sh -k -c "rm -rf PPC_DARWIN" import-libs m3cc m3core libm3 patternmatching sysutils unittest m3middle m3objfile m3linker m3back m3staloneback m3front m3quake cm3 m3scanner m3tools m3cgcat m3cggen m3bundle mklib fix_nl libdump bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles tcl === package m3-win/import-libs === === package omitted on this platform === ==> m3-win/import-libs done === package m3-sys/m3cc === === package omitted on this platform === ==> m3-sys/m3cc done === package m3-libs/m3core === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/m3core done === package m3-libs/libm3 === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/libm3 done === package m3-libs/patternmatching === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/patternmatching done === package m3-libs/sysutils === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/sysutils done === package m3-libs/unittest === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/unittest done === package m3-sys/m3middle === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/m3middle done === package m3-sys/m3objfile === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/m3objfile done === package m3-sys/m3linker === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/m3linker done === package m3-sys/m3back === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/m3back done === package m3-sys/m3staloneback === === package omitted on this platform === ==> m3-sys/m3staloneback done === package m3-sys/m3front === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/m3front done === package m3-sys/m3quake === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/m3quake done === package m3-sys/cm3 === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/cm3 done === package m3-sys/m3scanner === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/m3scanner done === package m3-sys/m3tools === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/m3tools done === package m3-sys/m3cgcat === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/m3cgcat done === package m3-sys/m3cggen === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/m3cggen done === package m3-tools/m3bundle === +++ rm -rf PPC_DARWIN +++ ==> m3-tools/m3bundle done === package m3-sys/mklib === === package omitted on this platform === ==> m3-sys/mklib done === package m3-sys/fix_nl === === package omitted on this platform === ==> m3-sys/fix_nl done === package m3-sys/libdump === === package omitted on this platform === ==> m3-sys/libdump done === package m3-libs/bitvector === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/bitvector done === package m3-libs/digraph === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/digraph done === package m3-libs/parseparams === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/parseparams done === package m3-libs/realgeometry === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/realgeometry done === package m3-libs/set === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/set done === package m3-libs/slisp === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/slisp done === package m3-libs/sortedtableextras === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/sortedtableextras done === package m3-libs/table-list === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/table-list done === package m3-libs/tempfiles === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/tempfiles done === package m3-libs/tcl === === package omitted on this platform === ==> m3-libs/tcl done /Users/wagner/work/cm3/scripts/do-cm3-core.sh buildship /Users/wagner/work/cm3/scripts/pkgmap.sh -c "cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' " import-libs m3cc m3core libm3 patternmatching sysutils unittest m3middle m3objfile m3linker m3back m3staloneback m3front m3quake cm3 m3scanner m3tools m3cgcat m3cggen m3bundle mklib fix_nl libdump bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles tcl === package m3-win/import-libs === === package omitted on this platform === ==> m3-win/import-libs done === package m3-sys/m3cc === === package omitted on this platform === ==> m3-sys/m3cc done === package m3-libs/m3core === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling WordRep.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 ../src/runtime/common/RuntimeError.m3: In function 'RuntimeError__Tag': ../src/runtime/common/RuntimeError.m3:56: error: type mismatch in binary expression int_32 int_32 word_32 D.252 = D.251 * 4 ../src/runtime/common/RuntimeError.m3:56: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 1024 m3cc (aka cm3cg) failed compiling: RuntimeError.mc new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling Scheduler.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling RTHeap.i3 new source -> compiling Cstdlib.i3 new source -> compiling LongRep.i3 new source -> compiling Long.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling Cstddef.i3 new source -> compiling Csetjmp.i3 new source -> compiling RTMachine.i3 new source -> compiling Uucontext.i3 new source -> compiling Usysdep.i3 new source -> compiling Cstdint.i3 new source -> compiling Utypes.i3 new source -> compiling Upthread.i3 new source -> compiling RTHeapRep.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 ../src/runtime/common/RTAllocator.m3: In function 'RTAllocator__CheckTypeFailed': ../src/runtime/common/RTAllocator.m3:181: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 1024 m3cc (aka cm3cg) failed compiling: RTAllocator.mc new source -> compiling RTAllocStats.i3 new source -> compiling Convert.i3 new source -> compiling TextClass.i3 new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 ../src/runtime/common/RTAllocStats.m3: In function 'RTAllocStats__EnableTrace': ../src/runtime/common/RTAllocStats.m3:40: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 1024 m3cc (aka cm3cg) failed compiling: RTAllocStats.mc new source -> compiling TextLiteral.i3 new source -> compiling RTHeap.m3 ../src/runtime/common/RTHeap.m3: In function 'RTHeap__GetDataAdr': ../src/runtime/common/RTHeap.m3:20: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 1024 m3cc (aka cm3cg) failed compiling: RTHeap.mc new source -> compiling RTHeapInfo.i3 new source -> compiling Cstring.i3 -------------- next part -------------- /Users/wagner/work/cm3/scripts/pkgmap.sh -c "cm3 -build -override -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' " m3core === package m3-libs/m3core === +++ cm3 -build -override -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling WordRep.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 ../src/runtime/common/RuntimeError.m3: In function 'RuntimeError__Tag': ../src/runtime/common/RuntimeError.m3:56: error: type mismatch in binary expression int_32 int_32 word_32 D.252 = D.251 * 4 ../src/runtime/common/RuntimeError.m3:56: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling Scheduler.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling RTHeap.i3 new source -> compiling Cstdlib.i3 new source -> compiling LongRep.i3 new source -> compiling Long.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling Cstddef.i3 new source -> compiling Csetjmp.i3 new source -> compiling RTMachine.i3 new source -> compiling Uucontext.i3 new source -> compiling Usysdep.i3 new source -> compiling Cstdint.i3 new source -> compiling Utypes.i3 new source -> compiling Upthread.i3 new source -> compiling RTHeapRep.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 ../src/runtime/common/RTAllocator.m3: In function 'RTAllocator__CheckTypeFailed': ../src/runtime/common/RTAllocator.m3:181: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTAllocStats.i3 new source -> compiling Convert.i3 new source -> compiling TextClass.i3 new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 ../src/runtime/common/RTAllocStats.m3: In function 'RTAllocStats__EnableTrace': ../src/runtime/common/RTAllocStats.m3:40: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling TextLiteral.i3 new source -> compiling RTHeap.m3 ../src/runtime/common/RTHeap.m3: In function 'RTHeap__GetDataAdr': ../src/runtime/common/RTHeap.m3:20: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTHeapInfo.i3 new source -> compiling Cstring.i3 new source -> compiling Thread.i3 new source -> compiling RTPerfTool.i3 new source -> compiling RTParams.i3 new source -> compiling RTHeapInfo.m3 ../src/runtime/common/RTHeapInfo.m3: In function 'RTHeapInfo__Producer': ../src/runtime/common/RTHeapInfo.m3:22: error: type mismatch in binary expression int_32 int_32 word_32 D.343 = M3_AcxOUs_i.6 * 4 ../src/runtime/common/RTHeapInfo.m3:22: error: type mismatch in binary expression int_32 int_32 word_32 D.365 = M3_AcxOUs_i.17 * 4 ../src/runtime/common/RTHeapInfo.m3:22: error: type mismatch in binary expression int_32 int_32 word_32 D.385 = M3_AcxOUs_i.26 * 4 ../src/runtime/common/RTHeapInfo.m3:22: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTHeapMap.i3 new source -> compiling RTIO.i3 new source -> compiling RTTypeMap.i3 new source -> compiling RTMapOp.i3 new source -> compiling RTModule.i3 new source -> compiling RTHeapMap.m3 ../src/runtime/common/RTHeapMap.m3: In function 'RTHeapMap__WalkGlobals': ../src/runtime/common/RTHeapMap.m3:73: error: type mismatch in binary expression int_32 int_32 word_32 D.450 = M3_AcxOUs_i.43 * 4 ../src/runtime/common/RTHeapMap.m3:73: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTHeapRep.m3 new source -> compiling RTHeapStats.i3 new source -> compiling FloatMode.i3 new source -> compiling ThreadF.i3 new source -> compiling RTTypeSRC.i3 new source -> compiling RTCollector.i3 new source -> compiling RTHeapStats.m3 ../src/runtime/common/RTHeapStats.m3: In function 'RTHeapStats__ReportReachable': ../src/runtime/common/RTHeapStats.m3:75: error: type mismatch in shift expression int_32 word_32 int_32 D.624 = D.623 >> 20 ../src/runtime/common/RTHeapStats.m3:75: error: type mismatch in shift expression int_32 word_32 int_32 D.634 = D.633 >> 20 ../src/runtime/common/RTHeapStats.m3:75: error: type mismatch in binary expression int_32 int_32 word_32 D.666 = D.665 * 24 ../src/runtime/common/RTHeapStats.m3:75: error: type mismatch in binary expression int_32 int_32 word_32 D.679 = D.678 * 24 ../src/runtime/common/RTHeapStats.m3:75: error: type mismatch in binary expression int_32 int_32 word_32 D.692 = D.691 * 24 ../src/runtime/common/RTHeapStats.m3:75: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Time.i3 new source -> compiling RTLinker.i3 new source -> compiling RTProcess.i3 new source -> compiling RTHeapEvent.i3 new source -> compiling RTWeakRef.i3 new source -> compiling RTCollectorSRC.i3 new source -> compiling RTCollector.m3 ../src/runtime/common/RTCollector.m3: In function 'RTCollector__Disable': ../src/runtime/common/RTCollector.m3:42: internal compiler error: in verify_gimple_expr, at tree-cfg.c:3957 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTIO.m3 new source -> compiling RTLinkerX.i3 new source -> compiling RTSignal.i3 new source -> compiling RTDebug.i3 new source -> compiling RTLinker.m3 ../src/runtime/common/RTLinker.m3: In function 'RTModule__Get': ../src/runtime/common/RTLinker.m3:439: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTDebug.m3 ../src/runtime/common/RTDebug.m3: In function 'RTDebug__DefaultMsg': ../src/runtime/common/RTDebug.m3:36: error: type mismatch in binary expression int_32 int_32 word_32 D.349 = M3_AcxOUs_i.22 * 4 ../src/runtime/common/RTDebug.m3:36: error: type mismatch in binary expression int_32 int_32 word_32 D.377 = M3_AcxOUs_i.29 * 4 ../src/runtime/common/RTDebug.m3:36: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTError.i3 new source -> compiling RTError.m3 new source -> compiling M3toC.i3 new source -> compiling RTException.m3 new source -> compiling RTMapOp.m3 ../src/runtime/common/RTMapOp.m3: In function 'RTMapOp__GetInt': ../src/runtime/common/RTMapOp.m3:11: error: type mismatch in binary expression word_32 word_32 int_32 D.234 = iftmp.12 | M3_AcxOUs_n.15 ../src/runtime/common/RTMapOp.m3:11: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTMisc.m3 new source -> compiling RTPacking.i3 new source -> compiling RTPacking.m3 ../src/runtime/common/RTPacking.m3: In function 'RTPacking__SizeOf': ../src/runtime/common/RTPacking.m3:63: error: type mismatch in binary expression int_32 int_32 word_32 D.311 = M3_AcxOUs_i.10 * 4 ../src/runtime/common/RTPacking.m3:63: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTArgs.i3 new source -> compiling RTParams.m3 ../src/runtime/common/RTParams.m3: In function 'RTParams__Init': ../src/runtime/common/RTParams.m3:78: error: type mismatch in shift expression int_32 word_32 int_32 D.618 = D.617 >> 1 ../src/runtime/common/RTParams.m3:78: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTProcedure.m3 ../src/runtime/common/RTProcedure.m3: In function 'RTProcedureSRC__FromPC': ../src/runtime/common/RTProcedure.m3:57: error: type mismatch in binary expression int_32 int_32 word_32 D.377 = M3_AcxOUs_i.14 * 4 ../src/runtime/common/RTProcedure.m3:57: error: type mismatch in binary expression int_32 int_32 word_32 D.413 = M3_AcxOUs_best.34 * 4 ../src/runtime/common/RTProcedure.m3:57: error: type mismatch in binary expression int_32 int_32 word_32 D.443 = M3_AcxOUs_best.48 * 4 ../src/runtime/common/RTProcedure.m3:57: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTProcess.m3 new source -> compiling RTTipe.i3 new source -> compiling RTTipe.m3 ../src/runtime/common/RTTipe.m3: In function 'RTTipe__ReadOp': ../src/runtime/common/RTTipe.m3:106: error: type mismatch in binary expression int_32 int_32 word_32 D.792 = D.791 * 4 ../src/runtime/common/RTTipe.m3:106: error: type mismatch in binary expression int_32 int_32 word_32 D.899 = D.898 * 4 ../src/runtime/common/RTTipe.m3:106: error: type mismatch in binary expression int_32 int_32 word_32 D.986 = D.985 * 4 ../src/runtime/common/RTTipe.m3:106: error: type mismatch in binary expression int_32 int_32 word_32 D.1073 = D.1072 * 4 ../src/runtime/common/RTTipe.m3:106: error: type mismatch in binary expression int_32 int_32 word_32 D.1157 = D.1156 * 4 ../src/runtime/common/RTTipe.m3:106: error: type mismatch in binary expression int_32 int_32 word_32 D.1303 = D.1302 * 4 ../src/runtime/common/RTTipe.m3:106: error: type mismatch in binary expression int_32 int_32 word_32 D.1412 = D.1411 * 4 ../src/runtime/common/RTTipe.m3:106: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTType.m3 ../src/runtime/common/RTType.m3: In function 'RTType__Get': ../src/runtime/common/RTType.m3:71: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTTypeFP.i3 new source -> compiling RTTypeFP.m3 ../src/runtime/common/RTTypeFP.m3: In function 'RTTypeFP__FromFingerprint': ../src/runtime/common/RTTypeFP.m3:23: error: type mismatch in binary expression int_32 int_32 word_32 D.285 = M3_AcxOUs_x.17 * 4 ../src/runtime/common/RTTypeFP.m3:23: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTTypeMap.m3 ../src/runtime/common/RTTypeMap.m3: In function 'RTTypeMap__Walk': ../src/runtime/common/RTTypeMap.m3:51: error: type mismatch in binary expression word_32 int_32 word_32 D.657 = M3_DrLXJX_mask.111 & 65536 ../src/runtime/common/RTTypeMap.m3:51: error: type mismatch in binary expression word_32 word_32 int_32 D.695 = iftmp.124 & M3_DrLXJX_mask.128 ../src/runtime/common/RTTypeMap.m3:51: error: type mismatch in binary expression int_32 int_32 word_32 D.715 = D.714 * 4 ../src/runtime/common/RTTypeMap.m3:51: error: type mismatch in binary expression word_32 word_32 int_32 D.736 = iftmp.139 & M3_DrLXJX_mask.143 ../src/runtime/common/RTTypeMap.m3:51: error: type mismatch in binary expression int_32 int_32 word_32 D.790 = D.789 * 4 ../src/runtime/common/RTTypeMap.m3:51: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTutils.i3 new source -> compiling RTutils.m3 ../src/runtime/common/RTutils.m3: In function 'RTutils__Delta': ../src/runtime/common/RTutils.m3:78: error: type mismatch in binary expression int_32 int_32 word_32 D.687 = M3_AcxOUs_i.30 * 12 ../src/runtime/common/RTutils.m3:78: error: type mismatch in binary expression int_32 int_32 word_32 D.718 = M3_AcxOUs_i.36 * 12 ../src/runtime/common/RTutils.m3:78: error: type mismatch in binary expression int_32 int_32 word_32 D.749 = M3_AcxOUs_i.42 * 12 ../src/runtime/common/RTutils.m3:78: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTHeapDebug.i3 new source -> compiling WeakRef.i3 new source -> compiling RTHeapDebug.m3 ../src/runtime/common/RTHeapDebug.m3: In function 'RTHeapDebug__Free': ../src/runtime/common/RTHeapDebug.m3:48: error: type mismatch in binary expression int_32 int_32 word_32 D.348 = D.347 * 8 ../src/runtime/common/RTHeapDebug.m3:48: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTArgs.m3 ../src/runtime/POSIX/RTArgs.m3: In function 'RTArgs__GetArg': ../src/runtime/POSIX/RTArgs.m3:21: error: type mismatch in binary expression int_32 int_32 word_32 D.245 = D.244 * 4 ../src/runtime/POSIX/RTArgs.m3:21: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Uuio.i3 new source -> compiling Unix.i3 new source -> compiling Utime.i3 new source -> compiling RTOS.m3 new source -> compiling Uexec.i3 new source -> compiling RTPerfTool.m3 new source -> compiling Usignal.i3 new source -> compiling RTThread.i3 new source -> compiling RTThreadStk.m3 ../src/runtime/POSIX/RTThreadStk.m3: In function 'RTThread__GetStack': ../src/runtime/POSIX/RTThreadStk.m3:15: error: type mismatch in binary expression int_32 int_32 word_32 D.238 = D.237 * 12 ../src/runtime/POSIX/RTThreadStk.m3:15: error: type mismatch in binary expression int_32 int_32 word_32 D.271 = D.270 * 12 ../src/runtime/POSIX/RTThreadStk.m3:15: error: type mismatch in binary expression int_32 int_32 word_32 D.279 = D.278 * 12 ../src/runtime/POSIX/RTThreadStk.m3:15: error: type mismatch in binary expression int_32 int_32 word_32 D.307 = D.306 * 12 ../src/runtime/POSIX/RTThreadStk.m3:15: error: type mismatch in binary expression int_32 int_32 word_32 D.320 = D.319 * 12 ../src/runtime/POSIX/RTThreadStk.m3:15: error: type mismatch in binary expression int_32 int_32 word_32 D.326 = D.325 * 12 ../src/runtime/POSIX/RTThreadStk.m3:15: error: type mismatch in binary expression int_32 int_32 word_32 D.334 = D.333 * 12 ../src/runtime/POSIX/RTThreadStk.m3:15: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTSignalPrivate.i3 new source -> compiling RTSignalC.i3 new source -> compiling RTSignal.m3 new source -> compiling Umman.i3 new source -> compiling RTThread.m3 ../src/runtime/PPC_DARWIN/RTThread.m3: In function 'RTThread__NewStack': ../src/runtime/PPC_DARWIN/RTThread.m3:26: error: type mismatch in shift expression int_32 word_32 int_32 D.261 = D.260 >> 2 ../src/runtime/PPC_DARWIN/RTThread.m3:26: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTExFrame.i3 new source -> compiling RTExFrame.m3 ../src/runtime/ex_frame/RTExFrame.m3: In function 'RTExFrame_M3': ../src/runtime/ex_frame/RTExFrame.m3:279: internal compiler error: tree check: did not expect class 'type', have 'type' (pointer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling SchedulerPosix.i3 new source -> compiling MutexRep.i3 new source -> compiling ThreadEvent.i3 new source -> compiling ThreadPThread.i3 new source -> compiling Uerror.i3 new source -> compiling Usched.i3 new source -> compiling Cerrno.i3 new source -> compiling ThreadPThread.m3 ../src/thread/PTHREAD/ThreadPThread.m3: In function 'ThreadPThread__SetState': ../src/thread/PTHREAD/ThreadPThread.m3:98: error: type mismatch in binary expression int_32 int_32 word_32 D.954 = D.953 * 4 ../src/thread/PTHREAD/ThreadPThread.m3:98: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling WinBaseTypes.i3 new source -> compiling WinDef.i3 new source -> compiling WinDef.m3 ../src/win32/WinDef.m3: In function 'WinDef__MAKEWORD': ../src/win32/WinDef.m3:78: error: type mismatch in binary expression word_32 word_32 int_32 D.365 = iftmp.1 | D.364 ../src/win32/WinDef.m3:78: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling WinNT.i3 new source -> compiling WinNT.m3 ../src/win32/WinNT.m3: In function 'WinNT__BTYPE': ../src/win32/WinNT.m3:19: error: type mismatch in binary expression word_32 int_32 int_32 D.212 = D.211 & 15 ../src/win32/WinNT.m3:19: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Unetdb.i3 new source -> compiling Uutmp.i3 new source -> compiling Ugrp.i3 new source -> compiling Upwd.i3 new source -> compiling Uugid.i3 new source -> compiling Uprocess.i3 new source -> compiling Unix.m3 new source -> compiling Usocket.i3 new source -> compiling Uin.i3 new source -> compiling Ustat.i3 new source -> compiling Udir.i3 new source -> compiling Usignal.m3 new source -> compiling Uin.m3 new source -> compiling Text8CString.i3 new source -> compiling Text8.i3 new source -> compiling M3toC.m3 new source -> compiling Csignal.i3 new source -> compiling Cstdio.i3 new source -> compiling Cstdio.m3 ../src/C/PPC_DARWIN/Cstdio.m3: In function 'Cstdio_M3': ../src/C/PPC_DARWIN/Cstdio.m3:6: error: type mismatch in binary expression int_32 int_32 word_32 D.212 = M3_AcxOUs_i.2 * 4 ../src/C/PPC_DARWIN/Cstdio.m3:6: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Real.i3 new source -> compiling RealFloat.i3 new source -> compiling LongReal.i3 new source -> compiling LongFloat.i3 new source -> compiling Extended.i3 new source -> compiling ExtendedFloat.i3 new source -> compiling IEEESpecial.i3 new source -> compiling LongRealRep.i3 new source -> compiling RealRep.i3 new source -> compiling IEEESpecial.m3 new source -> compiling Real.m3 new source -> compiling LongReal.m3 new source -> compiling Extended.m3 new source -> compiling DragonInt.i3 new source -> compiling DragonInt.m3 ../src/float/Common/DragonInt.m3: In function 'DragonInt__New': ../src/float/Common/DragonInt.m3:126: error: type mismatch in binary expression word_32 int_32 int_32 D.722 = M3_AcxOUs_a.24 & 16777215 ../src/float/Common/DragonInt.m3:126: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling DragonT.i3 new source -> compiling DragonT.m3 new source -> compiling FPU.i3 new source -> compiling RealFloat.m3 ../src/float/IEEE/RealFloat.m3: In function 'RealFloat__ILogb': ../src/float/IEEE/RealFloat.m3:40: error: type mismatch in binary expression word_32 int_32 int_32 D.409 = M3_AcxOUs_v.14 & M3_AcxOUs_w.15 ../src/float/IEEE/RealFloat.m3:40: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling LongFloat.m3 ../src/float/IEEE/LongFloat.m3: In function 'LongFloat__ILogb': ../src/float/IEEE/LongFloat.m3:44: error: type mismatch in binary expression word_32 int_32 int_32 D.410 = M3_AcxOUs_v.18 & M3_AcxOUs_w.19 ../src/float/IEEE/LongFloat.m3:44: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling ExtendedFloat.m3 new source -> compiling FPU.m3 new source -> compiling FloatMode.m3 new source -> compiling Tick.i3 new source -> compiling Date.i3 new source -> compiling FmtTime.i3 new source -> compiling FmtTime.m3 ../src/time/Common/FmtTime.m3: In function 'FmtTime__DateLong': ../src/time/Common/FmtTime.m3:38: error: type mismatch in binary expression int_32 int_32 word_32 D.300 = D.299 * 4 ../src/time/Common/FmtTime.m3:38: error: type mismatch in binary expression int_32 int_32 word_32 D.326 = D.325 * 4 ../src/time/Common/FmtTime.m3:38: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling TickPortable.m3 new source -> compiling TimePosix.i3 new source -> compiling DateBsd.m3 new source -> compiling TimePosix.m3 new source -> compiling CConvert.i3 new source -> compiling CConvert.m3 ../src/convert/CConvert.m3: In function 'CConvert__Acquire': ../src/convert/CConvert.m3:15: internal compiler error: in verify_gimple_expr, at tree-cfg.c:3957 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Convert.m3 ../src/convert/Convert.m3: In function 'Convert__InternalFromLongFloat': ../src/convert/Convert.m3:337: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling String8.i3 new source -> compiling String8.m3 ../src/text/String8.m3: In function 'String8__Hash': ../src/text/String8.m3:30: error: type mismatch in binary expression word_32 word_32 int_32 D.299 = D.294 ^ D.298 ../src/text/String8.m3:30: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling String16.i3 new source -> compiling String16.m3 ../src/text/String16.m3: In function 'String16__Hash': ../src/text/String16.m3:45: error: type mismatch in binary expression word_32 word_32 int_32 D.374 = D.369 ^ D.373 ../src/text/String16.m3:45: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Text16.i3 new source -> compiling Text.m3 ../src/text/Text.m3: In function 'Text__EqualBuf': ../src/text/Text.m3:47: error: type mismatch in binary expression int_32 int_32 word_32 D.611 = D.610 * 2 ../src/text/Text.m3:47: error: type mismatch in binary expression int_32 int_32 word_32 D.618 = D.617 * 2 ../src/text/Text.m3:47: error: type mismatch in binary expression int_32 int_32 word_32 D.685 = D.684 * 2 ../src/text/Text.m3:47: error: type mismatch in binary expression int_32 int_32 word_32 D.690 = D.689 * 2 ../src/text/Text.m3:47: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling TextClass.m3 ../src/text/TextClass.m3: In function 'TextClass__GetChar': ../src/text/TextClass.m3:8: error: type mismatch in binary expression word_32 int_32 int_32 D.234 = D.233 & 255 ../src/text/TextClass.m3:8: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling TextLiteral.m3 ../src/text/TextLiteral.m3: In function 'RTHooks__TextLitGetChar': ../src/text/TextLiteral.m3:19: error: type mismatch in binary expression word_32 int_32 int_32 D.307 = D.306 & 255 ../src/text/TextLiteral.m3:19: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Text8Short.i3 new source -> compiling Text8.m3 ../src/text/Text8.m3: In function 'Text8__New': ../src/text/Text8.m3:20: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Text8Short.m3 ../src/text/Text8Short.m3: In function 'Text8Short__GetChars': ../src/text/Text8Short.m3:41: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Text8CString.m3 new source -> compiling Text16Short.i3 new source -> compiling Text16.m3 ../src/text/Text16.m3: In function 'Text16__New': ../src/text/Text16.m3:20: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Text16Short.m3 ../src/text/Text16Short.m3: In function 'Text16Short__New': ../src/text/Text16Short.m3:15: error: type mismatch in binary expression int_32 int_32 word_32 D.276 = D.275 * 2 ../src/text/Text16Short.m3:15: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling TextSub.i3 new source -> compiling TextCat.i3 new source -> compiling TextSub.m3 ../src/text/TextSub.m3: In function 'Text__Sub': ../src/text/TextSub.m3:65: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling TextCat.m3 ../src/text/TextCat.m3: In function 'RTHooks__MultiCat': ../src/text/TextCat.m3:39: error: type mismatch in binary expression int_32 int_32 word_32 D.488 = M3_AcxOUs_i.42 * 4 ../src/text/TextCat.m3:39: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling TextConv.i3 new source -> compiling TextConv.m3 ../src/text/TextConv.m3: In function 'TextConv__EncodeChar': ../src/text/TextConv.m3:46: error: type mismatch in shift expression int_32 word_32 int_32 D.497 = D.496 >> 6 ../src/text/TextConv.m3:46: error: type mismatch in binary expression word_32 int_32 int_32 D.510 = D.509 & 63 ../src/text/TextConv.m3:46: error: type mismatch in shift expression int_32 word_32 int_32 D.511 = D.510 >> 3 ../src/text/TextConv.m3:46: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Poly.i3 new source -> compiling Fingerprint.m3 ../src/fingerprint/Fingerprint.m3: In function 'Fingerprint__Fix32': ../src/fingerprint/Fingerprint.m3:93: error: type mismatch in binary expression word_32 word_32 int_32 D.407 = M3_AcxOUs_x.61 | -2147483648 ../src/fingerprint/Fingerprint.m3:93: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Poly.m3 ../src/fingerprint/Poly.m3: In function 'Poly__Sum': ../src/fingerprint/Poly.m3:45: error: type mismatch in binary expression word_32 int_32 int_32 D.381 = D.377 ^ D.380 ../src/fingerprint/Poly.m3:45: error: type mismatch in binary expression word_32 int_32 int_32 D.391 = D.386 ^ D.390 ../src/fingerprint/Poly.m3:45: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling PolyBasis.i3 new source -> compiling PolyBasis.m3 new source -> compiling Main.i3 new source -> compiling WeakRef.m3 new source -> compiling Word.m3 ../src/word/Word.m3 => ../src/word/GenWord.mg: In function 'Word__And': ../src/word/Word.m3 => ../src/word/GenWord.mg:19: error: type mismatch in binary expression word_32 int_32 int_32 D.381 = M3_AcxOUs_x.36 & M3_AcxOUs_y.37 ../src/word/Word.m3 => ../src/word/GenWord.mg:19: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Long.m3 ../src/word/Long.m3 => ../src/word/GenWord.mg: In function 'Long__And': ../src/word/Long.m3 => ../src/word/GenWord.mg:19: error: type mismatch in binary expression word_64 int_64 int_64 D.382 = M3_AGDpCO_x.36 & M3_AGDpCO_y.37 ../src/word/Long.m3 => ../src/word/GenWord.mg:19: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTLinkerC.c new source -> compiling RTOSmmap.c new source -> compiling RTSignalC.c new source -> compiling RTThreadC.c new source -> compiling RTMachineC.c new source -> compiling RTStackC.c new source -> compiling ThreadPThreadC.c new source -> compiling WinNTc.c new source -> compiling UtimeC.c new source -> compiling UnixC.c new source -> compiling Uexec.c new source -> compiling Unetdb.c new source -> compiling Umman.c new source -> compiling Ugrp.c new source -> compiling Uconstants.c new source -> compiling UstatC.c new source -> compiling Usocket.c new source -> compiling UdirC.c new source -> compiling CerrnoC.c new exporters -> recompiling RTHooks.i3 new exporters -> recompiling RTAllocCnts.i3 new exporters -> recompiling RTHeapRep.i3 new exporters -> recompiling RTCollectorSRC.i3 new exporters -> recompiling RTWeakRef.i3 new exporters -> recompiling RTException.i3 new exporters -> recompiling RTModule.i3 new exporters -> recompiling RTProcedureSRC.i3 new exporters -> recompiling RTTypeSRC.i3 new exporters -> recompiling RTOS.i3 new exporters -> recompiling RTThread.i3 new exporters -> recompiling RTSignalPrivate.i3 new exporters -> recompiling Thread.i3 new exporters -> recompiling Scheduler.i3 new exporters -> recompiling SchedulerPosix.i3 new exporters -> recompiling ThreadF.i3 new exporters -> recompiling Time.i3 new exporters -> recompiling Tick.i3 new exporters -> recompiling Date.i3 new exporters -> recompiling Text.i3 compilation failed => not building library "libm3core.a" Fatal Error: package build failed *** execution of cm3 -build -override -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' failed *** From wagner at elegosoft.com Sat Apr 11 11:26:11 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 11 Apr 2009 11:26:11 +0200 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <49DE5A8A.5070307@bellsouth.net> References: <49DE5A8A.5070307@bellsouth.net> Message-ID: <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> Quoting Martin Bishop : > A few days ago there was more talk of a proper "release" for CM3. I > think this is very important. I second that. I'll try to start the release engineering now, as nobody else seems to volunteer ;-) We have two options here though: we can either (a) agree on a code freeze (beginning at some date we need to agree upon) (b) create a release branch immediately Code freeze would mean that nobody commits any major new functionality any more, but all commits concentrate on fixing bugs in some set of release candiates. I'd rather avoid creating a branch too early, as that means more work by selecting and merging fixes from trunk to branch. So here my questions: o Do we all agree on a temporary code freeze? o When should we start? I.e. wha changes would you like to complete before we start the release process? Please let me know your opinions, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 11 13:44:18 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 11 Apr 2009 13:44:18 +0200 Subject: [M3devel] (D)DCVSup in DCCS/DCVS for download Message-ID: <20090411134418.cqc2yem2g44ogkkg@mail.elegosoft.com> Hi, I've put most of the source code of our more or less abandoned DCCS project into http://www.opencm3.net/uploaded-archives/dccs-public.tar.gz for download. It contains a complete and extended version of CVSup along with much other potentially useful M3 code. I was able to compile everything with a recent CM3 for target FreeBSD4. To build everything, cd to dccs-public/prod and type make all. Please note that the resulting executables for CVSup are named dcvsup and dcvsupd, but they should work without DCVS configuration, too. At least you should be able to use the source to get get standard CVSup to compile. Hope this helps, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Sat Apr 11 13:44:41 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 11 Apr 2009 07:44:41 -0400 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> Message-ID: <20090411114441.GA22262@topoi.pooq.com> On Sat, Apr 11, 2009 at 11:26:11AM +0200, Olaf Wagner wrote: > o When should we start? I.e. wha changes would you like to complete > before we start the release process? The change to the ButtonVBT I brought up earlier. But if I continue not having time to get to it, you'd better release rather than watining indefinitely. I'd also like to make some progress in creating the monotone archive. But that's probably not relevant to the release process. It had perhaps better be thought of as (conceptually, at least) something for after the release. -- hendrik From jay.krell at cornell.edu Sat Apr 11 14:03:39 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 11 Apr 2009 12:03:39 +0000 Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN In-Reply-To: <20090411105512.92784fp7cc0o448k@mail.elegosoft.com> References: <20090411105512.92784fp7cc0o448k@mail.elegosoft.com> Message-ID: I do test on 10.4 fairly often, at least do-cm3-std buildship and/or make-dist, I even lately don't always skip gcc, I can report recent results soon. I've got a few PPC iBooks/PowerBooks and might yet try 10.2 or 3 or 5. It sounds like 7.9.0 is 10.3? Do my archives work for you, but then a locally build cm3cg doesn't? What does config.guess say? Can you try removing all the stuff I put in? cd somewhere configure -disable-bootstrap -disable-multilibs make If desperate I can send you a 10.4 machine and you can send me your 10.3, but it's not likely worth the shipping. - Jay > Date: Sat, 11 Apr 2009 10:55:12 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN > > After trying to upgrade cm3 on my notebook to the latest version, > I get lots of internal compiler errors.This is on > > % uname -a > Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 > 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power > Macintosh powerpc > > ... > new source -> compiling RuntimeError.m3 > ../src/runtime/common/RuntimeError.m3: In function 'RuntimeError__Tag': > ../src/runtime/common/RuntimeError.m3:56: error: type mismatch in > binary expression > int_32 > > int_32 > > word_32 > > D.252 = D.251 * 4 > ../src/runtime/common/RuntimeError.m3:56: internal compiler error: > verify_gimple failed > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > ... > > Full log attached. > > Before you ask, it won't be easy to upgrade Darwin on this notebook, > and I surely cannot do this within the next two weeks :-/ > > Any ideas? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Apr 11 14:19:37 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 11 Apr 2009 12:19:37 +0000 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <20090411114441.GA22262@topoi.pooq.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> Message-ID: > > o When should we start? I.e. wha changes would you like to complete > > before we start the release process? I'd like to see the formsvbt crash debugged and fixed, unless I'm the only one seeing it. I only see it on Solaris and PPC_DARWIN but haven't tried "everything". I'll try to get this. I'd also like to see: FreeBSD/x86 switched to the new Unix/*.i3 files. I'll do this. Maybe also I386_DARWIN, AMD64_DARWIN, but I don't have the hardware. $ORIGIN/LD_LIBRARY_PATH resolved a bit further, probably very little work (I'll do this). Basically just 1) put buildlocal back how it was 2) push it across more platforms e.g. I think FreeBSD/x86 is the main one missing, but I'll get to it. cvsup building and in "std" (I'll do this, probably very little left here really. -- beyond this, not required for release -- Maybe more AMD64 releases, e.g. NetBSD and Solaris. (If I get to it). (could be "mingw64" is good enough to try AMD64_NT now). Maybe update gmp/mpfr to fix the "maintainer" problem. (not likely by me) Maybe more new/resuscitated platforms..HPPA64_HPUX, IA64_*, *_VMS, ALPHA_*, ARM_*, *_IRIX, *_AIX, MIPS64_*.... but these take back seat to important fixes in existing platforms. Fix NT386 to use setjmp3 instead of setjmp so exceptions don't skip C __finally blocks. I've just been very lazy here, should demonstrate the behavior with a test case, then fix it.. Maybe fix cm3cg so other -g options besides -gstabs works, like plain -g, -ggdb, on at least one platform -gstabs isn't supported, leaving nothing, because others cause internal compiler errors, like on HPPA64_HPUX. Oh, and NT386GNU probably switched back to Win32 threads. Otherwise one of the test cases hangs and it doesn't look easy to figure out. I'll do this shortly if I remember. But I also wouldn't mind if this platform isn't officially released either (unless someone else wants to support it). Debug why many NT386MINGNU gui apps crash..but also probably just don't release this platform and ok asis. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Apr 11 14:21:38 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 11 Apr 2009 14:21:38 +0200 Subject: [M3devel] (D)DCVSup in DCCS/DCVS for download In-Reply-To: <20090411134418.cqc2yem2g44ogkkg@mail.elegosoft.com> References: <20090411134418.cqc2yem2g44ogkkg@mail.elegosoft.com> Message-ID: <20090411142138.mvnqsfqdus8wk8ko@mail.elegosoft.com> That still does not work on AMD64_LINUX yet. Even after changing dcvs/cvsup/quake/cvsup.quake to recognize Jay's new config files with if defined("INITIAL_REACTOR_EDITOR") or defined("CM3SetInstallRoot") M3_VARIANT = "CM3" I get several errors in FileAttr.m3 and dev_t_linux/DevT.m3. It seems there are some 64 bit issues. I've got to stop M3 work for today, though; perhaps Jay will look further into compiling CVSup for Linux today... Olaf Quoting Olaf Wagner : > Hi, > > I've put most of the source code of our more or less abandoned > DCCS project into > > http://www.opencm3.net/uploaded-archives/dccs-public.tar.gz > > for download. > > It contains a complete and extended version of CVSup along with > much other potentially useful M3 code. > > I was able to compile everything with a recent CM3 for target > FreeBSD4. > > To build everything, cd to dccs-public/prod and type make all. > Please note that the resulting executables for CVSup are named > dcvsup and dcvsupd, but they should work without DCVS configuration, > too. At least you should be able to use the source to get get standard > CVSup to compile. > > Hope this helps, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Sat Apr 11 16:27:02 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 11 Apr 2009 10:27:02 -0400 Subject: [M3devel] m3 CVS? In-Reply-To: References: <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> <20090325144505.GA16526@topoi.pooq.com> <20090325225421.GB17118@topoi.pooq.com> <20090330131918.GA6921@topoi.pooq.com> <20090331133910.flci659jockgo04c@mail.elegosoft.com> <20090331135610.GA9539@topoi.pooq.com> <20090331161908.3pferzf9c08oso40@mail.elegosoft.com> Message-ID: <20090411142702.GA22586@topoi.pooq.com> On Tue, Mar 31, 2009 at 10:41:42PM +0000, Jay wrote: > > Also, presumably you can copy the entire CVS repository with little CPU use and then do the monotone work locally. I doubt it is all that large, can tell you later.. (ssh in and du /usr/cvs) > > > > - Jay OK. What's the recommended way of copying the CVS repository? Downloading a .tgz file? Or figuring out how to get cvsup up first? (the more tools I have to build before I can test feasibility, the less likely I am to get there. cvsup doesn't seem to be available in Debian; perhaps that's because Modula 3 isn't either) I seem to have two ways to try to build the monotone repository. (1) use monotone's rcs_imnport command (2) use the cvs_sync branch, generate a new monotone from that branch, and see what it does. I'd have to try both so see what's feasible. Each seems to have limitations. rcs_import seems to want to have access to the cvs files instead of network access to CVS. -- hendrik > > > > Date: Tue, 31 Mar 2009 16:19:08 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > CC: manderson at elego.de > > Subject: Re: [M3devel] m3 CVS? > > > > Quoting hendrik at topoi.pooq.com: > > > > > On Tue, Mar 31, 2009 at 01:39:10PM +0200, Olaf Wagner wrote: > > >> Quoting hendrik at topoi.pooq.com: > > >> > > >> >Is CVS back up yet? Completely? I've been delaying trying the > > >> >monotone conversion because it would be nice to have only one set > > >> >of problems to look into. > > >> > > >> CVS is up and no history should be lost, but tinderbox is still not > > >> working and several archives are missing. Michael is working on it > > >> (but he's got some other tasks, too). > > > > > > So the current source is available, but not the tools to investigate > > > their status on-line. And the other archives? What are they? Are they > > > more source code? Should they be subject to revision control too? Are > > > they ancient prehistory that should be grafted into the revision tree > > > except that it may not be technically feasible? > > > > Mostly all the old installation archives and snapshots are still missing. > > I'm not sure what's the status of the re-installation of tinderbox. > > > > > Ah. I have too many questions. > > > > > > By the way, rumours are that monotone's cvs pull command is quite > > > demanding on the cvs server, but that sync operation isn't bad at all > > > after that. Getting really old versions of files requires CVS to chain > > > back through a lot of reverse differences. And I don't know if it > > > caches any of that in case it is asked to cough up another really old > > > version. > > > > > > If there are any scheduling considerations I'd like to hear them. I > > > don't know if I'll flatten your system, but if I do there are probably > > > better and worse times to do it. (I may saturate ny DSL link first, but > > > you never know until you try it.) > > > > > > By the way, what's the total size of Modula 3's CVS archive? > > > > I've got no access from here (can only check later tonight); please > > ask Michael Anderson directly for administrative topics. > > > > Olaf > > > > PS: I don't think you can bring the server down a one external CVS > > client; the syncing will just take a long time. Unless lots of parallel > > requests are started... > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > From neels at elego.de Sat Apr 11 23:20:24 2009 From: neels at elego.de (Neels J Hofmeyr) Date: Sat, 11 Apr 2009 23:20:24 +0200 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> Message-ID: <49E10998.5010205@elego.de> I have no opinion since I'm not active in the code. ~Neels Olaf Wagner wrote: > Quoting Martin Bishop : > >> A few days ago there was more talk of a proper "release" for CM3. I >> think this is very important. > > I second that. > > I'll try to start the release engineering now, as nobody else seems > to volunteer ;-) > > We have two options here though: we can either > > (a) agree on a code freeze (beginning at some date we need to agree upon) > (b) create a release branch immediately > > Code freeze would mean that nobody commits any major new functionality > any more, but all commits concentrate on fixing bugs in some set of > release candiates. > > I'd rather avoid creating a branch too early, as that means more work > by selecting and merging fixes from trunk to branch. So here my questions: > > o Do we all agree on a temporary code freeze? > o When should we start? I.e. wha changes would you like to complete > before we start the release process? > > Please let me know your opinions, > > Olaf -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From jay.krell at cornell.edu Sun Apr 12 05:00:39 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 12 Apr 2009 03:00:39 +0000 Subject: [M3devel] readdir/malloc Message-ID: cvsup source says: (*****************************************************************************) (* FIXME - The following procedures work around a bug in SRC Modula-3 thru version 3.6, at least. The FS.Iterator operations call the Unix opendir, readdir, and closedir functions, which in turn usually call malloc. This is done without any mutual exclusion, and malloc is normally not thread-safe. I have observed memory corruption and have traced it to this cause. As a work-around, these wrappers disable thread switching while the offending functions are executing. *) (*****************************************************************************) This is already fixed wrt opendir/closedir in cm3. But readdir? True? I guess I'll be pessimistic and assume it is true. - Jay From jay.krell at cornell.edu Sun Apr 12 13:32:07 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 12 Apr 2009 11:32:07 +0000 Subject: [M3devel] cvsup Message-ID: cvsup builds and starts up on a few platforms now, including Cygwin/x86, Linux/x86, Linux/AMD64 (birch), Macosx/PowerPC, FreeBSD/x86. I can verify more later.. I expect there might be problems on Macosx/x86 and AMD64. And FreeBSD/x86 might not work until I commit the change to use Unix/common. That is -- these are the only platforms not using Unix/common. Some platforms store extra "flags" with files -- Darwin and *BSD. Historically cvsup only get/sets those on FreeBSD. I extended that to the others, though didn't build NetBSD/OpenBSD. (nor have I tested any of the functionality at all..) The source should be refactored some in this regard, the "FreeBSD" directory split into "FreeBSD" and "flags" or something. But I don't like moving files since history might not track well. (I also chose "m3-tools" arbitrarily..) It might not even have to be refactored -- instead of the static platform checks, the code can check of the #defines in Ustat are zero or not, and UstatC.c can provide empty chflags/fchflags functions instead of none at all. It's a tricky area though in terms of what is best, providing no functions, vs. providing functions that do nothing and succeed, vs. providing functions that do nothing and fail, vs. providing a more explicit way to query if the functionality is provided, as well as deciding between build-time vs. run-time checks (we don't have anything like autoconf in our system, for better and worse). Now hopefully we can switch to svn or monotone and cvsup won't matter to us. :) (Well, I never use it in any case. I know it is big in FreeBSD-land.) - Jay From jay.krell at cornell.edu Sun Apr 12 13:34:49 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 12 Apr 2009 11:34:49 +0000 Subject: [M3devel] FW: cvsup Message-ID: [truncated again..] cvsup builds and starts up on a few platforms now, including Cygwin/x86, Linux/x86, Linux/AMD64 (birch), Macosx/PowerPC, FreeBSD/x86. I can verify more later.. I expect there might be problems on Macosx/x86 and AMD64. And FreeBSD/x86 might not work until I commit the change to use Unix/common. That is -- these are the only platforms not using Unix/common. Some platforms store extra "flags" with files -- Darwin and *BSD. see man chflags and man 2 chflags. Historically cvsup only get/sets those on FreeBSD. I extended that to the others, though didn't build NetBSD/OpenBSD. (nor have I tested any of the functionality at all..) The source should be refactored some in this regard, the "FreeBSD" directory split into "FreeBSD" and "flags" or something. But I don't like moving files since history might not track well. (I also chose "m3-tools" arbitrarily..) It might not even have to be refactored -- instead of the static platform checks, the code can check of the #defines in Ustat are zero or not, and UstatC.c can provide empty chflags/fchflags functions instead of none at all. It's a tricky area though in terms of what is best, providing no functions, vs. providing functions that do nothing and succeed, vs. providing functions that do nothing and fail, vs. providing a more explicit way to query if the functionality is provided, as well as deciding between build-time vs. run-time checks (we don't have anything like autoconf in our system, for better and worse). Now hopefully we can switch to svn or monotone and cvsup won't matter to us. :) (Well, I never use it in any case. I know it is big in FreeBSD-land.) - Jay From jay.krell at cornell.edu Sun Apr 12 13:40:45 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 12 Apr 2009 11:40:45 +0000 Subject: [M3devel] (D)DCVSup in DCCS/DCVS for download In-Reply-To: <20090411134418.cqc2yem2g44ogkkg@mail.elegosoft.com> References: <20090411134418.cqc2yem2g44ogkkg@mail.elegosoft.com> Message-ID: Yes, this helped, thank you. FreeBSD4 is unusual in that it has more complete and compatible (and platform specific) m3core/unix. - Jay ---------------------------------------- > Date: Sat, 11 Apr 2009 13:44:18 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] (D)DCVSup in DCCS/DCVS for download > > Hi, > > I've put most of the source code of our more or less abandoned > DCCS project into > > http://www.opencm3.net/uploaded-archives/dccs-public.tar.gz > > for download. > > It contains a complete and extended version of CVSup along with > much other potentially useful M3 code. > > I was able to compile everything with a recent CM3 for target > FreeBSD4. > > To build everything, cd to dccs-public/prod and type make all. > Please note that the resulting executables for CVSup are named > dcvsup and dcvsupd, but they should work without DCVS configuration, > too. At least you should be able to use the source to get get standard > CVSup to compile. > > Hope this helps, > > Olaf > -- From jay.krell at cornell.edu Sun Apr 12 14:07:44 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 12 Apr 2009 12:07:44 +0000 Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN In-Reply-To: <20090411105512.92784fp7cc0o448k@mail.elegosoft.com> References: <20090411105512.92784fp7cc0o448k@mail.elegosoft.com> Message-ID: My machine calls itself: jbook15:~ jay$ uname -a Darwin jbook15.local 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc That is 10.4.something. It works ok. cm3cg built as recently as 4/10.. - Jay ________________________________ > From: jay > To: wagner; m3devel > Subject: RE: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN > Date: Sat, 11 Apr 2009 12:03:39 +0000> > > I do test on 10.4 fairly often... > It sounds like 7.9.0 is 10.3? > > > - Jay > >> Date: Sat, 11 Apr 2009 10:55:12 +0200 >> From: wagner@ >> To: m3devel@ >> Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN >> >> After trying to upgrade cm3 on my notebook to the latest version, >> I get lots of internal compiler errors.This is on >> >> % uname -a >> Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 >> 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power >> Macintosh powerpc >> >> ... From jay.krell at cornell.edu Sun Apr 12 21:45:44 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 12 Apr 2009 19:45:44 +0000 Subject: [M3devel] cvsup and "flags" Message-ID: Um, these "flags" that cvsup is willing to traffic: 1) They are the same between machines that support them? Maybe, maybe not, I can check. 2) They are actually interesting? Given that many operating systems (e.g. Linux, Solaris) don't support them? They seem a little dubious. I suppose most cvsup users have both client and server on FreeBSD and if the FreeBSD source itself needs these flags on source controled files, it is useful. Even storing an executable bit in cvs seems not portable..but that is a different set of flags. (NTFS ACL should be reasonable superset, but then, FAT?) - Jay From mika at async.caltech.edu Sun Apr 12 22:05:49 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 12 Apr 2009 13:05:49 -0700 Subject: [M3devel] quick question for the Modula-3 ether... LONGFLOAT?? Message-ID: <200904122005.n3CK5omN035622@camembert.async.caltech.edu> Does anyone out there have any idea why a lot of bits of Modula-3 refer to something called "LONGFLOAT" or "LongFloat". I just checked Wirth, and Modula-2 used "REAL" as well so it doesn't seem like LONGREAL would ever have been called "LONGFLOAT". Is LONGFLOAT/LongFloat of any significance or is it OK to search-and-replace it away with LONGREAL/LongReal everywhere? (I'm talking about things like the emacs macro package as well as all over m3tk...) Mika From jay.krell at cornell.edu Mon Apr 13 00:01:35 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 12 Apr 2009 22:01:35 +0000 Subject: [M3devel] quick question for the Modula-3 ether... LONGFLOAT?? In-Reply-To: <200904122005.n3CK5omN035622@camembert.async.caltech.edu> References: <200904122005.n3CK5omN035622@camembert.async.caltech.edu> Message-ID: 1) I'm sure it is a natural term to all the other programmers, easy mistake to make. 2) There in fact this natural need to come up with alternate names. You know, if you read the compiler and runtime source, you see things called Type and/or Tipe, not just Type, because Type (or at least TYPE) is already a reserved word if you write "metacode" dealing with types, you can't use that name. In that vein there are some public m3core modules for dealing with floats/reals/whatever and they might use names like this. - Jay > To: m3devel at elegosoft.com > Date: Sun, 12 Apr 2009 13:05:49 -0700 > From: mika at async.caltech.edu > Subject: [M3devel] quick question for the Modula-3 ether... LONGFLOAT?? > > > Does anyone out there have any idea why a lot of bits of Modula-3 > refer to something called "LONGFLOAT" or "LongFloat". I just checked > Wirth, and Modula-2 used "REAL" as well so it doesn't seem like > LONGREAL would ever have been called "LONGFLOAT". > > Is LONGFLOAT/LongFloat of any significance or is it OK to > search-and-replace it away with LONGREAL/LongReal everywhere? > > (I'm talking about things like the emacs macro package as well as > all over m3tk...) > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Apr 13 00:22:23 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 12 Apr 2009 15:22:23 -0700 Subject: [M3devel] quick question for the Modula-3 ether... LONGFLOAT?? In-Reply-To: Your message of "Sun, 12 Apr 2009 22:01:35 -0000." Message-ID: <200904122222.n3CMMNTc041696@camembert.async.caltech.edu> It seems a bit more common a term than I would have thought from someone's making a mistake. I am talking about things like this. In the stubgen sources, there are two interfaces: Value.i3 and Type.i3. Not the only place I've seen it in Modula-3. Value.i3 has: TYPE T <: ROOT; (* Ordinal | Float | LongFloat | Extended | ArrayOrRecord | Set | Text | Null *) Ordinal = T OBJECT ord: INTEGER END; (* ORD(the value) *) Float = T OBJECT val: REAL END; (* XXX *) LongFloat = T OBJECT val: LONGREAL END; (* XXX *) Extended = T OBJECT val: EXTENDED END; ... Type.i3 has: TYPE T <: OBJECT name: Qid; visited := FALSE; brandsOK := TRUE END; (* Ordinal | Real | LongReal | Extended | Reference | Array | Packed | Record | Set | Procedure *) Ordinal = T BRANDED OBJECT END; (* Enumeration | Subrange *) (* ... *) Real = T BRANDED OBJECT END; (* YYY *) LongReal = T BRANDED OBJECT END; (* YYY *) Extended = T BRANDED OBJECT END; ... Is there a reason or is this just inconsistent crud from before the glaciers came thru? Mika Jay writes: >--_eaf98d33-2bbc-4e5b-8afc-bc1f32079c51_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >1) I'm sure it is a natural term to all the other programmers=2C easy mista= >ke to make. > >=20 > >2) There in fact this natural need to come up with alternate names. > >You know=2C if you read the compiler and runtime source=2C you see things c= >alled Type and/or Tipe=2C not just Type=2C because Type (or at least TYPE) = >is already a reserved word if you write "metacode" dealing with types=2C yo= >u can't use that name. > >=20 > >In that vein there are some public m3core modules for dealing with floats/r= >eals/whatever and they might use names like this. > >=20 > > - Jay > > >=20 >> To: m3devel at elegosoft.com >> Date: Sun=2C 12 Apr 2009 13:05:49 -0700 >> From: mika at async.caltech.edu >> Subject: [M3devel] quick question for the Modula-3 ether... LONGFLOAT?? >>=20 >>=20 >> Does anyone out there have any idea why a lot of bits of Modula-3 >> refer to something called "LONGFLOAT" or "LongFloat". I just checked >> Wirth=2C and Modula-2 used "REAL" as well so it doesn't seem like >> LONGREAL would ever have been called "LONGFLOAT". >>=20 >> Is LONGFLOAT/LongFloat of any significance or is it OK to >> search-and-replace it away with LONGREAL/LongReal everywhere? >>=20 >> (I'm talking about things like the emacs macro package as well as >> all over m3tk...) >>=20 >> Mika > >--_eaf98d33-2bbc-4e5b-8afc-bc1f32079c51_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >1) I'm sure it is a natural term to all the =3Bother programmers=2C eas= >y mistake to make.
> =3B
>2) There in fact this =3Bnatural need to come up with alternate names.<= >BR> >You know=2C if you read the compiler =3Band runtime source=2C you see t= >hings called Type and/or Tipe=2C not just Type=2C because Type (or at least= > TYPE) is already a reserved word if you write =3B"metacode" dealing wi= >th types=2C you can't use that name.
> =3B
>In that =3Bvein there are some =3Bpublic m3core modules for dealing= > with floats/reals/whatever and they =3Bmight use names like this.
> =3B
> =3B- Jay


 =3B
>=3B To: m3devel at elegosoft.com
&g= >t=3B Date: Sun=2C 12 Apr 2009 13:05:49 -0700
>=3B From: mika at async.cal= >tech.edu
>=3B Subject: [M3devel] quick question for the Modula-3 ether= >... LONGFLOAT??
>=3B
>=3B
>=3B Does anyone out there have = >any idea why a lot of bits of Modula-3
>=3B refer to something called = >"LONGFLOAT" or "LongFloat". I just checked
>=3B Wirth=2C and Modula-2 = >used "REAL" as well so it doesn't seem like
>=3B LONGREAL would ever h= >ave been called "LONGFLOAT".
>=3B
>=3B Is LONGFLOAT/LongFloat of= > any significance or is it OK to
>=3B search-and-replace it away with = >LONGREAL/LongReal everywhere?
>=3B
>=3B (I'm talking about thing= >s like the emacs macro package as well as
>=3B all over m3tk...)
&g= >t=3B
>=3B Mika
>= > >--_eaf98d33-2bbc-4e5b-8afc-bc1f32079c51_-- From jay.krell at cornell.edu Mon Apr 13 02:00:40 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 13 Apr 2009 00:00:40 +0000 Subject: [M3devel] quick question for the Modula-3 ether... LONGFLOAT?? In-Reply-To: <200904122222.n3CMMNTc041696@camembert.async.caltech.edu> References: Your message of "Sun, 12 Apr 2009 22:01:35 -0000." <200904122222.n3CMMNTc041696@camembert.async.caltech.edu> Message-ID: Here is the stuff I was talking about: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/float/Common/ This stuff is "standard" and in the green book. Surprising that both names occur here, float and real. You can see your example sort of proves my point. Imagine if there was no case sensitivity. Or if you aren't keen on identifiers varying only in case. The below needs to setup a parallel set of names for "wrapper types", or WrapperModule.T. Changing "Float" to "Real" or vice versa can help. Though, now that I'm saying it, it feels a bit sleazy. Maybe better to invent a prefix or suffix. IntegerValue, RealValue, etc. (That reminds me, I've seen "reel" used in a similar fashion.) You know, using homonyms -- ea vs. ee, y for long i, etc. tipe, type runtime, runtyme - Jay > To: jay.krell at cornell.edu > Date: Sun, 12 Apr 2009 15:22:23 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] quick question for the Modula-3 ether... LONGFLOAT?? > > > It seems a bit more common a term than I would have thought from > someone's making a mistake. > > I am talking about things like this. In the stubgen sources, there are > two interfaces: Value.i3 and Type.i3. > > Not the only place I've seen it in Modula-3. > > Value.i3 has: > > TYPE > T <: ROOT; > (* Ordinal | Float | LongFloat | Extended | ArrayOrRecord | Set | > Text | Null *) > > Ordinal = T OBJECT ord: INTEGER END; > (* ORD(the value) *) > > Float = T OBJECT val: REAL END; (* XXX *) > > LongFloat = T OBJECT val: LONGREAL END; (* XXX *) > > Extended = T OBJECT val: EXTENDED END; > > ... > > Type.i3 has: > > TYPE > T <: OBJECT name: Qid; visited := FALSE; brandsOK := TRUE END; > > (* Ordinal | Real | LongReal | Extended | Reference | Array > | Packed | Record | Set | Procedure *) > > Ordinal = T BRANDED OBJECT END; (* Enumeration | Subrange *) > > (* ... *) > > Real = T BRANDED OBJECT END; (* YYY *) > > LongReal = T BRANDED OBJECT END; (* YYY *) > > Extended = T BRANDED OBJECT END; > > ... > > Is there a reason or is this just inconsistent crud from before the > glaciers came thru? > > Mika > > > Jay writes: > >--_eaf98d33-2bbc-4e5b-8afc-bc1f32079c51_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >1) I'm sure it is a natural term to all the other programmers=2C easy mista= > >ke to make. > > > >=20 > > > >2) There in fact this natural need to come up with alternate names. > > > >You know=2C if you read the compiler and runtime source=2C you see things c= > >alled Type and/or Tipe=2C not just Type=2C because Type (or at least TYPE) = > >is already a reserved word if you write "metacode" dealing with types=2C yo= > >u can't use that name. > > > >=20 > > > >In that vein there are some public m3core modules for dealing with floats/r= > >eals/whatever and they might use names like this. > > > >=20 > > > > - Jay > > > > > >=20 > >> To: m3devel at elegosoft.com > >> Date: Sun=2C 12 Apr 2009 13:05:49 -0700 > >> From: mika at async.caltech.edu > >> Subject: [M3devel] quick question for the Modula-3 ether... LONGFLOAT?? > >>=20 > >>=20 > >> Does anyone out there have any idea why a lot of bits of Modula-3 > >> refer to something called "LONGFLOAT" or "LongFloat". I just checked > >> Wirth=2C and Modula-2 used "REAL" as well so it doesn't seem like > >> LONGREAL would ever have been called "LONGFLOAT". > >>=20 > >> Is LONGFLOAT/LongFloat of any significance or is it OK to > >> search-and-replace it away with LONGREAL/LongReal everywhere? > >>=20 > >> (I'm talking about things like the emacs macro package as well as > >> all over m3tk...) > >>=20 > >> Mika > > > >--_eaf98d33-2bbc-4e5b-8afc-bc1f32079c51_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >1) I'm sure it is a natural term to all the =3Bother programmers=2C eas= > >y mistake to make.
> > =3B
> >2) There in fact this =3Bnatural need to come up with alternate names.<= > >BR> > >You know=2C if you read the compiler =3Band runtime source=2C you see t= > >hings called Type and/or Tipe=2C not just Type=2C because Type (or at least= > > TYPE) is already a reserved word if you write =3B"metacode" dealing wi= > >th types=2C you can't use that name.
> > =3B
> >In that =3Bvein there are some =3Bpublic m3core modules for dealing= > > with floats/reals/whatever and they =3Bmight use names like this.
> > =3B
> > =3B- Jay


 =3B
>=3B To: m3devel at elegosoft.com
&g= > >t=3B Date: Sun=2C 12 Apr 2009 13:05:49 -0700
>=3B From: mika at async.cal= > >tech.edu
>=3B Subject: [M3devel] quick question for the Modula-3 ether= > >... LONGFLOAT??
>=3B
>=3B
>=3B Does anyone out there have = > >any idea why a lot of bits of Modula-3
>=3B refer to something called = > >"LONGFLOAT" or "LongFloat". I just checked
>=3B Wirth=2C and Modula-2 = > >used "REAL" as well so it doesn't seem like
>=3B LONGREAL would ever h= > >ave been called "LONGFLOAT".
>=3B
>=3B Is LONGFLOAT/LongFloat of= > > any significance or is it OK to
>=3B search-and-replace it away with = > >LONGREAL/LongReal everywhere?
>=3B
>=3B (I'm talking about thing= > >s like the emacs macro package as well as
>=3B all over m3tk...)
&g= > >t=3B
>=3B Mika
> >= > > > >--_eaf98d33-2bbc-4e5b-8afc-bc1f32079c51_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.m.bates at cox.net Mon Apr 13 04:12:34 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Sun, 12 Apr 2009 21:12:34 -0500 Subject: [M3devel] small objects In-Reply-To: <200904101918.n3AJIcLj003231@camembert.async.caltech.edu> References: <200904101918.n3AJIcLj003231@camembert.async.caltech.edu> Message-ID: <49E29F92.7000808@cox.net> Mika Nystrom wrote: > Sigh, I hate sending so many emails to a mailing list. Sorry about > the inboxes I'm clogging of people with no interest in this. > > But I just realized something important, which I think may be > decisive in deciding the fate of the name "REFANY" in the addition > of new types. > > Rodney proposes > > TAGGED T <: TAGGED REFANY > No. I am specifically proposing that TAGGED T and TAGGED U have _no_ subtype relation, when T #U. Putting the tagged types into their own hierarchy creates a big complicated subtype mess, with both two hierarchies on the one hand and subtype cross-links between them on the other hand. I also really calls for a new, complex structural type equality rule that is very out of sync with the existing type equality rule. > T <: REFANY <: TAGGED REFANY > > I propose > > TAGGED T <: REFANY > T <: UNTAGGEDREFANY <: REFANY > > Both proposals are identical in the power of the language that > results, because they differ merely in naming. > > Both proposals are also backward-compatible: all existing Modula-3 > programs are unchanged by them. > > However, UNTAGGEDREFANY (mine), is *forward*-compatible as well > as backward-compatible. > > Think about it. The TAGGED REFANY proposal will have the following > effect: people will go through all the M3 libraries and replace > every or almost every occurrence of REFANY with TAGGED REFANY. The > resulting code will not compile with an older compiler! > > In my proposal, it is the user of the TAGGED types who is responsible > for---in new code only!---deciding whether he wants his code to > compile both on older and newer M3 systems. If he does, then he > can add appropriate implementations for compilers that don't support > the TAGGED types (which will be trivial since he has to have those > anyway!) The burden of handling change is on the programmer of the > special new feature rather than on everyone who has a container > module. > Well, I do see how this certain class of uses of REFANY could have their meaning changed in this way, with no required editing of source code. But it reminds me of the joke that real programmers don't fix their code, they just patch the compiler. Despite my strong belief in the ability to have portable code, I think it is a terrible thing to have the same code have fundamentally different semantics when compiled by different compilers, even if you can cite a large class of uses for which this semantic change happens to be handy. For portable container data structures between pre/post tagged Modula-3, declare a type in one place and change it in that one place: TYPE MostGeneralContainerElement = REFANY. or TYPE MostGeneralContainerElement = TAGGED REFANY. Then have all the containter ADTs equate their element type to this. It is also a glaring inconsistency to have all reference types other than REFANY to be untagged by default and made tagged by an explicit TAGGED, while REFANY defaults the other way around. > I'll try to refrain from posting any more messages on this topic now. > > Mika > > "Rodney M. Bates" writes: > >> Mika Nystrom wrote: >> >>> Sorry to splice together two emails from you, but I feel I've already >>> used up my m3devel quota this week: >>> >>> "Rodney M. Bates" writes: >>> >>> >>>>> Are you sure? I want a type---some type---that can hold "any >>>>> reference, even a tagged one", and I would rewrite most library >>>>> code that today takes REFANY to take that instead. Why not? Why >>>>> would I want to limit it to REFANY when it performs no operations >>>>> that couldn't legally be performed on TAGGED REFANY. >>>>> >>>>> >>>>> >>>> I believe my "safe" proposal would make this very simple, if I am >>>> thinking of the kind of library code you are. >>>> >>>> I envision a container data structure that takes in things and returns >>>> them without performing operations on them other than moving them around >>>> and storing them, e.g. the ever belabored stack. The values going in >>>> and out are declared REFANY, and the client passes in values of >>>> some proper subtype of REFANY, which get assigned to the REFANY >>>> parameters. When it gets them back, it narrows them to this type. >>>> >>>> In this pattern, just changing the declared type of the container values >>>> >>>> >>> >from REFANY to TAGGED REFANY would do it. The library code's storage >>> ... >>> >>> >> There are two very different kinds of uses of reference and >> tagged types. The one I speak of above is for the type of the >> elements inside a container data structure. In this case, it >> is the client that knows what type the value really is, and will >> declare it as such. The library ADT module should know as little >> as possible about it, so it will declare it as REFANY or >> TAGGED REFANY. Here, you want the most general type >> possible, just to make the abstraction more versatile. >> And TAGGED REFANY generalizes it from REFANY. >> >> But... >> >>> >>> >> >>>>> you'd like to store these in a REFANY and dynamically test for the >>>>> appropriate tagged type: >>>>> >>>>> >>>> No, I do not want to store these in a variable of type REFANY or any >>>> other existing type. >>>> In fact, I want to forbid it. >>>> >>>> >>> I think you are thinking of exactly the same kind of library code. >>> TextRefTbl.T, RefList.T, etc. >>> >>> After the introduction of TAGGED REFANY, what use is there for >>> REFANY? What piece of code can you think of where the cost of the >>> 1-LSB check of TAGGED REFANY outweighs the convenience of being >>> able to process objects of type TAGGED T (for all ref types T) as >>> well as objects of type T? >>> >>> >> The other use is for the abstract type itself. Forgetting tagged >> types for a moment, I have never seen an interface/module that >> uses REFANY for this. Instead, the modules declare their abstract >> type as some proper subtype of REFANY, usually an opaque type. >> >> It would be possible to use just REFANY here of course, but that would >> require an otherwise unnecessary RT check on the allocated type, >> every time an operation of the module is called. This is a much >> more expensive check than a tag check, as has been pointed out >> in this discussion. >> >> But worse, it would sacrifice the static checking that we now have >> that prevents, at compile time, clients from passing, say a Text.T >> to some procedure in Atom that expects an Atom.T. If these modules >> ever wanted to use a tagged type, but the only tagged type were >> REFANY, we would lose this static checking, because Text.T would >> have to become equal to Atom.T. >> >> In cases where your algorithms don't specifically need dynamic >> typing, static typing is always much better, because one run of >> the compiler on the source code will do it. Bugs checked >> only at runtime require a massive test suit to be coded and then >> regularly rerun to get even close to the same confidence they've >> been found. >> >> So when using tagged types as the ADT itself,, we need to be able >> to have a tagged version of whatever proper subtype of REFANY >> the abstraction needs, including an opaque subtype of REFANY >> or an opaque subtype of some Public subtype of REFANY. This is >> why I am adamant that we need to be able to build a tagged type >> > >from any traced or object type. > >> And once you do this, keeping REFANY itself unchanged and allowing >> TAGGED REFANY as one case of a tagged type falls out of the system >> for free _and_ saves a lot of cases that would otherwise need a new RT >> check that can never fail, but the language can't know that, because >> the type system has lost the distinction. >> >> I really feel that the fad of all dynamic typing in languages is a huge >> mistake and that it will someday be recognized as such. In the >> meantime, we have a language that provides a very extensive set >> of statically-typed alternatives, while also allowing dynamic typing >> when you really need it. This is one of Modula-3's best principles. >> Let's don't erode the static alternatives unnecessarily. >> >> >>> Mika >>> >>> >>> > > From rodney.m.bates at cox.net Mon Apr 13 04:12:29 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Sun, 12 Apr 2009 21:12:29 -0500 Subject: [M3devel] small objects In-Reply-To: <200904101902.n3AJ27UI002559@camembert.async.caltech.edu> References: <200904101902.n3AJ27UI002559@camembert.async.caltech.edu> Message-ID: <49E29F8D.9040103@cox.net> Mika Nystrom wrote: > Specific proposal. > > What Rodney said, *except* make REFANY the root of everything. > Insert an untagged root with a new name. > > Rodney himself has said that the uses of REFANY he knows about would > be changed to accept the TAGGED type, No, not all of them. Just those that are the element type of general-purpose container data types. > so I simply propose allowing > REFANY to handle the TAGGED type by default, and insert a new root > for the untagged types. The structure of the type hierarchy is > exactly the same as in Rodney's proposal, but the different naming > makes it more backward-compatible. > > ROOT <: UNTAGGEDREFANY > T <: UNTAGGEDREFANY > > UNTAGGEDREFANY <: REFANY > > and finally. > > TAGGED T <: REFANY (* for all T *) > > The advantages with this proposal are that it does precisely what > Rodney is asking for (typesafe ADTs), but it's compatible with > Tony's runtime changes in the *current* M3 implementation and it > won't require anyone to do a massive search and replace, replacing > REFANY with "TAGGED REFANY" in every existing Modula-3 program. > > Supposed disadvantage: every TYPECASE, NARROW, etc., of REFANY will > cost an extra LSB check. Those who feel strongly about that and > for some reason *know* that they don't want to process TAGGED types > (which may be the empty set), can modify their code to use > UNTAGGEDREFANY instead of REFANY. > I am still not sure we are communicating. I am proposing that _only_ the tagged types, i.e., those constructed by TAGGED T, for T a traced or object type, can have a LSB nonzero. So TYPECASE and friends will not have an LSB check when applied to T, only when applied to TAGGED T. > Mika > > "Rodney M. Bates" writes: > >> Mika Nystrom wrote: >> >>> Sorry to splice together two emails from you, but I feel I've already >>> used up my m3devel quota this week: >>> >>> "Rodney M. Bates" writes: >>> >>> >>>>> Are you sure? I want a type---some type---that can hold "any >>>>> reference, even a tagged one", and I would rewrite most library >>>>> code that today takes REFANY to take that instead. Why not? Why >>>>> would I want to limit it to REFANY when it performs no operations >>>>> that couldn't legally be performed on TAGGED REFANY. >>>>> >>>>> >>>>> >>>> I believe my "safe" proposal would make this very simple, if I am >>>> thinking of the kind of library code you are. >>>> >>>> I envision a container data structure that takes in things and returns >>>> them without performing operations on them other than moving them around >>>> and storing them, e.g. the ever belabored stack. The values going in >>>> and out are declared REFANY, and the client passes in values of >>>> some proper subtype of REFANY, which get assigned to the REFANY >>>> parameters. When it gets them back, it narrows them to this type. >>>> >>>> In this pattern, just changing the declared type of the container values >>>> >>>> >>> >from REFANY to TAGGED REFANY would do it. The library code's storage >>> ... >>> >>> >> There are two very different kinds of uses of reference and >> tagged types. The one I speak of above is for the type of the >> elements inside a container data structure. In this case, it >> is the client that knows what type the value really is, and will >> declare it as such. The library ADT module should know as little >> as possible about it, so it will declare it as REFANY or >> TAGGED REFANY. Here, you want the most general type >> possible, just to make the abstraction more versatile. >> And TAGGED REFANY generalizes it from REFANY. >> >> But... >> >>> >>> >> >>>>> you'd like to store these in a REFANY and dynamically test for the >>>>> appropriate tagged type: >>>>> >>>>> >>>> No, I do not want to store these in a variable of type REFANY or any >>>> other existing type. >>>> In fact, I want to forbid it. >>>> >>>> >>> I think you are thinking of exactly the same kind of library code. >>> TextRefTbl.T, RefList.T, etc. >>> >>> After the introduction of TAGGED REFANY, what use is there for >>> REFANY? What piece of code can you think of where the cost of the >>> 1-LSB check of TAGGED REFANY outweighs the convenience of being >>> able to process objects of type TAGGED T (for all ref types T) as >>> well as objects of type T? >>> >>> >> The other use is for the abstract type itself. Forgetting tagged >> types for a moment, I have never seen an interface/module that >> uses REFANY for this. Instead, the modules declare their abstract >> type as some proper subtype of REFANY, usually an opaque type. >> >> It would be possible to use just REFANY here of course, but that would >> require an otherwise unnecessary RT check on the allocated type, >> every time an operation of the module is called. This is a much >> more expensive check than a tag check, as has been pointed out >> in this discussion. >> >> But worse, it would sacrifice the static checking that we now have >> that prevents, at compile time, clients from passing, say a Text.T >> to some procedure in Atom that expects an Atom.T. If these modules >> ever wanted to use a tagged type, but the only tagged type were >> REFANY, we would lose this static checking, because Text.T would >> have to become equal to Atom.T. >> >> In cases where your algorithms don't specifically need dynamic >> typing, static typing is always much better, because one run of >> the compiler on the source code will do it. Bugs checked >> only at runtime require a massive test suit to be coded and then >> regularly rerun to get even close to the same confidence they've >> been found. >> >> So when using tagged types as the ADT itself,, we need to be able >> to have a tagged version of whatever proper subtype of REFANY >> the abstraction needs, including an opaque subtype of REFANY >> or an opaque subtype of some Public subtype of REFANY. This is >> why I am adamant that we need to be able to build a tagged type >> > >from any traced or object type. > >> And once you do this, keeping REFANY itself unchanged and allowing >> TAGGED REFANY as one case of a tagged type falls out of the system >> for free _and_ saves a lot of cases that would otherwise need a new RT >> check that can never fail, but the language can't know that, because >> the type system has lost the distinction. >> >> I really feel that the fad of all dynamic typing in languages is a huge >> mistake and that it will someday be recognized as such. In the >> meantime, we have a language that provides a very extensive set >> of statically-typed alternatives, while also allowing dynamic typing >> when you really need it. This is one of Modula-3's best principles. >> Let's don't erode the static alternatives unnecessarily. >> >> >>> Mika >>> >>> >>> > > From jay.krell at cornell.edu Mon Apr 13 11:46:22 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 13 Apr 2009 09:46:22 +0000 Subject: [M3devel] pieces of TARGET? Message-ID: We have: TARGET= NT386, LINUXLIBC6, AMD64_DARWIN, etc. OS_TYPE= Win32 or POSIX I added HOST, HOST_OS_TYPE, etc. We should also have TARGET_ARCHITECTURE=X86,AMD64,SPARC32,SPARC64,PPC32,PPC64,MIP32,MIP64,etc. probably defined be whatever preceded the first underscore in new consistently named targets (X86 or I386?) Because already have WORD_SIZE, can probably refine this to just: X86,AMD64,SPARC,PPC,MIPS, no general need for "32" and "64" variants. (I hesitate to point out that neither ALPHA nor IA64 imply WORD_SIZE=64. NT on Alpha had 32bit and 64bit variants, HP-UX on IA64 ditto for usermode). Maybe even can drop AMD64 from this list. TARGET_OS or TARGET_KERNEL or somesuch=NT,LINUX,SOLARIS,DARWIN,CYGWIN, etc. probably defined to be whatever follows the lone underscore in new consistently named targets, with a single underscore Leaving unspecified what to do about ARM and its competing calling conventions and C runtimes Then we can check, for example, if TARGET_OS == "FREEBSD" and get all architectures at once. There isn't a huge need for this, but some. Besides, TARGET_ENDIAN= BIG or LITTLE should probably be exposed. You know, if you look at the lists of platforms, both in Target.m3 and the various m3makefiles, sometimes they can be shortened. Sometimes all that is needed is the "OS" (e.g. the time/date stuff) or the endian or architecture(the float stuff). I realize there aren't tons of these lists, so it's not a huge deal. Let me know if any objections are strong opinions on nailing some of the details. My biggest objection is there is always a lag from the time compiler changes are in, until you can/should depend on them. Building newer code with older compiler and such. It makes it such that it seems sometimes not worth changing anything. Thanks, - Jay From wagner at elegosoft.com Mon Apr 13 12:51:48 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 13 Apr 2009 12:51:48 +0200 Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN In-Reply-To: References: <20090411105512.92784fp7cc0o448k@mail.elegosoft.com> Message-ID: <20090413125148.vxbxs7ftessckwko@mail.elegosoft.com> Quoting Jay : > > My machine calls itself: > > jbook15:~ jay$ uname -a > Darwin jbook15.local 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 > 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh > powerpc > > That is 10.4.something. It works ok. cm3cg built as recently as 4/10.. So it seems OK for newer MacOS X releases. I worked around it here by continuning to use an older backend, which seems OK for now. Doing a realclean and a complete rebuild, I got syntax errors with some pattern substitution in a Makefile, and the build stopped. I'll try a newer backend compiled on another machine, too. Olaf > - Jay > > > ________________________________ >> From: jay >> To: wagner; m3devel >> Subject: RE: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN >> Date: Sat, 11 Apr 2009 12:03:39 +0000> >> >> I do test on 10.4 fairly often... > >> It sounds like 7.9.0 is 10.3? >> >> >> - Jay >> >>> Date: Sat, 11 Apr 2009 10:55:12 +0200 >>> From: wagner@ >>> To: m3devel@ >>> Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN >>> >>> After trying to upgrade cm3 on my notebook to the latest version, >>> I get lots of internal compiler errors.This is on >>> >>> % uname -a >>> Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 >>> 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power >>> Macintosh powerpc >>> >>> ... -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 13 12:56:40 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 13 Apr 2009 12:56:40 +0200 Subject: [M3devel] cvsup and "flags" In-Reply-To: References: Message-ID: <20090413125640.58q2uf7spw0w844o@mail.elegosoft.com> Quoting Jay : > > Um, these "flags" that cvsup is willing to traffic: > > 1) They are the same between machines that support them? > Maybe, maybe not, I can check. > > 2) They are actually interesting? Given that many operating > systems (e.g. Linux, Solaris) don't support them? Yes, they are interesting and important, since they are in use at many sites. They're not portable as far as I know though. The system immutable flag is used by many FreeBSD installations to further protect from accidental and unauthorized changes. > They seem a little dubious. > I suppose most cvsup users have both client and server on FreeBSD > and if the FreeBSD source itself needs these flags on source > controled files, it is useful. > > Even storing an executable bit in cvs seems not portable..but that > is a different set of flags. (NTFS ACL should be reasonable > superset, but then, FAT?) POSIX file access control lists should be portable to a certain degree. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 13 12:58:30 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 13 Apr 2009 10:58:30 +0000 Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN In-Reply-To: <20090413125148.vxbxs7ftessckwko@mail.elegosoft.com> References: <20090411105512.92784fp7cc0o448k@mail.elegosoft.com> <20090413125148.vxbxs7ftessckwko@mail.elegosoft.com> Message-ID: > I got syntax errors with > some pattern substitution in a Makefile, and the build stopped. make vs. gmake? - Jay ---------------------------------------- > Date: Mon, 13 Apr 2009 12:51:48 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN > > Quoting Jay : > >> >> My machine calls itself: >> >> jbook15:~ jay$ uname -a >> Darwin jbook15.local 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 >> 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh >> powerpc >> >> That is 10.4.something. It works ok. cm3cg built as recently as 4/10.. > > So it seems OK for newer MacOS X releases. I worked around it here by > continuning to use an older backend, which seems OK for now. > Doing a realclean and a complete rebuild, I got syntax errors with > some pattern substitution in a Makefile, and the build stopped. > > I'll try a newer backend compiled on another machine, too. > > Olaf > >> - Jay >> >> >> ________________________________ >>> From: jay >>> To: wagner; m3devel >>> Subject: RE: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN >>> Date: Sat, 11 Apr 2009 12:03:39 +0000> >>> >>> I do test on 10.4 fairly often... >> >>> It sounds like 7.9.0 is 10.3? >>> >>> >>> - Jay >>> >>>> Date: Sat, 11 Apr 2009 10:55:12 +0200 >>>> From: wagner@ >>>> To: m3devel@ >>>> Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN >>>> >>>> After trying to upgrade cm3 on my notebook to the latest version, >>>> I get lots of internal compiler errors.This is on >>>> >>>> % uname -a >>>> Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 >>>> 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power >>>> Macintosh powerpc >>>> >>>> ... > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 13 13:04:58 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 13 Apr 2009 11:04:58 +0000 Subject: [M3devel] cvsup and "flags" In-Reply-To: <20090413125640.58q2uf7spw0w844o@mail.elegosoft.com> References: <20090413125640.58q2uf7spw0w844o@mail.elegosoft.com> Message-ID: It's a little different to say "these flags are useful" vs. "I should be able to store these flags in source control". Not entirely different, but somewhat. If you need them in source control, then you need your source control system to bother with system-dependent possibly esoteric features. On the other hand, if nobody every catered to good system-dependent aspects, a lot of things would be a lot worse. I only skimmed the cvsup source a little, but I think it traffics in plain integers. It would be smarter to traffic in the "name" of the flag, and the "OS name" it originated from..and maybe allow some "required" vs. "optional" bit. That way, if Darwin and FreeBSD both had the flag "FOO", it hopefully/probably means the same on each, but could be "translated" into the proper integer. And if user deemed flag "FOO" important than cvsup could error for updates to a system that doesn't support it. Maybe it already does do these things though. Some people use "source control" for keep track of and backup their "system configuration" or perhaps their entire "system install". Whereas most people just store a bunch of text files. There can be quite a difference -- e.g. support for hardlinks, symlinks, owner user, owner group, etc.. Folks just storing textual source files tend to have lighter requirements. (which reminds me -- can you clear the executable bit on the vast majority of non-directories in the tree, like outside of scripts/*.sh and scripts/*.py) - Jay ---------------------------------------- > Date: Mon, 13 Apr 2009 12:56:40 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] cvsup and "flags" > > Quoting Jay : > >> >> Um, these "flags" that cvsup is willing to traffic: >> >> 1) They are the same between machines that support them? >> Maybe, maybe not, I can check. >> >> 2) They are actually interesting? Given that many operating >> systems (e.g. Linux, Solaris) don't support them? > > Yes, they are interesting and important, since they are in use > at many sites. They're not portable as far as I know though. > > The system immutable flag is used by many FreeBSD installations to > further protect from accidental and unauthorized changes. > >> They seem a little dubious. >> I suppose most cvsup users have both client and server on FreeBSD >> and if the FreeBSD source itself needs these flags on source >> controled files, it is useful. >> >> Even storing an executable bit in cvs seems not portable..but that >> is a different set of flags. (NTFS ACL should be reasonable >> superset, but then, FAT?) > > POSIX file access control lists should be portable to a certain degree. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 13 13:07:20 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 13 Apr 2009 13:07:20 +0200 Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN In-Reply-To: References: <20090411105512.92784fp7cc0o448k@mail.elegosoft.com> <20090413125148.vxbxs7ftessckwko@mail.elegosoft.com> Message-ID: <20090413130720.aziv5e0fggwgccw0@mail.elegosoft.com> Quoting Jay : > >> I got syntax errors with >> some pattern substitution in a Makefile, and the build stopped. > > make vs. gmake? Maybe (log attached). But shouldn't configure be able to figure this out by itself? GNU make is /usr/bin/gnumake on this system (Fink packages). Olaf > - Jay > > > > ---------------------------------------- >> Date: Mon, 13 Apr 2009 12:51:48 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN >> >> Quoting Jay : >> >>> >>> My machine calls itself: >>> >>> jbook15:~ jay$ uname -a >>> Darwin jbook15.local 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 >>> 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh >>> powerpc >>> >>> That is 10.4.something. It works ok. cm3cg built as recently as 4/10.. >> >> So it seems OK for newer MacOS X releases. I worked around it here by >> continuning to use an older backend, which seems OK for now. >> Doing a realclean and a complete rebuild, I got syntax errors with >> some pattern substitution in a Makefile, and the build stopped. >> >> I'll try a newer backend compiled on another machine, too. >> >> Olaf >> >>> - Jay >>> >>> >>> ________________________________ >>>> From: jay >>>> To: wagner; m3devel >>>> Subject: RE: [M3devel] Internal compiler errors after upgrade on >>>> PPC_DARWIN >>>> Date: Sat, 11 Apr 2009 12:03:39 +0000> >>>> >>>> I do test on 10.4 fairly often... >>> >>>> It sounds like 7.9.0 is 10.3? >>>> >>>> >>>> - Jay >>>> >>>>> Date: Sat, 11 Apr 2009 10:55:12 +0200 >>>>> From: wagner@ >>>>> To: m3devel@ >>>>> Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN >>>>> >>>>> After trying to upgrade cm3 on my notebook to the latest version, >>>>> I get lots of internal compiler errors.This is on >>>>> >>>>> % uname -a >>>>> Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 >>>>> 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power >>>>> Macintosh powerpc >>>>> >>>>> ... >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 -------------- --- building in PPC_DARWIN --- ignoring ../src/m3overrides cd . && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: configure-host | tee -a _m3.log cd . && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: configure-host | tee -a _m3.log make all-recursive Making all in tests Making all in . make[4]: Nothing to be done for `all-am'. Making all in devel make[4]: Nothing to be done for `all'. Making all in mpn make[4]: Nothing to be done for `all'. Making all in mpz make[4]: Nothing to be done for `all'. Making all in mpq make[4]: Nothing to be done for `all'. Making all in mpf make[4]: Nothing to be done for `all'. Making all in rand make[4]: Nothing to be done for `all'. Making all in misc make[4]: Nothing to be done for `all'. Making all in cxx make[4]: Nothing to be done for `all'. Making all in mpbsd make[4]: Nothing to be done for `all'. Making all in mpn make[3]: Nothing to be done for `all'. Making all in mpz make[3]: Nothing to be done for `all'. Making all in mpq make[3]: Nothing to be done for `all'. Making all in mpf make[3]: Nothing to be done for `all'. Making all in printf make[3]: Nothing to be done for `all'. Making all in scanf make[3]: Nothing to be done for `all'. Making all in cxx make[3]: Nothing to be done for `all'. Making all in mpbsd make[3]: Nothing to be done for `all'. Making all in demos Making all in calc make all-am make[5]: Nothing to be done for `all-am'. Making all in expr make[4]: Nothing to be done for `all'. make[4]: Nothing to be done for `all-am'. Making all in tune make[3]: Nothing to be done for `all'. Making all in doc make[3]: Nothing to be done for `all'. make[3]: Nothing to be done for `all-am'. sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./gcc/Makefile > ./gcc/Makefile.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./gcc/Makefile > ./gcc/Makefile.1 ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./gcc/Makefile > ./gcc/Makefile.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./gcc/Makefile > ./gcc/Makefile.1 ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile sed -e 's/^#define HAVE_ICONV 1$//' < ./gcc/Makefile > ./gcc/Makefile.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./gcc/Makefile > ./gcc/Makefile.1 ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile sed -e 's/^#define HAVE_ICONV_H 1$//' < ./gcc/Makefile > ./gcc/Makefile.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./gcc/Makefile > ./gcc/Makefile.1 ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h sed -e 's/^#define HAVE_ICONV 1$//' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h sed -e 's/^#define HAVE_ICONV_H 1$//' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./libcpp/Makefile > ./libcpp/Makefile.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./libcpp/Makefile > ./libcpp/Makefile.1 ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./libcpp/Makefile > ./libcpp/Makefile.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./libcpp/Makefile > ./libcpp/Makefile.1 ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile sed -e 's/^#define HAVE_ICONV 1$//' < ./libcpp/Makefile > ./libcpp/Makefile.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./libcpp/Makefile > ./libcpp/Makefile.1 ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile sed -e 's/^#define HAVE_ICONV_H 1$//' < ./libcpp/Makefile > ./libcpp/Makefile.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./libcpp/Makefile > ./libcpp/Makefile.1 ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./libcpp/config.h > ./libcpp/config.h.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./libcpp/config.h > ./libcpp/config.h.1 ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./libcpp/config.h > ./libcpp/config.h.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./libcpp/config.h > ./libcpp/config.h.1 ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h sed -e 's/^#define HAVE_ICONV 1$//' < ./libcpp/config.h > ./libcpp/config.h.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./libcpp/config.h > ./libcpp/config.h.1 ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h sed -e 's/^#define HAVE_ICONV_H 1$//' < ./libcpp/config.h > ./libcpp/config.h.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./libcpp/config.h > ./libcpp/config.h.1 ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./mpfr/Makefile > ./mpfr/Makefile.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./mpfr/Makefile > ./mpfr/Makefile.1 ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./mpfr/Makefile > ./mpfr/Makefile.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./mpfr/Makefile > ./mpfr/Makefile.1 ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile sed -e 's/^#define HAVE_ICONV 1$//' < ./mpfr/Makefile > ./mpfr/Makefile.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./mpfr/Makefile > ./mpfr/Makefile.1 ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile sed -e 's/^#define HAVE_ICONV_H 1$//' < ./mpfr/Makefile > ./mpfr/Makefile.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./mpfr/Makefile > ./mpfr/Makefile.1 ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile sed -e 's/^#define HAVE_ICONV 1$//' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile sed -e 's/^#define HAVE_ICONV_H 1$//' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile cd . && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: all-gmp all-mpfr all-build-libiberty all-libiberty all-libdecnumber | tee -a _m3.log cd . && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: all-gmp all-mpfr all-build-libiberty all-libiberty all-libdecnumber | tee -a _m3.log make all-recursive Making all in tests Making all in . make[4]: Nothing to be done for `all-am'. Making all in devel make[4]: Nothing to be done for `all'. Making all in mpn make[4]: Nothing to be done for `all'. Making all in mpz make[4]: Nothing to be done for `all'. Making all in mpq make[4]: Nothing to be done for `all'. Making all in mpf make[4]: Nothing to be done for `all'. Making all in rand make[4]: Nothing to be done for `all'. Making all in misc make[4]: Nothing to be done for `all'. Making all in cxx make[4]: Nothing to be done for `all'. Making all in mpbsd make[4]: Nothing to be done for `all'. Making all in mpn make[3]: Nothing to be done for `all'. Making all in mpz make[3]: Nothing to be done for `all'. Making all in mpq make[3]: Nothing to be done for `all'. Making all in mpf make[3]: Nothing to be done for `all'. Making all in printf make[3]: Nothing to be done for `all'. Making all in scanf make[3]: Nothing to be done for `all'. Making all in cxx make[3]: Nothing to be done for `all'. Making all in mpbsd make[3]: Nothing to be done for `all'. Making all in demos Making all in calc make all-am make[5]: Nothing to be done for `all-am'. Making all in expr make[4]: Nothing to be done for `all'. make[4]: Nothing to be done for `all-am'. Making all in tune make[3]: Nothing to be done for `all'. Making all in doc make[3]: Nothing to be done for `all'. make[3]: Nothing to be done for `all-am'. Making all in tests make[2]: Nothing to be done for `all'. make[2]: Nothing to be done for `all-am'. make[2]: Nothing to be done for `all'. make[2]: Nothing to be done for `all'. make[1]: Nothing to be done for `all'. cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a _m3.log cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a _m3.log Makefile:191: *** Insufficient number of arguments (2) to function `patsubst'. Stop. cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a _m3.log cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a _m3.log Makefile:4437: *** Insufficient number of arguments (2) to function `patsubst'. Stop. "/Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile", line 463: quake runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2 --procedure-- -line- -file--- cp_if -- postcp 463 /Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile include_dir 529 /Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile 4 /Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args Fatal Error: package build failed From wagner at elegosoft.com Mon Apr 13 13:12:00 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 13 Apr 2009 13:12:00 +0200 Subject: [M3devel] cvsup and "flags" In-Reply-To: References: <20090413125640.58q2uf7spw0w844o@mail.elegosoft.com> Message-ID: <20090413131200.aai00p9vk44cgc00@mail.elegosoft.com> Well, yes, that's all correct, but CVSup is not only a CVS mirroring tool, as its name suggest, but also a general efficient file replication tool (which can be used to replicate whole systems). We should try to keep all of its functionality (improvements possible, of course). Olaf Quoting Jay : > > It's a little different to say "these flags are useful" vs. > "I should be able to store these flags in source control". > Not entirely different, but somewhat. > > > If you need them in source control, then you need your source control > system to bother with system-dependent possibly esoteric features. > On the other hand, if nobody every catered to good system-dependent > aspects, a lot of things would be a lot worse. > > > I only skimmed the cvsup source a little, but I think it traffics > in plain integers. It would be smarter to traffic in the "name" > of the flag, and the "OS name" it originated from..and maybe allow > some "required" vs. "optional" bit. That way, if Darwin and FreeBSD > both had the flag "FOO", it hopefully/probably means the same on each, > but could be "translated" into the proper integer. And if user deemed > flag "FOO" important than cvsup could error for updates to a system > that doesn't support it. Maybe it already does do these things though. > > > Some people use "source control" for keep track of and backup > their "system configuration" or perhaps their entire "system install". > Whereas most people just store a bunch of text files. > There can be quite a difference -- e.g. support for hardlinks, symlinks, > owner user, owner group, etc.. > > > Folks just storing textual source files tend to have lighter requirements. > (which reminds me -- can you clear the executable bit on the vast > majority of non-directories in the tree, like outside of > scripts/*.sh and scripts/*.py) > > > - Jay > > > ---------------------------------------- >> Date: Mon, 13 Apr 2009 12:56:40 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] cvsup and "flags" >> >> Quoting Jay : >> >>> >>> Um, these "flags" that cvsup is willing to traffic: >>> >>> 1) They are the same between machines that support them? >>> Maybe, maybe not, I can check. >>> >>> 2) They are actually interesting? Given that many operating >>> systems (e.g. Linux, Solaris) don't support them? >> >> Yes, they are interesting and important, since they are in use >> at many sites. They're not portable as far as I know though. >> >> The system immutable flag is used by many FreeBSD installations to >> further protect from accidental and unauthorized changes. >> >>> They seem a little dubious. >>> I suppose most cvsup users have both client and server on FreeBSD >>> and if the FreeBSD source itself needs these flags on source >>> controled files, it is useful. >>> >>> Even storing an executable bit in cvs seems not portable..but that >>> is a different set of flags. (NTFS ACL should be reasonable >>> superset, but then, FAT?) >> >> POSIX file access control lists should be portable to a certain degree. >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Mon Apr 13 13:34:13 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 13 Apr 2009 13:34:13 +0200 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> Message-ID: <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> Well, that's a quite long list; but many things are bug fixes anyway, and wouldn't be affected by a code freeze, while others are already finished (as integrating CVSup, as I understand). The only thing we should not do is introduce new platforms while trying to get the system stable. We should concentrate on installation support and bug fixing. I'd suggest to start the release process in about two weeks at the start of May. That should give everybody enough time to either finish their ongoing work that shall make it into the release or decide to postpone it ;-) Any objections? Olaf Quoting Jay : > > > > o When should we start? I.e. wha changes would you like to complete > > > before we start the release process? > > > > > I'd like to see the formsvbt crash debugged and fixed, unless I'm > the only one seeing it. > > I only see it on Solaris and PPC_DARWIN but haven't tried "everything". > > I'll try to get this. > > > > > > I'd also like to see: > > > > > > FreeBSD/x86 switched to the new Unix/*.i3 files. I'll do this. > > Maybe also I386_DARWIN, AMD64_DARWIN, but I don't have the hardware. > > > > > > $ORIGIN/LD_LIBRARY_PATH resolved a bit further, probably very > little work (I'll do this). > > Basically just 1) put buildlocal back how it was 2) push it across > more platforms e.g. I think FreeBSD/x86 is the main one missing, > but I'll get to it. > > > > > > cvsup building and in "std" (I'll do this, probably very little > left here really. > > > > > > -- beyond this, not required for release -- > > > > > > Maybe more AMD64 releases, e.g. NetBSD and Solaris. (If I get to it). > > (could be "mingw64" is good enough to try AMD64_NT now). > > > > > > Maybe update gmp/mpfr to fix the "maintainer" problem. (not likely by me) > > > > > > Maybe more new/resuscitated platforms..HPPA64_HPUX, IA64_*, *_VMS, > ALPHA_*, ARM_*, *_IRIX, *_AIX, MIPS64_*.... but these take back > seat to important fixes in existing platforms. > > > > > > Fix NT386 to use setjmp3 instead of setjmp so exceptions don't > skip C __finally blocks. I've just been very lazy here, should > demonstrate the behavior with a test case, then fix it.. > > > > > > Maybe fix cm3cg so other -g options besides -gstabs works, like > plain -g, -ggdb, on at least one platform -gstabs isn't supported, > leaving nothing, because others cause internal compiler errors, like > on HPPA64_HPUX. > > > > > > Oh, and NT386GNU probably switched back to Win32 threads. > Otherwise one of the test cases hangs and it doesn't look easy to > figure out. I'll do this shortly if I remember. > > But I also wouldn't mind if this platform isn't officially released > either (unless someone else wants to support it). > > > > > > Debug why many NT386MINGNU gui apps crash..but also probably just > don't release this platform and ok asis. > > > > > > - 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 hendrik at topoi.pooq.com Mon Apr 13 17:08:54 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 13 Apr 2009 11:08:54 -0400 Subject: [M3devel] FW: cvsup In-Reply-To: References: Message-ID: <20090413150854.GA32577@topoi.pooq.com> On Sun, Apr 12, 2009 at 11:34:49AM +0000, Jay wrote: > > [truncated again..] > > cvsup builds and starts up on a few platforms now, > including Cygwin/x86, Linux/x86, Linux/AMD64 (birch), > Macosx/PowerPC, FreeBSD/x86. I can verify more later.. > > > I expect there might be problems on Macosx/x86 and AMD64. > And FreeBSD/x86 might not work until I commit the change to use Unix/common. > That is -- these are the only platforms not using Unix/common. > > > Some platforms store extra "flags" with files -- Darwin and *BSD. > see man chflags and man 2 chflags. > Historically cvsup only get/sets those on FreeBSD. > I extended that to the others, though didn't build NetBSD/OpenBSD. > (nor have I tested any of the functionality at all..) > The source should be refactored some in this regard, the "FreeBSD" > directory split into "FreeBSD" and "flags" or something. But > I don't like moving files since history might not track well. > (I also chose "m3-tools" arbitrarily..) > > > It might not even have to be refactored -- instead of the static platform checks, the code can check of the #defines in Ustat are zero or not, and UstatC.c can provide empty chflags/fchflags functions instead of none at all. It's a tricky area though in terms of what is best, providing no functions, vs. providing functions that do nothing and succeed, vs. providing functions that do nothing and fail, vs. providing a more explicit way to query if the functionality is provided, as well as deciding between build-time vs. run-time checks (we don't have anything like autoconf in our system, for better and worse). > > > Now hopefully we can switch to svn or monotone and cvsup won't matter to us. :) > (Well, I never use it in any case. I know it is big in FreeBSD-land.) Yes, monotone... I'm trying to organise putting together the monotone repository, and it seems that the first thing to do is to get a local copy of the existing modula 3 CVS repository to experiment on. There are at least two ways to go about putting the monotone repository together, on of them seems to requre me to have a local copy of the repository. I suspect I need to get cvsup running to make this local copy of the CVS. Where should I get cvsup? (It doesn't seem to be distributed as a Debian package; perhaps that's because Modula 3 ins't either?) Did you make changes to cvsup to get it to work on current versions of Modula 3? If so I should probably get the changed version. Or else maybe someone could make a .tgz file out of the entire cm3 CVS and I could download and work with that? -- hendrik From hendrik at topoi.pooq.com Mon Apr 13 21:20:06 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 13 Apr 2009 15:20:06 -0400 Subject: [M3devel] FW: cvsup In-Reply-To: <20090413150854.GA32577@topoi.pooq.com> References: <20090413150854.GA32577@topoi.pooq.com> Message-ID: <20090413192006.GA660@topoi.pooq.com> On Mon, Apr 13, 2009 at 11:08:54AM -0400, hendrik at topoi.pooq.com wrote: > On Sun, Apr 12, 2009 at 11:34:49AM +0000, Jay wrote: > > > > Now hopefully we can switch to svn or monotone and cvsup won't matter to us. :) > > (Well, I never use it in any case. I know it is big in FreeBSD-land.) > > Yes, monotone... I'm trying to organise putting together the monotone > repository, and it seems that the first thing to do is to get a local > copy of the existing modula 3 CVS repository to experiment on. There > are at least two ways to go about putting the monotone repository > together, on of them seems to requre me to have a local copy of the > repository. > > I suspect I need to get cvsup running to make this local copy of the > CVS. Where should I get cvsup? (It doesn't seem to be distributed as a > Debian package; perhaps that's because Modula 3 ins't either?) Did you > make changes to cvsup to get it to work on current versions of Modula 3? > If so I should probably get the changed version. I should definitely get the changed version, to avoid wasting time. I just tried downloading and installing cvsup-snap-16.1h.tar.gz on an x86 Debian system. It seems to run into trouble because it duplicates code in cm3 itself: hendrik at lovesong:~/dv/cvsup/cvsup-snap-16.1h$ make make[1]: Entering directory `/farhome/hendrik/dv/cvsup/cvsup-snap-16.1h' --- building in LINUXLIBC6 --- ===> suptcp make[2]: Entering directory `/farhome/hendrik/dv/cvsup/cvsup-snap-16.1h/suptcp' cm3 --- building in LINUXLIBC6 --- Fatal Error: duplicate unit: /usr/local/cm3/pkg/tcp/src/POSIX/SockOpt.i3 ../src/POSIX/SockOpt.i3 -- hendrik > > Or else maybe someone could make a .tgz file out of the entire cm3 CVS > and I could download and work with that? > > -- hendrik From wagner at elegosoft.com Mon Apr 13 21:58:44 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 13 Apr 2009 21:58:44 +0200 Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN In-Reply-To: <20090413130720.aziv5e0fggwgccw0@mail.elegosoft.com> References: <20090411105512.92784fp7cc0o448k@mail.elegosoft.com> <20090413125148.vxbxs7ftessckwko@mail.elegosoft.com> <20090413130720.aziv5e0fggwgccw0@mail.elegosoft.com> Message-ID: <20090413215844.i3cr5vkecks48004@mail.elegosoft.com> FYI: installing the latest version of GNU make and autoconf manually fixed the problem. m3cc builds after realclean and works perfectly. Olaf Quoting Olaf Wagner : > Quoting Jay : > >> >>> I got syntax errors with >>> some pattern substitution in a Makefile, and the build stopped. >> >> make vs. gmake? > > Maybe (log attached). But shouldn't configure be able to figure this > out by itself? GNU make is /usr/bin/gnumake on this system (Fink > packages). > > Olaf > >> - Jay >> >> >> >> ---------------------------------------- >>> Date: Mon, 13 Apr 2009 12:51:48 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN >>> >>> Quoting Jay : >>> >>>> >>>> My machine calls itself: >>>> >>>> jbook15:~ jay$ uname -a >>>> Darwin jbook15.local 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 >>>> 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh >>>> powerpc >>>> >>>> That is 10.4.something. It works ok. cm3cg built as recently as 4/10.. >>> >>> So it seems OK for newer MacOS X releases. I worked around it here by >>> continuning to use an older backend, which seems OK for now. >>> Doing a realclean and a complete rebuild, I got syntax errors with >>> some pattern substitution in a Makefile, and the build stopped. >>> >>> I'll try a newer backend compiled on another machine, too. >>> >>> Olaf >>> >>>> - Jay >>>> >>>> >>>> ________________________________ >>>>> From: jay >>>>> To: wagner; m3devel >>>>> Subject: RE: [M3devel] Internal compiler errors after upgrade on >>>>> PPC_DARWIN >>>>> Date: Sat, 11 Apr 2009 12:03:39 +0000> >>>>> >>>>> I do test on 10.4 fairly often... >>>> >>>>> It sounds like 7.9.0 is 10.3? >>>>> >>>>> >>>>> - Jay >>>>> >>>>>> Date: Sat, 11 Apr 2009 10:55:12 +0200 >>>>>> From: wagner@ >>>>>> To: m3devel@ >>>>>> Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN >>>>>> >>>>>> After trying to upgrade cm3 on my notebook to the latest version, >>>>>> I get lots of internal compiler errors.This is on >>>>>> >>>>>> % uname -a >>>>>> Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 >>>>>> 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power >>>>>> Macintosh powerpc >>>>>> >>>>>> ... >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 rodney.m.bates at cox.net Mon Apr 13 23:24:06 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 13 Apr 2009 16:24:06 -0500 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> Message-ID: <49E3AD76.1080108@cox.net> Any opinions about the TEXT branch? Anybody tried it? To summarize: - I have tested it extensively on LINUXLIBC6, with a large random test program and two successive rebuilds of CM3. - It makes no changes in data structure, neither to static declarations nor to invariants. Thus it creates no compatibility problems with existing pickles, etc. - It slows down concatenation, but more than makes it up in other string accessing operations, if the numbers of concatenations and accessing operations are equal. - It cuts down on tree depth and even more or recursion depth (which implies needed stack space.) - This effect is dramatic when strings are built by "linear" concatenations, i.e., strictly left-to-right, or vice versa. Gains are moderate when concatenations are random. - It allocates a lot more storage, but abandons a lot more garbage, retaining somewhat more space when lots of old strings are retained along with newly-built ones. It probably retains less when operand strings of concatenations are not kept, but I haven't measured that. - Strategies are partial rebalancing of concatenation trees, flattening of short concatenations, elimination of a lot of tail-recursion, and recursing on the shorter side. Olaf Wagner wrote: > Well, that's a quite long list; but many things are bug fixes anyway, > and wouldn't be affected by a code freeze, while others are already > finished (as integrating CVSup, as I understand). > > The only thing we should not do is introduce new platforms while > trying to get the system stable. We should concentrate on installation > support and bug fixing. > > I'd suggest to start the release process in about two weeks at the > start of May. That should give everybody enough time to either finish > their ongoing work that shall make it into the release or decide to > postpone it ;-) > > Any objections? > > Olaf > > Quoting Jay : > >> >> > > o When should we start? I.e. wha changes would you like to complete >> > > before we start the release process? >> >> >> >> >> I'd like to see the formsvbt crash debugged and fixed, unless I'm >> the only one seeing it. >> >> I only see it on Solaris and PPC_DARWIN but haven't tried "everything". >> >> I'll try to get this. >> >> >> >> >> >> I'd also like to see: >> >> >> >> >> >> FreeBSD/x86 switched to the new Unix/*.i3 files. I'll do this. >> >> Maybe also I386_DARWIN, AMD64_DARWIN, but I don't have the hardware. >> >> >> >> >> >> $ORIGIN/LD_LIBRARY_PATH resolved a bit further, probably very >> little work (I'll do this). >> >> Basically just 1) put buildlocal back how it was 2) push it across >> more platforms e.g. I think FreeBSD/x86 is the main one missing, >> but I'll get to it. >> >> >> >> >> >> cvsup building and in "std" (I'll do this, probably very little >> left here really. >> >> >> >> >> >> -- beyond this, not required for release -- >> >> >> >> >> >> Maybe more AMD64 releases, e.g. NetBSD and Solaris. (If I get to it). >> >> (could be "mingw64" is good enough to try AMD64_NT now). >> >> >> >> >> >> Maybe update gmp/mpfr to fix the "maintainer" problem. (not likely >> by me) >> >> >> >> >> >> Maybe more new/resuscitated platforms..HPPA64_HPUX, IA64_*, *_VMS, >> ALPHA_*, ARM_*, *_IRIX, *_AIX, MIPS64_*.... but these take back >> seat to important fixes in existing platforms. >> >> >> >> >> >> Fix NT386 to use setjmp3 instead of setjmp so exceptions don't >> skip C __finally blocks. I've just been very lazy here, should >> demonstrate the behavior with a test case, then fix it.. >> >> >> >> >> >> Maybe fix cm3cg so other -g options besides -gstabs works, like >> plain -g, -ggdb, on at least one platform -gstabs isn't supported, >> leaving nothing, because others cause internal compiler errors, like >> on HPPA64_HPUX. >> >> >> >> >> >> Oh, and NT386GNU probably switched back to Win32 threads. >> Otherwise one of the test cases hangs and it doesn't look easy to >> figure out. I'll do this shortly if I remember. >> >> But I also wouldn't mind if this platform isn't officially released >> either (unless someone else wants to support it). >> >> >> >> >> >> Debug why many NT386MINGNU gui apps crash..but also probably just >> don't release this platform and ok asis. >> >> >> >> >> >> - Jay >> > > > From rcoleburn at scires.com Mon Apr 13 23:51:21 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 13 Apr 2009 17:51:21 -0400 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <49E3AD76.1080108@cox.net> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> Message-ID: <49E37ADC.1E75.00D7.1@scires.com> Rodney, sorry but I haven't tried your changes. If your test program is available, I would be glad to compile and run it on Windows to obtain results for that platform. Just let me know how to obtain/install your TEXT changes and the test program. I am ok with Olaf's suggestion of starting the release process in May. Again, I will be glad to help on Windows platforms. If necessary, I can also test cygwin on Windows. If we need to test/build/release on HPUX, I have an old v10 system I can pull out of storage (note that v10 is an older version of HPUX and not current). Regards, Randy Coleburn >>> "Rodney M. Bates" 4/13/2009 5:24 PM >>> Any opinions about the TEXT branch? Anybody tried it? To summarize: - I have tested it extensively on LINUXLIBC6, with a large random test program and two successive rebuilds of CM3. - It makes no changes in data structure, neither to static declarations nor to invariants. Thus it creates no compatibility problems with existing pickles, etc. - It slows down concatenation, but more than makes it up in other string accessing operations, if the numbers of concatenations and accessing operations are equal. - It cuts down on tree depth and even more or recursion depth (which implies needed stack space.) - This effect is dramatic when strings are built by "linear" concatenations, i.e., strictly left-to-right, or vice versa. Gains are moderate when concatenations are random. - It allocates a lot more storage, but abandons a lot more garbage, retaining somewhat more space when lots of old strings are retained along with newly-built ones. It probably retains less when operand strings of concatenations are not kept, but I haven't measured that. - Strategies are partial rebalancing of concatenation trees, flattening of short concatenations, elimination of a lot of tail-recursion, and recursing on the shorter side. Olaf Wagner wrote: > Well, that's a quite long list; but many things are bug fixes anyway, > and wouldn't be affected by a code freeze, while others are already > finished (as integrating CVSup, as I understand). > > The only thing we should not do is introduce new platforms while > trying to get the system stable. We should concentrate on installation > support and bug fixing. > > I'd suggest to start the release process in about two weeks at the > start of May. That should give everybody enough time to either finish > their ongoing work that shall make it into the release or decide to > postpone it ;-) > > Any objections? > > Olaf > > Quoting Jay : > >> >> > > o When should we start? I.e. wha changes would you like to complete >> > > before we start the release process? >> >> >> >> >> I'd like to see the formsvbt crash debugged and fixed, unless I'm >> the only one seeing it. >> >> I only see it on Solaris and PPC_DARWIN but haven't tried "everything". >> >> I'll try to get this. >> >> >> >> >> >> I'd also like to see: >> >> >> >> >> >> FreeBSD/x86 switched to the new Unix/*.i3 files. I'll do this. >> >> Maybe also I386_DARWIN, AMD64_DARWIN, but I don't have the hardware. >> >> >> >> >> >> $ORIGIN/LD_LIBRARY_PATH resolved a bit further, probably very >> little work (I'll do this). >> >> Basically just 1) put buildlocal back how it was 2) push it across >> more platforms e.g. I think FreeBSD/x86 is the main one missing, >> but I'll get to it. >> >> >> >> >> >> cvsup building and in "std" (I'll do this, probably very little >> left here really. >> >> >> >> >> >> -- beyond this, not required for release -- >> >> >> >> >> >> Maybe more AMD64 releases, e.g. NetBSD and Solaris. (If I get to it). >> >> (could be "mingw64" is good enough to try AMD64_NT now). >> >> >> >> >> >> Maybe update gmp/mpfr to fix the "maintainer" problem. (not likely >> by me) >> >> >> >> >> >> Maybe more new/resuscitated platforms..HPPA64_HPUX, IA64_*, *_VMS, >> ALPHA_*, ARM_*, *_IRIX, *_AIX, MIPS64_*.... but these take back >> seat to important fixes in existing platforms. >> >> >> >> >> >> Fix NT386 to use setjmp3 instead of setjmp so exceptions don't >> skip C __finally blocks. I've just been very lazy here, should >> demonstrate the behavior with a test case, then fix it.. >> >> >> >> >> >> Maybe fix cm3cg so other -g options besides -gstabs works, like >> plain -g, -ggdb, on at least one platform -gstabs isn't supported, >> leaving nothing, because others cause internal compiler errors, like >> on HPPA64_HPUX. >> >> >> >> >> >> Oh, and NT386GNU probably switched back to Win32 threads. >> Otherwise one of the test cases hangs and it doesn't look easy to >> figure out. I'll do this shortly if I remember. >> >> But I also wouldn't mind if this platform isn't officially released >> either (unless someone else wants to support it). >> >> >> >> >> >> Debug why many NT386MINGNU gui apps crash..but also probably just >> don't release this platform and ok asis. >> >> >> >> >> >> - 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 wagner at elegosoft.com Mon Apr 13 23:49:13 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 13 Apr 2009 23:49:13 +0200 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <49E3AD76.1080108@cox.net> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> Message-ID: <20090413234913.28trgcepwk488sc8@mail.elegosoft.com> Quoting "Rodney M. Bates" : > Any opinions about the TEXT branch? Anybody tried it? To summarize: > > - I have tested it extensively on LINUXLIBC6, with a large random > test program and two successive rebuilds of CM3. > > - It makes no changes in data structure, neither to static declarations > nor to invariants. Thus it creates no compatibility problems with existing > pickles, etc. > > - It slows down concatenation, but more than makes it up in other > string accessing operations, if the numbers of concatenations and > accessing operations are equal. > > - It cuts down on tree depth and even more or recursion depth > (which implies needed stack space.) > > - This effect is dramatic when strings are built by "linear" concatenations, > i.e., strictly left-to-right, or vice versa. Gains are moderate when > concatenations are random. > > - It allocates a lot more storage, but abandons a lot more garbage, > retaining somewhat more space when lots of old strings are retained > along with newly-built ones. It probably retains less when operand > strings of concatenations are not kept, but I haven't measured that. > > - Strategies are partial rebalancing of concatenation trees, flattening > of short concatenations, elimination of a lot of tail-recursion, and > recursing on the shorter side. I would tend to give it a try, i.e. include it in the release candiates, but I'd like to have some data about the impacts on real applications, let's say the cm3 compiler itself, the caltech parser generator, and cvsup. How do these perform for a small set of sample data? I won't have the time to do these tests though, so I'll trust the opinion of others regarding the inclusion in the next release. Olaf > Olaf Wagner wrote: >> Well, that's a quite long list; but many things are bug fixes anyway, >> and wouldn't be affected by a code freeze, while others are already >> finished (as integrating CVSup, as I understand). >> >> The only thing we should not do is introduce new platforms while >> trying to get the system stable. We should concentrate on installation >> support and bug fixing. >> >> I'd suggest to start the release process in about two weeks at the >> start of May. That should give everybody enough time to either finish >> their ongoing work that shall make it into the release or decide to >> postpone it ;-) >> >> Any objections? >> >> Olaf >> >> Quoting Jay : >> >>> >>> > > o When should we start? I.e. wha changes would you like to complete >>> > > before we start the release process? >>> >>> >>> >>> >>> I'd like to see the formsvbt crash debugged and fixed, unless I'm >>> the only one seeing it. >>> >>> I only see it on Solaris and PPC_DARWIN but haven't tried "everything". >>> >>> I'll try to get this. >>> >>> >>> >>> >>> >>> I'd also like to see: >>> >>> >>> >>> >>> >>> FreeBSD/x86 switched to the new Unix/*.i3 files. I'll do this. >>> >>> Maybe also I386_DARWIN, AMD64_DARWIN, but I don't have the hardware. >>> >>> >>> >>> >>> >>> $ORIGIN/LD_LIBRARY_PATH resolved a bit further, probably very >>> little work (I'll do this). >>> >>> Basically just 1) put buildlocal back how it was 2) push it >>> across more platforms e.g. I think FreeBSD/x86 is the main one >>> missing, but I'll get to it. >>> >>> >>> >>> >>> >>> cvsup building and in "std" (I'll do this, probably very little >>> left here really. >>> >>> >>> >>> >>> >>> -- beyond this, not required for release -- >>> >>> >>> >>> >>> >>> Maybe more AMD64 releases, e.g. NetBSD and Solaris. (If I get to it). >>> >>> (could be "mingw64" is good enough to try AMD64_NT now). >>> >>> >>> >>> >>> >>> Maybe update gmp/mpfr to fix the "maintainer" problem. (not likely by me) >>> >>> >>> >>> >>> >>> Maybe more new/resuscitated platforms..HPPA64_HPUX, IA64_*, >>> *_VMS, ALPHA_*, ARM_*, *_IRIX, *_AIX, MIPS64_*.... but these take >>> back seat to important fixes in existing platforms. >>> >>> >>> >>> >>> >>> Fix NT386 to use setjmp3 instead of setjmp so exceptions don't >>> skip C __finally blocks. I've just been very lazy here, should >>> demonstrate the behavior with a test case, then fix it.. >>> >>> >>> >>> >>> >>> Maybe fix cm3cg so other -g options besides -gstabs works, like >>> plain -g, -ggdb, on at least one platform -gstabs isn't supported, >>> leaving nothing, because others cause internal compiler errors, >>> like on HPPA64_HPUX. >>> >>> >>> >>> >>> >>> Oh, and NT386GNU probably switched back to Win32 threads. >>> Otherwise one of the test cases hangs and it doesn't look easy to >>> figure out. I'll do this shortly if I remember. >>> >>> But I also wouldn't mind if this platform isn't officially >>> released either (unless someone else wants to support it). >>> >>> >>> >>> >>> >>> Debug why many NT386MINGNU gui apps crash..but also probably just >>> don't release this platform and ok asis. >>> >>> >>> >>> >>> >>> - 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 Mon Apr 13 23:51:31 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 13 Apr 2009 16:51:31 -0500 Subject: [M3devel] small objects] Message-ID: <49E3B3E3.8090400@cox.net> Mika Nystrom wrote: > Ahhhh!!!!! Now I get it, Rodney! > > You're talking about using tagged types "within" Modula-3. > > I've just been asking for tagged types to do something "that's not > Modula-3". I'm completely aware that passing REFANY around is not > the "Modula-3 way", and had no intention of making it so. (That's > why I keep saying that only lazy people do it, so it doesn't matter.) > > My desire for storing integers and pointers in the same machine word > is not something I thought would ever be useful in Modula-3 itself. > But now what you say makes sense to me... you want to build your > ADTs with this. Then you do need the full M3 type system "above" > your tagged reference. > > I agree with you on MOST of the following: > > >> I really feel that the fad of all dynamic typing in languages is a huge >> mistake and that it will someday be recognized as such. In the >> meantime, we have a language that provides a very extensive set >> of statically-typed alternatives, while also allowing dynamic typing >> when you really need it. This is one of Modula-3's best principles. >> Let's don't erode the static alternatives unnecessarily. >> > > I program, currently, mostly in Scheme and in Modula-3, (mostly M3) > and I am constantly amazed by: > > 1. The way that Modula-3 programs often are correct the first time > they are compiled, even if they haven't been carefully designed. > Using the M3 type system can really make your code obviously correct. > > 2. The way that Scheme programs can sometimes abstract away all sorts > of type irrelevancies. In M3 you'd have to have many versions of the > same code, or at least many generic instances. This is especially > true for "higher-higher order" types, where one type is made from > another and that was made from another, etc. (Interpret "type" > liberally, please. It's probably just some sort of lambda expression.) > > Now I agree that untyped languages are probably a fad, and they have > set computing back by years or decades(?). Too easy to make mistakes. > But there is something of value there, and my feeling is that the best > way to take advantage of it is to *combine* the two worlds, rather than > trying to come up with some sort of "super language" that incorporates > the best of both worlds and somehow manages to step on no one's toes. > I'm presenting this as an alternative to type inferencing schemes in > environments such as ML. > > So my idea, my "vision" if you like, is that we embed untyped > languages in Modula-3. The parts of the system that need performance > or are more convenient to program in the "bondage and discipline" > world of Algol get written in Modula-3, and the parts of the system > that it is more convenient (all things considered) to program in a > typeless environment can be programmed in Scheme (currently, other > interpreted languages can be added later if this turns out to be a > good idea). But it is clear that the typeless approach of REFANY > (REALLYREFANY, including the tagged types) is necessary to implement > this layer of the system---if you want to be able to pass data > structures seamlessly between the two layers. > > Maybe that explains better where I'm coming from. I have no intention > of using these types for Modula-3 programming :-) > > However, I do see your point. A facility provided is a facility > used, so if there's a very compact way of storing data in pointers, > other applications than the ones I have in mind will use them, too, > and perhaps lead to an abuse of Modula-3. But I'm not sure if this > isn't over the line of legislating programming *style*---if we go > down that route, we can do it the Java way and ban UNSAFE as well, > so people won't be tempted to program C in Modula-3. In any case, > the particular feature that one can hide 31 bits of information in > a REFANY (and only a REFANY) can't hurt you if you don't choose to > avail yourself of it---in fact it's transparent to people who don't > care about it. Ok, an added 2 instructions out of 1,000 on an > ISTYPE or TYPECASE of r : REFANY, but come on, that's not really > an argument! > > So I am supportive of making a new type hierarchy TAGGED T for any > No, not a tagged hierarchy. That was an earlier idea I toyed with that I considered a tar pit. The reference types remain in the existing hierarchy, but the tagged types have no subtype relation to each other. > T. And yes I understand that now---once you have TAGGED T---it is > trivial to add a TAGGED REFANY, which you can distinguish from > REFANY. I think your arguments for the TAGGED hierarchy are very > good. > > However, I still don't think you have made a good argument *against* > being able to hide 31 bits of information in a REFANY. You don't > have to use the facility if it doesn't meet your requirements! > > Please remember that what I've been proposing is not a language > change at all but a request that the runtime system and compiler > respect a couple of not-difficult-to-ensure properties, so that we > may do some new tricks in UNSAFE code. Nothing more than that. > > Mika > > P.S. You didn't actually give any examples of code where you > would, after *your* proposed change, still use REFANY instead of > switching the code to TAGGED REFANY. I brought up container data structures as one important group, but they are not the universe of uses of REFANY. As an example, I have a good sized module that builds a tree--not a general tree determined by input, but exactly one, hard-coded specific tree. It's needed to boostrap the general tree-building code. The tree is rather large, and hard coding all the node constructor calls was very tedious and boring. I wrote some node constructor procedures with the intent of minimizing the keystrokes in the calls on them. One way I did this was to make the child parameters have type REFANY, with meaningful values being either TEXT or previously-built tree nodes of a few possible different types. The constructors then TYPECASE on them. REFANY is the narrowest possible type that can take this set of options. This has nothing to do with any abstract data type and is not intended for any general-purpose use by various other code. In fact, it has a very specific and limited purpose. > You said that: > > >> And TAGGED REFANY generalizes it from REFANY. >> > > i.e., container code would switch to TAGGED REFANY > > >> The other use is for the abstract type itself. Forgetting tagged >> types for a moment, I have never seen an interface/module that >> uses REFANY for this. Instead, the modules declare their abstract >> type as some proper subtype of REFANY, usually an opaque type. >> > > i.e., other code doesn't actually use REFANY! > > (For what it's worth, your experience here matches mine. Container > types (may) use REFANY and ADTs (almost) never do.) > > So back to my question: where would you use REFANY???? If never, > then why bother having the two roots? > > What you're saying is that after *my* proposed runtime change, *you* > will be tempted to abuse REFANY for ADTs. I don't think this is a > very good argument against my proposal (but it is a good argument > for yours, which is not incompatible with mine but instead expands it). > The only thing that makes your proposal slightly incompatible with > mine is that you're insisting on having a new distinction between > REFANY and TAGGED REFANY, which I am saying will never be used in > practice. And both your experience with Modula-3 and mine seem to > back up this assertion. > > > "Rodney M. Bates" writes: > >> Mika Nystrom wrote: >> >>> Sorry to splice together two emails from you, but I feel I've already >>> used up my m3devel quota this week: >>> >>> "Rodney M. Bates" writes: >>> >>> >>>>> Are you sure? I want a type---some type---that can hold "any >>>>> reference, even a tagged one", and I would rewrite most library >>>>> code that today takes REFANY to take that instead. Why not? Why >>>>> would I want to limit it to REFANY when it performs no operations >>>>> that couldn't legally be performed on TAGGED REFANY. >>>>> >>>>> >>>>> >>>> I believe my "safe" proposal would make this very simple, if I am >>>> thinking of the kind of library code you are. >>>> >>>> I envision a container data structure that takes in things and returns >>>> them without performing operations on them other than moving them around >>>> and storing them, e.g. the ever belabored stack. The values going in >>>> and out are declared REFANY, and the client passes in values of >>>> some proper subtype of REFANY, which get assigned to the REFANY >>>> parameters. When it gets them back, it narrows them to this type. >>>> >>>> In this pattern, just changing the declared type of the container values >>>> >>>> >>> >from REFANY to TAGGED REFANY would do it. The library code's storage >>> ... >>> >>> >> There are two very different kinds of uses of reference and >> tagged types. The one I speak of above is for the type of the >> elements inside a container data structure. In this case, it >> is the client that knows what type the value really is, and will >> declare it as such. The library ADT module should know as little >> as possible about it, so it will declare it as REFANY or >> TAGGED REFANY. Here, you want the most general type >> possible, just to make the abstraction more versatile. >> And TAGGED REFANY generalizes it from REFANY. >> >> But... >> >>> >>> >> >>>>> you'd like to store these in a REFANY and dynamically test for the >>>>> appropriate tagged type: >>>>> >>>>> >>>> No, I do not want to store these in a variable of type REFANY or any >>>> other existing type. >>>> In fact, I want to forbid it. >>>> >>>> >>> I think you are thinking of exactly the same kind of library code. >>> TextRefTbl.T, RefList.T, etc. >>> >>> After the introduction of TAGGED REFANY, what use is there for >>> REFANY? What piece of code can you think of where the cost of the >>> 1-LSB check of TAGGED REFANY outweighs the convenience of being >>> able to process objects of type TAGGED T (for all ref types T) as >>> well as objects of type T? >>> >>> >> The other use is for the abstract type itself. Forgetting tagged >> types for a moment, I have never seen an interface/module that >> uses REFANY for this. Instead, the modules declare their abstract >> type as some proper subtype of REFANY, usually an opaque type. >> >> It would be possible to use just REFANY here of course, but that would >> require an otherwise unnecessary RT check on the allocated type, >> every time an operation of the module is called. This is a much >> more expensive check than a tag check, as has been pointed out >> in this discussion. >> >> But worse, it would sacrifice the static checking that we now have >> that prevents, at compile time, clients from passing, say a Text.T >> to some procedure in Atom that expects an Atom.T. If these modules >> ever wanted to use a tagged type, but the only tagged type were >> REFANY, we would lose this static checking, because Text.T would >> have to become equal to Atom.T. >> >> In cases where your algorithms don't specifically need dynamic >> typing, static typing is always much better, because one run of >> the compiler on the source code will do it. Bugs checked >> only at runtime require a massive test suit to be coded and then >> regularly rerun to get even close to the same confidence they've >> been found. >> >> So when using tagged types as the ADT itself,, we need to be able >> to have a tagged version of whatever proper subtype of REFANY >> the abstraction needs, including an opaque subtype of REFANY >> or an opaque subtype of some Public subtype of REFANY. This is >> why I am adamant that we need to be able to build a tagged type >> > >from any traced or object type. > >> And once you do this, keeping REFANY itself unchanged and allowing >> TAGGED REFANY as one case of a tagged type falls out of the system >> for free _and_ saves a lot of cases that would otherwise need a new RT >> check that can never fail, but the language can't know that, because >> the type system has lost the distinction. >> >> I really feel that the fad of all dynamic typing in languages is a huge >> mistake and that it will someday be recognized as such. In the >> meantime, we have a language that provides a very extensive set >> of statically-typed alternatives, while also allowing dynamic typing >> when you really need it. This is one of Modula-3's best principles. >> Let's don't erode the static alternatives unnecessarily. >> >> >>> Mika >>> >>> >>> > > From jay.krell at cornell.edu Tue Apr 14 02:37:42 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 14 Apr 2009 00:37:42 +0000 Subject: [M3devel] FW: cvsup In-Reply-To: <20090413192006.GA660@topoi.pooq.com> References: <20090413150854.GA32577@topoi.pooq.com> <20090413192006.GA660@topoi.pooq.com> Message-ID: I think you can ssh into birch and tar cfz /usr/cvs/cm3 or such. If you want/need cvsup, yes please try current cm3 source. It at least builds and the changes weren't really significant. Yes they had their own copy of TCP. Olaf's does too, but his used "override" to avoid the duplicate. I just don't use the duplicate. It looks like the mainline and cvsup were mostly in sync, though mainline has 64bit big endian bug fixes ("one is int not INTEGER"). I should double check that though. I think there is a bit of a language problem in Modula3. I can have: INTERFACE A; PROCEDURE F; INTERFACE B; PROCEDURE F; and IMPORT both A and B from a third module, since I can refer to A.F and B.F, but I cannot IMPORT A from B's implementation or vice versa. The implementation of F is ambiguous. A possible solution is to let the implementation put the interface name ahead of the function. MODULE B IMPORTS A; PROCEDURE B.F() = BEGIN END B.F; and all uses of F within B must say B.F or A.F. - Jay ---------------------------------------- > Date: Mon, 13 Apr 2009 15:20:06 -0400 > From: hendrik > To: m3devel > Subject: Re: [M3devel] FW: cvsup > From rodney.m.bates at cox.net Tue Apr 14 04:33:48 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 13 Apr 2009 21:33:48 -0500 Subject: [M3devel] FW: cvsup In-Reply-To: References: <20090413150854.GA32577@topoi.pooq.com> <20090413192006.GA660@topoi.pooq.com> Message-ID: <49E3F60C.3070808@cox.net> Jay wrote: > I think you can ssh into birch and tar cfz /usr/cvs/cm3 or such. > > > If you want/need cvsup, yes please try current cm3 source. > It at least builds and the changes weren't really significant. > Yes they had their own copy of TCP. > Olaf's does too, but his used "override" to avoid the duplicate. > I just don't use the duplicate. > It looks like the mainline and cvsup were mostly in sync, > though mainline has 64bit big endian bug fixes ("one is int not INTEGER"). > I should double check that though. > > > I think there is a bit of a language problem in Modula3. > I can have: > > > INTERFACE A; > PROCEDURE F; > > > INTERFACE B; > PROCEDURE F; > > > and IMPORT both A and B from a third module, since I can refer to A.F and B.F, > > but I cannot IMPORT A from B's implementation or vice versa. > The implementation of F is ambiguous. > Sure you can. > > > A possible solution is to let the implementation put the > interface name ahead of the function. > > MODULE B IMPORTS A; > In module B, you can refer to A.F. If you want the F in B, its name is just unqualified F. MODULE B is short for MODULE B EXPORTS B (see 2.5.3, 1st paragraph), and one consequence of exporting B is that everything declared in interface B is available without qualification in the module that does the export . See 2.5.3, 2nd paragraph. What you can't do is have the same module export both A and B. That would make F an illegal redeclaration. See 2.5.3, 4th paragraph. > > PROCEDURE B.F() = BEGIN END B.F; > > > and all uses of F within B must say B.F or A.F. > > > - Jay > > > ---------------------------------------- > >> Date: Mon, 13 Apr 2009 15:20:06 -0400 >> From: hendrik >> To: m3devel >> Subject: Re: [M3devel] FW: cvsup >> >> From hosking at cs.purdue.edu Tue Apr 14 05:43:45 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 14 Apr 2009 13:43:45 +1000 Subject: [M3devel] FW: cvsup In-Reply-To: References: <20090413150854.GA32577@topoi.pooq.com> <20090413192006.GA660@topoi.pooq.com> Message-ID: <7F0E7523-EC64-44C5-932B-48EA3F3B05A6@cs.purdue.edu> ssh + rsync! On 14 Apr 2009, at 10:37, Jay wrote: > > I think you can ssh into birch and tar cfz /usr/cvs/cm3 or such. > > > If you want/need cvsup, yes please try current cm3 source. > It at least builds and the changes weren't really significant. > Yes they had their own copy of TCP. > Olaf's does too, but his used "override" to avoid the duplicate. > I just don't use the duplicate. > It looks like the mainline and cvsup were mostly in sync, > though mainline has 64bit big endian bug fixes ("one is int not > INTEGER"). > I should double check that though. > > > I think there is a bit of a language problem in Modula3. > I can have: > > > INTERFACE A; > PROCEDURE F; > > > INTERFACE B; > PROCEDURE F; > > > and IMPORT both A and B from a third module, since I can refer to > A.F and B.F, > > but I cannot IMPORT A from B's implementation or vice versa. > The implementation of F is ambiguous. > > > A possible solution is to let the implementation put the > interface name ahead of the function. > > MODULE B IMPORTS A; > > PROCEDURE B.F() = BEGIN END B.F; > > > and all uses of F within B must say B.F or A.F. > > > - Jay > > > ---------------------------------------- >> Date: Mon, 13 Apr 2009 15:20:06 -0400 >> From: hendrik >> To: m3devel >> Subject: Re: [M3devel] FW: cvsup >> From wagner at elegosoft.com Tue Apr 14 12:02:17 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 14 Apr 2009 12:02:17 +0200 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <49E37ADC.1E75.00D7.1@scires.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> <49E37ADC.1E75.00D7.1@scires.com> Message-ID: <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> If anybody could test Rodney's TEXT changes and provide some information on the impacts on our applications, that would help a lot. I also wasn't able to read and understand all the mails about small objects. (Guessing, I'd say I'd need another day for that :-) Can anybody summarize? Has a conclusion been reached and what will be done/implemented? Is this relevant for the next release, or will it take longer? Olaf Quoting Randy Coleburn : > Rodney, sorry but I haven't tried your changes. If your test > program is available, I would be glad to compile and run it on > Windows to obtain results for that platform. Just let me know how > to obtain/install your TEXT changes and the test program. > > I am ok with Olaf's suggestion of starting the release process in May. > > Again, I will be glad to help on Windows platforms. If necessary, I > can also test cygwin on Windows. > > If we need to test/build/release on HPUX, I have an old v10 system I > can pull out of storage (note that v10 is an older version of HPUX > and not current). > > Regards, > Randy Coleburn > >>>> "Rodney M. Bates" 4/13/2009 5:24 PM >>> > Any opinions about the TEXT branch? Anybody tried it? To summarize: > > - I have tested it extensively on LINUXLIBC6, with a large random > test program and two successive rebuilds of CM3. > > - It makes no changes in data structure, neither to static declarations > nor to invariants. Thus it creates no compatibility problems with > existing > pickles, etc. > > - It slows down concatenation, but more than makes it up in other > string accessing operations, if the numbers of concatenations and > accessing operations are equal. > > - It cuts down on tree depth and even more or recursion depth > (which implies needed stack space.) > > - This effect is dramatic when strings are built by "linear" concatenations, > i.e., strictly left-to-right, or vice versa. Gains are moderate when > concatenations are random. > > - It allocates a lot more storage, but abandons a lot more garbage, > retaining somewhat more space when lots of old strings are retained > along with newly-built ones. It probably retains less when operand > strings of concatenations are not kept, but I haven't measured that. > > - Strategies are partial rebalancing of concatenation trees, flattening > of short concatenations, elimination of a lot of tail-recursion, and > recursing on the shorter side. > > > > Olaf Wagner wrote: >> Well, that's a quite long list; but many things are bug fixes anyway, >> and wouldn't be affected by a code freeze, while others are already >> finished (as integrating CVSup, as I understand). >> >> The only thing we should not do is introduce new platforms while >> trying to get the system stable. We should concentrate on installation >> support and bug fixing. >> >> I'd suggest to start the release process in about two weeks at the >> start of May. That should give everybody enough time to either finish >> their ongoing work that shall make it into the release or decide to >> postpone it ;-) >> >> Any objections? >> >> Olaf >> >> Quoting Jay : >> >>> >>> > > o When should we start? I.e. wha changes would you like to complete >>> > > before we start the release process? >>> >>> >>> >>> >>> I'd like to see the formsvbt crash debugged and fixed, unless I'm >>> the only one seeing it. >>> >>> I only see it on Solaris and PPC_DARWIN but haven't tried "everything". >>> >>> I'll try to get this. >>> >>> >>> >>> >>> >>> I'd also like to see: >>> >>> >>> >>> >>> >>> FreeBSD/x86 switched to the new Unix/*.i3 files. I'll do this. >>> >>> Maybe also I386_DARWIN, AMD64_DARWIN, but I don't have the hardware. >>> >>> >>> >>> >>> >>> $ORIGIN/LD_LIBRARY_PATH resolved a bit further, probably very >>> little work (I'll do this). >>> >>> Basically just 1) put buildlocal back how it was 2) push it across >>> more platforms e.g. I think FreeBSD/x86 is the main one missing, >>> but I'll get to it. >>> >>> >>> >>> >>> >>> cvsup building and in "std" (I'll do this, probably very little >>> left here really. >>> >>> >>> >>> >>> >>> -- beyond this, not required for release -- >>> >>> >>> >>> >>> >>> Maybe more AMD64 releases, e.g. NetBSD and Solaris. (If I get to it). >>> >>> (could be "mingw64" is good enough to try AMD64_NT now). >>> >>> >>> >>> >>> >>> Maybe update gmp/mpfr to fix the "maintainer" problem. (not likely >>> by me) >>> >>> >>> >>> >>> >>> Maybe more new/resuscitated platforms..HPPA64_HPUX, IA64_*, *_VMS, >>> ALPHA_*, ARM_*, *_IRIX, *_AIX, MIPS64_*.... but these take back >>> seat to important fixes in existing platforms. >>> >>> >>> >>> >>> >>> Fix NT386 to use setjmp3 instead of setjmp so exceptions don't >>> skip C __finally blocks. I've just been very lazy here, should >>> demonstrate the behavior with a test case, then fix it.. >>> >>> >>> >>> >>> >>> Maybe fix cm3cg so other -g options besides -gstabs works, like >>> plain -g, -ggdb, on at least one platform -gstabs isn't supported, >>> leaving nothing, because others cause internal compiler errors, like >>> on HPPA64_HPUX. >>> >>> >>> >>> >>> >>> Oh, and NT386GNU probably switched back to Win32 threads. >>> Otherwise one of the test cases hangs and it doesn't look easy to >>> figure out. I'll do this shortly if I remember. >>> >>> But I also wouldn't mind if this platform isn't officially released >>> either (unless someone else wants to support it). >>> >>> >>> >>> >>> >>> Debug why many NT386MINGNU gui apps crash..but also probably just >>> don't release this platform and ok asis. >>> >>> >>> >>> >>> >>> - 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. > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Tue Apr 14 15:04:33 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 14 Apr 2009 09:04:33 -0400 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> <49E37ADC.1E75.00D7.1@scires.com> <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> Message-ID: <20090414130433.GA2968@topoi.pooq.com> On Tue, Apr 14, 2009 at 12:02:17PM +0200, Olaf Wagner wrote: > If anybody could test Rodney's TEXT changes and provide some > information on the impacts on our applications, that would help a lot. > > I also wasn't able to read and understand all the mails about small objects. > (Guessing, I'd say I'd need another day for that :-) > Can anybody summarize? > Has a conclusion been reached and what will be done/implemented? > Is this relevant for the next release, or will it take longer? Deciding that the garbage collector should test for the low-order bit of pointers and leave them alone if the bit is set could probably dop done immediately, and would make it possible for users to build unsafe code to do the small-objects stuff. This could go in the next release if the garbage-collector change wom't upset anything. There's still some discussion about just what form the final language feature should take. I don't know if that will be finished in time for the release. -- hendrik From rodney.m.bates at cox.net Tue Apr 14 14:21:07 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Tue, 14 Apr 2009 07:21:07 -0500 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <49E37ADC.1E75.00D7.1@scires.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> <49E37ADC.1E75.00D7.1@scires.com> Message-ID: <49E47FB3.2070102@cox.net> Randy Coleburn wrote: > Rodney, sorry but I haven't tried your changes. If your test program > is available, I would be glad to compile and run it on Windows to > obtain results for that platform. Just let me know how to > obtain/install your TEXT changes and the test program. It's in a branch named: devel_m3core_text_newtext_branch It's all part of m3core, which you have to rebuild and ship. The test program source code is in m3-libs/m3core/tests/newtext/src of the branch, along with a README file. > > I am ok with Olaf's suggestion of starting the release process in May. > > Again, I will be glad to help on Windows platforms. If necessary, I > can also test cygwin on Windows. > > If we need to test/build/release on HPUX, I have an old v10 system I > can pull out of storage (note that v10 is an older version of HPUX and > not current). > > Regards, > Randy Coleburn > > >>> "Rodney M. Bates" 4/13/2009 5:24 PM >>> > Any opinions about the TEXT branch? Anybody tried it? To summarize: > > - I have tested it extensively on LINUXLIBC6, with a large random > test program and two successive rebuilds of CM3. > > - It makes no changes in data structure, neither to static declarations > nor to invariants. Thus it creates no compatibility problems with > existing > pickles, etc. > > - It slows down concatenation, but more than makes it up in other > string accessing operations, if the numbers of concatenations and > accessing operations are equal. > > - It cuts down on tree depth and even more or recursion depth > (which implies needed stack space.) > > - This effect is dramatic when strings are built by "linear" > concatenations, > i.e., strictly left-to-right, or vice versa. Gains are moderate when > concatenations are random. > > - It allocates a lot more storage, but abandons a lot more garbage, > retaining somewhat more space when lots of old strings are retained > along with newly-built ones. It probably retains less when operand > strings of concatenations are not kept, but I haven't measured that. > > - Strategies are partial rebalancing of concatenation trees, flattening > of short concatenations, elimination of a lot of tail-recursion, and > recursing on the shorter side. > > > > Olaf Wagner wrote: > > Well, that's a quite long list; but many things are bug fixes anyway, > > and wouldn't be affected by a code freeze, while others are already > > finished (as integrating CVSup, as I understand). > > > > The only thing we should not do is introduce new platforms while > > trying to get the system stable. We should concentrate on installation > > support and bug fixing. > > > > I'd suggest to start the release process in about two weeks at the > > start of May. That should give everybody enough time to either finish > > their ongoing work that shall make it into the release or decide to > > postpone it ;-) > > > > Any objections? > > > > Olaf > > > > Quoting Jay : > > > >> > >> > > o When should we start? I.e. wha changes would you like to > complete > >> > > before we start the release process? > >> > >> > >> > >> > >> I'd like to see the formsvbt crash debugged and fixed, unless I'm > >> the only one seeing it. > >> > >> I only see it on Solaris and PPC_DARWIN but haven't tried > "everything". > >> > >> I'll try to get this. > >> > >> > >> > >> > >> > >> I'd also like to see: > >> > >> > >> > >> > >> > >> FreeBSD/x86 switched to the new Unix/*.i3 files. I'll do this. > >> > >> Maybe also I386_DARWIN, AMD64_DARWIN, but I don't have the > hardware. > >> > >> > >> > >> > >> > >> $ORIGIN/LD_LIBRARY_PATH resolved a bit further, probably very > >> little work (I'll do this). > >> > >> Basically just 1) put buildlocal back how it was 2) push it across > >> more platforms e.g. I think FreeBSD/x86 is the main one missing, > >> but I'll get to it. > >> > >> > >> > >> > >> > >> cvsup building and in "std" (I'll do this, probably very little > >> left here really. > >> > >> > >> > >> > >> > >> -- beyond this, not required for release -- > >> > >> > >> > >> > >> > >> Maybe more AMD64 releases, e.g. NetBSD and Solaris. (If I get to it). > >> > >> (could be "mingw64" is good enough to try AMD64_NT now). > >> > >> > >> > >> > >> > >> Maybe update gmp/mpfr to fix the "maintainer" problem. (not likely > >> by me) > >> > >> > >> > >> > >> > >> Maybe more new/resuscitated platforms..HPPA64_HPUX, IA64_*, *_VMS, > >> ALPHA_*, ARM_*, *_IRIX, *_AIX, MIPS64_*.... but these take back > >> seat to important fixes in existing platforms. > >> > >> > >> > >> > >> > >> Fix NT386 to use setjmp3 instead of setjmp so exceptions don't > >> skip C __finally blocks. I've just been very lazy here, should > >> demonstrate the behavior with a test case, then fix it.. > >> > >> > >> > >> > >> > >> Maybe fix cm3cg so other -g options besides -gstabs works, like > >> plain -g, -ggdb, on at least one platform -gstabs isn't supported, > >> leaving nothing, because others cause internal compiler errors, like > >> on HPPA64_HPUX. > >> > >> > >> > >> > >> > >> Oh, and NT386GNU probably switched back to Win32 threads. > >> Otherwise one of the test cases hangs and it doesn't look easy to > >> figure out. I'll do this shortly if I remember. > >> > >> But I also wouldn't mind if this platform isn't officially released > >> either (unless someone else wants to support it). > >> > >> > >> > >> > >> > >> Debug why many NT386MINGNU gui apps crash..but also probably just > >> don't release this platform and ok asis. > >> > >> > >> > >> > >> > >> - Jay > >> > > > > > > > > From jay.krell at cornell.edu Tue Apr 14 17:29:11 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 14 Apr 2009 15:29:11 +0000 Subject: [M3devel] $ORIGIN/../lib vs. $ORIGIN/../../../lib? Message-ID: $ORIGIN/../lib vs. $ORIGIN/../../../lib? It doesn't appear simple to know which of these runpaths to use. It depends on if the file is exported to bin or just "regular". It would be nice to just use one of these and not concatenate them. Usually "libraries" are in pkg and "executables" are not. But cm3 is an exception, can be ignored in general anything "standalone" can be ignored vorun is an exception. cmpfp is an exception. Also standalone. Is that it? Ignore cm3, change the others to go to bin, and use that rule then? cvsup and cvsupd where also exceptions but I went ahead and changed them. m3back is an exception, but isn't really ever used. uniq is an exception. But it is build static. There, is you know, the notion of an executable that is only meant to be run by code, not humans directly (e.g. cm3cg, cc1, etc.). These can be located outside of $PATH. I guess I can do this with "non local" information or parameter passing? I assume it is too painful right now to add a parameter to the quake link function. or maybe not -- go ahead and add a parameter to m3_link and make_lib, giving the installed path of the file? proc make_lib(lib, options, objects, imported_libs, shared, installed_path) is proc m3_link(prog, options, objects, imported_libs, shared, installed_path) is ? This would affect all configuration files. Several alternatives..that might be too large: Stop shippping any shared libraries or executables to pkg, just bin and lib? Or, reverse the sense of the file vs. symlink? Or make them hardlinks -- not great, since runpath would be wrong for one of them. Relink-upon-install still seems reasonable -- it knows the destination path. Is "../../../lib" moving too far around? How about the notion of confirming the layout, using: $ORIGIN/../pkg/m3core/target/../../.. $ORIGIN/../../../pkg/m3core/target/../../.. Does that feel safer? And not too inefficient? This way generally the ../../../ doesn't hold, unless "pkg/m3core/target" exists. - Jay From mika at async.caltech.edu Tue Apr 14 18:56:34 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 14 Apr 2009 09:56:34 -0700 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: Your message of "Tue, 14 Apr 2009 09:04:33 EDT." <20090414130433.GA2968@topoi.pooq.com> Message-ID: <200904141656.n3EGuYuZ061174@camembert.async.caltech.edu> I agree with what Hendrik says, but what about TYPECASE, ISTYPE, NARROW? Those are necessary to make it possible to pass "pointers" with the low-order bit set outside of unsafe code. My feeling is that if Tony can make the necessary changes, it could be done immediately, and the language issues can be pushed to the future. But admittedly I'm biased because of the application I'm working on. I need to get a recent CM3 up to test the TEXTs.... are they the default now? Mika hendrik at topoi.pooq.com writes: >On Tue, Apr 14, 2009 at 12:02:17PM +0200, Olaf Wagner wrote: >> If anybody could test Rodney's TEXT changes and provide some >> information on the impacts on our applications, that would help a lot. >> >> I also wasn't able to read and understand all the mails about small objects. >> (Guessing, I'd say I'd need another day for that :-) >> Can anybody summarize? >> Has a conclusion been reached and what will be done/implemented? >> Is this relevant for the next release, or will it take longer? > >Deciding that the garbage collector should test for the low-order bit of >pointers and leave them alone if the bit is set could probably dop done >immediately, and would make it possible for users to build unsafe code >to do the small-objects stuff. This could go in the next release if >the garbage-collector change wom't upset anything. > >There's still some discussion about just what form the final language >feature should take. I don't know if that will be finished in time for >the release. > >-- hendrik > From hendrik at topoi.pooq.com Tue Apr 14 18:59:57 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 14 Apr 2009 12:59:57 -0400 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <200904141656.n3EGuYuZ061174@camembert.async.caltech.edu> References: <20090414130433.GA2968@topoi.pooq.com> <200904141656.n3EGuYuZ061174@camembert.async.caltech.edu> Message-ID: <20090414165957.GA3460@topoi.pooq.com> On Tue, Apr 14, 2009 at 09:56:34AM -0700, Mika Nystrom wrote: > > I agree with what Hendrik says, but what about TYPECASE, ISTYPE, > NARROW? Those are necessary to make it possible to pass "pointers" > with the low-order bit set outside of unsafe code. Actually, it's possible to hack this inside unsafe code. So the language chenges are not absolutely essential. But if we have the right langauge changes, agreed, it would be pleasant not to have teo rewrite our code when the language changes finally freeze. -- hendrik From hendrik at topoi.pooq.com Tue Apr 14 19:11:33 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 14 Apr 2009 13:11:33 -0400 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> Message-ID: <20090414171133.GB3460@topoi.pooq.com> On Sat, Apr 11, 2009 at 11:26:11AM +0200, Olaf Wagner wrote: > > I'd rather avoid creating a branch too early, as that means more work > by selecting and merging fixes from trunk to branch. So here my questions: > > o Do we all agree on a temporary code freeze? > o When should we start? I.e. wha changes would you like to complete > before we start the release process? One thing that's essential is to debug the documentation -- specifically, the installation instructions, the various README files, and so forth. A naive user. competent in the ways of computers, but not yet in the ways of Modula 3, should be able to follow the instructions and succeed. Now I've done Modula 3 installations from snapshots before. So I'm no longer the naive user you want from this. If we can find a few colunteers who have never done such installations before, it would be useful to have them try to install, log the results, and come up with a list of obscuritues in the docs. (right down to difficulties in finding the docs!) But I have never compiled and installed the entire system from CVS. I've just downloaded the source from CVS, using the helpful instructions on http://modula3.elegosoft.com/cm3/, so I can report on how this goes, and there there are problems. First problem: the instructions don't say that cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 create a new dubdirectory of the current directory called cm3, and put everything in there. In particular, if there's already a directory called cm3, the downloaded source code will be plunked right on top of whatever was there. This may be obvious to experienced cvs users, but cvs is no longer the standard version control system, and we shouln't expect familiarity. -- hendrik From hendrik at topoi.pooq.com Wed Apr 15 04:54:32 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 14 Apr 2009 22:54:32 -0400 Subject: [M3devel] cvsup and TEXT In-Reply-To: References: <20090413150854.GA32577@topoi.pooq.com> <20090413192006.GA660@topoi.pooq.com> <20090414021311.GB1549@topoi.pooq.com> Message-ID: <20090415025432.GA3881@topoi.pooq.com> On Tue, Apr 14, 2009 at 03:00:48AM +0000, Jay wrote: > > > birch's full domain name > > > > .elegosoft.com > > aka m3.elegosoft.com > > aka modula3.elegosoft.com > > > > > Maybe it's time to change all this. > > > Could be. > > > > > So I should just remove the duplicate from the m3makefile, and maybe > > from the src directory? > > > Just cvs upd -dAP in cm3/m3-tools/cvsup. > > The current commited code should work. > > > > Specifically: remove the suptcp directory, change import(suptcp) to > tcp, any occurences of IMPORT SupFoo AS Foo changed to just IMPORT > Foo, where Foo is roughly in the set TCP, ConnFD, ConnRW, and similer > for SupErrno vs. CErrno, but don't take my word for it, try the > current source. There are more changes than that, such as adapt for > non-const errno values, fixes for big endian 64bit system (a rare > thing, I realize)... Anyway, I checked out cm3 from cvs and spent a while (that's another story) getting a lot of it built and shipped. I'm not quite sure if you're enumerating the things I still have to do, or the things that already have been done on the mainline CVS version. Most of the Sup things seem to be gone already, except suptcp and suplib are still there. Or maybe I haven't looked in the right places yet. I ran ..//scripts/do-pkg.sh buildship cvsup in the source tree as obtained from CVS, without changes, and got no complaints about suptcp (but maybe they were masked by other problems, in which case I'll get around to them soon). Instead I got a complaint that seems to have nothing at all to do with sup: Fatal Error: duplicate unit: ../suplib/src/text_cm3/CText.m3 ../suplib/src/text_pm3/CText.m3 Would this be related to the TEXT changes that are going on? -- hendrik From jay.krell at cornell.edu Wed Apr 15 12:59:59 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 15 Apr 2009 10:59:59 +0000 Subject: [M3devel] cvsup In-Reply-To: <20090415025432.GA3881@topoi.pooq.com> References: <20090413150854.GA32577@topoi.pooq.com> <20090413192006.GA660@topoi.pooq.com> <20090414021311.GB1549@topoi.pooq.com> <20090415025432.GA3881@topoi.pooq.com> Message-ID: Again, the current source builds. The stuff I listed is some of what I did, what you would have to do if you started with the snapshop. I shouldn't have mentioned it. I did not make "do-pkg cvsup" and such work however. Or test it. But it might work, like do-pkg suplib && do-pkg cvsup/server && do-pkg cvsup/client. The error indicates you don't have current source maybe. Or, whatever, the pm3 vs. cm3 check isn't working. I' think I'll just make unconditional. The text changes do not change the interface or even the underlying data structures/pickes (future changes will conceivable change the underlying structures). Only small bugfixes are even in the mainline. suplib is fine and needed. It is specific to cvsup and a bunch of code unique to it. Just suptcp is dead now. cd $CVSROOT/m3-tools cvs -z3 upd cvsup cd cvsup/suplib cm3 cm3 -ship cd ../server cm3 cm3 -ship (optional) cd ../client cm3 cm3 -ship (optional) (client and server can be built in either order; suplib must be built before either) - Jay From hendrik at topoi.pooq.com Wed Apr 15 15:39:53 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 15 Apr 2009 09:39:53 -0400 Subject: [M3devel] cvsup In-Reply-To: References: <20090413150854.GA32577@topoi.pooq.com> <20090413192006.GA660@topoi.pooq.com> <20090414021311.GB1549@topoi.pooq.com> <20090415025432.GA3881@topoi.pooq.com> Message-ID: <20090415133953.GB5233@topoi.pooq.com> On Wed, Apr 15, 2009 at 10:59:59AM +0000, Jay wrote: > > Again, the current source builds. > The stuff I listed is some of what I did, what > you would have to do if you started with the snapshop. > I shouldn't have mentioned it. > > > I did not make "do-pkg cvsup" and such work however. Or test it. > But it might work, like do-pkg suplib && do-pkg cvsup/server && do-pkg cvsup/client. > The error indicates you don't have current source maybe. Well, I just checked the entire cm3 out from cvs yesterday (or was it the evening before? No earlier, anyway.). > Or, whatever, the pm3 vs. cm3 check isn't working. Perhaps this is the problem. What is the pm3 vs cm3 check? > I' think I'll just make unconditional. > The text changes do not change the interface or even the > underlying data structures/pickes (future changes will conceivable > change the underlying structures). Only small bugfixes > are even in the mainline. So I should see where the extraneous interfece comes from and try to get rid of it. > > > suplib is fine and needed. It is specific to cvsup and a bunch > of code unique to it. > Just suptcp is dead now. > > > cd $CVSROOT/m3-tools > cvs -z3 upd cvsup > cd cvsup/suplib > cm3 > cm3 -ship > cd ../server > cm3 > cm3 -ship (optional) > cd ../client > cm3 > cm3 -ship (optional) Will try this first. -- hendrik > > > (client and server can be built in either order; suplib must be built before either) > > > - Jay From jay.krell at cornell.edu Wed Apr 15 16:12:34 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 15 Apr 2009 14:12:34 +0000 Subject: [M3devel] fewer wrappers/more C? (or a wash?) Message-ID: This "rewrites" ThreadPThread.InitMutex and ThreadPThread.InitCondition in C. They are only a few lines either way. Thereby removing all uses of initMu from Modula-3 and enabling removing the "bridging" of it between Modula-3 and C. Better? I'm not sure. No real difference? Maybe. Likewise can be done for CreateT's allocation/initialization of cond_t. And then MemAlloc/MemFree would be moved. Ultimately this is the route toward - writing most/all of ThreadPThread.c in C - removing most/all bridging I'm aware it should handle out of memory. - Jay Index: ThreadPThread.i3 =================================================================== RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThread.i3,v retrieving revision 1.14 diff -u -r1.14 ThreadPThread.i3 --- ThreadPThread.i3 30 Mar 2009 21:52:15 -0000 1.14 +++ ThreadPThread.i3 15 Apr 2009 14:03:58 -0000 @@ -137,20 +137,10 @@ pthread_mutex_t = ADDRESS; pthread_cond_t = ADDRESS; - -(*CONST*) VAR sizeof_pthread_mutex_t:int; - (*CONST*) VAR sizeof_pthread_cond_t:int; -PROCEDURE pthread_mutex_init(mutex: pthread_mutex_t; attr:ADDRESS:=NIL):int; - -(* This wrapper has some OS-specific bug workarounds. *) - -PROCEDURE pthread_mutex_destroy(mutex: pthread_mutex_t):int; - - PROCEDURE pthread_mutex_lock(mutex: pthread_mutex_t):int; @@ -170,4 +160,12 @@ (*---------------------------------------------------------------------------*) + +PROCEDURE InitMutex (MutexRoot: REFANY; VAR pthread_mutex: pthread_mutex_t); + + +PROCEDURE InitCondition (ConditionRoot: REFANY; VAR pthread_mutex: pthread_mutex_t); + +(*---------------------------------------------------------------------------*) + END ThreadPThread. Index: ThreadPThread.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThread.m3,v retrieving revision 1.101 diff -u -r1.101 ThreadPThread.m3 --- ThreadPThread.m3 30 Mar 2009 21:59:31 -0000 1.101 +++ ThreadPThread.m3 15 Apr 2009 14:03:58 -0000 @@ -155,35 +155,13 @@ m.release (); END Release; -PROCEDURE CleanMutex (r: REFANY) = - VAR m := NARROW(r, Mutex); - BEGIN - WITH r = pthread_mutex_destroy (m.mutex) DO END; - MemFree(m.mutex); - END CleanMutex; - -PROCEDURE InitMutex (m: Mutex) = - VAR mutex: pthread_mutex_t; - BEGIN - TRY - WITH r = pthread_mutex_lock_init() DO END; - IF m.mutex # NIL THEN RETURN END; - mutex := MemAlloc(sizeof_pthread_mutex_t); - WITH r = pthread_mutex_init(mutex) DO END; - m.mutex := mutex; - FINALLY - WITH r = pthread_mutex_unlock_init() DO END; - END; - RTHeapRep.RegisterFinalCleanup (m, CleanMutex); - END InitMutex; - PROCEDURE LockMutex (m: Mutex) = VAR self := Self(); BEGIN IF self = NIL THEN Die(ThisLine(), "LockMutex called from a non-Modula-3 thread"); END; - IF m.mutex = NIL THEN InitMutex(m) END; + IF m.mutex = NIL THEN InitMutex(m, m.mutex) END; IF perfOn THEN PerfChanged(self.id, State.locking) END; WITH r = pthread_mutex_lock(m.mutex) DO IF r # 0 THEN @@ -211,34 +189,12 @@ (*---------------------------------------- Condition variables and Alerts ---*) -PROCEDURE CleanCondition (r: REFANY) = - VAR c := NARROW(r, Condition); - BEGIN - WITH r = pthread_mutex_destroy (c.mutex) DO END; - MemFree(c.mutex); - END CleanCondition; - -PROCEDURE InitCondition (c: Condition) = - VAR mutex: pthread_mutex_t; - BEGIN - TRY - WITH r = pthread_mutex_lock_init() DO END; - IF c.mutex # NIL THEN RETURN END; - mutex := MemAlloc(sizeof_pthread_mutex_t); - WITH r = pthread_mutex_init(mutex) DO END; - c.mutex := mutex; - FINALLY - WITH r = pthread_mutex_unlock_init() DO END; - END; - RTHeapRep.RegisterFinalCleanup (c, CleanCondition); - END InitCondition; - PROCEDURE XWait (self: T; m: Mutex; c: Condition; alertable: BOOLEAN) RAISES {Alerted} = (* LL = m *) VAR next, prev: T; BEGIN - IF c.mutex = NIL THEN InitCondition(c) END; + IF c.mutex = NIL THEN InitCondition(c, c.mutex) END; TRY @@ -325,7 +281,7 @@ PROCEDURE Signal (c: Condition) = BEGIN - IF c.mutex = NIL THEN InitCondition(c) END; + IF c.mutex = NIL THEN InitCondition(c, c.mutex) END; WITH r = pthread_mutex_lock(c.mutex) DO END; IF c.waiters # NIL THEN DequeueHead(c) END; WITH r = pthread_mutex_unlock(c.mutex) DO END; @@ -333,7 +289,7 @@ PROCEDURE Broadcast (c: Condition) = BEGIN - IF c.mutex = NIL THEN InitCondition(c) END; + IF c.mutex = NIL THEN InitCondition(c, c.mutex) END; WITH r = pthread_mutex_lock(c.mutex) DO END; WHILE c.waiters # NIL DO DequeueHead(c) END; WITH r = pthread_mutex_unlock(c.mutex) DO END; Index: ThreadPThreadC.c =================================================================== RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThreadC.c,v retrieving revision 1.19 diff -u -r1.19 ThreadPThreadC.c --- ThreadPThreadC.c 30 Mar 2009 21:52:15 -0000 1.19 +++ ThreadPThreadC.c 15 Apr 2009 14:03:58 -0000 @@ -250,16 +250,12 @@ MUTEX(active) /* global lock for list of active threads */ MUTEX(slot) /* global lock for thread slot table */ -MUTEX(init) /* global lock for initializers */ MUTEX(perf) MUTEX(heap) CONDITION_VARIABLE(heap) THREAD_LOCAL(activations) EXTERN_CONST -int ThreadPThread__sizeof_pthread_mutex_t = sizeof(pthread_mutex_t); - -EXTERN_CONST int ThreadPThread__sizeof_pthread_cond_t = sizeof(pthread_cond_t); int @@ -271,17 +267,83 @@ pthread_mutex_destroy() intermittently returns EBUSY even when there are no threads accessing the mutex. */ int e; - do - { - e = pthread_mutex_destroy(mutex); - } - while (e == EBUSY); + while ((e = pthread_mutex_destroy(mutex)) == EBUSY) { } return e; #else return pthread_mutex_destroy(mutex); #endif } +void RTHeapRep__RegisterFinalCleanup (char* Root, void (*clean)(char*)); + +/* This should be known at compile-time, but I don't know the Modula-3 object model. */ +size_t M3MutexToPthreadMutex; +size_t M3ConditionToPthreadMutex; + +#define MemAlloc ThreadPThread__MemAlloc +#define MemFree ThreadPThread__MemFree + +void* MemAlloc (size_t size); +void MemFree (void* a); + +static void Common_CleanMutex(char* Root, size_t Offset) +{ + pthread_mutex_t** inout_Mutex = (pthread_mutex_t**)(Root + Offset); + pthread_mutex_t* Mutex = *inout_Mutex; + *inout_Mutex = NULL; + if (Mutex != NULL) + { + ThreadPThread__pthread_mutex_destroy(Mutex); + MemFree(Mutex); + } +} + +static void CleanCondition(char* Root) +{ + Common_CleanMutex(Root, M3ConditionToPthreadMutex); +} + +static void CleanMutex(char* Root) +{ + Common_CleanMutex(Root, M3MutexToPthreadMutex); +} + +static void Common_InitMutex(char* Root, pthread_mutex_t** inout_Mutex, size_t* inout_Offset, void (*Clean)(char*)) +{ + static pthread_mutex_t initMu = PTHREAD_MUTEX_INITIALIZER; /* global lock for initializers */ + size_t Offset = *inout_Offset; + + if (Offset == 0) + *inout_Offset = (((char*)inout_Mutex) - Root); + else + assert(Offset == (((char*)inout_Mutex) - Root)); + assert((char*)inout_Mutex>= Root); + + pthread_mutex_lock(&initMu); + if (*inout_Mutex == NULL) + { + pthread_mutex_t* Mutex = (pthread_mutex_t*)calloc(1, sizeof(*Mutex)); + if (Mutex) + { + pthread_mutex_init(Mutex, NULL); + *inout_Mutex = Mutex; + } + } + pthread_mutex_unlock(&initMu); + + RTHeapRep__RegisterFinalCleanup (Root, Clean); +} + +void ThreadPThread__InitMutex(char* Root, pthread_mutex_t** Mutex) +{ + Common_InitMutex(Root, Mutex, &M3MutexToPthreadMutex, CleanMutex); +} + +void ThreadPThread__InitCondition (char* Root, pthread_mutex_t** Mutex) +{ + Common_InitMutex(Root, Mutex, &M3ConditionToPthreadMutex, CleanCondition); +} + #ifdef __cplusplus } /* extern "C" */ #endif -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ThreadPThreadC.c URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ThreadPThread.m3 URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt URL: From jay.krell at cornell.edu Wed Apr 15 16:09:33 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 15 Apr 2009 14:09:33 +0000 Subject: [M3devel] cvsup In-Reply-To: <20090415133953.GB5233@topoi.pooq.com> References: <20090413150854.GA32577@topoi.pooq.com> <20090413192006.GA660@topoi.pooq.com> <20090414021311.GB1549@topoi.pooq.com> <20090415025432.GA3881@topoi.pooq.com> <20090415133953.GB5233@topoi.pooq.com> Message-ID: cm3/m3-tools/cvsup/quake/cvsup.quake I made it unconditional after your mail. There is code that is PM3 or CM3 or SRC specific and tries to pick the right one by sniffing the compiler. or Windows, easy to find it: cd \dev2\cm3\m3-tools\cvsup findstr /s PM3 * or dir /s/b/a-d | findstr /i cm3 dir /s/b/a-d | findstr /i pm3 It should all be easy to find. But again, it should just work from current cvs. - Jay From hendrik at topoi.pooq.com Wed Apr 15 19:25:29 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 15 Apr 2009 13:25:29 -0400 Subject: [M3devel] cvsup In-Reply-To: References: <20090413150854.GA32577@topoi.pooq.com> <20090413192006.GA660@topoi.pooq.com> <20090414021311.GB1549@topoi.pooq.com> <20090415025432.GA3881@topoi.pooq.com> <20090415133953.GB5233@topoi.pooq.com> Message-ID: <20090415172529.GA5566@topoi.pooq.com> On Wed, Apr 15, 2009 at 02:09:33PM +0000, Jay wrote: > > cm3/m3-tools/cvsup/quake/cvsup.quake > I made it unconditional after your mail. Maybe that's why it works now. And cvsup runs and I now have over a gigabyte of Modula 3 .v files. Next to figure out what monotone wants me to do with them. -- hendrik From hosking at cs.purdue.edu Fri Apr 17 04:54:13 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 17 Apr 2009 12:54:13 +1000 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <200904141656.n3EGuYuZ061174@camembert.async.caltech.edu> References: <200904141656.n3EGuYuZ061174@camembert.async.caltech.edu> Message-ID: <0DEE58D2-97B2-4BE3-A5F9-4FAFC326EC68@cs.purdue.edu> Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 15 Apr 2009, at 02:56, Mika Nystrom wrote: > > I agree with what Hendrik says, but what about TYPECASE, ISTYPE, > NARROW? Those are necessary to make it possible to pass "pointers" > with the low-order bit set outside of unsafe code. > > My feeling is that if Tony can make the necessary changes, it could > be done immediately, and the language issues can be pushed to the > future. But admittedly I'm biased because of the application I'm > working on. I can take care of this next week. > I need to get a recent CM3 up to test the TEXTs.... are they the > default now? > > Mika > > hendrik at topoi.pooq.com writes: >> On Tue, Apr 14, 2009 at 12:02:17PM +0200, Olaf Wagner wrote: >>> If anybody could test Rodney's TEXT changes and provide some >>> information on the impacts on our applications, that would help a >>> lot. >>> >>> I also wasn't able to read and understand all the mails about >>> small objects. >>> (Guessing, I'd say I'd need another day for that :-) >>> Can anybody summarize? >>> Has a conclusion been reached and what will be done/implemented? >>> Is this relevant for the next release, or will it take longer? >> >> Deciding that the garbage collector should test for the low-order >> bit of >> pointers and leave them alone if the bit is set could probably dop >> done >> immediately, and would make it possible for users to build unsafe >> code >> to do the small-objects stuff. This could go in the next release if >> the garbage-collector change wom't upset anything. >> >> There's still some discussion about just what form the final language >> feature should take. I don't know if that will be finished in time >> for >> the release. >> >> -- hendrik >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 17 14:57:10 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 17 Apr 2009 22:57:10 +1000 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: References: Message-ID: I am a little concerned about passing REFANY directly to C code as there is no guarantee that REFANY and C pointers will always be compatible. ADDRESS can more safely be assumed compatible. On 16 Apr 2009, at 00:12, Jay wrote: > > This "rewrites" ThreadPThread.InitMutex and > ThreadPThread.InitCondition in C. > They are only a few lines either way. > Thereby removing all uses of initMu from Modula-3 and enabling > removing > the "bridging" of it between Modula-3 and C. > > > Better? I'm not sure. > No real difference? Maybe. > > > Likewise can be done for CreateT's allocation/initialization of > cond_t. > And then MemAlloc/MemFree would be moved. > > > Ultimately this is the route toward > - writing most/all of ThreadPThread.c in C > - removing most/all bridging > > > I'm aware it should handle out of memory. > > > - Jay > > > Index: ThreadPThread.i3 > =================================================================== > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ > ThreadPThread.i3,v > retrieving revision 1.14 > diff -u -r1.14 ThreadPThread.i3 > --- ThreadPThread.i3 30 Mar 2009 21:52:15 -0000 1.14 > +++ ThreadPThread.i3 15 Apr 2009 14:03:58 -0000 > @@ -137,20 +137,10 @@ > pthread_mutex_t = ADDRESS; > pthread_cond_t = ADDRESS; > > - > -(*CONST*) VAR sizeof_pthread_mutex_t:int; > - > > (*CONST*) VAR sizeof_pthread_cond_t:int; > > > -PROCEDURE pthread_mutex_init(mutex: pthread_mutex_t; > attr:ADDRESS:=NIL):int; > - > -(* This wrapper has some OS-specific bug workarounds. *) > - > -PROCEDURE pthread_mutex_destroy(mutex: pthread_mutex_t):int; > - > - > PROCEDURE pthread_mutex_lock(mutex: pthread_mutex_t):int; > > > @@ -170,4 +160,12 @@ > > (*---------------------------------------------------------------------------*) > > + > +PROCEDURE InitMutex (MutexRoot: REFANY; VAR pthread_mutex: > pthread_mutex_t); > + > + > +PROCEDURE InitCondition (ConditionRoot: REFANY; VAR pthread_mutex: > pthread_mutex_t); > + > + > (*---------------------------------------------------------------------------*) > + > END ThreadPThread. > Index: ThreadPThread.m3 > =================================================================== > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ > ThreadPThread.m3,v > retrieving revision 1.101 > diff -u -r1.101 ThreadPThread.m3 > --- ThreadPThread.m3 30 Mar 2009 21:59:31 -0000 1.101 > +++ ThreadPThread.m3 15 Apr 2009 14:03:58 -0000 > @@ -155,35 +155,13 @@ > m.release (); > END Release; > > -PROCEDURE CleanMutex (r: REFANY) = > - VAR m := NARROW(r, Mutex); > - BEGIN > - WITH r = pthread_mutex_destroy (m.mutex) DO END; > - MemFree(m.mutex); > - END CleanMutex; > - > -PROCEDURE InitMutex (m: Mutex) = > - VAR mutex: pthread_mutex_t; > - BEGIN > - TRY > - WITH r = pthread_mutex_lock_init() DO END; > - IF m.mutex # NIL THEN RETURN END; > - mutex := MemAlloc(sizeof_pthread_mutex_t); > - WITH r = pthread_mutex_init(mutex) DO END; > - m.mutex := mutex; > - FINALLY > - WITH r = pthread_mutex_unlock_init() DO END; > - END; > - RTHeapRep.RegisterFinalCleanup (m, CleanMutex); > - END InitMutex; > - > PROCEDURE LockMutex (m: Mutex) = > VAR self := Self(); > BEGIN > IF self = NIL THEN > Die(ThisLine(), "LockMutex called from a non-Modula-3 thread"); > END; > - IF m.mutex = NIL THEN InitMutex(m) END; > + IF m.mutex = NIL THEN InitMutex(m, m.mutex) END; > IF perfOn THEN PerfChanged(self.id, State.locking) END; > WITH r = pthread_mutex_lock(m.mutex) DO > IF r # 0 THEN > @@ -211,34 +189,12 @@ > > (*---------------------------------------- Condition variables and > Alerts ---*) > > -PROCEDURE CleanCondition (r: REFANY) = > - VAR c := NARROW(r, Condition); > - BEGIN > - WITH r = pthread_mutex_destroy (c.mutex) DO END; > - MemFree(c.mutex); > - END CleanCondition; > - > -PROCEDURE InitCondition (c: Condition) = > - VAR mutex: pthread_mutex_t; > - BEGIN > - TRY > - WITH r = pthread_mutex_lock_init() DO END; > - IF c.mutex # NIL THEN RETURN END; > - mutex := MemAlloc(sizeof_pthread_mutex_t); > - WITH r = pthread_mutex_init(mutex) DO END; > - c.mutex := mutex; > - FINALLY > - WITH r = pthread_mutex_unlock_init() DO END; > - END; > - RTHeapRep.RegisterFinalCleanup (c, CleanCondition); > - END InitCondition; > - > PROCEDURE XWait (self: T; m: Mutex; c: Condition; alertable: BOOLEAN) > RAISES {Alerted} = > (* LL = m *) > VAR next, prev: T; > BEGIN > - IF c.mutex = NIL THEN InitCondition(c) END; > + IF c.mutex = NIL THEN InitCondition(c, c.mutex) END; > TRY > > > @@ -325,7 +281,7 @@ > > PROCEDURE Signal (c: Condition) = > BEGIN > - IF c.mutex = NIL THEN InitCondition(c) END; > + IF c.mutex = NIL THEN InitCondition(c, c.mutex) END; > WITH r = pthread_mutex_lock(c.mutex) DO END; > IF c.waiters # NIL THEN DequeueHead(c) END; > WITH r = pthread_mutex_unlock(c.mutex) DO END; > @@ -333,7 +289,7 @@ > > PROCEDURE Broadcast (c: Condition) = > BEGIN > - IF c.mutex = NIL THEN InitCondition(c) END; > + IF c.mutex = NIL THEN InitCondition(c, c.mutex) END; > WITH r = pthread_mutex_lock(c.mutex) DO END; > WHILE c.waiters # NIL DO DequeueHead(c) END; > WITH r = pthread_mutex_unlock(c.mutex) DO END; > Index: ThreadPThreadC.c > =================================================================== > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ > ThreadPThreadC.c,v > retrieving revision 1.19 > diff -u -r1.19 ThreadPThreadC.c > --- ThreadPThreadC.c 30 Mar 2009 21:52:15 -0000 1.19 > +++ ThreadPThreadC.c 15 Apr 2009 14:03:58 -0000 > @@ -250,16 +250,12 @@ > > MUTEX(active) /* global lock for list of active threads */ > MUTEX(slot) /* global lock for thread slot table */ > -MUTEX(init) /* global lock for initializers */ > MUTEX(perf) > MUTEX(heap) > CONDITION_VARIABLE(heap) > THREAD_LOCAL(activations) > > EXTERN_CONST > -int ThreadPThread__sizeof_pthread_mutex_t = sizeof(pthread_mutex_t); > - > -EXTERN_CONST > int ThreadPThread__sizeof_pthread_cond_t = sizeof(pthread_cond_t); > > int > @@ -271,17 +267,83 @@ > pthread_mutex_destroy() intermittently returns > EBUSY even when there are no threads accessing the mutex. */ > int e; > - do > - { > - e = pthread_mutex_destroy(mutex); > - } > - while (e == EBUSY); > + while ((e = pthread_mutex_destroy(mutex)) == EBUSY) { } > return e; > #else > return pthread_mutex_destroy(mutex); > #endif > } > > +void RTHeapRep__RegisterFinalCleanup (char* Root, void (*clean) > (char*)); > + > +/* This should be known at compile-time, but I don't know the > Modula-3 object model. */ > +size_t M3MutexToPthreadMutex; > +size_t M3ConditionToPthreadMutex; > + > +#define MemAlloc ThreadPThread__MemAlloc > +#define MemFree ThreadPThread__MemFree > + > +void* MemAlloc (size_t size); > +void MemFree (void* a); > + > +static void Common_CleanMutex(char* Root, size_t Offset) > +{ > + pthread_mutex_t** inout_Mutex = (pthread_mutex_t**)(Root + > Offset); > + pthread_mutex_t* Mutex = *inout_Mutex; > + *inout_Mutex = NULL; > + if (Mutex != NULL) > + { > + ThreadPThread__pthread_mutex_destroy(Mutex); > + MemFree(Mutex); > + } > +} > + > +static void CleanCondition(char* Root) > +{ > + Common_CleanMutex(Root, M3ConditionToPthreadMutex); > +} > + > +static void CleanMutex(char* Root) > +{ > + Common_CleanMutex(Root, M3MutexToPthreadMutex); > +} > + > +static void Common_InitMutex(char* Root, pthread_mutex_t** > inout_Mutex, size_t* inout_Offset, void (*Clean)(char*)) > +{ > + static pthread_mutex_t initMu = PTHREAD_MUTEX_INITIALIZER; /* > global lock for initializers */ > + size_t Offset = *inout_Offset; > + > + if (Offset == 0) > + *inout_Offset = (((char*)inout_Mutex) - Root); > + else > + assert(Offset == (((char*)inout_Mutex) - Root)); > + assert((char*)inout_Mutex>= Root); > + > + pthread_mutex_lock(&initMu); > + if (*inout_Mutex == NULL) > + { > + pthread_mutex_t* Mutex = (pthread_mutex_t*)calloc(1, > sizeof(*Mutex)); > + if (Mutex) > + { > + pthread_mutex_init(Mutex, NULL); > + *inout_Mutex = Mutex; > + } > + } > + pthread_mutex_unlock(&initMu); > + > + RTHeapRep__RegisterFinalCleanup (Root, Clean); > +} > + > +void ThreadPThread__InitMutex(char* Root, pthread_mutex_t** Mutex) > +{ > + Common_InitMutex(Root, Mutex, &M3MutexToPthreadMutex, > CleanMutex); > +} > + > +void ThreadPThread__InitCondition (char* Root, pthread_mutex_t** > Mutex) > +{ > + Common_InitMutex(Root, Mutex, &M3ConditionToPthreadMutex, > CleanCondition); > +} > + > #ifdef __cplusplus > } /* extern "C" */ > #endif > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Apr 17 23:48:44 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 17 Apr 2009 21:48:44 +0000 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: References: Message-ID: Ok. And the rest/overall? Usually I'm very certain my "more C code" changes are for the better. In this case it might be a wash. REFANY might have some tag bits set? ADDRESS really is/must-be a direct pointer that us C programmers are familiar with? UNTRACED REF T would have to be a plain old pointer too right? - Jay ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: fewer wrappers/more C? (or a wash?) > Date: Fri, 17 Apr 2009 22:57:10 +1000 > > I am a little concerned about passing REFANY directly to C code as there is no guarantee that REFANY and C pointers will always be compatible. ADDRESS can more safely be assumed compatible. > > On 16 Apr 2009, at 00:12, Jay wrote: > > > This "rewrites" ThreadPThread.InitMutex and ThreadPThread.InitCondition in C. > They are only a few lines either way. > Thereby removing all uses of initMu from Modula-3 and enabling removing > the "bridging" of it between Modula-3 and C. > > > Better? I'm not sure. > No real difference? Maybe. > > > Likewise can be done for CreateT's allocation/initialization of cond_t. > And then MemAlloc/MemFree would be moved. > > > Ultimately this is the route toward > - writing most/all of ThreadPThread.c in C > - removing most/all bridging > > > I'm aware it should handle out of memory. > > > - Jay > > > Index: ThreadPThread.i3 > =================================================================== > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThread.i3,v > retrieving revision 1.14 > diff -u -r1.14 ThreadPThread.i3 > --- ThreadPThread.i3 30 Mar 2009 21:52:15 -0000 1.14 > +++ ThreadPThread.i3 15 Apr 2009 14:03:58 -0000 > @@ -137,20 +137,10 @@ > pthread_mutex_t = ADDRESS; > pthread_cond_t = ADDRESS; > > - > -(*CONST*) VAR sizeof_pthread_mutex_t:int; > - > > (*CONST*) VAR sizeof_pthread_cond_t:int; > > > -PROCEDURE pthread_mutex_init(mutex: pthread_mutex_t; attr:ADDRESS:=NIL):int; > - > -(* This wrapper has some OS-specific bug workarounds. *) > - > -PROCEDURE pthread_mutex_destroy(mutex: pthread_mutex_t):int; > - > - > PROCEDURE pthread_mutex_lock(mutex: pthread_mutex_t):int; > > > @@ -170,4 +160,12 @@ > > (*---------------------------------------------------------------------------*) > > + > +PROCEDURE InitMutex (MutexRoot: REFANY; VAR pthread_mutex: pthread_mutex_t); > + > + > +PROCEDURE InitCondition (ConditionRoot: REFANY; VAR pthread_mutex: pthread_mutex_t); > + > +(*---------------------------------------------------------------------------*) > + > END ThreadPThread. > Index: ThreadPThread.m3 > =================================================================== > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThread.m3,v > retrieving revision 1.101 > diff -u -r1.101 ThreadPThread.m3 > --- ThreadPThread.m3 30 Mar 2009 21:59:31 -0000 1.101 > +++ ThreadPThread.m3 15 Apr 2009 14:03:58 -0000 > @@ -155,35 +155,13 @@ > m.release (); > END Release; > > -PROCEDURE CleanMutex (r: REFANY) = > - VAR m := NARROW(r, Mutex); > - BEGIN > - WITH r = pthread_mutex_destroy (m.mutex) DO END; > - MemFree(m.mutex); > - END CleanMutex; > - > -PROCEDURE InitMutex (m: Mutex) = > - VAR mutex: pthread_mutex_t; > - BEGIN > - TRY > - WITH r = pthread_mutex_lock_init() DO END; > - IF m.mutex # NIL THEN RETURN END; > - mutex := MemAlloc(sizeof_pthread_mutex_t); > - WITH r = pthread_mutex_init(mutex) DO END; > - m.mutex := mutex; > - FINALLY > - WITH r = pthread_mutex_unlock_init() DO END; > - END; > - RTHeapRep.RegisterFinalCleanup (m, CleanMutex); > - END InitMutex; > - > PROCEDURE LockMutex (m: Mutex) = > VAR self := Self(); > BEGIN > IF self = NIL THEN > Die(ThisLine(), "LockMutex called from a non-Modula-3 thread"); > END; > - IF m.mutex = NIL THEN InitMutex(m) END; > + IF m.mutex = NIL THEN InitMutex(m, m.mutex) END; > IF perfOn THEN PerfChanged(self.id, State.locking) END; > WITH r = pthread_mutex_lock(m.mutex) DO > IF r # 0 THEN > @@ -211,34 +189,12 @@ > > (*---------------------------------------- Condition variables and Alerts ---*) > > -PROCEDURE CleanCondition (r: REFANY) = > - VAR c := NARROW(r, Condition); > - BEGIN > - WITH r = pthread_mutex_destroy (c.mutex) DO END; > - MemFree(c.mutex); > - END CleanCondition; > - > -PROCEDURE InitCondition (c: Condition) = > - VAR mutex: pthread_mutex_t; > - BEGIN > - TRY > - WITH r = pthread_mutex_lock_init() DO END; > - IF c.mutex # NIL THEN RETURN END; > - mutex := MemAlloc(sizeof_pthread_mutex_t); > - WITH r = pthread_mutex_init(mutex) DO END; > - c.mutex := mutex; > - FINALLY > - WITH r = pthread_mutex_unlock_init() DO END; > - END; > - RTHeapRep.RegisterFinalCleanup (c, CleanCondition); > - END InitCondition; > - > PROCEDURE XWait (self: T; m: Mutex; c: Condition; alertable: BOOLEAN) > RAISES {Alerted} = > (* LL = m *) > VAR next, prev: T; > BEGIN > - IF c.mutex = NIL THEN InitCondition(c) END; > + IF c.mutex = NIL THEN InitCondition(c, c.mutex) END; > TRY > > > @@ -325,7 +281,7 @@ > > PROCEDURE Signal (c: Condition) = > BEGIN > - IF c.mutex = NIL THEN InitCondition(c) END; > + IF c.mutex = NIL THEN InitCondition(c, c.mutex) END; > WITH r = pthread_mutex_lock(c.mutex) DO END; > IF c.waiters # NIL THEN DequeueHead(c) END; > WITH r = pthread_mutex_unlock(c.mutex) DO END; > @@ -333,7 +289,7 @@ > > PROCEDURE Broadcast (c: Condition) = > BEGIN > - IF c.mutex = NIL THEN InitCondition(c) END; > + IF c.mutex = NIL THEN InitCondition(c, c.mutex) END; > WITH r = pthread_mutex_lock(c.mutex) DO END; > WHILE c.waiters # NIL DO DequeueHead(c) END; > WITH r = pthread_mutex_unlock(c.mutex) DO END; > Index: ThreadPThreadC.c > =================================================================== > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThreadC.c,v > retrieving revision 1.19 > diff -u -r1.19 ThreadPThreadC.c > --- ThreadPThreadC.c 30 Mar 2009 21:52:15 -0000 1.19 > +++ ThreadPThreadC.c 15 Apr 2009 14:03:58 -0000 > @@ -250,16 +250,12 @@ > > MUTEX(active) /* global lock for list of active threads */ > MUTEX(slot) /* global lock for thread slot table */ > -MUTEX(init) /* global lock for initializers */ > MUTEX(perf) > MUTEX(heap) > CONDITION_VARIABLE(heap) > THREAD_LOCAL(activations) > > EXTERN_CONST > -int ThreadPThread__sizeof_pthread_mutex_t = sizeof(pthread_mutex_t); > - > -EXTERN_CONST > int ThreadPThread__sizeof_pthread_cond_t = sizeof(pthread_cond_t); > > int > @@ -271,17 +267,83 @@ > pthread_mutex_destroy() intermittently returns > EBUSY even when there are no threads accessing the mutex. */ > int e; > - do > - { > - e = pthread_mutex_destroy(mutex); > - } > - while (e == EBUSY); > + while ((e = pthread_mutex_destroy(mutex)) == EBUSY) { } > return e; > #else > return pthread_mutex_destroy(mutex); > #endif > } > > +void RTHeapRep__RegisterFinalCleanup (char* Root, void (*clean)(char*)); > + > +/* This should be known at compile-time, but I don't know the Modula-3 object model. */ > +size_t M3MutexToPthreadMutex; > +size_t M3ConditionToPthreadMutex; > + > +#define MemAlloc ThreadPThread__MemAlloc > +#define MemFree ThreadPThread__MemFree > + > +void* MemAlloc (size_t size); > +void MemFree (void* a); > + > +static void Common_CleanMutex(char* Root, size_t Offset) > +{ > + pthread_mutex_t** inout_Mutex = (pthread_mutex_t**)(Root + Offset); > + pthread_mutex_t* Mutex = *inout_Mutex; > + *inout_Mutex = NULL; > + if (Mutex != NULL) > + { > + ThreadPThread__pthread_mutex_destroy(Mutex); > + MemFree(Mutex); > + } > +} > + > +static void CleanCondition(char* Root) > +{ > + Common_CleanMutex(Root, M3ConditionToPthreadMutex); > +} > + > +static void CleanMutex(char* Root) > +{ > + Common_CleanMutex(Root, M3MutexToPthreadMutex); > +} > + > +static void Common_InitMutex(char* Root, pthread_mutex_t** inout_Mutex, size_t* inout_Offset, void (*Clean)(char*)) > +{ > + static pthread_mutex_t initMu = PTHREAD_MUTEX_INITIALIZER; /* global lock for initializers */ > + size_t Offset = *inout_Offset; > + > + if (Offset == 0) > + *inout_Offset = (((char*)inout_Mutex) - Root); > + else > + assert(Offset == (((char*)inout_Mutex) - Root)); > + assert((char*)inout_Mutex>= Root); > + > + pthread_mutex_lock(&initMu); > + if (*inout_Mutex == NULL) > + { > + pthread_mutex_t* Mutex = (pthread_mutex_t*)calloc(1, sizeof(*Mutex)); > + if (Mutex) > + { > + pthread_mutex_init(Mutex, NULL); > + *inout_Mutex = Mutex; > + } > + } > + pthread_mutex_unlock(&initMu); > + > + RTHeapRep__RegisterFinalCleanup (Root, Clean); > +} > + > +void ThreadPThread__InitMutex(char* Root, pthread_mutex_t** Mutex) > +{ > + Common_InitMutex(Root, Mutex, &M3MutexToPthreadMutex, CleanMutex); > +} > + > +void ThreadPThread__InitCondition (char* Root, pthread_mutex_t** Mutex) > +{ > + Common_InitMutex(Root, Mutex, &M3ConditionToPthreadMutex, CleanCondition); > +} > + > #ifdef __cplusplus > } /* extern "C" */ > #endif > > From hendrik at topoi.pooq.com Sat Apr 18 00:02:58 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 17 Apr 2009 18:02:58 -0400 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <0DEE58D2-97B2-4BE3-A5F9-4FAFC326EC68@cs.purdue.edu> References: <200904141656.n3EGuYuZ061174@camembert.async.caltech.edu> <0DEE58D2-97B2-4BE3-A5F9-4FAFC326EC68@cs.purdue.edu> Message-ID: <20090417220257.GB15700@topoi.pooq.com> On Fri, Apr 17, 2009 at 12:54:13PM +1000, Tony Hosking wrote: > > On 15 Apr 2009, at 02:56, Mika Nystrom wrote: > > > > >I agree with what Hendrik says, but what about TYPECASE, ISTYPE, > >NARROW? Those are necessary to make it possible to pass "pointers" > >with the low-order bit set outside of unsafe code. > > > >My feeling is that if Tony can make the necessary changes, it could should > >be done immediately, and the language issues can be pushed to the > >future. But admittedly I'm biased because of the application I'm > >working on. > > I can take care of this next week. I'm in favour of trying it out before freezing the feature. That means going ahead now with an implementation, and reconsidering it in a few months. Perhaps marking it experimental with an appropriate warning message. A few months is little enough time to use it that it won't be traumatic if code that uses the new features has to be partially rewritten. -- hendrik From rcoleburn at scires.com Sat Apr 18 01:07:02 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 17 Apr 2009 19:07:02 -0400 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <20090417220257.GB15700@topoi.pooq.com> References: <200904141656.n3EGuYuZ061174@camembert.async.caltech.edu> <0DEE58D2-97B2-4BE3-A5F9-4FAFC326EC68@cs.purdue.edu> <20090417220257.GB15700@topoi.pooq.com> Message-ID: <49E8D325.1E75.00D7.1@scires.com> There have been a lot of messages flying back and forth on this idea of adding some sort of tagged ref. I'm afraid I've gotten lost on what exactly is being proposed. Can someone please succinctly state the proposal again along with the reasoning behind why it should be done--what does this change enable us to do that we couldn't do before? Based on the messages, I'm not sure that Mika, Tony, Rodney, et al are all saying the same thing. Also, not sure I clued into the significance of the LSB value. Regards, Randy >>> 4/17/2009 6:02 PM >>> On Fri, Apr 17, 2009 at 12:54:13PM +1000, Tony Hosking wrote: > > On 15 Apr 2009, at 02:56, Mika Nystrom wrote: > > > > >I agree with what Hendrik says, but what about TYPECASE, ISTYPE, > >NARROW? Those are necessary to make it possible to pass "pointers" > >with the low-order bit set outside of unsafe code. > > > >My feeling is that if Tony can make the necessary changes, it could should > >be done immediately, and the language issues can be pushed to the > >future. But admittedly I'm biased because of the application I'm > >working on. > > I can take care of this next week. I'm in favour of trying it out before freezing the feature. That means going ahead now with an implementation, and reconsidering it in a few months. Perhaps marking it experimental with an appropriate warning message. A few months is little enough time to use it that it won't be traumatic if code that uses the new features has to be partially rewritten. -- hendrik CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Apr 19 04:58:37 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 18 Apr 2009 19:58:37 -0700 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: Your message of "Fri, 17 Apr 2009 19:07:02 EDT." <49E8D325.1E75.00D7.1@scires.com> Message-ID: <200904190258.n3J2wcfG066701@camembert.async.caltech.edu> Randy, I think Tony and I are on the same page. I've proposed that the runtime and compiler be modified as necessary to allow values of type REFANY to hold, instead of an actual memory reference, an arbitrary (wordsize-1)-bit integer. The necessary changes would only guarantee that the type safety of Modula-3 could not be subverted within any type of safe code by any manipulations involving these new REFANY values. The necessary modifications are pretty limited: a tag check for uses of ISTYPE, NARROW, TYPECASE, and TYPECODE on values known only to be REFANY. Rodney has proposed adding a type constructor (I think that's the right terminology) to permit tagged values as above to be held in variables of type other than REFANY. And our disagreement at this point I think is only on whether REFANY itself should then be allowed to hold the tagged values, as it wouldn't strictly speaking be necessary, but I contend there are good "software engineering" reasons for permitting it. There are several applications for this idea. Think of it as using all those unused values of a reference. My application is to do small integers (a la Smalltalk); Rodney wants to do efficient data structures that can either be small (max 31 bits) or pointers to something bigger. In the former case they wouldn't involve memory allocation or garbage collection. Mika "Randy Coleburn" writes: >This is a MIME message. If you are reading this text, you may want to >consider changing to a mail reader or gateway that understands how to >properly handle MIME multipart messages. > >--=__Part456DE886.0__= >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: quoted-printable > >There have been a lot of messages flying back and forth on this idea of = >adding some sort of tagged ref. I'm afraid I've gotten lost on what = >exactly is being proposed. >=20 >Can someone please succinctly state the proposal again along with the = >reasoning behind why it should be done--what does this change enable us to = >do that we couldn't do before? Based on the messages, I'm not sure that = >Mika, Tony, Rodney, et al are all saying the same thing. >=20 >Also, not sure I clued into the significance of the LSB value. >=20 >Regards, >Randy > >>>> 4/17/2009 6:02 PM >>> >On Fri, Apr 17, 2009 at 12:54:13PM +1000, Tony Hosking wrote: >>=20 >> On 15 Apr 2009, at 02:56, Mika Nystrom wrote: >>=20 >> > >> >I agree with what Hendrik says, but what about TYPECASE, ISTYPE, >> >NARROW? Those are necessary to make it possible to pass "pointers" >> >with the low-order bit set outside of unsafe code. >> > >> >My feeling is that if Tony can make the necessary changes, it could > should >> >be done immediately, and the language issues can be pushed to the >> >future. But admittedly I'm biased because of the application I'm >> >working on. >>=20 >> I can take care of this next week. > >I'm in favour of trying it out before freezing the feature. That=20 >means going ahead now with an implementation, and reconsidering it=20 >in a few months. Perhaps marking it experimental with an appropriate=20 >warning message. A few months is little enough time to use it that it=20 >won't be traumatic if code that uses the new features has to be=20 >partially rewritten. > >-- hendrik > > >CONFIDENTIALITY NOTICE: This email and any attachments are intended = >solely for the use of the named recipient(s). This e-mail may contain = >confidential and/or proprietary information of Scientific Research = >Corporation. If you are not a named recipient, you are prohibited from = >making any use of the information in the email and attachments. If you = >believe you have received this email in error, please notify the sender = >immediately and permanently delete the email, any attachments, and all = >copies thereof from any drives or storage media and destroy any printouts = >of the email or attachments. > >EXPORT COMPLIANCE NOTICE: This email and any attachments may contain = >technical data subject to U.S export restrictions under the International = >Traffic in Arms Regulations (ITAR) or the Export Administration Regulations= > (EAR). Export or transfer of this technical data and/or related = >information to any foreign person(s) or entity(ies), either within the = >U.S. or outside of the U.S., may require export authorization by the = >appropriate U.S. Government agency prior to export or transfer. In = >addition, technical data may not be exported or transferred to certain = >countries or specified designated nationals identified by U.S. embargo = >controls without prior export authorization. By accepting this email and = >any attachments, all recipients confirm that they understand and will = >comply with all applicable ITAR, EAR and embargo compliance requirements. > > >--=__Part456DE886.0__= >Content-Type: text/html; charset=US-ASCII >Content-Transfer-Encoding: quoted-printable >Content-Description: HTML > > >"> > > >
There have been a lot of messages flying back and forth on this idea = >of adding some sort of tagged ref.  I'm afraid I've gotten lost on = >what exactly is being proposed.
>
 
>
Can someone please succinctly state the proposal again along with the = >reasoning behind why it should be done--what does this change enable us to = >do that we couldn't do before?  Based on the messages, I'm not sure = >that Mika, Tony, Rodney, et al are all saying the same thing.
>
 
>
Also, not sure I clued into the significance of the LSB value.
>
 
>
Regards,
>
Randy

>>> <hendrik at topoi.pooq.com> 4/17/2009 = >6:02 PM >>>
On Fri, Apr 17, 2009 at 12:54:13PM +1000, Tony = >Hosking wrote:
>
> On 15 Apr 2009, at 02:56, Mika Nystrom = >wrote:
>
> >
> >I agree with what Hendrik says, = >but what about TYPECASE, ISTYPE,
> >NARROW?  Those are = >necessary to make it possible to pass "pointers"
> >with the = >low-order bit set outside of unsafe code.
> >
> >My = >feeling is that if Tony can make the necessary changes, it could
 &= >nbsp;           &nbs= >p;            &= >nbsp;           &nbs= >p;            &= >nbsp;            = >should
> >be done immediately, and the language issues can be = >pushed to the
> >future.  But admittedly I'm biased because = >of the application I'm
> >working on.
>
> I can take = >care of this next week.

I'm in favour of trying it out before = >freezing the feature.  That
means going ahead now with an = >implementation, and reconsidering it
in a few months.  Perhaps = >marking it experimental with an appropriate
warning message.  A = >few months is little enough time to use it that it
won't be traumatic = >if code that uses the new features has to be
partially rewritten.
R>-- hendrik

> >--=__Part456DE886.0__=-- From hendrik at topoi.pooq.com Mon Apr 20 03:21:29 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 19 Apr 2009 21:21:29 -0400 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: References: Message-ID: <20090420012129.GA22387@topoi.pooq.com> On Fri, Apr 17, 2009 at 10:57:10PM +1000, Tony Hosking wrote: > I am a little concerned about passing REFANY directly to C code as > there is no guarantee that REFANY and C pointers will always be > compatible. ADDRESS can more safely be assumed compatible. Indeed, I once read the X toolkit specs, and it was rife with small integers being packed into pointers. Apparently the toolkit resolved it not by a tag bit, but by its magnitude. There was some constant somewhere that identified which numbers were small enough to be considered not-pointers. This was a discrimination without a tag bit. Similar concept to what we're planning for the future of REFANY, but different implementation. I don't know how they figured out which pointer values were safe to treat as integers. -- hendrik From rodney.m.bates at cox.net Mon Apr 20 04:37:37 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Sun, 19 Apr 2009 21:37:37 -0500 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <49E8D325.1E75.00D7.1@scires.com> References: <200904141656.n3EGuYuZ061174@camembert.async.caltech.edu> <0DEE58D2-97B2-4BE3-A5F9-4FAFC326EC68@cs.purdue.edu> <20090417220257.GB15700@topoi.pooq.com> <49E8D325.1E75.00D7.1@scires.com> Message-ID: <49EBDFF1.2070902@cox.net> Randy Coleburn wrote: > There have been a lot of messages flying back and forth on this idea > of adding some sort of tagged ref. I'm afraid I've gotten lost on > what exactly is being proposed. > > Can someone please succinctly state the proposal again along with the > reasoning behind why it should be done--what does this change enable > us to do that we couldn't do before? The idea is to be able to have a "pointer", but certain values of the pointer actually have the desired data right in the "pointer" itself instead of located in a separate object in the heap. If the actual value is relatively small but common, this can save a _lot_ of overhead. I have an abstract data type module that implements sets of integers that are bounded only by the range of INTEGER, in which, for small sets that actually can fit in one word minus one bit, this technique would save memory words 11-to-one. On a 64-bit machine, the savings measured in bytes would be even bigger, and the likelihood the savings would happen would also be greater. Smalltalk implementations have used this idea. In Smalltalk, there is no static typing at all, so all variables have the same universal type, which, at runtime, can hold any value of any type and be changed with every assignment. For some common values such as false, true, and relatively small integers, the value is stored right in the variable. Otherwise, the variable is a pointer to a heap object. The heap object tells what class it belongs to and has other information about the value. Since heap objects are always aligned at least modulo 2, it follows that a heap pointer always has a zero in the lsb. So a one in the lsb can be used as a flag that says the value is right in the variable. Of course, it will have been shifted left by at least a bit in that case. How Smalltalk makes this look abstractly in the language is another story and a bit tricky. Even with a static typing system in Modula-3, the reference types still have at least 2 lsb's that are always zero in a 32-bit system, where heap objects will always be aligned modulo 4. So the idea is to arrange things so that at least the lsb can be used as a tag to indicate that a value is actually stored in the variable rather than in the heap. We seem to be calling these "tagged" values, and also "small objects". With unsafe code, such values can be created and accessed by bit-twiddling. However, the garbage collector as it stands would undoubtedly be confused by improperly aligned reference type values, when they occur in fields/elements inside heap objects. The GC can presumably be easily fixed to tolerate them. But then, other operations in the language would also be broken. The code for NARROW, ISTYPE, TYPECASE, and assignments that implicitly narrow a value would undoubtedly crash if they got a misaligned value of a supposedly reference type. So such values would have to never be given to these four operations. That undermines the language's principle that the writers of unsafe code can, if they coded everything correctly, ensure that all other (safe) code can't suffer events that are not explainable by the rules of the language. So we really should do a language fix, if we are to do this. > Based on the messages, I'm not sure that Mika, Tony, Rodney, et al are > all saying the same thing. > > Also, not sure I clued into the significance of the LSB value. See above. > > Regards, > Randy > > >>> 4/17/2009 6:02 PM >>> > On Fri, Apr 17, 2009 at 12:54:13PM +1000, Tony Hosking wrote: > > > > On 15 Apr 2009, at 02:56, Mika Nystrom wrote: > > > > > > > >I agree with what Hendrik says, but what about TYPECASE, ISTYPE, > > >NARROW? Those are necessary to make it possible to pass "pointers" > > >with the low-order bit set outside of unsafe code. > > > > > >My feeling is that if Tony can make the necessary changes, it could > should > > >be done immediately, and the language issues can be pushed to the > > >future. But admittedly I'm biased because of the application I'm > > >working on. > > > > I can take care of this next week. > > I'm in favour of trying it out before freezing the feature. That > means going ahead now with an implementation, and reconsidering it > in a few months. Perhaps marking it experimental with an appropriate > warning message. A few months is little enough time to use it that it > won't be traumatic if code that uses the new features has to be > partially rewritten. > > -- hendrik > From rodney.m.bates at cox.net Mon Apr 20 04:45:49 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Sun, 19 Apr 2009 21:45:49 -0500 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: <20090420012129.GA22387@topoi.pooq.com> References: <20090420012129.GA22387@topoi.pooq.com> Message-ID: <49EBE1DD.6080809@cox.net> hendrik at topoi.pooq.com wrote: > On Fri, Apr 17, 2009 at 10:57:10PM +1000, Tony Hosking wrote: > >> I am a little concerned about passing REFANY directly to C code as >> there is no guarantee that REFANY and C pointers will always be >> compatible. ADDRESS can more safely be assumed compatible. >> > > Indeed, I once read the X toolkit specs, and it was rife with small > integers being packed into pointers. Apparently the toolkit resolved > it not by a tag bit, but by its magnitude. There was some constant > somewhere that identified which numbers were small enough to be > considered not-pointers. > > This was a discrimination without a tag bit. Similar concept to what > we're planning for the future of REFANY, but different implementation. > > I don't know how they figured out which pointer values were safe to > treat as integers. > In my more elaborate "safe" proposal, at least, the language itself does not specify anything about what the bit-encodings of tagged types are. It's an implementors' option, and the language can support whatever the implementors choose. This could be used to match the X toolkit's encoding. However, using the lsb takes advantage of the fact that heap objects must always be aligned and thus the lsb is already always zero, when it's really a heap pointer. That seems like by far the most efficient encoding. > -- hendrik > > > From jay.krell at cornell.edu Mon Apr 20 05:31:27 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 20 Apr 2009 03:31:27 +0000 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: <49EBE1DD.6080809@cox.net> References: <20090420012129.GA22387@topoi.pooq.com> <49EBE1DD.6080809@cox.net> Message-ID: Um..you know..if you just use ADDRESS instead of REFANY, doesn't that get you what you need, with no language/compiler/runtime changes? Can't you check the low bit of the address and only if it is zero, assign it to a REFANY, and that party (NARROW/ISTYPE/etc.) on the REFANY? Otherwise LOOPHOLE the ADDRESS to an INTEGER and shift it right by one? There is danger here no matter what. Who says heap pointers need any alignment? On most machines they are aligned, but on most machines (x86, AMD64) they don't need to be. x86/AMD64 may have an option for triggering "alignment exceptions" in the hardware, but I don't think any OS ever enables it. And I doubt that any application can. On Windows when dealing with "resources" (strings, bitmaps, etc., same notion as Apple), anything under 64K is considered a small integer. This gives you a system where resources can be efficiently identified by small integers, and you need to coordinate with all contributors of resources to a particular file, or less efficiently but more flexibily use strings and less/no coordination is needed. It's a nice compromise. Very little code relies on the alignment of pointers. It is a "special purpose" kind of thing. Very little code makes these "policy" decisions either. On most machines, the pointer NULL is made invalid at the hardware level by making the first page inaccessible. On most machines, a page is at least 4K. On many machines it is larger, or even variably sized. Going further and always reserving the first 64K of address space is not a big waste. It's not physical memory, it's "just" address space. (It does cost something, but not much; it costs you some reduced capacity) There is danger here no matter what but also a lot of efficiency to be gained in some scenarios. On most machines you can probably take more than 1 bit. On NT the heap allocator aligns to "two pointers", so that gives you 3 (32bit) or 4 (64bit) bits. But that's just for typical code. Modula-3 usually allocates with mmap/sbrk/VirtualAlloc, giving it at least 4K alignment, probably in reality something larger like 64K. It is the under its control to subdivide that as it sees fit. So you could arbitrarily decree that all Modula-3 objects are aligned at say 32 bytes and have 5 tag bits. It's just that at some point you start wasting space. Allocating a bunch of 10 byte objects with 32 byte alignment wastes a lot of space. But allocating a bunch of 32 or 64 or 96 etc., byte objects with 32 byte alignment wastes nothing.. On NT as well, historically, the address space was split in two. (It still is split, but details vary). The upper bit was zero for usermode, one for kernelmode. Therefore, historically, another avenue this proposal could take is to use the high bit for a tag bit. Assuming nobody is writing drivers in kernel mode. However, this 2gig/2gig split can be constraining on usermode (and kernelmode..). So there is an option at boot-time to make it 3gig/1gig -- 3gig user mode, 1 gig usermode. However that breaks any code that uses the high bit as a tag bit. Therefore executables (.exes, not .dlls) have a flag in them to indicate if they are "large address aware". If they are not, even if you boot /3gig, you still, I guess, won't ever see addresses over 2gig. If you are using tag bits, it then becomes that the upper two bits are: 00: definitely usermode 01: ambiguous 10: definitely kernelmode (can be used as a 30 bit integer) 11: definitely kernelmode (can be used as a 30 bit integer) However if you run a "large address aware" 32bit executable on a 64bit system, you get all 4gig as usermode. The kernelmode addresses are even higher than 4gig and you can't even encode them in a 32bit usermode address, which is fine. It becomes that all addresses are usermode. (This is a little mind-bending at first). Using a small struct with a type tag (possibly an entire pointer) and a separate data word also seems very viable. Very portable, very safe. Just that it grows the representation. - Jay ---------------------------------------- > Date: Sun, 19 Apr 2009 21:45:49 -0500 > From: rodney.m.bates at cox.net > To: m3devel at elegosoft.com > Subject: Re: [M3devel] fewer wrappers/more C? (or a wash?) > > hendrik at topoi.pooq.com wrote: >> On Fri, Apr 17, 2009 at 10:57:10PM +1000, Tony Hosking wrote: >> >>> I am a little concerned about passing REFANY directly to C code as >>> there is no guarantee that REFANY and C pointers will always be >>> compatible. ADDRESS can more safely be assumed compatible. >>> >> >> Indeed, I once read the X toolkit specs, and it was rife with small >> integers being packed into pointers. Apparently the toolkit resolved >> it not by a tag bit, but by its magnitude. There was some constant >> somewhere that identified which numbers were small enough to be >> considered not-pointers. >> >> This was a discrimination without a tag bit. Similar concept to what >> we're planning for the future of REFANY, but different implementation. >> >> I don't know how they figured out which pointer values were safe to >> treat as integers. >> > In my more elaborate "safe" proposal, at least, the language itself > does not specify anything about what the bit-encodings of tagged > types are. It's an implementors' option, and the language > can support whatever the implementors choose. > > This could be used to match the X toolkit's encoding. However, > using the lsb takes advantage of the fact that heap objects must > always be aligned and thus the lsb is already always zero, when > it's really a heap pointer. That seems like by far the most efficient > encoding. >> -- hendrik >> >> >> > From hosking at cs.purdue.edu Mon Apr 20 05:34:15 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 20 Apr 2009 13:34:15 +1000 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: References: <20090420012129.GA22387@topoi.pooq.com> <49EBE1DD.6080809@cox.net> Message-ID: <3130252C-D715-4C35-8F20-5D6BAB71B523@cs.purdue.edu> The proposal that Mika and I have converged on doesn't require language changes. And it works with ISTYPE, etc. Confusing REFANY with ADDRESS is a swamp. On 20 Apr 2009, at 13:31, Jay wrote: > > > Um..you know..if you just use ADDRESS instead of REFANY, doesn't > that get you what you need, with no language/compiler/runtime changes? > > Can't you check the low bit of the address and only if it is zero, > assign it to a REFANY, and that party (NARROW/ISTYPE/etc.) on the > REFANY? Otherwise LOOPHOLE the ADDRESS to an INTEGER and shift it > right by one? > > > > > There is danger here no matter what. > > > Who says heap pointers need any alignment? > > > On most machines they are aligned, but on most machines (x86, AMD64) > they don't need to be. x86/AMD64 may have an option for triggering > "alignment exceptions" in the hardware, but I don't think any OS > ever enables it. And I doubt that any application can. > > > On Windows when dealing with "resources" (strings, bitmaps, etc., > same notion as Apple), anything under 64K is considered a small > integer. > This gives you a system where resources can be efficiently > identified by small integers, and you need to coordinate with all > contributors of resources to a particular file, or less efficiently > but more flexibily use strings and less/no coordination is needed. > It's a nice compromise. > > > Very little code relies on the alignment of pointers. > It is a "special purpose" kind of thing. > > > Very little code makes these "policy" decisions either. > > > On most machines, the pointer NULL is made invalid at the hardware > level by making the first page inaccessible. On most machines, a > page is at least 4K. On many machines it is larger, or even variably > sized. > Going further and always reserving the first 64K of address space is > not a big waste. > It's not physical memory, it's "just" address space. (It does cost > something, but not much; it costs you some reduced capacity) > > > There is danger here no matter what but also a lot of efficiency to > be gained in some scenarios. > > > On most machines you can probably take more than 1 bit. > > > On NT the heap allocator aligns to "two pointers", so that gives you > 3 (32bit) or 4 (64bit) bits. But that's just for typical code. > Modula-3 usually allocates with mmap/sbrk/VirtualAlloc, giving it at > least 4K alignment, probably in reality something larger like 64K. > It is the under its control to subdivide that as it sees fit. > So you could arbitrarily decree that all Modula-3 objects are > aligned at say 32 bytes and have 5 tag bits. It's just that at some > point you start wasting space. Allocating a bunch of 10 byte objects > with 32 byte alignment wastes a lot of space. But allocating a bunch > of 32 or 64 or 96 etc., byte objects with 32 byte alignment wastes > nothing.. > > > On NT as well, historically, the address space was split in two. > (It still is split, but details vary). > The upper bit was zero for usermode, one for kernelmode. > Therefore, historically, another avenue this proposal could take is > to use the high bit for a tag bit. Assuming nobody is writing > drivers in kernel mode. > > > However, this 2gig/2gig split can be constraining on usermode (and > kernelmode..). > So there is an option at boot-time to make it 3gig/1gig -- 3gig user > mode, 1 gig usermode. > However that breaks any code that uses the high bit as a tag bit. > Therefore executables (.exes, not .dlls) have a flag in them to > indicate if they are "large address aware". If they are not, even if > you boot /3gig, you still, I guess, won't ever see addresses over > 2gig. > If you are using tag bits, it then becomes that the upper two bits > are: > 00: definitely usermode > 01: ambiguous > 10: definitely kernelmode (can be used as a 30 bit integer) > 11: definitely kernelmode (can be used as a 30 bit integer) > > > However if you run a "large address aware" 32bit executable on a > 64bit system, you get all 4gig as usermode. The kernelmode addresses > are even higher than 4gig and you can't even encode them in a 32bit > usermode address, which is fine. It becomes that all addresses are > usermode. (This is a little mind-bending at first). > > > Using a small struct with a type tag (possibly an entire pointer) > and a separate data word also seems very viable. Very portable, very > safe. Just that it grows the representation. > > > - Jay > > > > ---------------------------------------- >> Date: Sun, 19 Apr 2009 21:45:49 -0500 >> From: rodney.m.bates at cox.net >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] fewer wrappers/more C? (or a wash?) >> >> hendrik at topoi.pooq.com wrote: >>> On Fri, Apr 17, 2009 at 10:57:10PM +1000, Tony Hosking wrote: >>> >>>> I am a little concerned about passing REFANY directly to C code as >>>> there is no guarantee that REFANY and C pointers will always be >>>> compatible. ADDRESS can more safely be assumed compatible. >>>> >>> >>> Indeed, I once read the X toolkit specs, and it was rife with small >>> integers being packed into pointers. Apparently the toolkit resolved >>> it not by a tag bit, but by its magnitude. There was some constant >>> somewhere that identified which numbers were small enough to be >>> considered not-pointers. >>> >>> This was a discrimination without a tag bit. Similar concept to what >>> we're planning for the future of REFANY, but different >>> implementation. >>> >>> I don't know how they figured out which pointer values were safe to >>> treat as integers. >>> >> In my more elaborate "safe" proposal, at least, the language itself >> does not specify anything about what the bit-encodings of tagged >> types are. It's an implementors' option, and the language >> can support whatever the implementors choose. >> >> This could be used to match the X toolkit's encoding. However, >> using the lsb takes advantage of the fact that heap objects must >> always be aligned and thus the lsb is already always zero, when >> it's really a heap pointer. That seems like by far the most efficient >> encoding. >>> -- hendrik >>> >>> >>> >> From jay.krell at cornell.edu Mon Apr 20 05:36:38 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 20 Apr 2009 03:36:38 +0000 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: References: <20090420012129.GA22387@topoi.pooq.com> <49EBE1DD.6080809@cox.net> Message-ID: > Assuming nobody is writing drivers in kernel mode. I meant, "in Modula-3". Even so, the runtime could discover the tag bits at initialization time. Or more efficiently, the runtime could be built twice. But the variations available make the high bit or bits as a tag not really viable. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: rodney.m.bates at cox.net; m3devel at elegosoft.com > Date: Mon, 20 Apr 2009 03:31:27 +0000 > Subject: Re: [M3devel] fewer wrappers/more C? (or a wash?) > > > > Um..you know..if you just use ADDRESS instead of REFANY, doesn't that get you what you need, with no language/compiler/runtime changes? > > Can't you check the low bit of the address and only if it is zero, assign it to a REFANY, and that party (NARROW/ISTYPE/etc.) on the REFANY? Otherwise LOOPHOLE the ADDRESS to an INTEGER and shift it right by one? > > > > > There is danger here no matter what. > > > Who says heap pointers need any alignment? > > > On most machines they are aligned, but on most machines (x86, AMD64) they don't need to be. x86/AMD64 may have an option for triggering "alignment exceptions" in the hardware, but I don't think any OS ever enables it. And I doubt that any application can. > > > On Windows when dealing with "resources" (strings, bitmaps, etc., same notion as Apple), anything under 64K is considered a small integer. > This gives you a system where resources can be efficiently identified by small integers, and you need to coordinate with all contributors of resources to a particular file, or less efficiently but more flexibily use strings and less/no coordination is needed. It's a nice compromise. > > > Very little code relies on the alignment of pointers. > It is a "special purpose" kind of thing. > > > Very little code makes these "policy" decisions either. > > > On most machines, the pointer NULL is made invalid at the hardware level by making the first page inaccessible. On most machines, a page is at least 4K. On many machines it is larger, or even variably sized. > Going further and always reserving the first 64K of address space is not a big waste. > It's not physical memory, it's "just" address space. (It does cost something, but not much; it costs you some reduced capacity) > > > There is danger here no matter what but also a lot of efficiency to be gained in some scenarios. > > > On most machines you can probably take more than 1 bit. > > > On NT the heap allocator aligns to "two pointers", so that gives you 3 (32bit) or 4 (64bit) bits. But that's just for typical code. Modula-3 usually allocates with mmap/sbrk/VirtualAlloc, giving it at least 4K alignment, probably in reality something larger like 64K. It is the under its control to subdivide that as it sees fit. > So you could arbitrarily decree that all Modula-3 objects are aligned at say 32 bytes and have 5 tag bits. It's just that at some point you start wasting space. Allocating a bunch of 10 byte objects with 32 byte alignment wastes a lot of space. But allocating a bunch of 32 or 64 or 96 etc., byte objects with 32 byte alignment wastes nothing.. > > > On NT as well, historically, the address space was split in two. > (It still is split, but details vary). > The upper bit was zero for usermode, one for kernelmode. > Therefore, historically, another avenue this proposal could take is to use the high bit for a tag bit. Assuming nobody is writing drivers in kernel mode. > > > However, this 2gig/2gig split can be constraining on usermode (and kernelmode..). > So there is an option at boot-time to make it 3gig/1gig -- 3gig user mode, 1 gig usermode. > However that breaks any code that uses the high bit as a tag bit. > Therefore executables (.exes, not .dlls) have a flag in them to indicate if they are "large address aware". If they are not, even if you boot /3gig, you still, I guess, won't ever see addresses over 2gig. > If you are using tag bits, it then becomes that the upper two bits are: > 00: definitely usermode > 01: ambiguous > 10: definitely kernelmode (can be used as a 30 bit integer) > 11: definitely kernelmode (can be used as a 30 bit integer) > > > However if you run a "large address aware" 32bit executable on a 64bit system, you get all 4gig as usermode. The kernelmode addresses are even higher than 4gig and you can't even encode them in a 32bit usermode address, which is fine. It becomes that all addresses are usermode. (This is a little mind-bending at first). > > > Using a small struct with a type tag (possibly an entire pointer) and a separate data word also seems very viable. Very portable, very safe. Just that it grows the representation. > > > - Jay > > > > ---------------------------------------- >> Date: Sun, 19 Apr 2009 21:45:49 -0500 >> From: rodney.m.bates at cox.net >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] fewer wrappers/more C? (or a wash?) >> >> hendrik at topoi.pooq.com wrote: >>> On Fri, Apr 17, 2009 at 10:57:10PM +1000, Tony Hosking wrote: >>> >>>> I am a little concerned about passing REFANY directly to C code as >>>> there is no guarantee that REFANY and C pointers will always be >>>> compatible. ADDRESS can more safely be assumed compatible. >>>> >>> >>> Indeed, I once read the X toolkit specs, and it was rife with small >>> integers being packed into pointers. Apparently the toolkit resolved >>> it not by a tag bit, but by its magnitude. There was some constant >>> somewhere that identified which numbers were small enough to be >>> considered not-pointers. >>> >>> This was a discrimination without a tag bit. Similar concept to what >>> we're planning for the future of REFANY, but different implementation. >>> >>> I don't know how they figured out which pointer values were safe to >>> treat as integers. >>> >> In my more elaborate "safe" proposal, at least, the language itself >> does not specify anything about what the bit-encodings of tagged >> types are. It's an implementors' option, and the language >> can support whatever the implementors choose. >> >> This could be used to match the X toolkit's encoding. However, >> using the lsb takes advantage of the fact that heap objects must >> always be aligned and thus the lsb is already always zero, when >> it's really a heap pointer. That seems like by far the most efficient >> encoding. >>> -- hendrik >>> >>> >>> >> From jay.krell at cornell.edu Mon Apr 20 05:46:30 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 20 Apr 2009 03:46:30 +0000 Subject: [M3devel] explanation of CheckLoadTracedRef? Message-ID: - What does CheckLoadTracedRef and co. do? - Can the compiler be smarter? Easily/effectively? I'm just reading code to understand the object model.. and I see like this: b.F1(1); (* line 60 *) b.F2(2); .stabn 68,0,60,LM17-LFBB2 (",60," means line 60) LM17: movl _MM_Main+584, %esi testl %esi, %esi je L13 testb $64, -2(%esi) je L13 movl %esi, (%esp) call _RTHooks__CheckLoadTracedRef L13: movl (%esi), %eax movl (%eax), %ebx movl $1, 4(%esp) movl %esi, (%esp) call *%ebx .stabn 68,0,61,LM18-LFBB2 (",61," means line 61) LM18: movl _MM_Main+584, %ebx testl %ebx, %ebx je L14 testb $64, -2(%ebx) je L14 movl %ebx, (%esp) call _RTHooks__CheckLoadTracedRef L14: movl (%ebx), %eax movl 4(%eax), %esi movl $2, 4(%esp) movl %ebx, (%esp) call *%esi Does one really need to "check" pointers so often? You know, like twice in a row? Granted, there is a call in between. I understand, that one call could have done "anything". Ok, here is another case cm3 -O, cm3cg -O3, no intervening function call, still two checks: T3 = OBJECT a: INTEGER; END; c := NEW(T3); RTIO.PutInt(c.a + c.a); .stabn 68,0,63,LM20-LFBB2 LM20: movl _MM_Main+588, %esi testl %esi, %esi je L15 testb $64, -2(%esi) je L15 movl %esi, (%esp) call _RTHooks__CheckLoadTracedRef L15: movl _MM_Main+588, %ebx testl %ebx, %ebx je L16 testb $64, -2(%ebx) je L16 movl %ebx, (%esp) call _RTHooks__CheckLoadTracedRef L16: movl $0, 4(%esp) movl 4(%ebx), %eax addl 4(%esi), %eax movl %eax, (%esp) call _RTIO__PutInt I'm of two minds on optimizing though. Do it. Don't it. I don't like debugging optimize code. Nor do I want to waste time having the compiler make the code less debuggable. But when I look at the code and how bad the code quality is, and that it could be substantially better without sacrificing debuging... This example is somewhat contrived, but the code seems like 33% waste. Eventually that much bloat is going to cost in terms of I/O in the assembly, linker, paging it in at runtime, and even a little extra to run it. "Now that I understand things somewhat better.." How bad/unportable was it the previous way, the VM-synchronized way? Can the checks only be generated for calls to extern functions? When I write C wrappers, am I missing checks? (I can check, maybe the checks are generated). Are they missing sometimes with regard to X Windows? I think I understand just barely some of what is going on. That writes through pointers need to be checked. Because objects can move around. But moving objects doesn't update the references, but instead marks pages as different? (In the VM-synchronized world, moving an object would mark its original page invalid, triggering a page fault upon subsequent access, which is handled by referencing the new location and maybe updating the old pointer). ??? Something like that ??? - Jay From jay.krell at cornell.edu Mon Apr 20 05:48:00 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 20 Apr 2009 03:48:00 +0000 Subject: [M3devel] explanation of CheckLoadTracedRef? Message-ID: - What does CheckLoadTracedRef and co. do? - Can the compiler be smarter? Easily/effectively? I'm just reading code to understand the object model.. and I see like this: b.F1(1); (* line 60 *) b.F2(2); .stabn 68,0,60,LM17-LFBB2 (",60," means line 60) LM17: movl _MM_Main+584, %esi testl %esi, %esi je L13 testb $64, -2(%esi) je L13 movl %esi, (%esp) call _RTHooks__CheckLoadTracedRef L13: movl (%esi), %eax movl (%eax), %ebx movl $1, 4(%esp) movl %esi, (%esp) call *%ebx .stabn 68,0,61,LM18-LFBB2 (",61," means line 61) LM18: movl _MM_Main+584, %ebx testl %ebx, %ebx je L14 testb $64, -2(%ebx) je L14 movl %ebx, (%esp) call _RTHooks__CheckLoadTracedRef L14: movl (%ebx), %eax movl 4(%eax), %esi movl $2, 4(%esp) movl %ebx, (%esp) call *%esi Does one really need to "check" pointers so often? You know, like twice in a row? Granted, there is a call in between. I understand, that one call could have done "anything". Ok, here is another case cm3 -O, cm3cg -O3, no intervening function call, still two checks: T3 = OBJECT a: INTEGER; END; c := NEW(T3); RTIO.PutInt(c.a + c.a); .stabn 68,0,63,LM20-LFBB2 LM20: movl _MM_Main+588, %esi testl %esi, %esi je L15 testb $64, -2(%esi) je L15 movl %esi, (%esp) call _RTHooks__CheckLoadTracedRef L15: movl _MM_Main+588, %ebx testl %ebx, %ebx je L16 testb $64, -2(%ebx) je L16 movl %ebx, (%esp) call _RTHooks__CheckLoadTracedRef L16: movl $0, 4(%esp) movl 4(%ebx), %eax addl 4(%esi), %eax movl %eax, (%esp) call _RTIO__PutInt I'm of two minds on optimizing though. Do it. Don't it. I don't like debugging optimize code. Nor do I want to waste time having the compiler make the code less debuggable. But when I look at the code and how bad the code quality is, and that it could be substantially better without sacrificing debuging... This example is somewhat contrived, but the code seems like 33% waste. Eventually that much bloat is going to cost in terms of I/O in the assembly, linker, paging it in at runtime, and even a little extra to run it. "Now that I understand things somewhat better.." How bad/unportable was it the previous way, the VM-synchronized way? Can the checks only be generated for calls to extern functions? When I write C wrappers, am I missing checks? (I can check, maybe the checks are generated). Are they missing sometimes with regard to X Windows? I think I understand just barely some of what is going on. That writes through pointers need to be checked. Because objects can move around. But moving objects doesn't update the references, but instead marks pages as different? (In the VM-synchronized world, moving an object would mark its original page invalid, triggering a page fault upon subsequent access, which is handled by referencing the new location and maybe updating the old pointer). ??? Something like that ??? - Jay From jay.krell at cornell.edu Mon Apr 20 05:47:09 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 20 Apr 2009 03:47:09 +0000 Subject: [M3devel] explanation of CheckLoadTracedRef? Message-ID: - What does CheckLoadTracedRef and co. do? - Can the compiler be smarter? Easily/effectively? I'm just reading code to understand the object model.. and I see like this: b.F1(1); (* line 60 *) b.F2(2); .stabn 68,0,60,LM17-LFBB2 (",60," means line 60) LM17: movl _MM_Main+584, %esi testl %esi, %esi je L13 testb $64, -2(%esi) je L13 movl %esi, (%esp) call _RTHooks__CheckLoadTracedRef L13: movl (%esi), %eax movl (%eax), %ebx movl $1, 4(%esp) movl %esi, (%esp) call *%ebx .stabn 68,0,61,LM18-LFBB2 (",61," means line 61) LM18: movl _MM_Main+584, %ebx testl %ebx, %ebx je L14 testb $64, -2(%ebx) je L14 movl %ebx, (%esp) call _RTHooks__CheckLoadTracedRef L14: movl (%ebx), %eax movl 4(%eax), %esi movl $2, 4(%esp) movl %ebx, (%esp) call *%esi Does one really need to "check" pointers so often? You know, like twice in a row? Granted, there is a call in between. I understand, that one call could have done "anything". Ok, here is another case cm3 -O, cm3cg -O3, no intervening function call, still two checks: T3 = OBJECT a: INTEGER; END; c := NEW(T3); RTIO.PutInt(c.a + c.a); .stabn 68,0,63,LM20-LFBB2 LM20: movl _MM_Main+588, %esi testl %esi, %esi je L15 testb $64, -2(%esi) je L15 movl %esi, (%esp) call _RTHooks__CheckLoadTracedRef L15: movl _MM_Main+588, %ebx testl %ebx, %ebx je L16 testb $64, -2(%ebx) je L16 movl %ebx, (%esp) call _RTHooks__CheckLoadTracedRef L16: movl $0, 4(%esp) movl 4(%ebx), %eax addl 4(%esi), %eax movl %eax, (%esp) call _RTIO__PutInt I'm of two minds on optimizing though. Do it. Don't it. I don't like debugging optimize code. Nor do I want to waste time having the compiler make the code less debuggable. But when I look at the code and how bad the code quality is, and that it could be substantially better without sacrificing debuging... This example is somewhat contrived, but the code seems like 33% waste. Eventually that much bloat is going to cost in terms of I/O in the assembly, linker, paging it in at runtime, and even a little extra to run it. "Now that I understand things somewhat better.." How bad/unportable was it the previous way, the VM-synchronized way? Can the checks only be generated for calls to extern functions? When I write C wrappers, am I missing checks? (I can check, maybe the checks are generated). Are they missing sometimes with regard to X Windows? I think I understand just barely some of what is going on. That writes through pointers need to be checked. Because objects can move around. But moving objects doesn't update the references, but instead marks pages as different? (In the VM-synchronized world, moving an object would mark its original page invalid, triggering a page fault upon subsequent access, which is handled by referencing the new location and maybe updating the old pointer). ??? Something like that ??? - Jay From hosking at cs.purdue.edu Mon Apr 20 06:55:13 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 20 Apr 2009 14:55:13 +1000 Subject: [M3devel] explanation of CheckLoadTracedRef? In-Reply-To: References: Message-ID: On 20 Apr 2009, at 13:47, Jay wrote: > > > - What does CheckLoadTracedRef and co. do? It makes sure that when loading a reference from the heap we make sure that reference is black (i.e., not gray). The invariant is that mutator threads should never be exposed to pointers to old space while the incrememtal collector is executing. > - Can the compiler be smarter? It's tricky. We'd like to eliminate two checks on the same field. So long as we can ensure that no GC flip occurs between the first check and the second then yes. If not then we must keep both checks. > Easily/effectively? > I'm just reading code to understand the object model.. > and I see like this: > b.F1(1); (* line 60 *) > b.F2(2); > > > > .stabn 68,0,60,LM17-LFBB2 (",60," means line 60) > LM17: > movl _MM_Main+584, %esi > testl %esi, %esi > je L13 > testb $64, -2(%esi) > je L13 > movl %esi, (%esp) > call _RTHooks__CheckLoadTracedRef > L13: > movl (%esi), %eax > movl (%eax), %ebx > movl $1, 4(%esp) > movl %esi, (%esp) > call *%ebx > .stabn 68,0,61,LM18-LFBB2 (",61," means line 61) > LM18: > movl _MM_Main+584, %ebx > testl %ebx, %ebx > je L14 > testb $64, -2(%ebx) > je L14 > movl %ebx, (%esp) > call _RTHooks__CheckLoadTracedRef > L14: > movl (%ebx), %eax > movl 4(%eax), %esi > movl $2, 4(%esp) > movl %ebx, (%esp) > call *%esi > > > Does one really need to "check" pointers so often? > You know, like twice in a row? > Granted, there is a call in between. > I understand, that one call could have done "anything". > > > Ok, here is another case cm3 -O, cm3cg -O3, no intervening function > call, still two checks: > > > T3 = OBJECT > a: INTEGER; > END; > > > c := NEW(T3); > > > RTIO.PutInt(c.a + c.a); > > > .stabn 68,0,63,LM20-LFBB2 > LM20: > movl _MM_Main+588, %esi > testl %esi, %esi > je L15 > testb $64, -2(%esi) > je L15 > movl %esi, (%esp) > call _RTHooks__CheckLoadTracedRef > L15: > movl _MM_Main+588, %ebx > testl %ebx, %ebx > je L16 > testb $64, -2(%ebx) > je L16 > movl %ebx, (%esp) > call _RTHooks__CheckLoadTracedRef > L16: > movl $0, 4(%esp) > movl 4(%ebx), %eax > addl 4(%esi), %eax > movl %eax, (%esp) > call _RTIO__PutInt > > > I'm of two minds on optimizing though. > Do it. Don't it. > > I don't like debugging optimize code. > Nor do I want to waste time having the compiler make the code less > debuggable. > But when I look at the code and how bad the code quality is, and > that it could be substantially > better without sacrificing debuging... > > > This example is somewhat contrived, but the code seems like 33% waste. > Eventually that much bloat is going to cost in terms of I/O in the > assembly, linker, > paging it in at runtime, and even a little extra to run it. It would be useful to see what the overhead actually is. You can do this by changing Host.doIncGC to FALSE instead of TRUE in m3front. There is a flag that will do this: -NoIncGC. I forget how we actually pass those flags to the front-end from m3build. I think something like: M3Option("-NoIncGC") > "Now that I understand things somewhat better.." > How bad/unportable was it the previous way, the VM-synchronized way? Not compatible with system threading. > Can the checks only be generated for calls to extern functions? Huh? Not pertinent. > When I write C wrappers, am I missing checks? > (I can check, maybe the checks are generated). > Are they missing sometimes with regard to X Windows? You should *never* access a field in the heap in C code! All accesses to traced fields in the heap must take place in Modula-3. Otherwise things will break! C wrappers should not do anything other than forward calls to C library calls. They should not perform heap accesses. > I think I understand just barely some of what is going on. > That writes through pointers need to be checked. Yes, writes of references to traced fields in the heap need the checks too for generational GC. > Because objects can move around. > But moving objects doesn't update the references, but instead > marks pages as different? (In the VM-synchronized world, > moving an object would mark its original page invalid, triggering > a page fault upon subsequent access, which is handled by referencing > the new location and maybe updating the old pointer). I think you are confusing incremental and incremental GC. > > > > ??? Something like that ??? > > > - Jay From jay.krell at cornell.edu Mon Apr 20 10:47:21 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 20 Apr 2009 08:47:21 +0000 Subject: [M3devel] crummy ThreadWin32.m3 implementation? Message-ID: Um, ThreadWin32.m3 looks pretty crummy -- all LockMutex calls bottleneck on one giant lock. .v0 and .v1 aren't bad this way. - Jay From jay.krell at cornell.edu Mon Apr 20 11:11:17 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 20 Apr 2009 09:11:17 +0000 Subject: [M3devel] crummy ThreadWin32.m3 implementation? In-Reply-To: References: Message-ID: Searching the web...finds this which seems very relevant: http://birrell.org/andrew/papers/ImplementingCVs.pdf - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 20 Apr 2009 08:47:21 +0000 > Subject: [M3devel] crummy ThreadWin32.m3 implementation? > > > Um, ThreadWin32.m3 looks pretty crummy -- all LockMutex calls bottleneck on one giant lock. .v0 and .v1 aren't bad this way. > > > - Jay From rodney.m.bates at cox.net Mon Apr 20 15:35:02 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 20 Apr 2009 08:35:02 -0500 Subject: [M3devel] Resummary of tagged reference proposals Message-ID: <49EC7A06.5040403@cox.net> I am going to try to resummarize the various proposals, as their description has now gotten rather scattered around in all the discussion. --------------------------------------------------------------------- Mika's proposal (I'll call it the "minimalist" propsal): Mika, please correct me if I misrepresent what you are proposing. There are no language changes at all, only changes in implementation. The implementation of the existing type REFANY, and no other type, allows it to have values whose lsb is nonzero. ISTYPE, NARROW, TYPECASE, and narrowing assignments, when and only when applied to REFANY, have their generated code fixed so it checks the lsb, and, if it is nonzero, consider the runtime type check to have failed, in whichever way such a failure is already handled. The only effect is to liberalize the rules unsafe code must follow to avoid undermining the safety of safe code. Only unsafe code can create or detect these misaligned values. Today, it must never return them in a variable of any reference type, lest the four narrowing operations unexpectedly crash. In the proposal, unsafe code would be able to return such values in variables of type REFANY, but not any other type. Already, the only things safe code can do with values of REFANY are copy them around (which would happily work on misaligned values) and narrow them. With the implementation of the narrowing operations changed, misaligned values can never escape from REFANY variables. In safe code, there is no way to detect whether a value of type REFANY is misaligned. Doing it by elimination, trying to narrow to any proper subtype of REFANY, is impractical, as there are an unbounded number of REF types to eliminate. If there is more than one abstract data type that uses this mechanism, client code can not be prevented from mixing up values from the different abstractions. (Perhaps this could be fixed by a language change allowing BRANDED REFANY?) --------------------------------------------------------------------- My (Rodney's) "safe" proposal: There is a new type named TAGABLE. It is a subrange of INTEGER, whose bounds are implementation-defined. These can be queried by the existing FIRST and LAST functions. Similar to CARDINAL, it has all the properties of a subrange type but is not the same type as the corresponding subrange. There is a new type constructor TAGGED. If T is any traced or object type, including branded and opaque types, then TAGGED T is a new type whose value set is the union of the value sets of T and TAGABLE. Moreover, TAGABLE <: TAGGED T T <: TAGGED T. IF T # U, then TAGGED T and TAGGED U are not the same type and have no subtype or assignability relation to each other. The semantics of ISTYPE, NARROW, TYPECASE, and assignability of a type to a type are generalized so that their to-be-narrowed operand can have a tagged type, and if it does, their to-be-narrowed-to type can be TAGABLE. Comments: Making TAGGED T have no relation to TAGGED U avoids a lot of really complicated type equality and subtype rules. The former would be a drastic departure from the current state of Modula-3. It is up to the implementation to decide the bit representation of tagged types, including how values of TAGABLE will be distinguished from reference values. Though the language would not require it, most likely a word the same size as a pointer will be used. Using the lsb as the tag bit is an efficient encoding, because in any currently conceivable machine, it will be zero for all pointers to heap objects. There is no reason pickles would have to use the same representation as compiler-generated code. The implementation should define the bounds of TAGABLE to be whatever it can fit in its representation, after removing the values that are true pointers. If the lsb is used as a tag, this will no doubt be a 31-bit integer on a 32-bit machine and 63-bit integer on a 64-bit machine. The language wouldn't even specify whether it is signed, although somehow unsigned seems nice to me. If it is unsigned and the suggested encodings are used, TAGABLE would have the same bounds as CARDINAL, but it really should be a separate type, so as not to overconstrain the implementation. If T is branded, then the effects of branding will propagate to TAGGED T, thus allowing independent abstract data types to ensure each one's values can't be mixed up with the other's. This will statically detect misuses by client code. However, TAGGED T is not a branded type. If T is an opaque type, then TAGGED T can be used to combine the space efficiency of tagging with the ability of an opaque type to reveal some but not all of its properties. To use this, client code will have to narrow a value first, since access to methods/fields could not have a definable meaning for a value in TAGABLE. On the other hand, T could be an opaque subtype of REFANY, thus revealing almost nothing about TAGGED T to clients. This would give tagged types the existing ability of ensuring statically, that the code in a revealed context will never get TAGGED REFANY, thus avoiding extra runtime type checks. From rodney.m.bates at cox.net Mon Apr 20 16:06:12 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 20 Apr 2009 09:06:12 -0500 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: References: <20090420012129.GA22387@topoi.pooq.com> <49EBE1DD.6080809@cox.net> Message-ID: <49EC8154.20909@cox.net> Jay wrote: > > Um..you know..if you just use ADDRESS instead of REFANY, doesn't that get you what you need, with no language/compiler/runtime changes? > > Can't you check the low bit of the address and only if it is zero, assign it to a REFANY, and that party (NARROW/ISTYPE/etc.) on the REFANY? Otherwise LOOPHOLE the ADDRESS to an INTEGER and shift it right by one? > > > > > There is danger here no matter what. > > > Who says heap pointers need any alignment? > They need alignment for the conjunction of the following two reasons: 1. Some heap objects have to be aligned because they contain a field or element that must be aligned. Examples are an open array of INTEGER and a linked-list node that contains a pointer. And, 2. It is impractically overcomplicated to build a heap allocator/garbage collector that handles a mix of aligned and unaligned heap objects. Even if one did so, there would probably be no benefit, or maybe memory use might even get worse, on account of increased fragmentation. So heap managers give all objects the strictest alignment any object could require. > > > On most machines they are aligned, but on most machines (x86, AMD64) they don't need to be. x86/AMD64 may have an option for triggering "alignment exceptions" in the hardware, but I don't think any OS ever enables it. And I doubt that any application can. > > > On Windows when dealing with "resources" (strings, bitmaps, etc., same notion as Apple), anything under 64K is considered a small integer. > This gives you a system where resources can be efficiently identified by small integers, and you need to coordinate with all contributors of resources to a particular file, or less efficiently but more flexibily use strings and less/no coordination is needed. It's a nice compromise. > > > Very little code relies on the alignment of pointers. > It is a "special purpose" kind of thing. > > > Very little code makes these "policy" decisions either. > > > On most machines, the pointer NULL is made invalid at the hardware level by making the first page inaccessible. On most machines, a page is at least 4K. On many machines it is larger, or even variably sized. > Going further and always reserving the first 64K of address space is not a big waste. > It's not physical memory, it's "just" address space. (It does cost something, but not much; it costs you some reduced capacity) > > > There is danger here no matter what but also a lot of efficiency to be gained in some scenarios. > > > On most machines you can probably take more than 1 bit. > > > On NT the heap allocator aligns to "two pointers", so that gives you 3 (32bit) or 4 (64bit) bits. But that's just for typical code. Modula-3 usually allocates with mmap/sbrk/VirtualAlloc, giving it at least 4K alignment, probably in reality something larger like 64K. It is the under its control to subdivide that as it sees fit. > So you could arbitrarily decree that all Modula-3 objects are aligned at say 32 bytes and have 5 tag bits. It's just that at some point you start wasting space. Allocating a bunch of 10 byte objects with 32 byte alignment wastes a lot of space. But allocating a bunch of 32 or 64 or 96 etc., byte objects with 32 byte alignment wastes nothing.. > > > On NT as well, historically, the address space was split in two. > (It still is split, but details vary). > The upper bit was zero for usermode, one for kernelmode. > Therefore, historically, another avenue this proposal could take is to use the high bit for a tag bit. Assuming nobody is writing drivers in kernel mode. > > > However, this 2gig/2gig split can be constraining on usermode (and kernelmode..). > So there is an option at boot-time to make it 3gig/1gig -- 3gig user mode, 1 gig usermode. > However that breaks any code that uses the high bit as a tag bit. > Therefore executables (.exes, not .dlls) have a flag in them to indicate if they are "large address aware". If they are not, even if you boot /3gig, you still, I guess, won't ever see addresses over 2gig. > If you are using tag bits, it then becomes that the upper two bits are: > 00: definitely usermode > 01: ambiguous > 10: definitely kernelmode (can be used as a 30 bit integer) > 11: definitely kernelmode (can be used as a 30 bit integer) > > > However if you run a "large address aware" 32bit executable on a 64bit system, you get all 4gig as usermode. The kernelmode addresses are even higher than 4gig and you can't even encode them in a 32bit usermode address, which is fine. It becomes that all addresses are usermode. (This is a little mind-bending at first). > > > Using a small struct with a type tag (possibly an entire pointer) and a separate data word also seems very viable. Very portable, very safe. Just that it grows the representation. > > > - Jay > > > > ---------------------------------------- > >> Date: Sun, 19 Apr 2009 21:45:49 -0500 >> From: rodney.m.bates at cox.net >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] fewer wrappers/more C? (or a wash?) >> >> hendrik at topoi.pooq.com wrote: >> >>> On Fri, Apr 17, 2009 at 10:57:10PM +1000, Tony Hosking wrote: >>> >>> >>>> I am a little concerned about passing REFANY directly to C code as >>>> there is no guarantee that REFANY and C pointers will always be >>>> compatible. ADDRESS can more safely be assumed compatible. >>>> >>>> >>> Indeed, I once read the X toolkit specs, and it was rife with small >>> integers being packed into pointers. Apparently the toolkit resolved >>> it not by a tag bit, but by its magnitude. There was some constant >>> somewhere that identified which numbers were small enough to be >>> considered not-pointers. >>> >>> This was a discrimination without a tag bit. Similar concept to what >>> we're planning for the future of REFANY, but different implementation. >>> >>> I don't know how they figured out which pointer values were safe to >>> treat as integers. >>> >>> >> In my more elaborate "safe" proposal, at least, the language itself >> does not specify anything about what the bit-encodings of tagged >> types are. It's an implementors' option, and the language >> can support whatever the implementors choose. >> >> This could be used to match the X toolkit's encoding. However, >> using the lsb takes advantage of the fact that heap objects must >> always be aligned and thus the lsb is already always zero, when >> it's really a heap pointer. That seems like by far the most efficient >> encoding. >> >>> -- hendrik >>> >>> >>> >>> From hendrik at topoi.pooq.com Mon Apr 20 16:53:20 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 20 Apr 2009 10:53:20 -0400 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: <49EBE1DD.6080809@cox.net> References: <20090420012129.GA22387@topoi.pooq.com> <49EBE1DD.6080809@cox.net> Message-ID: <20090420145320.GA23397@topoi.pooq.com> On Sun, Apr 19, 2009 at 09:45:49PM -0500, Rodney M. Bates wrote: > hendrik at topoi.pooq.com wrote: > >On Fri, Apr 17, 2009 at 10:57:10PM +1000, Tony Hosking wrote: > > > >>I am a little concerned about passing REFANY directly to C code as > >>there is no guarantee that REFANY and C pointers will always be > >>compatible. ADDRESS can more safely be assumed compatible. > >> > > > >Indeed, I once read the X toolkit specs, and it was rife with small > >integers being packed into pointers. Apparently the toolkit resolved > >it not by a tag bit, but by its magnitude. There was some constant > >somewhere that identified which numbers were small enough to be > >considered not-pointers. > > > >This was a discrimination without a tag bit. Similar concept to what > >we're planning for the future of REFANY, but different implementation. > > > >I don't know how they figured out which pointer values were safe to > >treat as integers. > > > In my more elaborate "safe" proposal, at least, the language itself > does not specify anything about what the bit-encodings of tagged > types are. It's an implementors' option, and the language > can support whatever the implementors choose. > > This could be used to match the X toolkit's encoding. However, > using the lsb takes advantage of the fact that heap objects must > always be aligned and thus the lsb is already always zero, when > it's really a heap pointer. That seems like by far the most efficient > encoding. The X toolkit was set up to be called from C, and the small integers were just parameters to a C function, or else pointers, whatever was more convenient. They had a specific range of small integers (which was machine-dependent as far as I can tell), and the whole convention seems to have been set up for coding convenience. I don't know how the limit on "small" inetgers was decided. The LSB trick is what I would recommend for us. I was just reinforcing the hopelessless of assuming we can make REFANY match C conventions. I suspect there are too many different ones. -- hendrik From jay.krell at cornell.edu Mon Apr 20 16:51:52 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 20 Apr 2009 14:51:52 +0000 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: <49EC8154.20909@cox.net> References: <20090420012129.GA22387@topoi.pooq.com> <49EBE1DD.6080809@cox.net> <49EC8154.20909@cox.net> Message-ID: > 1. Some heap objects have to be aligned because they contain a field or > element > that must be aligned. Examples are an open array of INTEGER and a > linked-list node that contains a pointer. And, And on every system there exist fields/elements that really require alignment? The following works fine for me..x86 tends to be very lax on requiring any alignment. #include int main() { unsigned char a[20]; unsigned i; for (i = 0 ; i < 20 ; ++i) a[i] = (unsigned char)i; for (i = 0 ; i < 8 ; ++i) printf("%x\n", *(unsigned*)&a[i]); for (i = 0 ; i < 8 ; ++i) printf("%f\n", *(double*)&a[i]); return 0; } I think we only care about Modula-3 heap allocated pointers, so what folks do in their C code doesn't matter. We can even introduce and depend upon higher alignment than the hardware requires or the underlying allocator provides. I realize that SPARC, MIPS, maybe Alpha, ARM?, IA64, and probably others, do have hardware-enforced alignment requirements. (Having debugged some of them.) I'm mostly just causing trouble. The proposals are all somewhat dangerous, but in reality they are ok, and can buy significant efficiencies in certain applications. Alignment is normal, even on x86. Btw, presumably on a 64 bit system, you can get a 32bit float in one of these things. - Jay From hendrik at topoi.pooq.com Mon Apr 20 16:57:48 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 20 Apr 2009 10:57:48 -0400 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: References: <20090420012129.GA22387@topoi.pooq.com> <49EBE1DD.6080809@cox.net> Message-ID: <20090420145748.GB23397@topoi.pooq.com> On Mon, Apr 20, 2009 at 03:36:38AM +0000, Jay wrote: > > > Assuming nobody is writing drivers in kernel mode. > > I meant, "in Modula-3". Hasn't an operating system been written in Modula 3? But not NT, I guess. -- hendrik From jay.krell at cornell.edu Mon Apr 20 17:06:41 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 20 Apr 2009 15:06:41 +0000 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: <20090420145748.GB23397@topoi.pooq.com> References: <20090420012129.GA22387@topoi.pooq.com> <49EBE1DD.6080809@cox.net> <20090420145748.GB23397@topoi.pooq.com> Message-ID: Yes, SPIN. - Jay ---------------------------------------- > Date: Mon, 20 Apr 2009 10:57:48 -0400 > From: hendrik@ >>> Assuming nobody is writing drivers in kernel mode. >> >> I meant, "in Modula-3". > > Hasn't an operating system been written in Modula 3? > But not NT, I guess. > > -- hendrik From mika at async.caltech.edu Mon Apr 20 17:31:32 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 20 Apr 2009 08:31:32 -0700 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: Your message of "Mon, 20 Apr 2009 14:51:52 -0000." Message-ID: <200904201531.n3KFVWLl065496@camembert.async.caltech.edu> I just wanted to point out that the discussion about X pointers is introducing a large red herring into the discussion about tagged REFANYs. The tagged REFANY idea just depends on Modula-3's own heap allocator's returning aligned addresses. If they're not aligned, you can't tag the REFANY. If they are, you can, because the only thing ever held by a REFANY is a Modula-3-heap-allocated address, NIL, or a tagged value. X pointers should clearly be passed as ADDRESS, not as REFANY. Completely different issue. Mika Jay writes: > >> 1. Some heap objects have to be aligned because they contain a field or >> element >> that must be aligned. Examples are an open array of INTEGER and a >> linked-list node that contains a pointer. And, > > >And on every system there exist fields/elements that really require alignment? > > >The following works fine for me..x86 tends to be very lax on requiring any alignment. > > >#include > > >int main() >{ >unsigned char a[20]; >unsigned i; > > >for (i = 0 ; i < 20 ; ++i) > a[i] = (unsigned char)i; > > >for (i = 0 ; i < 8 ; ++i) > printf("%x\n", *(unsigned*)&a[i]); > >for (i = 0 ; i < 8 ; ++i) > printf("%f\n", *(double*)&a[i]); > >return 0; >} > > >I think we only care about Modula-3 heap allocated pointers, so what >folks do in their C code doesn't matter. >We can even introduce and depend upon higher alignment than the hardware requires >or the underlying allocator provides. > > >I realize that SPARC, MIPS, maybe Alpha, ARM?, IA64, and probably others, >do have hardware-enforced alignment requirements. >(Having debugged some of them.) > > >I'm mostly just causing trouble. >The proposals are all somewhat dangerous, but in reality they are ok, >and can buy significant efficiencies in certain applications. >Alignment is normal, even on x86. > > >Btw, presumably on a 64 bit system, you can get a 32bit float in one of these things. > > > > - Jay From hosking at cs.purdue.edu Mon Apr 20 23:53:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Apr 2009 07:53:57 +1000 Subject: [M3devel] crummy ThreadWin32.m3 implementation? In-Reply-To: References: Message-ID: <14FDB4AD-26AA-43B0-BD25-925C596452EF@cs.purdue.edu> Also, note that win32 now supports CVs directly! No need for semaphores. On 20 Apr 2009, at 19:11, Jay wrote: > > Searching the web...finds this which seems very relevant: > > http://birrell.org/andrew/papers/ImplementingCVs.pdf > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Mon, 20 Apr 2009 08:47:21 +0000 >> Subject: [M3devel] crummy ThreadWin32.m3 implementation? >> >> >> Um, ThreadWin32.m3 looks pretty crummy -- all LockMutex calls >> bottleneck on one giant lock. .v0 and .v1 aren't bad this way. >> >> >> - Jay From hosking at cs.purdue.edu Tue Apr 21 03:53:05 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Apr 2009 11:53:05 +1000 Subject: [M3devel] Latest ThreadPThread Message-ID: <8510055B-CBC6-4A02-BAFA-B26AF9A827EC@cs.purdue.edu> Jay, I have some questions about why you have moved the Activation declaration to C code. I'm not sure what this gains, and I have strong reasons for wanting to keep it in Modula-3. I'd like to revert these most recent changes if possible, unless you can say why you want to retain them. Perhaps you have a good reason, but I remain to be convinced. -- Tony Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Apr 21 03:58:31 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Apr 2009 11:58:31 +1000 Subject: [M3devel] Latest ThreadPThread In-Reply-To: <8510055B-CBC6-4A02-BAFA-B26AF9A827EC@cs.purdue.edu> References: <8510055B-CBC6-4A02-BAFA-B26AF9A827EC@cs.purdue.edu> Message-ID: Jay, I am curious why you are using atomic operations for INC and DEC of inCritical (on WIN32/WIN64). In general, they are protected by an appropriate lock, so I don't know what the need is. Are you trying to move towards lock-free implementations of some of the thread primitives? 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 21 Apr 2009, at 11:53, Tony Hosking wrote: > Jay, > > I have some questions about why you have moved the Activation > declaration to C code. I'm not sure what this gains, and I have > strong reasons for wanting to keep it in Modula-3. I'd like to > revert these most recent changes if possible, unless you can say why > you want to retain them. Perhaps you have a good reason, but I > remain to be convinced. > > -- Tony > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Apr 21 04:51:18 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Apr 2009 12:51:18 +1000 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <49EC7A06.5040403@cox.net> References: <49EC7A06.5040403@cox.net> Message-ID: I note that Mika's proposal is no less safe than Rodney's. On 20 Apr 2009, at 23:35, Rodney M. Bates wrote: > I am going to try to resummarize the various proposals, as their > description has now gotten rather scattered around in all the > discussion. > --------------------------------------------------------------------- > Mika's proposal (I'll call it the "minimalist" propsal): > > Mika, please correct me if I misrepresent what you are proposing. > > There are no language changes at all, only changes in implementation. > The implementation of the existing type REFANY, and no other type, > allows it to have values whose lsb is nonzero. ISTYPE, NARROW, > TYPECASE, and narrowing assignments, when and only when applied to > REFANY, have their generated code fixed so it checks the lsb, and, if > it is nonzero, consider the runtime type check to have failed, in > whichever way such a failure is already handled. > > The only effect is to liberalize the rules unsafe code must follow to > avoid undermining the safety of safe code. Only unsafe code can > create or detect these misaligned values. Today, it must never return > them in a variable of any reference type, lest the four narrowing > operations unexpectedly crash. In the proposal, unsafe code would be > able to return such values in variables of type REFANY, but not any > other type. > > Already, the only things safe code can do with values of REFANY are > copy them around (which would happily work on misaligned values) and > narrow them. With the implementation of the narrowing operations > changed, misaligned values can never escape from REFANY variables. > > In safe code, there is no way to detect whether a value of type REFANY > is misaligned. Doing it by elimination, trying to narrow to any > proper subtype of REFANY, is impractical, as there are an unbounded > number of REF types to eliminate. > > If there is more than one abstract data type that uses this mechanism, > client code can not be prevented from mixing up values from the > different abstractions. (Perhaps this could be fixed by a language > change allowing BRANDED REFANY?) > > --------------------------------------------------------------------- > My (Rodney's) "safe" proposal: > > There is a new type named TAGABLE. It is a subrange of INTEGER, whose > bounds are implementation-defined. These can be queried by the > existing FIRST and LAST functions. Similar to CARDINAL, it has all > the properties of a subrange type but is not the same type as the > corresponding subrange. > > There is a new type constructor TAGGED. If T is any traced or object > type, including branded and opaque types, then TAGGED T is a new type > whose value set is the union of the value sets of T and TAGABLE. > Moreover, > > TAGABLE <: TAGGED T > T <: TAGGED T. > > IF T # U, then TAGGED T and TAGGED U are not the same type and have no > subtype or assignability relation to each other. > > The semantics of ISTYPE, NARROW, TYPECASE, and assignability of a type > to a type are generalized so that their to-be-narrowed operand can > have a tagged type, and if it does, their to-be-narrowed-to type can > be TAGABLE. > > Comments: > > Making TAGGED T have no relation to TAGGED U avoids a lot of really > complicated type equality and subtype rules. The former would be a > drastic departure from the current state of Modula-3. > > It is up to the implementation to decide the bit representation of > tagged types, including how values of TAGABLE will be distinguished > from reference values. Though the language would not require it, most > likely a word the same size as a pointer will be used. Using the lsb > as the tag bit is an efficient encoding, because in any currently > conceivable machine, it will be zero for all pointers to heap objects. > There is no reason pickles would have to use the same representation > as compiler-generated code. > > The implementation should define the bounds of TAGABLE to be whatever > it can fit in its representation, after removing the values that are > true pointers. If the lsb is used as a tag, this will no doubt be a > 31-bit integer on a 32-bit machine and 63-bit integer on a 64-bit > machine. The language wouldn't even specify whether it is signed, > although somehow unsigned seems nice to me. If it is unsigned and the > suggested encodings are used, TAGABLE would have the same bounds as > CARDINAL, but it really should be a separate type, so as not to > overconstrain the implementation. > > If T is branded, then the effects of branding will propagate to TAGGED > T, thus allowing independent abstract data types to ensure each one's > values can't be mixed up with the other's. This will statically > detect misuses by client code. However, TAGGED T is not a branded > type. > > If T is an opaque type, then TAGGED T can be used to combine the space > efficiency of tagging with the ability of an opaque type to reveal > some but not all of its properties. To use this, client code will > have to narrow a value first, since access to methods/fields could not > have a definable meaning for a value in TAGABLE. > > On the other hand, T could be an opaque subtype of REFANY, thus > revealing almost nothing about TAGGED T to clients. This would give > tagged types the existing ability of ensuring statically, that the > code in a revealed context will never get TAGGED REFANY, thus avoiding > extra runtime type checks. From hosking at cs.purdue.edu Tue Apr 21 05:59:35 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Apr 2009 13:59:35 +1000 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <49EC7A06.5040403@cox.net> References: <49EC7A06.5040403@cox.net> Message-ID: On 20 Apr 2009, at 23:35, Rodney M. Bates wrote: > I am going to try to resummarize the various proposals, as their > description has now gotten rather scattered around in all the > discussion. > --------------------------------------------------------------------- > Mika's proposal (I'll call it the "minimalist" propsal): > > Mika, please correct me if I misrepresent what you are proposing. > > There are no language changes at all, only changes in implementation. > The implementation of the existing type REFANY, and no other type, > allows it to have values whose lsb is nonzero. ISTYPE, NARROW, > TYPECASE, and narrowing assignments, when and only when applied to > REFANY, have their generated code fixed so it checks the lsb, and, if > it is nonzero, consider the runtime type check to have failed, in > whichever way such a failure is already handled. > > The only effect is to liberalize the rules unsafe code must follow to > avoid undermining the safety of safe code. Only unsafe code can > create or detect these misaligned values. Today, it must never return > them in a variable of any reference type, lest the four narrowing > operations unexpectedly crash. In the proposal, unsafe code would be > able to return such values in variables of type REFANY, but not any > other type. I don't see why we can't have safe creation of the misaligned values as per Mika's interface. > Already, the only things safe code can do with values of REFANY are > copy them around (which would happily work on misaligned values) and > narrow them. With the implementation of the narrowing operations > changed, misaligned values can never escape from REFANY variables. > > In safe code, there is no way to detect whether a value of type REFANY > is misaligned. Doing it by elimination, trying to narrow to any > proper subtype of REFANY, is impractical, as there are an unbounded > number of REF types to eliminate. An alternative would be to loosen the language spec to allow TYPECODE(REFANY) and use this typecode for tagged references. Then one can explicitly test for it without elimination of alternatives. > If there is more than one abstract data type that uses this mechanism, > client code can not be prevented from mixing up values from the > different abstractions. (Perhaps this could be fixed by a language > change allowing BRANDED REFANY?) Indeed. > --------------------------------------------------------------------- > My (Rodney's) "safe" proposal: > > There is a new type named TAGABLE. It is a subrange of INTEGER, whose > bounds are implementation-defined. These can be queried by the > existing FIRST and LAST functions. Similar to CARDINAL, it has all > the properties of a subrange type but is not the same type as the > corresponding subrange. > > There is a new type constructor TAGGED. If T is any traced or object > type, including branded and opaque types, then TAGGED T is a new type > whose value set is the union of the value sets of T and TAGABLE. > Moreover, > > TAGABLE <: TAGGED T > T <: TAGGED T. > > IF T # U, then TAGGED T and TAGGED U are not the same type and have no > subtype or assignability relation to each other. > > The semantics of ISTYPE, NARROW, TYPECASE, and assignability of a type > to a type are generalized so that their to-be-narrowed operand can > have a tagged type, and if it does, their to-be-narrowed-to type can > be TAGABLE. Hmm. It seems there is a nasty loophole in your spec. Consider: TYPE T = BRANDED OBJECT END TYPE U = BRANDED OBJECT END These are unrelated types. Now, the rules let me take: t: TAGGED T and obtain: i: TAGABLE := NARROW(t, TAGABLE); But TAGABLE <: TAGGED U so I can do: u: TAGGED U := t; Is that your intention? > > > Comments: > > Making TAGGED T have no relation to TAGGED U avoids a lot of really > complicated type equality and subtype rules. The former would be a > drastic departure from the current state of Modula-3. > > It is up to the implementation to decide the bit representation of > tagged types, including how values of TAGABLE will be distinguished > from reference values. Though the language would not require it, most > likely a word the same size as a pointer will be used. Using the lsb > as the tag bit is an efficient encoding, because in any currently > conceivable machine, it will be zero for all pointers to heap objects. > There is no reason pickles would have to use the same representation > as compiler-generated code. > > The implementation should define the bounds of TAGABLE to be whatever > it can fit in its representation, after removing the values that are > true pointers. If the lsb is used as a tag, this will no doubt be a > 31-bit integer on a 32-bit machine and 63-bit integer on a 64-bit > machine. The language wouldn't even specify whether it is signed, > although somehow unsigned seems nice to me. If it is unsigned and the > suggested encodings are used, TAGABLE would have the same bounds as > CARDINAL, but it really should be a separate type, so as not to > overconstrain the implementation. > > If T is branded, then the effects of branding will propagate to TAGGED > T, thus allowing independent abstract data types to ensure each one's > values can't be mixed up with the other's. This will statically > detect misuses by client code. However, TAGGED T is not a branded > type. > > If T is an opaque type, then TAGGED T can be used to combine the space > efficiency of tagging with the ability of an opaque type to reveal > some but not all of its properties. To use this, client code will > have to narrow a value first, since access to methods/fields could not > have a definable meaning for a value in TAGABLE. > > On the other hand, T could be an opaque subtype of REFANY, thus > revealing almost nothing about TAGGED T to clients. This would give > tagged types the existing ability of ensuring statically, that the > code in a revealed context will never get TAGGED REFANY, thus avoiding > extra runtime type checks. From jay.krell at cornell.edu Tue Apr 21 06:14:43 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 21 Apr 2009 04:14:43 +0000 Subject: [M3devel] crummy ThreadWin32.m3 implementation? In-Reply-To: <14FDB4AD-26AA-43B0-BD25-925C596452EF@cs.purdue.edu> References: <14FDB4AD-26AA-43B0-BD25-925C596452EF@cs.purdue.edu> Message-ID: Only if you drop support for pre-Vista versions. - Jay > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 21 Apr 2009 07:53:57 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? > > Also, note that win32 now supports CVs directly! No need for > semaphores. > > On 20 Apr 2009, at 19:11, Jay wrote: > > > > > Searching the web...finds this which seems very relevant: > > > > http://birrell.org/andrew/papers/ImplementingCVs.pdf > > > > - Jay > > > > > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: m3devel at elegosoft.com > >> Date: Mon, 20 Apr 2009 08:47:21 +0000 > >> Subject: [M3devel] crummy ThreadWin32.m3 implementation? > >> > >> > >> Um, ThreadWin32.m3 looks pretty crummy -- all LockMutex calls > >> bottleneck on one giant lock. .v0 and .v1 aren't bad this way. > >> > >> > >> - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 21 06:13:23 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 21 Apr 2009 04:13:23 +0000 Subject: [M3devel] Latest ThreadPThread In-Reply-To: <8510055B-CBC6-4A02-BAFA-B26AF9A827EC@cs.purdue.edu> References: <8510055B-CBC6-4A02-BAFA-B26AF9A827EC@cs.purdue.edu> Message-ID: Question is whether or not it is interesting to have fewer of those very thin pthread wrappers or not. This has fewer of them. Not clearly worthwhile. I can it put back later. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 21 Apr 2009 11:53:05 +1000 CC: m3devel at elegosoft.com Subject: [M3devel] Latest ThreadPThread Jay, I have some questions about why you have moved the Activation declaration to C code. I'm not sure what this gains, and I have strong reasons for wanting to keep it in Modula-3. I'd like to revert these most recent changes if possible, unless you can say why you want to retain them. Perhaps you have a good reason, but I remain to be convinced. -- Tony Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Apr 21 06:33:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Apr 2009 14:33:29 +1000 Subject: [M3devel] crummy ThreadWin32.m3 implementation? In-Reply-To: References: <14FDB4AD-26AA-43B0-BD25-925C596452EF@cs.purdue.edu> Message-ID: <3577783C-1892-435E-95E3-5E967C9BA638@cs.purdue.edu> Might not be such a bad thing ;-) On 21 Apr 2009, at 14:14, Jay wrote: > Only if you drop support for pre-Vista versions. > > - Jay > > > > > From: hosking at cs.purdue.edu > > To: jay.krell at cornell.edu > > Date: Tue, 21 Apr 2009 07:53:57 +1000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? > > > > Also, note that win32 now supports CVs directly! No need for > > semaphores. > > > > On 20 Apr 2009, at 19:11, Jay wrote: > > > > > > > > Searching the web...finds this which seems very relevant: > > > > > > http://birrell.org/andrew/papers/ImplementingCVs.pdf > > > > > > - Jay > > > > > > > > > > > > ---------------------------------------- > > >> From: jay.krell at cornell.edu > > >> To: m3devel at elegosoft.com > > >> Date: Mon, 20 Apr 2009 08:47:21 +0000 > > >> Subject: [M3devel] crummy ThreadWin32.m3 implementation? > > >> > > >> > > >> Um, ThreadWin32.m3 looks pretty crummy -- all LockMutex calls > > >> bottleneck on one giant lock. .v0 and .v1 aren't bad this way. > > >> > > >> > > >> - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 21 06:41:55 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 21 Apr 2009 04:41:55 +0000 Subject: [M3devel] crummy ThreadWin32.m3 implementation? In-Reply-To: <3577783C-1892-435E-95E3-5E967C9BA638@cs.purdue.edu> References: <14FDB4AD-26AA-43B0-BD25-925C596452EF@cs.purdue.edu> <3577783C-1892-435E-95E3-5E967C9BA638@cs.purdue.edu> Message-ID: I'm not keen on it. Checking the version and having two implementation switched between at initialization would be ok though -- actually using function pointers like so: void DoSomething_v2(void) { } void DoSomething_v1(void) { } void DoSomething_init(void) { if (... ) DoSomething = DoSomething_v1; else DoSomething = DoSomething_v2; DoSomething(); } void (*DoSomething)(void) = DoSomething_init; Something more if switching multiple pointers though -- switching a pointer to a struct of function pointers. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 21 Apr 2009 14:33:29 +1000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? Might not be such a bad thing ;-) On 21 Apr 2009, at 14:14, Jay wrote: Only if you drop support for pre-Vista versions. - Jay > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 21 Apr 2009 07:53:57 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? > > Also, note that win32 now supports CVs directly! No need for > semaphores. > > On 20 Apr 2009, at 19:11, Jay wrote: > > > > > Searching the web...finds this which seems very relevant: > > > > http://birrell.org/andrew/papers/ImplementingCVs.pdf > > > > - Jay > > > > > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: m3devel at elegosoft.com > >> Date: Mon, 20 Apr 2009 08:47:21 +0000 > >> Subject: [M3devel] crummy ThreadWin32.m3 implementation? > >> > >> > >> Um, ThreadWin32.m3 looks pretty crummy -- all LockMutex calls > >> bottleneck on one giant lock. .v0 and .v1 aren't bad this way. > >> > >> > >> - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 21 06:44:33 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 21 Apr 2009 04:44:33 +0000 Subject: [M3devel] Latest ThreadPThread In-Reply-To: References: <8510055B-CBC6-4A02-BAFA-B26AF9A827EC@cs.purdue.edu> Message-ID: The Interlocked doesn't have a strong reason. It's fairly cheap at least. There are places in the Modula-3 code with comments about inc/dec taking one instruction, which these would but otherwise I'm skeptical.. - Jay From: hosking at cs.purdue.edu To: hosking at cs.purdue.edu Date: Tue, 21 Apr 2009 11:58:31 +1000 CC: m3devel at elegosoft.com; jay.krell at cornell.edu Subject: Re: [M3devel] Latest ThreadPThread Jay, I am curious why you are using atomic operations for INC and DEC of inCritical (on WIN32/WIN64). In general, they are protected by an appropriate lock, so I don't know what the need is. Are you trying to move towards lock-free implementations of some of the thread primitives? 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 21 Apr 2009, at 11:53, Tony Hosking wrote: Jay, I have some questions about why you have moved the Activation declaration to C code. I'm not sure what this gains, and I have strong reasons for wanting to keep it in Modula-3. I'd like to revert these most recent changes if possible, unless you can say why you want to retain them. Perhaps you have a good reason, but I remain to be convinced. -- Tony Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Apr 21 07:05:48 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Apr 2009 15:05:48 +1000 Subject: [M3devel] Latest ThreadPThread In-Reply-To: References: <8510055B-CBC6-4A02-BAFA-B26AF9A827EC@cs.purdue.edu> Message-ID: On 21 Apr 2009, at 14:44, Jay wrote: > The Interlocked doesn't have a strong reason. > It's fairly cheap at least. It's many cycles (~50x depending on hardware) more expensive than an unlocked INC/DEC. > There are places in the Modula-3 code with comments about inc/dec > taking one instruction, > which these would but otherwise I'm skeptical.. I'm pretty sure that is only in the user-level threading model, where thread switches only occur on delivery of a signal to the process. I am unaware of any OS/hardware that will deliver a thread switch signal in the middle of INC/DEC. So, effectively, for user level threads INC/ DEC can be assumed atomic. That's what the comments are meant to imply. Outside ThreadPosix, all other uses of INC/DEC manipulate state that is already protected appropriately by a lock so should be thread safe. > > > > - Jay > > > > From: hosking at cs.purdue.edu > To: hosking at cs.purdue.edu > Date: Tue, 21 Apr 2009 11:58:31 +1000 > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] Latest ThreadPThread > > Jay, I am curious why you are using atomic operations for INC and > DEC of inCritical (on WIN32/WIN64). In general, they are protected > by an appropriate lock, so I don't know what the need is. Are you > trying to move towards lock-free implementations of some of the > thread primitives? > > 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 21 Apr 2009, at 11:53, Tony Hosking wrote: > > Jay, > > I have some questions about why you have moved the Activation > declaration to C code. I'm not sure what this gains, and I have > strong reasons for wanting to keep it in Modula-3. I'd like to > revert these most recent changes if possible, unless you can say why > you want to retain them. Perhaps you have a good reason, but I > remain to be convinced. > > -- Tony > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 21 11:37:21 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 21 Apr 2009 09:37:21 +0000 Subject: [M3devel] explanation of CheckLoadTracedRef? In-Reply-To: References: Message-ID: > > How bad/unportable was it the previous way, the VM-synchronized way? > > Not compatible with system threading. Really? NT386 wasn't VM-synchronized back in 3.6, 4.1, etc.? Or only with great cost? I have to admit, those old import .libs, kernel32.lib, etc. I didn't realize what was in them when I deleted them. I thought they were just regular import .libs. I think I got luckly in that the overlap between me deleting them and you removing VM-synchronized GC was small or zero. > You should *never* access a field in the heap in C code! All > accesses to traced fields in the heap must take place in Modula-3. > Otherwise things will break! C wrappers should not do anything other > than forward calls to C library calls. They should not perform heap > accesses. Ok, that makes sense. Important "out" is the accessing stack is always ok. But this is a requirement I didn't keep in mind. Now, luckily, the C wrappers are all relatively thin and not difficult to re-review in their entirety. But, take for example "open". The first parameter to it is bound to be in the heap. But probably it is untraced or somehow ok, since it does come from a module used primarily for C interop. And, the line between C wrappers and the "C library" that they forward to does not exist. If I, say, pass a VAR to a VAR..no check is made? Important to declare extern/C functions as taking UNTRACED REF and not VAR? > I think you are confusing incremental and incremental GC. You assume I understand more than I do (I assume you have a typo. :)) "generational" -- the concept that most objects die young. (aka most objects could have been allocated on the stack...) But does that imply detailed implementation choices, or is just like a "guiding principle"? I guess it implies the heap is split into at least two generations, old and young. Though I guess in reality there is a range of young, less young, lesser young, least young, etc. And that has objects age, they should be moved from young to old heaps, and references to them either updated right away, or "caught" upon use and updated then...something like that. "incremental" -- don't pause the world.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Apr 21 14:18:00 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 21 Apr 2009 08:18:00 -0400 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: <200904201531.n3KFVWLl065496@camembert.async.caltech.edu> References: <200904201531.n3KFVWLl065496@camembert.async.caltech.edu> Message-ID: <20090421121800.GA25465@topoi.pooq.com> On Mon, Apr 20, 2009 at 08:31:32AM -0700, Mika Nystrom wrote: > > I just wanted to point out that the discussion about X pointers > is introducing a large red herring into the discussion about tagged REFANYs. > > The tagged REFANY idea just depends on Modula-3's own heap allocator's > returning aligned addresses. If they're not aligned, you can't tag > the REFANY. If they are, you can, because the only thing ever held by > a REFANY is a Modula-3-heap-allocated address, NIL, or a tagged value. > > X pointers should clearly be passed as ADDRESS, not as REFANY. Completely > different issue. Because Modula 3's reference data structures are subject to the Modula 3 garbage collector, and C's are not. And further, C's addresses don't have to be aligned; neither do ADDRESSes. -- hendrik From hendrik at topoi.pooq.com Tue Apr 21 14:26:48 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 21 Apr 2009 08:26:48 -0400 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <49EC7A06.5040403@cox.net> References: <49EC7A06.5040403@cox.net> Message-ID: <20090421122648.GB25465@topoi.pooq.com> On Mon, Apr 20, 2009 at 08:35:02AM -0500, Rodney M. Bates wrote: > > --------------------------------------------------------------------- > My (Rodney's) "safe" proposal: > > There is a new type named TAGABLE. It is a subrange of INTEGER, whose Please spell it TAGGABLE. TAG doubles its last consonant when adding suffixes: TAGGED, TAGGING. -- hendrik From jay.krell at cornell.edu Tue Apr 21 14:46:22 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 21 Apr 2009 12:46:22 +0000 Subject: [M3devel] crummy ThreadWin32.m3 implementation? In-Reply-To: References: <14FDB4AD-26AA-43B0-BD25-925C596452EF@cs.purdue.edu> <3577783C-1892-435E-95E3-5E967C9BA638@cs.purdue.edu> Message-ID: did more "research" (search the web..) It sounds like: if fairness not critical, and pre NT 4.0 compat is needed, there are options where mutex/lock=criticalsection If fairness is important, and NT 4.0 can be used, and perf can be degraded, then mutex/lock=kernel mutex, and use the SignalAndWait function They never seem to use a global lock like ours. Should we maybe adopt Boost's code? e.g.: http://svn.boost.org/trac/boost/browser/trunk/boost/thread/win32/mutex.hpp http://svn.boost.org/trac/boost/browser/trunk/boost/thread/win32/condition_variable.hpp I don't know, it all seems kind of unforunate. Perhaps there should be two types of locks, one that can be associated with a conditionvariable (kernel mutex), one that cannot (criticalsection)? I guess our implementation is quite simple and solves "all the problems" by throwing scalability right out -- lots of independent threads acquiring lots of independent locks will all interfere somewhat with each other, but not a ton. The "giant" lock protects too much data, but not for long durations. It might be interesting to see what cygwin does..but I notice..pthread is a superset, e.g. timedwait, trylock, etc. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 21 Apr 2009 04:41:55 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? I'm not keen on it. Checking the version and having two implementation switched between at initialization would be ok though -- actually using function pointers like so: void DoSomething_v2(void) { } void DoSomething_v1(void) { } void DoSomething_init(void) { if (... ) DoSomething = DoSomething_v1; else DoSomething = DoSomething_v2; DoSomething(); } void (*DoSomething)(void) = DoSomething_init; Something more if switching multiple pointers though -- switching a pointer to a struct of function pointers. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 21 Apr 2009 14:33:29 +1000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? Might not be such a bad thing ;-) On 21 Apr 2009, at 14:14, Jay wrote: Only if you drop support for pre-Vista versions. - Jay > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 21 Apr 2009 07:53:57 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? > > Also, note that win32 now supports CVs directly! No need for > semaphores. > > On 20 Apr 2009, at 19:11, Jay wrote: > > > > > Searching the web...finds this which seems very relevant: > > > > http://birrell.org/andrew/papers/ImplementingCVs.pdf > > > > - Jay > > > > > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: m3devel at elegosoft.com > >> Date: Mon, 20 Apr 2009 08:47:21 +0000 > >> Subject: [M3devel] crummy ThreadWin32.m3 implementation? > >> > >> > >> Um, ThreadWin32.m3 looks pretty crummy -- all LockMutex calls > >> bottleneck on one giant lock. .v0 and .v1 aren't bad this way. > >> > >> > >> - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 21 14:47:16 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 21 Apr 2009 12:47:16 +0000 Subject: [M3devel] crummy ThreadWin32.m3 implementation? In-Reply-To: References: <14FDB4AD-26AA-43B0-BD25-925C596452EF@cs.purdue.edu> <3577783C-1892-435E-95E3-5E967C9BA638@cs.purdue.edu> Message-ID: did more "research" (search the web..) It sounds like: if fairness not critical, and pre NT 4.0 compat is needed, there are options where mutex/lock=criticalsection If fairness is important, and NT 4.0 can be used, and perf can be degraded, then mutex/lock=kernel mutex, and use the SignalAndWait function They never seem to use a global lock like ours. Should we maybe adopt Boost's code? e.g.: http://svn.boost.org/trac/boost/browser/trunk/boost/thread/win32/mutex.hpp http://svn.boost.org/trac/boost/browser/trunk/boost/thread/win32/condition_variable.hpp I don't know, it all seems kind of unforunate. Perhaps there should be two types of locks, one that can be associated with a conditionvariable (kernel mutex), one that cannot (criticalsection)? I guess our implementation is quite simple and solves "all the problems" by throwing scalability right out -- lots of independent threads acquiring lots of independent locks will all interfere somewhat with each other, but not a ton. The "giant" lock protects too much data, but not for long durations. It might be interesting to see what cygwin does..but I notice..pthread is a superset, e.g. timedwait, trylock, etc. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 21 Apr 2009 04:41:55 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? I'm not keen on it. Checking the version and having two implementation switched between at initialization would be ok though -- actually using function pointers like so: void DoSomething_v2(void) { } void DoSomething_v1(void) { } void DoSomething_init(void) { if (... ) DoSomething = DoSomething_v1; else DoSomething = DoSomething_v2; DoSomething(); } void (*DoSomething)(void) = DoSomething_init; Something more if switching multiple pointers though -- switching a pointer to a struct of function pointers. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 21 Apr 2009 14:33:29 +1000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? Might not be such a bad thing ;-) On 21 Apr 2009, at 14:14, Jay wrote: Only if you drop support for pre-Vista versions. - Jay > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 21 Apr 2009 07:53:57 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? > > Also, note that win32 now supports CVs directly! No need for > semaphores. > > On 20 Apr 2009, at 19:11, Jay wrote: > > > > > Searching the web...finds this which seems very relevant: > > > > http://birrell.org/andrew/papers/ImplementingCVs.pdf > > > > - Jay > > > > > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: m3devel at elegosoft.com > >> Date: Mon, 20 Apr 2009 08:47:21 +0000 > >> Subject: [M3devel] crummy ThreadWin32.m3 implementation? > >> > >> > >> Um, ThreadWin32.m3 looks pretty crummy -- all LockMutex calls > >> bottleneck on one giant lock. .v0 and .v1 aren't bad this way. > >> > >> > >> - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carson at taltos.org Tue Apr 21 20:29:28 2009 From: carson at taltos.org (Carson Gaspar) Date: Tue, 21 Apr 2009 11:29:28 -0700 Subject: [M3devel] Latest ThreadPThread In-Reply-To: References: <8510055B-CBC6-4A02-BAFA-B26AF9A827EC@cs.purdue.edu> Message-ID: <49EE1088.6030006@taltos.org> Tony Hosking wrote: > I'm pretty sure that is only in the user-level threading model, where > thread switches only occur on delivery of a signal to the process. I am > unaware of any OS/hardware that will deliver a thread switch signal in > the middle of INC/DEC. So, effectively, for user level threads INC/DEC > can be assumed atomic. That's what the comments are meant to imply. > Outside ThreadPosix, all other uses of INC/DEC manipulate state that is > already protected appropriately by a lock so should be thread safe. I'm not sure what you mean by INC/DEC... but if it involves changing a value in memory (as opposed to a register), then it is _not_ atomic and _must_ use a lock. The most common mistake I've seen is a variable modified in a signal handler and in the main code, especially SIGCHLD. "nchildren++" is _not_ signal or thread safe. If you're talking about purely register instructions, please ignore me ;-) -- Carson From mika at async.caltech.edu Tue Apr 21 23:41:49 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 21 Apr 2009 14:41:49 -0700 Subject: [M3devel] an old, recurring issue: mapping runtime errors to exceptions? Message-ID: <200904212141.n3LLfnZ4030631@camembert.async.caltech.edu> Hello Modula-3ers, I know this is a question that comes up from time to time, and I am aware of Greg Nelson's short article in "Threads" about why Modula-3 doesn't map runtime errors to exceptions, but the Green Book does allude to mapping runtime errors to exceptions, and I know that the SPIN OS did that. How hard would this be to support in CM3? Attached is a transcript of an interactive session with my current Scheme environment. I think it ought to be obvious why I ask about exceptions. In Modula-3, from safe code, only checked runtime errors can occur. Checked runtime errors cannot violate invariants of the runtime system, so it ought to be safe to convert them to exceptions that can be caught, and then permit the program to continue. I realize this isn't *always* what you want to do, but in an interactive environment, making the system dump core on runtime errors sort of spoils the whole experience. In this application, there are many places where you may want to raise an exception that hasn't been declared. In a non-interactive environment, it is probably best to go for the core dump, but in an interactive environment, it seems to me it ought to just return control to the read-eval-print loop.... Mika LITHP ITH LITHENING. > (define wr (scheme-procedure-stubs-call '(TextWr . New) '())) wr > wr > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) "hello!" > (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) "" > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) "hello!hello!hello!hello!hello!" > (scheme-procedure-stubs-call '(TextWr . ToText) (list '()) '()) *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x80c69c8 = LockMutex + 0x28 in /usr/ports/lang/ezm3/work/ezm3-1.0/libs/m3core/src/thread/POSIX/ThreadPosix.m3 *** use option @M3stackdump to get a stack trace Abort From rcoleburn at scires.com Wed Apr 22 00:22:28 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 21 Apr 2009 18:22:28 -0400 Subject: [M3devel] an old, recurring issue: mapping runtime errors to exceptions? In-Reply-To: <200904212141.n3LLfnZ4030631@camembert.async.caltech.edu> References: <200904212141.n3LLfnZ4030631@camembert.async.caltech.edu> Message-ID: <49EE0E7B.1E75.00D7.1@scires.com> Mika: You state that "Checked runtime errors cannot violate invariants of the runtime system, so it ought to be safe to ..." Are you sure this statement is true for all implementations? I would tend to think that SPIN was able to do this mapping for itself, but in general, it would be difficult to be able to do this for any arbitrary OS environment, esp with differences in underlying libraries and implementations, which is part of what Greg alluded to in the Threads article you reference. Note also on pg 47 of the green book under "2.5.7 Safety" the notes about intrinsic safety and when the compiler makes the guarantee vs. the programmer. I also note from the path in your example (ezm3) that you may not be using the current cm3. Is it possible that the NIL dereference problem in your example has been solved in a later implementation? Regards, Randy >>> Mika Nystrom 4/21/2009 5:41 PM >>> Hello Modula-3ers, I know this is a question that comes up from time to time, and I am aware of Greg Nelson's short article in "Threads" about why Modula-3 doesn't map runtime errors to exceptions, but the Green Book does allude to mapping runtime errors to exceptions, and I know that the SPIN OS did that. How hard would this be to support in CM3? Attached is a transcript of an interactive session with my current Scheme environment. I think it ought to be obvious why I ask about exceptions. In Modula-3, from safe code, only checked runtime errors can occur. Checked runtime errors cannot violate invariants of the runtime system, so it ought to be safe to convert them to exceptions that can be caught, and then permit the program to continue. I realize this isn't *always* what you want to do, but in an interactive environment, making the system dump core on runtime errors sort of spoils the whole experience. In this application, there are many places where you may want to raise an exception that hasn't been declared. In a non-interactive environment, it is probably best to go for the core dump, but in an interactive environment, it seems to me it ought to just return control to the read-eval-print loop.... Mika LITHP ITH LITHENING. > (define wr (scheme-procedure-stubs-call '(TextWr . New) '())) wr > wr > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) "hello!" > (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) "" > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) "hello!hello!hello!hello!hello!" > (scheme-procedure-stubs-call '(TextWr . ToText) (list '()) '()) *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x80c69c8 = LockMutex + 0x28 in /usr/ports/lang/ezm3/work/ezm3-1.0/libs/m3core/src/thread/POSIX/ThreadPosix.m3 *** use option @M3stackdump to get a stack trace Abort 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 mika at async.caltech.edu Wed Apr 22 00:41:19 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 21 Apr 2009 15:41:19 -0700 Subject: [M3devel] an old, recurring issue: mapping runtime errors to exceptions? In-Reply-To: Your message of "Tue, 21 Apr 2009 18:22:28 EDT." <49EE0E7B.1E75.00D7.1@scires.com> Message-ID: <200904212241.n3LMfJB7032643@camembert.async.caltech.edu> Well the point of "safety" is that the system can guarantee that the runtime environment hasn't been damaged by a misbehaving program, no? In fact, in Threads 3 there are not one but *two* reports of implementations that "reflect" runtime errors as exceptions. On of them is SPIN, the other is the commercial CM3 with JVM. See http://www.modula3.org/threads/3/ Nelson's article in Threads 2 doesn't give the possibility of having had the runtime invariants violated as a reason to abort. His arguments are more practical, having to do with debugging. I agree, and I think that the default method of dealing with runtime errors should be to abort the program. But it just is very unfriendly in an interactive environment, and I would love some kind of (possibly very implementation-dependent) way of catching the runtime error. The way Java does it would be ideal, I think..... Nelson's article is here http://www.modula3.org/threads/2/ [Tony, the link in your M3 bibliography is broken!] I'm running this example in a PM3/EZM3 environment right now but that's not relevant. The code I showed you *should* crash. In plain M3 it was: TextWr.ToText(NIL) But in an interactive environment, the user can do this sort of thing. It should give you a nasty error message, not crash your whole environment. Mika "Randy Coleburn" writes: >This is a MIME message. If you are reading this text, you may want to >consider changing to a mail reader or gateway that understands how to >properly handle MIME multipart messages. > >--=__PartBC941634.0__= >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: quoted-printable > >Mika: >=20 >You state that "Checked runtime errors cannot violate invariants of the = >runtime system, so it ought to be safe to ..." >=20 >Are you sure this statement is true for all implementations? >=20 >I would tend to think that SPIN was able to do this mapping for itself, = >but in general, it would be difficult to be able to do this for any = >arbitrary OS environment, esp with differences in underlying libraries and = >implementations, which is part of what Greg alluded to in the Threads = >article you reference. >=20 >Note also on pg 47 of the green book under "2.5.7 Safety" the notes about = >intrinsic safety and when the compiler makes the guarantee vs. the = >programmer. >=20 >I also note from the path in your example (ezm3) that you may not be using = >the current cm3. Is it possible that the NIL dereference problem in your = >example has been solved in a later implementation? >=20 >Regards, >Randy > >>>> Mika Nystrom 4/21/2009 5:41 PM >>> > >Hello Modula-3ers, > >I know this is a question that comes up from time to time, and I >am aware of Greg Nelson's short article in "Threads" about why=20 >Modula-3 doesn't map runtime errors to exceptions, but the Green Book >does allude to mapping runtime errors to exceptions, and I know that >the SPIN OS did that. > >How hard would this be to support in CM3? > >Attached is a transcript of an interactive session with my current >Scheme environment. I think it ought to be obvious why I ask about >exceptions. In Modula-3, from safe code, only checked runtime errors >can occur. Checked runtime errors cannot violate invariants of the >runtime system, so it ought to be safe to convert them to exceptions >that can be caught, and then permit the program to continue. =20 > >I realize this isn't *always* what you want to do, but in an interactive >environment, making the system dump core on runtime errors sort of >spoils the whole experience. > >In this application, there are many places where you may want to >raise an exception that hasn't been declared. In a non-interactive >environment, it is probably best to go for the core dump, but in >an interactive environment, it seems to me it ought to just return >control to the read-eval-print loop.... > Mika > >LITHP ITH LITHENING. >> (define wr (scheme-procedure-stubs-call '(TextWr . New) '())) >wr >> wr > >> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >#t >> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >"hello!" >> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >"" >> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >#t >> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >#t >> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >#t >> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >#t >> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >#t >> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >"hello!hello!hello!hello!hello!" >> (scheme-procedure-stubs-call '(TextWr . ToText) (list '()) '()) > > >*** >*** runtime error: >*** Segmentation violation - possible attempt to dereference NIL >*** pc =3D 0x80c69c8 =3D LockMutex + 0x28 in /usr/ports/lang/ezm3/work/e= >zm3-1.0/libs/m3core/src/thread/POSIX/ThreadPosix.m3 >*** > > use option @M3stackdump to get a stack trace >Abort > > > > > > > >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. > > >--=__PartBC941634.0__= >Content-Type: text/html; charset=US-ASCII >Content-Transfer-Encoding: quoted-printable >Content-Description: HTML > > >"> > > >
Mika:
>
 
>
You state that "Checked runtime errors cannot violate invariants of = >the runtime system, so it ought to be safe to ..."
>
 
>
Are you sure this statement is true for all implementations?> >
 
>
I would tend to think that SPIN was able to do this mapping for = >itself, but in general, it would be difficult to be able to do this for = >any arbitrary OS environment, esp with differences in underlying libraries = >and implementations, which is part of what Greg alluded to in the Threads = >article you reference.
>
 
>
Note also on pg 47 of the green book under "2.5.7 Safety" the notes = >about intrinsic safety and when the compiler makes the guarantee vs. the = >programmer.
>
 
>
I also note from the path in your example (ezm3) that you may not be = >using the current cm3.  Is it possible that the NIL dereference = >problem in your example has been solved in a later implementation?
>
 
>
Regards,
>
Randy

>>> Mika Nystrom <mika at async.caltech.edu> = >4/21/2009 5:41 PM >>>

Hello Modula-3ers,

I know = >this is a question that comes up from time to time, and I
am aware of = >Greg Nelson's short article in "Threads" about why
Modula-3 doesn't = >map runtime errors to exceptions, but the Green Book
does allude to = >mapping runtime errors to exceptions, and I know that
the SPIN OS did = >that.

How hard would this be to support in CM3?

Attached is = >a transcript of an interactive session with my current
Scheme environmen= >t.  I think it ought to be obvious why I ask about
exceptions. = >; In Modula-3, from safe code, only checked runtime errors
can = >occur.  Checked runtime errors cannot violate invariants of the
run= >time system, so it ought to be safe to convert them to exceptions
that = >can be caught, and then permit the program to continue. 

I = >realize this isn't *always* what you want to do, but in an interactive
e= >nvironment, making the system dump core on runtime errors sort of
spoils= > the whole experience.

In this application, there are many places = >where you may want to
raise an exception that hasn't been declared. = >; In a non-interactive
environment, it is probably best to go for the = >core dump, but in
an interactive environment, it seems to me it ought = >to just return
control to the read-eval-print loop....

 &nbs= >p;   Mika

LITHP ITH LITHENING.
> (define wr = >(scheme-procedure-stubs-call '(TextWr . New) '()))
wr
> wr
<= >Modula-3 object : TextWr.T, BRANDED TextWr_^%#%^__0001M>
> = >(scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '())
#t<= >BR>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) = >'())
"hello!"
> (scheme-procedure-stubs-call '(TextWr . ToText) = >(list wr) '())
""
> (scheme-procedure-stubs-call '(Wr . PutText) = >(list wr "hello!") '())
#t
> (scheme-procedure-stubs-call '(Wr . = >PutText) (list wr "hello!") '())
#t
> (scheme-procedure-stubs-call= > '(Wr . PutText) (list wr "hello!") '())
#t
> (scheme-procedure-st= >ubs-call '(Wr . PutText) (list wr "hello!") '())
#t
> (scheme-proc= >edure-stubs-call '(Wr . PutText) (list wr "hello!") '())
#t
> = >(scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '())
"hello!he= >llo!hello!hello!hello!"
> (scheme-procedure-stubs-call '(TextWr . = >ToText) (list '()) '())


***
*** runtime error:
*** &n= >bsp;  Segmentation violation - possible attempt to dereference = >NIL
***    pc =3D 0x80c69c8 =3D LockMutex + 0x28 in = >/usr/ports/lang/ezm3/work/ezm3-1.0/libs/m3core/src/thread/POSIX/ThreadPosix= >.m3
***

  use option @M3stackdump to get a stack trace
Ab= >ort






> >--=__PartBC941634.0__=-- From hosking at cs.purdue.edu Wed Apr 22 02:02:52 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Apr 2009 10:02:52 +1000 Subject: [M3devel] explanation of CheckLoadTracedRef? In-Reply-To: References: Message-ID: <19C20763-18A0-413A-9440-3D7ED0C918B1@cs.purdue.edu> On 21 Apr 2009, at 19:37, Jay wrote: > > > How bad/unportable was it the previous way, the VM-synchronized > way? > > > > Not compatible with system threading. > > > Really? NT386 wasn't VM-synchronized back in 3.6, 4.1, etc.? It was, but every system call had to be wrapped with a call to acquire the global heap lock! > Or only with great cost? Yes, taking the lock was expensive and prevented scaling on multi-cores. > I have to admit, those old import .libs, kernel32.lib, etc. I didn't > realize what was in them when I deleted them. I thought they were > just regular import .libs. There was also the work to wrap all dll symbols to acquire the lock. > I think I got luckly in that the overlap between me deleting them > and you removing VM-synchronized GC was small or zero. You should have seen the mess it was before... ;-) > > You should *never* access a field in the heap in C code! All > > accesses to traced fields in the heap must take place in Modula-3. > > Otherwise things will break! C wrappers should not do anything other > > than forward calls to C library calls. They should not perform heap > > accesses. > > > Ok, that makes sense. > Important "out" is the accessing stack is always ok. Yes, so long as a references to an object is held on the stack then it is safe to pass an address within it to external calls. Thus, many C functions can take VAR arguments that may end being references to the fields of objects. The compiler injects the necessary CheckLoad/ CheckStore operations when passing VAR parameters, etc., and the GC maintains the invariant that all stack-referenced objects don't move, stay black (for incremental GC), and remain dirty (for generational GC). > But this is a requirement I didn't keep in mind. > Now, luckily, the C wrappers are all relatively thin and not difficult > to re-review in their entirety. Right. I think I did see you compute and pass an offset to C code, but that may have only been in code you e-mailed me for perusal rather than code that got checked in. Might be worth reviewing... > But, take for example "open". > The first parameter to it is bound to be in the heap. The ambiguous roots garbage collector we use maintains the invariant that pointers to the interior of heap objects from the stack *pin* that object in the heap: it will not move while the pointer from the stack exists, and invariants will be maintained so that its contenst can be manipulated safely even in the face of incremental and generational GC. > But probably it is untraced or somehow ok, since it does > come from a module used primarily for C interop. Certainly, C code should never be manipulating the *traced* fields of traced heap objects. It is fine for it to manipulate the untraced fields of traced heap objects. > And, the line between C wrappers and the "C library" that they > forward to > does not exist. > If I, say, pass a VAR to a VAR..no check is made? Not sure what you mean by this. Any call that passes traced VAR params will generate a check as necessary before the call. > Important to declare extern/C functions as taking UNTRACED REF and > not VAR? No, VAR is fine. So long as the VAR value being passed is not traced. > > I think you are confusing incremental and incremental GC. > You assume I understand more than I do (I assume you have a typo. :)) ;-) > "generational" -- the concept that most objects die young. > (aka most objects could have been allocated on the stack...) Not quite. The idea is that the likelihood of an object dying is a function of its age. There is a *weak* generational hypothesis that "most objects die young", and a *strong* generational hypothesis that "the older an object is the less likely it is to die". Many (but not all) programs support these hypotheses, which permits generational GC to focus effort where it is likely to be profitable (i.e., to free up a lot of space). > But does that imply detailed implementation choices, or is just like > a "guiding principle"? > I guess it implies the heap is split into at least two generations, > old and young. > Though I guess in reality there is a range of young, less young, > lesser young, least young, etc. Right, many different collectors have exploited age in this way. For the M3 collector we have just two generations: old and young. > And that has objects age, they should be moved from young to old > heaps, and references to them either updated right away, or "caught" > upon use and updated then...something like that. Old-space objects are "clean" if they contain no references to young- space objects. The Modula-3 compiler injects checks to make sure that whenever we store a reference into a clean old-space object it is marked "dirty". When a young-space collection occurs we must process the references in dirty old-space objects as roots into the young-space. > "incremental" -- don't pause the world.. Not quite. The opposite of stop-the-world (stopping all the mutator threads to process their stacks) is on-the-fly. Incremental refers to the ability to interleave GC work with mutator work. If the GC work can be interleaved with mutator threads without stopping the mutator threads at each increment then the collector is said to be concurrent (GC work proceeds concurrently with mutator work). The current M3 collector has a stop-the-world non-moving phase, followed by an concurrent copying phase. I have some incomplete work that will also make the M3 collector on-the-fly (no STW phase) and parallel (multiple GC threads can operate concurrently). Hope all this helps! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Apr 22 02:10:09 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Apr 2009 10:10:09 +1000 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <20090421122648.GB25465@topoi.pooq.com> References: <49EC7A06.5040403@cox.net> <20090421122648.GB25465@topoi.pooq.com> Message-ID: I'd prefer something like TAGGEDINT or some such. But I am still not convinced that the minimalist proposal and this proposal differ in any significant way. On 21 Apr 2009, at 22:26, hendrik at topoi.pooq.com wrote: > On Mon, Apr 20, 2009 at 08:35:02AM -0500, Rodney M. Bates wrote: >> >> --------------------------------------------------------------------- >> My (Rodney's) "safe" proposal: >> >> There is a new type named TAGABLE. It is a subrange of INTEGER, >> whose > > Please spell it TAGGABLE. TAG doubles its last consonant when adding > suffixes: TAGGED, TAGGING. > > -- hendrik From hosking at cs.purdue.edu Wed Apr 22 02:11:53 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Apr 2009 10:11:53 +1000 Subject: [M3devel] crummy ThreadWin32.m3 implementation? In-Reply-To: References: <14FDB4AD-26AA-43B0-BD25-925C596452EF@cs.purdue.edu> <3577783C-1892-435E-95E3-5E967C9BA638@cs.purdue.edu> Message-ID: <591C91AF-5362-43FE-8564-7FB9F4D32ECB@cs.purdue.edu> I'd be curious what OpenJDK does on Windows... On 21 Apr 2009, at 22:46, Jay wrote: > did more "research" (search the web..) > > It sounds like: > if fairness not critical, and pre NT 4.0 compat is needed, there > are options where mutex/lock=criticalsection > > If fairness is important, and NT 4.0 can be used, and perf can be > degraded, then mutex/lock=kernel mutex, and use the SignalAndWait > function > > They never seem to use a global lock like ours. > > Should we maybe adopt Boost's code? > e.g.: > > http://svn.boost.org/trac/boost/browser/trunk/boost/thread/win32/mutex.hpp > http://svn.boost.org/trac/boost/browser/trunk/boost/thread/win32/condition_variable.hpp > > I don't know, it all seems kind of unforunate. > > Perhaps there should be two types of locks, one that can be > associated with a conditionvariable (kernel mutex), one that cannot > (criticalsection)? > > I guess our implementation is quite simple and solves "all the > problems" by throwing scalability right out -- lots of independent > threads acquiring lots of independent locks will all interfere > somewhat with each other, but not a ton. The "giant" lock protects > too much data, but not for long durations. > > It might be interesting to see what cygwin does..but I > notice..pthread is a superset, e.g. timedwait, trylock, etc. > > - Jay > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Tue, 21 Apr 2009 04:41:55 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? > > I'm not keen on it. > Checking the version and having two implementation switched between > at initialization would be ok though -- actually using function > pointers like so: > > void DoSomething_v2(void) { } > void DoSomething_v1(void) { } > void DoSomething_init(void) > { > if (... ) > DoSomething = DoSomething_v1; > else > DoSomething = DoSomething_v2; > DoSomething(); > } > > void (*DoSomething)(void) = DoSomething_init; > > Something more if switching multiple pointers though -- switching a > pointer to a struct of function pointers. > > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 21 Apr 2009 14:33:29 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? > > Might not be such a bad thing ;-) > > On 21 Apr 2009, at 14:14, Jay wrote: > > Only if you drop support for pre-Vista versions. > > - Jay > > > > > From: hosking at cs.purdue.edu > > To: jay.krell at cornell.edu > > Date: Tue, 21 Apr 2009 07:53:57 +1000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? > > > > Also, note that win32 now supports CVs directly! No need for > > semaphores. > > > > On 20 Apr 2009, at 19:11, Jay wrote: > > > > > > > > Searching the web...finds this which seems very relevant: > > > > > > http://birrell.org/andrew/papers/ImplementingCVs.pdf > > > > > > - Jay > > > > > > > > > > > > ---------------------------------------- > > >> From: jay.krell at cornell.edu > > >> To: m3devel at elegosoft.com > > >> Date: Mon, 20 Apr 2009 08:47:21 +0000 > > >> Subject: [M3devel] crummy ThreadWin32.m3 implementation? > > >> > > >> > > >> Um, ThreadWin32.m3 looks pretty crummy -- all LockMutex calls > > >> bottleneck on one giant lock. .v0 and .v1 aren't bad this way. > > >> > > >> > > >> - Jay > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 22 02:54:00 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 22 Apr 2009 00:54:00 +0000 Subject: [M3devel] explanation of CheckLoadTracedRef? In-Reply-To: <19C20763-18A0-413A-9440-3D7ED0C918B1@cs.purdue.edu> References: <19C20763-18A0-413A-9440-3D7ED0C918B1@cs.purdue.edu> Message-ID: Yes this helps, thank you. Maybe checkin under doc? One thing you didn't understand my wording about and you seemed to contradict is "VAR to VAR". PROCEDURE F1() = VAR i; BEGIN F2(i); END F1; PROCEDURE F2(VAR a:INTEGER)= BEGIN F3(i); END F2; PROCEDURE F3(VAR a:INTEGER)= BEGIN a := 1; END F3; Where are the calls to CheckLoad/StoreTracedRef? (Duh, I can try it out..) It seems redundant to put them "everywhere". Esp. it seems that F2 shouldn't have do anything. But throw in that F3 might extern and that is unclear. So I just made up a suggestion that VAR is not good to pass to C code. That checks are inserted when 1) a pointer is dereferenced -- loaded or stored in Modula-3 or 2) a pointer becomes untraced (var becomes untraced ref, among others). > Right. I think I did see you compute and pass an offset to C code I had something like that very recently but think I didn't set it or commit it. I had something like: size_t offset; Init(Mutex* root, int* interior) { offset = (size_t)interior - (size_t)root; } DoSomething(Mutex* anotherRoot) { int* interior = (int*)(offset + (size_t)anotherRoot); printf("%d\n", *interior); } but I came up with a way to avoid that I think, and then rolled it all back or something anyway. - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] explanation of CheckLoadTracedRef? Date: Wed, 22 Apr 2009 10:02:52 +1000 On 21 Apr 2009, at 19:37, Jay wrote: > > How bad/unportable was it the previous way, the VM-synchronized way? > > Not compatible with system threading. Really? NT386 wasn't VM-synchronized back in 3.6, 4.1, etc.? It was, but every system call had to be wrapped with a call to acquire the global heap lock! Or only with great cost? Yes, taking the lock was expensive and prevented scaling on multi-cores. I have to admit, those old import .libs, kernel32.lib, etc. I didn't realize what was in them when I deleted them. I thought they were just regular import .libs. There was also the work to wrap all dll symbols to acquire the lock. I think I got luckly in that the overlap between me deleting them and you removing VM-synchronized GC was small or zero. You should have seen the mess it was before... ;-) > You should *never* access a field in the heap in C code! All > accesses to traced fields in the heap must take place in Modula-3. > Otherwise things will break! C wrappers should not do anything other > than forward calls to C library calls. They should not perform heap > accesses. Ok, that makes sense. Important "out" is the accessing stack is always ok. Yes, so long as a references to an object is held on the stack then it is safe to pass an address within it to external calls. Thus, many C functions can take VAR arguments that may end being references to the fields of objects. The compiler injects the necessary CheckLoad/CheckStore operations when passing VAR parameters, etc., and the GC maintains the invariant that all stack-referenced objects don't move, stay black (for incremental GC), and remain dirty (for generational GC). But this is a requirement I didn't keep in mind. Now, luckily, the C wrappers are all relatively thin and not difficult to re-review in their entirety. Right. I think I did see you compute and pass an offset to C code, but that may have only been in code you e-mailed me for perusal rather than code that got checked in. Might be worth reviewing... But, take for example "open". The first parameter to it is bound to be in the heap. The ambiguous roots garbage collector we use maintains the invariant that pointers to the interior of heap objects from the stack *pin* that object in the heap: it will not move while the pointer from the stack exists, and invariants will be maintained so that its contenst can be manipulated safely even in the face of incremental and generational GC. But probably it is untraced or somehow ok, since it does come from a module used primarily for C interop. Certainly, C code should never be manipulating the *traced* fields of traced heap objects. It is fine for it to manipulate the untraced fields of traced heap objects. And, the line between C wrappers and the "C library" that they forward to does not exist. If I, say, pass a VAR to a VAR..no check is made? Not sure what you mean by this. Any call that passes traced VAR params will generate a check as necessary before the call. Important to declare extern/C functions as taking UNTRACED REF and not VAR? No, VAR is fine. So long as the VAR value being passed is not traced. > I think you are confusing incremental and incremental GC. You assume I understand more than I do (I assume you have a typo. :)) ;-) "generational" -- the concept that most objects die young. (aka most objects could have been allocated on the stack...) Not quite. The idea is that the likelihood of an object dying is a function of its age. There is a *weak* generational hypothesis that "most objects die young", and a *strong* generational hypothesis that "the older an object is the less likely it is to die". Many (but not all) programs support these hypotheses, which permits generational GC to focus effort where it is likely to be profitable (i.e., to free up a lot of space). But does that imply detailed implementation choices, or is just like a "guiding principle"? I guess it implies the heap is split into at least two generations, old and young. Though I guess in reality there is a range of young, less young, lesser young, least young, etc. Right, many different collectors have exploited age in this way. For the M3 collector we have just two generations: old and young. And that has objects age, they should be moved from young to old heaps, and references to them either updated right away, or "caught" upon use and updated then...something like that. Old-space objects are "clean" if they contain no references to young-space objects. The Modula-3 compiler injects checks to make sure that whenever we store a reference into a clean old-space object it is marked "dirty". When a young-space collection occurs we must process the references in dirty old-space objects as roots into the young-space. "incremental" -- don't pause the world.. Not quite. The opposite of stop-the-world (stopping all the mutator threads to process their stacks) is on-the-fly. Incremental refers to the ability to interleave GC work with mutator work. If the GC work can be interleaved with mutator threads without stopping the mutator threads at each increment then the collector is said to be concurrent (GC work proceeds concurrently with mutator work). The current M3 collector has a stop-the-world non-moving phase, followed by an concurrent copying phase. I have some incomplete work that will also make the M3 collector on-the-fly (no STW phase) and parallel (multiple GC threads can operate concurrently). Hope all this helps! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Apr 22 04:14:13 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Apr 2009 12:14:13 +1000 Subject: [M3devel] Latest ThreadPThread In-Reply-To: <49EE1088.6030006@taltos.org> References: <8510055B-CBC6-4A02-BAFA-B26AF9A827EC@cs.purdue.edu> <49EE1088.6030006@taltos.org> Message-ID: <16FF28FE-78F3-4C16-A756-72C8D55437D5@cs.purdue.edu> On 22 Apr 2009, at 04:29, Carson Gaspar wrote: > Tony Hosking wrote: > >> I'm pretty sure that is only in the user-level threading model, >> where thread switches only occur on delivery of a signal to the >> process. I am unaware of any OS/hardware that will deliver a thread >> switch signal in the middle of INC/DEC. So, effectively, for user >> level threads INC/DEC can be assumed atomic. That's what the >> comments are meant to imply. Outside ThreadPosix, all other uses >> of INC/DEC manipulate state that is already protected appropriately >> by a lock so should be thread safe. > > I'm not sure what you mean by INC/DEC... but if it involves changing > a value in memory (as opposed to a register), then it is _not_ > atomic and _must_ use a lock. The most common mistake I've seen is a > variable modified in a signal handler and in the main code, > especially SIGCHLD. "nchildren++" is _not_ signal or thread safe. Indeed, on a multi-processor with system-scheduled threads that is the case. My comments pertain only to the rather narrow implementation of single-processor user-level threads using signal-handling that the Modula-3 user-level threads implementation uses/used. That implementation is pretty much unused on modern platforms where we support proper hardware-level parallelism. There, all memory operations must be protected by proper synchronization. From hosking at cs.purdue.edu Wed Apr 22 04:26:01 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Apr 2009 12:26:01 +1000 Subject: [M3devel] an old, recurring issue: mapping runtime errors to exceptions? In-Reply-To: <200904212241.n3LMfJB7032643@camembert.async.caltech.edu> References: <200904212241.n3LMfJB7032643@camembert.async.caltech.edu> Message-ID: CM3 does map some (I'm not sure if all) run-time errors to exceptions. See RuntimeError.i3 for details of what exceptions might occur. On 22 Apr 2009, at 08:41, Mika Nystrom wrote: > > Well the point of "safety" is that the system can guarantee that the > runtime environment hasn't been damaged by a misbehaving program, no? > > In fact, in Threads 3 there are not one but *two* reports of > implementations that "reflect" runtime errors as exceptions. On > of them is SPIN, the other is the commercial CM3 with JVM. > > See > > http://www.modula3.org/threads/3/ > > Nelson's article in Threads 2 doesn't give the possibility of having > had the runtime invariants violated as a reason to abort. His > arguments are more practical, having to do with debugging. I agree, > and I think that the default method of dealing with runtime errors > should be to abort the program. But it just is very unfriendly in > an interactive environment, and I would love some kind of (possibly > very implementation-dependent) way of catching the runtime error. > The way Java does it would be ideal, I think..... > > Nelson's article is here > > http://www.modula3.org/threads/2/ > > [Tony, the link in your M3 bibliography is broken!] > > I'm running this example in a PM3/EZM3 environment right now but > that's not relevant. The code I showed you *should* crash. In > plain M3 it was: > > TextWr.ToText(NIL) > > But in an interactive environment, the user can do this sort of > thing. It should give you a nasty error message, not crash your > whole environment. > > Mika > > > > "Randy Coleburn" writes: >> This is a MIME message. If you are reading this text, you may want to >> consider changing to a mail reader or gateway that understands how to >> properly handle MIME multipart messages. >> >> --=__PartBC941634.0__= >> Content-Type: text/plain; charset=US-ASCII >> Content-Transfer-Encoding: quoted-printable >> >> Mika: >> =20 >> You state that "Checked runtime errors cannot violate invariants of >> the = >> runtime system, so it ought to be safe to ..." >> =20 >> Are you sure this statement is true for all implementations? >> =20 >> I would tend to think that SPIN was able to do this mapping for >> itself, = >> but in general, it would be difficult to be able to do this for any = >> arbitrary OS environment, esp with differences in underlying >> libraries and = >> implementations, which is part of what Greg alluded to in the >> Threads = >> article you reference. >> =20 >> Note also on pg 47 of the green book under "2.5.7 Safety" the notes >> about = >> intrinsic safety and when the compiler makes the guarantee vs. the = >> programmer. >> =20 >> I also note from the path in your example (ezm3) that you may not >> be using = >> the current cm3. Is it possible that the NIL dereference problem >> in your = >> example has been solved in a later implementation? >> =20 >> Regards, >> Randy >> >>>>> Mika Nystrom 4/21/2009 5:41 PM >>> >> >> Hello Modula-3ers, >> >> I know this is a question that comes up from time to time, and I >> am aware of Greg Nelson's short article in "Threads" about why=20 >> Modula-3 doesn't map runtime errors to exceptions, but the Green Book >> does allude to mapping runtime errors to exceptions, and I know that >> the SPIN OS did that. >> >> How hard would this be to support in CM3? >> >> Attached is a transcript of an interactive session with my current >> Scheme environment. I think it ought to be obvious why I ask about >> exceptions. In Modula-3, from safe code, only checked runtime errors >> can occur. Checked runtime errors cannot violate invariants of the >> runtime system, so it ought to be safe to convert them to exceptions >> that can be caught, and then permit the program to continue. =20 >> >> I realize this isn't *always* what you want to do, but in an >> interactive >> environment, making the system dump core on runtime errors sort of >> spoils the whole experience. >> >> In this application, there are many places where you may want to >> raise an exception that hasn't been declared. In a non-interactive >> environment, it is probably best to go for the core dump, but in >> an interactive environment, it seems to me it ought to just return >> control to the read-eval-print loop.... > >> Mika >> >> LITHP ITH LITHENING. >>> (define wr (scheme-procedure-stubs-call '(TextWr . New) '())) >> wr >>> wr >> >>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >> #t >>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >> "hello!" >>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >> "" >>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >> #t >>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >> #t >>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >> #t >>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >> #t >>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >> #t >>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >> "hello!hello!hello!hello!hello!" >>> (scheme-procedure-stubs-call '(TextWr . ToText) (list '()) '()) >> >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL >> *** pc =3D 0x80c69c8 =3D LockMutex + 0x28 in /usr/ports/lang/ >> ezm3/work/e= >> zm3-1.0/libs/m3core/src/thread/POSIX/ThreadPosix.m3 >> *** >> >> use option @M3stackdump to get a stack trace >> Abort >> >> >> >> >> >> >> >> 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. >> >> >> --=__PartBC941634.0__= >> Content-Type: text/html; charset=US-ASCII >> Content-Transfer-Encoding: quoted-printable >> Content-Description: HTML >> >> >> > charset=3Diso-8859-15= >> "> >> >> >>
Mika:
>>
 
>>
You state that "Checked runtime errors cannot violate >> invariants of = >> the runtime system, so it ought to be safe to ..."
>>
 
>>
Are you sure this statement is true for all >> implementations?>> >>
 
>>
I would tend to think that SPIN was able to do this mapping >> for = >> itself, but in general, it would be difficult to be able to do this >> for = >> any arbitrary OS environment, esp with differences in underlying >> libraries = >> and implementations, which is part of what Greg alluded to in the >> Threads = >> article you reference.
>>
 
>>
Note also on pg 47 of the green book under "2.5.7 Safety" the >> notes = >> about intrinsic safety and when the compiler makes the guarantee >> vs. the = >> programmer.
>>
 
>>
I also note from the path in your example (ezm3) that you may >> not be = >> using the current cm3.  Is it possible that the NIL >> dereference = >> problem in your example has been solved in a later implementation?> DIV> >>
 
>>
Regards,
>>
Randy

>>> Mika Nystrom <mika at async.caltech.edu >> > = >> 4/21/2009 5:41 PM >>>

Hello Modula-3ers,

I >> know = >> this is a question that comes up from time to time, and I
am >> aware of = >> Greg Nelson's short article in "Threads" about why
Modula-3 >> doesn't = >> map runtime errors to exceptions, but the Green Book
does allude >> to = >> mapping runtime errors to exceptions, and I know that
the SPIN >> OS did = >> that.

How hard would this be to support in CM3? >>

Attached is = >> a transcript of an interactive session with my current
Scheme >> environmen= >> t.  I think it ought to be obvious why I ask >> about
exceptions. = >> ; In Modula-3, from safe code, only checked runtime errors
can = >> occur.  Checked runtime errors cannot violate invariants of >> the
run= >> time system, so it ought to be safe to convert them to >> exceptions
that = >> can be caught, and then permit the program to continue.  >>

I = >> realize this isn't *always* what you want to do, but in an >> interactive
e= >> nvironment, making the system dump core on runtime errors sort >> of
spoils= >> the whole experience.

In this application, there are many >> places = >> where you may want to
raise an exception that hasn't been >> declared. = >> ; In a non-interactive
environment, it is probably best to go >> for the = >> core dump, but in
an interactive environment, it seems to me it >> ought = >> to just return
control to the read-eval-print >> loop....

 &nbs= >> p;   Mika

LITHP ITH LITHENING.
> (define wr = >> (scheme-procedure-stubs-call '(TextWr . New) '()))
wr
> >> wr
<= >> Modula-3 object : TextWr.T, BRANDED TextWr_^%#%^__0001M>
> = >> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") >> '())
#t<= >> BR>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) = >> '())
"hello!"
> (scheme-procedure-stubs-call '(TextWr . >> ToText) = >> (list wr) '())
""
> (scheme-procedure-stubs-call '(Wr . >> PutText) = >> (list wr "hello!") '())
#t
> (scheme-procedure-stubs-call >> '(Wr . = >> PutText) (list wr "hello!") '())
#t
> (scheme-procedure- >> stubs-call= >> '(Wr . PutText) (list wr "hello!") '())
#t
> (scheme- >> procedure-st= >> ubs-call '(Wr . PutText) (list wr "hello!") '())
#t
> >> (scheme-proc= >> edure-stubs-call '(Wr . PutText) (list wr "hello!") >> '())
#t
> = >> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) >> '())
"hello!he= >> llo!hello!hello!hello!"
> (scheme-procedure-stubs-call >> '(TextWr . = >> ToText) (list '()) '())


***
*** runtime >> error:
*** &n= >> bsp;  Segmentation violation - possible attempt to dereference = >> NIL
***    pc =3D 0x80c69c8 =3D LockMutex + 0x28 >> in = >> /usr/ports/lang/ezm3/work/ezm3-1.0/libs/m3core/src/thread/POSIX/ >> ThreadPosix= >> .m3
***

  use option @M3stackdump to get a stack >> trace
Ab= >> ort






>> >> --=__PartBC941634.0__=-- From mika at async.caltech.edu Wed Apr 22 04:38:18 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 21 Apr 2009 19:38:18 -0700 Subject: [M3devel] an old, recurring issue: mapping runtime errors to exceptions? In-Reply-To: Your message of "Wed, 22 Apr 2009 12:26:01 +1000." Message-ID: <200904220238.n3M2cIWk040392@camembert.async.caltech.edu> It's as simple as that!? Wow! Tony Hosking writes: >CM3 does map some (I'm not sure if all) run-time errors to >exceptions. See RuntimeError.i3 for details of what exceptions might >occur. > >On 22 Apr 2009, at 08:41, Mika Nystrom wrote: > >> > Well the point of "safety" is that the system can guarantee that the >> runtime environment hasn't been damaged by a misbehaving program, no? >> >> In fact, in Threads 3 there are not one but *two* reports of >> implementations that "reflect" runtime errors as exceptions. On >> of them is SPIN, the other is the commercial CM3 with JVM. >> >> See >> >> http://www.modula3.org/threads/3/ >> >> Nelson's article in Threads 2 doesn't give the possibility of having >> had the runtime invariants violated as a reason to abort. His >> arguments are more practical, having to do with debugging. I agree, >> and I think that the default method of dealing with runtime errors >> should be to abort the program. But it just is very unfriendly in >> an interactive environment, and I would love some kind of (possibly >> very implementation-dependent) way of catching the runtime error. >> The way Java does it would be ideal, I think..... >> >> Nelson's article is here >> >> http://www.modula3.org/threads/2/ >> >> [Tony, the link in your M3 bibliography is broken!] >> >> I'm running this example in a PM3/EZM3 environment right now but >> that's not relevant. The code I showed you *should* crash. In >> plain M3 it was: >> >> TextWr.ToText(NIL) >> >> But in an interactive environment, the user can do this sort of >> thing. It should give you a nasty error message, not crash your >> whole environment. >> >> Mika >> >> >> >> "Randy Coleburn" writes: >>> This is a MIME message. If you are reading this text, you may want to >>> consider changing to a mail reader or gateway that understands how to >>> properly handle MIME multipart messages. >>> >>> --=__PartBC941634.0__= >>> Content-Type: text/plain; charset=US-ASCII >>> Content-Transfer-Encoding: quoted-printable >>> >>> Mika: >>> =20 >>> You state that "Checked runtime errors cannot violate invariants of >>> the = >>> runtime system, so it ought to be safe to ..." >>> =20 >>> Are you sure this statement is true for all implementations? >>> =20 >>> I would tend to think that SPIN was able to do this mapping for >>> itself, = >>> but in general, it would be difficult to be able to do this for any = >>> arbitrary OS environment, esp with differences in underlying >>> libraries and = >>> implementations, which is part of what Greg alluded to in the >>> Threads = >>> article you reference. >>> =20 >>> Note also on pg 47 of the green book under "2.5.7 Safety" the notes >>> about = >>> intrinsic safety and when the compiler makes the guarantee vs. the = >>> programmer. >>> =20 >>> I also note from the path in your example (ezm3) that you may not >>> be using = >>> the current cm3. Is it possible that the NIL dereference problem >>> in your = >>> example has been solved in a later implementation? >>> =20 >>> Regards, >>> Randy >>> >>>>>> Mika Nystrom 4/21/2009 5:41 PM >>> >>> >>> Hello Modula-3ers, >>> >>> I know this is a question that comes up from time to time, and I >>> am aware of Greg Nelson's short article in "Threads" about why=20 >>> Modula-3 doesn't map runtime errors to exceptions, but the Green Book >>> does allude to mapping runtime errors to exceptions, and I know that >>> the SPIN OS did that. >>> >>> How hard would this be to support in CM3? >>> >>> Attached is a transcript of an interactive session with my current >>> Scheme environment. I think it ought to be obvious why I ask about >>> exceptions. In Modula-3, from safe code, only checked runtime errors >>> can occur. Checked runtime errors cannot violate invariants of the >>> runtime system, so it ought to be safe to convert them to exceptions >>> that can be caught, and then permit the program to continue. =20 >>> >>> I realize this isn't *always* what you want to do, but in an >>> interactive >>> environment, making the system dump core on runtime errors sort of >>> spoils the whole experience. >>> >>> In this application, there are many places where you may want to >>> raise an exception that hasn't been declared. In a non-interactive >>> environment, it is probably best to go for the core dump, but in >>> an interactive environment, it seems to me it ought to just return >>> control to the read-eval-print loop.... >> >>> Mika >>> >>> LITHP ITH LITHENING. >>>> (define wr (scheme-procedure-stubs-call '(TextWr . New) '())) >>> wr >>>> wr >>> >>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>> #t >>>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >>> "hello!" >>>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >>> "" >>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>> #t >>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>> #t >>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>> #t >>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>> #t >>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>> #t >>>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >>> "hello!hello!hello!hello!hello!" >>>> (scheme-procedure-stubs-call '(TextWr . ToText) (list '()) '()) >>> >>> >>> *** >>> *** runtime error: >>> *** Segmentation violation - possible attempt to dereference NIL >>> *** pc =3D 0x80c69c8 =3D LockMutex + 0x28 in /usr/ports/lang/ >>> ezm3/work/e= >>> zm3-1.0/libs/m3core/src/thread/POSIX/ThreadPosix.m3 >>> *** >>> >>> use option @M3stackdump to get a stack trace >>> Abort >>> >>> >>> >>> >>> >>> >>> >>> 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. >>> >>> >>> --=__PartBC941634.0__= >>> Content-Type: text/html; charset=US-ASCII >>> Content-Transfer-Encoding: quoted-printable >>> Content-Description: HTML >>> >>> >>> >> charset=3Diso-8859-15= >>> "> >>> >>> >>>
Mika:
>>>
 
>>>
You state that "Checked runtime errors cannot violate >>> invariants of = >>> the runtime system, so it ought to be safe to ..."
>>>
 
>>>
Are you sure this statement is true for all >>> implementations?>>> >>>
 
>>>
I would tend to think that SPIN was able to do this mapping >>> for = >>> itself, but in general, it would be difficult to be able to do this >>> for = >>> any arbitrary OS environment, esp with differences in underlying >>> libraries = >>> and implementations, which is part of what Greg alluded to in the >>> Threads = >>> article you reference.
>>>
 
>>>
Note also on pg 47 of the green book under "2.5.7 Safety" the >>> notes = >>> about intrinsic safety and when the compiler makes the guarantee >>> vs. the = >>> programmer.
>>>
 
>>>
I also note from the path in your example (ezm3) that you may >>> not be = >>> using the current cm3.  Is it possible that the NIL >>> dereference = >>> problem in your example has been solved in a later implementation?>> DIV> >>>
 
>>>
Regards,
>>>
Randy

>>> Mika Nystrom <mika at async.caltech.edu >>> > = >>> 4/21/2009 5:41 PM >>>

Hello Modula-3ers,

I >>> know = >>> this is a question that comes up from time to time, and I
am >>> aware of = >>> Greg Nelson's short article in "Threads" about why
Modula-3 >>> doesn't = >>> map runtime errors to exceptions, but the Green Book
does allude >>> to = >>> mapping runtime errors to exceptions, and I know that
the SPIN >>> OS did = >>> that.

How hard would this be to support in CM3? >>>

Attached is = >>> a transcript of an interactive session with my current
Scheme >>> environmen= >>> t.  I think it ought to be obvious why I ask >>> about
exceptions. = >>> ; In Modula-3, from safe code, only checked runtime errors
can = >>> occur.  Checked runtime errors cannot violate invariants of >>> the
run= >>> time system, so it ought to be safe to convert them to >>> exceptions
that = >>> can be caught, and then permit the program to continue.  >>>

I = >>> realize this isn't *always* what you want to do, but in an >>> interactive
e= >>> nvironment, making the system dump core on runtime errors sort >>> of
spoils= >>> the whole experience.

In this application, there are many >>> places = >>> where you may want to
raise an exception that hasn't been >>> declared. = >>> ; In a non-interactive
environment, it is probably best to go >>> for the = >>> core dump, but in
an interactive environment, it seems to me it >>> ought = >>> to just return
control to the read-eval-print >>> loop....

 &nbs= >>> p;   Mika

LITHP ITH LITHENING.
> (define wr = >>> (scheme-procedure-stubs-call '(TextWr . New) '()))
wr
> >>> wr
<= >>> Modula-3 object : TextWr.T, BRANDED TextWr_^%#%^__0001M>
> = >>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") >>> '())
#t<= >>> BR>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) = >>> '())
"hello!"
> (scheme-procedure-stubs-call '(TextWr . >>> ToText) = >>> (list wr) '())
""
> (scheme-procedure-stubs-call '(Wr . >>> PutText) = >>> (list wr "hello!") '())
#t
> (scheme-procedure-stubs-call >>> '(Wr . = >>> PutText) (list wr "hello!") '())
#t
> (scheme-procedure- >>> stubs-call= >>> '(Wr . PutText) (list wr "hello!") '())
#t
> (scheme- >>> procedure-st= >>> ubs-call '(Wr . PutText) (list wr "hello!") '())
#t
> >>> (scheme-proc= >>> edure-stubs-call '(Wr . PutText) (list wr "hello!") >>> '())
#t
> = >>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) >>> '())
"hello!he= >>> llo!hello!hello!hello!"
> (scheme-procedure-stubs-call >>> '(TextWr . = >>> ToText) (list '()) '())


***
*** runtime >>> error:
*** &n= >>> bsp;  Segmentation violation - possible attempt to dereference = >>> NIL
***    pc =3D 0x80c69c8 =3D LockMutex + 0x28 >>> in = >>> /usr/ports/lang/ezm3/work/ezm3-1.0/libs/m3core/src/thread/POSIX/ >>> ThreadPosix= >>> .m3
***

  use option @M3stackdump to get a stack >>> trace
Ab= >>> ort






>>> >>> --=__PartBC941634.0__=-- From hosking at cs.purdue.edu Wed Apr 22 04:37:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Apr 2009 12:37:36 +1000 Subject: [M3devel] explanation of CheckLoadTracedRef? In-Reply-To: References: <19C20763-18A0-413A-9440-3D7ED0C918B1@cs.purdue.edu> Message-ID: I believe there is just one check when the parameter is first passed. On 22 Apr 2009, at 10:54, Jay wrote: > Yes this helps, thank you. Maybe checkin under doc? One thing you > didn't understand my wording about and you seemed to contradict is > "VAR to VAR". > > > PROCEDURE F1() = > VAR i; > BEGIN > F2(i); > END F1; > > > PROCEDURE F2(VAR a:INTEGER)= > BEGIN > F3(i); > END F2; > > > PROCEDURE F3(VAR a:INTEGER)= > BEGIN > a := 1; > END F3; > > > Where are the calls to CheckLoad/StoreTracedRef? > (Duh, I can try it out..) > It seems redundant to put them "everywhere". > Esp. it seems that F2 shouldn't have do anything. > > > But throw in that F3 might extern and that is unclear. > So I just made up a suggestion that VAR is not good to pass to C code. > That checks are inserted when 1) a pointer is dereferenced -- loaded > or stored in Modula-3 or 2) a > pointer becomes untraced (var becomes untraced ref, among others). > > > > Right. I think I did see you compute and pass an offset to C code > > > I had something like that very recently but think I didn't set it or > commit it. > I had something like: > > > size_t offset; > > > Init(Mutex* root, int* interior) > { > offset = (size_t)interior - (size_t)root; > } > > > DoSomething(Mutex* anotherRoot) > { > int* interior = (int*)(offset + (size_t)anotherRoot); > printf("%d\n", *interior); > } > > > but I came up with a way to avoid that I think, and then rolled it > all back or something anyway. > > > > - Jay > > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] explanation of CheckLoadTracedRef? > Date: Wed, 22 Apr 2009 10:02:52 +1000 > > On 21 Apr 2009, at 19:37, Jay wrote: > > > > How bad/unportable was it the previous way, the VM-synchronized > way? > > > > Not compatible with system threading. > > > Really? NT386 wasn't VM-synchronized back in 3.6, 4.1, etc.? > > It was, but every system call had to be wrapped with a call to > acquire the global heap lock! > > Or only with great cost? > > Yes, taking the lock was expensive and prevented scaling on multi- > cores. > > I have to admit, those old import .libs, kernel32.lib, etc. I didn't > realize what was in them when I deleted them. I thought they were > just regular import .libs. > > There was also the work to wrap all dll symbols to acquire the lock. > > I think I got luckly in that the overlap between me deleting them > and you removing VM-synchronized GC was small or zero. > > You should have seen the mess it was before... ;-) > > > You should *never* access a field in the heap in C code! All > > accesses to traced fields in the heap must take place in Modula-3. > > Otherwise things will break! C wrappers should not do anything other > > than forward calls to C library calls. They should not perform heap > > accesses. > > > Ok, that makes sense. > Important "out" is the accessing stack is always ok. > > Yes, so long as a references to an object is held on the stack then > it is safe to pass an address within it to external calls. Thus, > many C functions can take VAR arguments that may end being > references to the fields of objects. The compiler injects the > necessary CheckLoad/CheckStore operations when passing VAR > parameters, etc., and the GC maintains the invariant that all stack- > referenced objects don't move, stay black (for incremental GC), and > remain dirty (for generational GC). > > But this is a requirement I didn't keep in mind. > Now, luckily, the C wrappers are all relatively thin and not difficult > to re-review in their entirety. > > Right. I think I did see you compute and pass an offset to C code, > but that may have only been in code you e-mailed me for perusal > rather than code that got checked in. Might be worth reviewing... > > But, take for example "open". > The first parameter to it is bound to be in the heap. > > The ambiguous roots garbage collector we use maintains the invariant > that pointers to the interior of heap objects from the stack *pin* > that object in the heap: it will not move while the pointer from the > stack exists, and invariants will be maintained so that its contenst > can be manipulated safely even in the face of incremental and > generational GC. > > But probably it is untraced or somehow ok, since it does > come from a module used primarily for C interop. > > Certainly, C code should never be manipulating the *traced* fields > of traced heap objects. It is fine for it to manipulate the > untraced fields of traced heap objects. > > And, the line between C wrappers and the "C library" that they > forward to > does not exist. > If I, say, pass a VAR to a VAR..no check is made? > > Not sure what you mean by this. Any call that passes traced VAR > params will generate a check as necessary before the call. > > Important to declare extern/C functions as taking UNTRACED REF and > not VAR? > > No, VAR is fine. So long as the VAR value being passed is not traced. > > > I think you are confusing incremental and incremental GC. > You assume I understand more than I do (I assume you have a typo. :)) > > ;-) > > "generational" -- the concept that most objects die young. > (aka most objects could have been allocated on the stack...) > > Not quite. The idea is that the likelihood of an object dying is a > function of its age. There is a *weak* generational hypothesis that > "most objects die young", and a *strong* generational hypothesis > that "the older an object is the less likely it is to die". Many > (but not all) programs support these hypotheses, which permits > generational GC to focus effort where it is likely to be profitable > (i.e., to free up a lot of space). > > But does that imply detailed implementation choices, or is just like > a "guiding principle"? > I guess it implies the heap is split into at least two generations, > old and young. > Though I guess in reality there is a range of young, less young, > lesser young, least young, etc. > > Right, many different collectors have exploited age in this way. > For the M3 collector we have just two generations: old and young. > > And that has objects age, they should be moved from young to old > heaps, and references to them either updated right away, or "caught" > upon use and updated then...something like that. > > Old-space objects are "clean" if they contain no references to young- > space objects. The Modula-3 compiler injects checks to make sure > that whenever we store a reference into a clean old-space object it > is marked "dirty". When a young-space collection occurs we must > process the references in dirty old-space objects as roots into the > young-space. > > "incremental" -- don't pause the world.. > > Not quite. The opposite of stop-the-world (stopping all the mutator > threads to process their stacks) is on-the-fly. Incremental refers > to the ability to interleave GC work with mutator work. If the GC > work can be interleaved with mutator threads without stopping the > mutator threads at each increment then the collector is said to be > concurrent (GC work proceeds concurrently with mutator work). > The current M3 collector has a stop-the-world non-moving phase, > followed by an concurrent copying phase. I have some incomplete > work that will also make the M3 collector on-the-fly (no STW phase) > and parallel (multiple GC threads can operate concurrently). > > Hope all this helps! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Apr 22 08:54:37 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 22 Apr 2009 08:54:37 +0200 Subject: [M3devel] an old, recurring issue: mapping runtime errors to exceptions? In-Reply-To: <200904220238.n3M2cIWk040392@camembert.async.caltech.edu> References: <200904220238.n3M2cIWk040392@camembert.async.caltech.edu> Message-ID: <20090422085437.i0hqnzu6rk0gw80w@mail.elegosoft.com> Quoting Mika Nystrom : > > It's as simple as that!? IMO it should just work. See m3-sys/m3tests/src/p2/p208/Main.m3: % cat m3-sys/m3tests/src/p2/p208/Main.m3 MODULE Main; IMPORT RuntimeError, IO, Process; CONST Tag = RuntimeError.Tag; PROCEDURE CatchAssert() = BEGIN TRY <*ASSERT FALSE*> EXCEPT RuntimeError.E( t ) => IO.Put( "OK: caught RuntimeError.Assert: " & Tag( t ) & "\n" ); END; END CatchAssert; PROCEDURE TestAll() = BEGIN CatchAssert(); END TestAll; BEGIN TRY <*NOWARN*> TestAll(); EXCEPT ELSE IO.Put( "ERROR: caught unexpected exception\n" ); Process.Exit( 1 ); END; END Main. Olaf > > Wow! > > Tony Hosking writes: >> CM3 does map some (I'm not sure if all) run-time errors to >> exceptions. See RuntimeError.i3 for details of what exceptions might >> occur. >> >> On 22 Apr 2009, at 08:41, Mika Nystrom wrote: >> >>> >> Well the point of "safety" is that the system can guarantee that the >>> runtime environment hasn't been damaged by a misbehaving program, no? >>> >>> In fact, in Threads 3 there are not one but *two* reports of >>> implementations that "reflect" runtime errors as exceptions. On >>> of them is SPIN, the other is the commercial CM3 with JVM. >>> >>> See >>> >>> http://www.modula3.org/threads/3/ >>> >>> Nelson's article in Threads 2 doesn't give the possibility of having >>> had the runtime invariants violated as a reason to abort. His >>> arguments are more practical, having to do with debugging. I agree, >>> and I think that the default method of dealing with runtime errors >>> should be to abort the program. But it just is very unfriendly in >>> an interactive environment, and I would love some kind of (possibly >>> very implementation-dependent) way of catching the runtime error. >>> The way Java does it would be ideal, I think..... >>> >>> Nelson's article is here >>> >>> http://www.modula3.org/threads/2/ >>> >>> [Tony, the link in your M3 bibliography is broken!] >>> >>> I'm running this example in a PM3/EZM3 environment right now but >>> that's not relevant. The code I showed you *should* crash. In >>> plain M3 it was: >>> >>> TextWr.ToText(NIL) >>> >>> But in an interactive environment, the user can do this sort of >>> thing. It should give you a nasty error message, not crash your >>> whole environment. >>> >>> Mika >>> >>> >>> >>> "Randy Coleburn" writes: >>>> This is a MIME message. If you are reading this text, you may want to >>>> consider changing to a mail reader or gateway that understands how to >>>> properly handle MIME multipart messages. >>>> >>>> --=__PartBC941634.0__= >>>> Content-Type: text/plain; charset=US-ASCII >>>> Content-Transfer-Encoding: quoted-printable >>>> >>>> Mika: >>>> =20 >>>> You state that "Checked runtime errors cannot violate invariants of >>>> the = >>>> runtime system, so it ought to be safe to ..." >>>> =20 >>>> Are you sure this statement is true for all implementations? >>>> =20 >>>> I would tend to think that SPIN was able to do this mapping for >>>> itself, = >>>> but in general, it would be difficult to be able to do this for any = >>>> arbitrary OS environment, esp with differences in underlying >>>> libraries and = >>>> implementations, which is part of what Greg alluded to in the >>>> Threads = >>>> article you reference. >>>> =20 >>>> Note also on pg 47 of the green book under "2.5.7 Safety" the notes >>>> about = >>>> intrinsic safety and when the compiler makes the guarantee vs. the = >>>> programmer. >>>> =20 >>>> I also note from the path in your example (ezm3) that you may not >>>> be using = >>>> the current cm3. Is it possible that the NIL dereference problem >>>> in your = >>>> example has been solved in a later implementation? >>>> =20 >>>> Regards, >>>> Randy >>>> >>>>>>> Mika Nystrom 4/21/2009 5:41 PM >>> >>>> >>>> Hello Modula-3ers, >>>> >>>> I know this is a question that comes up from time to time, and I >>>> am aware of Greg Nelson's short article in "Threads" about why=20 >>>> Modula-3 doesn't map runtime errors to exceptions, but the Green Book >>>> does allude to mapping runtime errors to exceptions, and I know that >>>> the SPIN OS did that. >>>> >>>> How hard would this be to support in CM3? >>>> >>>> Attached is a transcript of an interactive session with my current >>>> Scheme environment. I think it ought to be obvious why I ask about >>>> exceptions. In Modula-3, from safe code, only checked runtime errors >>>> can occur. Checked runtime errors cannot violate invariants of the >>>> runtime system, so it ought to be safe to convert them to exceptions >>>> that can be caught, and then permit the program to continue. =20 >>>> >>>> I realize this isn't *always* what you want to do, but in an >>>> interactive >>>> environment, making the system dump core on runtime errors sort of >>>> spoils the whole experience. >>>> >>>> In this application, there are many places where you may want to >>>> raise an exception that hasn't been declared. In a non-interactive >>>> environment, it is probably best to go for the core dump, but in >>>> an interactive environment, it seems to me it ought to just return >>>> control to the read-eval-print loop.... >>> >>>> Mika >>>> >>>> LITHP ITH LITHENING. >>>>> (define wr (scheme-procedure-stubs-call '(TextWr . New) '())) >>>> wr >>>>> wr >>>> >>>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>>> #t >>>>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >>>> "hello!" >>>>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >>>> "" >>>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>>> #t >>>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>>> #t >>>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>>> #t >>>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>>> #t >>>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>>> #t >>>>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >>>> "hello!hello!hello!hello!hello!" >>>>> (scheme-procedure-stubs-call '(TextWr . ToText) (list '()) '()) >>>> >>>> >>>> *** >>>> *** runtime error: >>>> *** Segmentation violation - possible attempt to dereference NIL >>>> *** pc =3D 0x80c69c8 =3D LockMutex + 0x28 in /usr/ports/lang/ >>>> ezm3/work/e= >>>> zm3-1.0/libs/m3core/src/thread/POSIX/ThreadPosix.m3 >>>> *** >>>> >>>> use option @M3stackdump to get a stack trace >>>> Abort >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> 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. >>>> >>>> >>>> --=__PartBC941634.0__= >>>> Content-Type: text/html; charset=US-ASCII >>>> Content-Transfer-Encoding: quoted-printable >>>> Content-Description: HTML >>>> >>>> >>>> >>> charset=3Diso-8859-15= >>>> "> >>>> >>>> >>>>
Mika:
>>>>
 
>>>>
You state that "Checked runtime errors cannot violate >>>> invariants of = >>>> the runtime system, so it ought to be safe to ..."
>>>>
 
>>>>
Are you sure this statement is true for all >>>> implementations?>>>> >>>>
 
>>>>
I would tend to think that SPIN was able to do this mapping >>>> for = >>>> itself, but in general, it would be difficult to be able to do this >>>> for = >>>> any arbitrary OS environment, esp with differences in underlying >>>> libraries = >>>> and implementations, which is part of what Greg alluded to in the >>>> Threads = >>>> article you reference.
>>>>
 
>>>>
Note also on pg 47 of the green book under "2.5.7 Safety" the >>>> notes = >>>> about intrinsic safety and when the compiler makes the guarantee >>>> vs. the = >>>> programmer.
>>>>
 
>>>>
I also note from the path in your example (ezm3) that you may >>>> not be = >>>> using the current cm3.  Is it possible that the NIL >>>> dereference = >>>> problem in your example has been solved in a later implementation?>>> DIV> >>>>
 
>>>>
Regards,
>>>>
Randy

>>> Mika Nystrom <mika at async.caltech.edu >>>> > = >>>> 4/21/2009 5:41 PM >>>

Hello Modula-3ers,

I >>>> know = >>>> this is a question that comes up from time to time, and I
am >>>> aware of = >>>> Greg Nelson's short article in "Threads" about why
Modula-3 >>>> doesn't = >>>> map runtime errors to exceptions, but the Green Book
does allude >>>> to = >>>> mapping runtime errors to exceptions, and I know that
the SPIN >>>> OS did = >>>> that.

How hard would this be to support in CM3? >>>>

Attached is = >>>> a transcript of an interactive session with my current
Scheme >>>> environmen= >>>> t.  I think it ought to be obvious why I ask >>>> about
exceptions. = >>>> ; In Modula-3, from safe code, only checked runtime errors
can = >>>> occur.  Checked runtime errors cannot violate invariants of >>>> the
run= >>>> time system, so it ought to be safe to convert them to >>>> exceptions
that = >>>> can be caught, and then permit the program to continue.  >>>>

I = >>>> realize this isn't *always* what you want to do, but in an >>>> interactive
e= >>>> nvironment, making the system dump core on runtime errors sort >>>> of
spoils= >>>> the whole experience.

In this application, there are many >>>> places = >>>> where you may want to
raise an exception that hasn't been >>>> declared. = >>>> ; In a non-interactive
environment, it is probably best to go >>>> for the = >>>> core dump, but in
an interactive environment, it seems to me it >>>> ought = >>>> to just return
control to the read-eval-print >>>> loop....

 &nbs= >>>> p;   Mika

LITHP ITH LITHENING.
> (define wr = >>>> (scheme-procedure-stubs-call '(TextWr . New) '()))
wr
> >>>> wr
<= >>>> Modula-3 object : TextWr.T, BRANDED TextWr_^%#%^__0001M>
> = >>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") >>>> '())
#t<= >>>> BR>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) = >>>> '())
"hello!"
> (scheme-procedure-stubs-call '(TextWr . >>>> ToText) = >>>> (list wr) '())
""
> (scheme-procedure-stubs-call '(Wr . >>>> PutText) = >>>> (list wr "hello!") '())
#t
> (scheme-procedure-stubs-call >>>> '(Wr . = >>>> PutText) (list wr "hello!") '())
#t
> (scheme-procedure- >>>> stubs-call= >>>> '(Wr . PutText) (list wr "hello!") '())
#t
> (scheme- >>>> procedure-st= >>>> ubs-call '(Wr . PutText) (list wr "hello!") '())
#t
> >>>> (scheme-proc= >>>> edure-stubs-call '(Wr . PutText) (list wr "hello!") >>>> '())
#t
> = >>>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) >>>> '())
"hello!he= >>>> llo!hello!hello!hello!"
> (scheme-procedure-stubs-call >>>> '(TextWr . = >>>> ToText) (list '()) '())


***
*** runtime >>>> error:
*** &n= >>>> bsp;  Segmentation violation - possible attempt to dereference = >>>> NIL
***    pc =3D 0x80c69c8 =3D LockMutex + 0x28 >>>> in = >>>> /usr/ports/lang/ezm3/work/ezm3-1.0/libs/m3core/src/thread/POSIX/ >>>> ThreadPosix= >>>> .m3
***

  use option @M3stackdump to get a stack >>>> trace
Ab= >>>> ort






>>>> >>>> --=__PartBC941634.0__=-- > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Wed Apr 22 18:00:03 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 22 Apr 2009 11:00:03 -0500 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: References: <49EC7A06.5040403@cox.net> Message-ID: <49EF3F03.5090104@cox.net> Tony Hosking wrote: > On 20 Apr 2009, at 23:35, Rodney M. Bates wrote: > >> I am going to try to resummarize the various proposals, as their >> description has now gotten rather scattered around in all the >> discussion. >> --------------------------------------------------------------------- >> Mika's proposal (I'll call it the "minimalist" propsal): >> >> Mika, please correct me if I misrepresent what you are proposing. >> >> There are no language changes at all, only changes in implementation. >> The implementation of the existing type REFANY, and no other type, >> allows it to have values whose lsb is nonzero. ISTYPE, NARROW, >> TYPECASE, and narrowing assignments, when and only when applied to >> REFANY, have their generated code fixed so it checks the lsb, and, if >> it is nonzero, consider the runtime type check to have failed, in >> whichever way such a failure is already handled. >> >> The only effect is to liberalize the rules unsafe code must follow to >> avoid undermining the safety of safe code. Only unsafe code can >> create or detect these misaligned values. Today, it must never return >> them in a variable of any reference type, lest the four narrowing >> operations unexpectedly crash. In the proposal, unsafe code would be >> able to return such values in variables of type REFANY, but not any >> other type. > > I don't see why we can't have safe creation of the misaligned values > as per Mika's interface. Well, somebody has to implement that interface, and that module will have to be UNSAFE. You weren't thinking of implementing it in C were you? ;-) > >> Already, the only things safe code can do with values of REFANY are >> copy them around (which would happily work on misaligned values) and >> narrow them. With the implementation of the narrowing operations >> changed, misaligned values can never escape from REFANY variables. >> >> In safe code, there is no way to detect whether a value of type REFANY >> is misaligned. Doing it by elimination, trying to narrow to any >> proper subtype of REFANY, is impractical, as there are an unbounded >> number of REF types to eliminate. > > An alternative would be to loosen the language spec to allow > TYPECODE(REFANY) and use this typecode for tagged references. Then > one can explicitly test for it without elimination of alternatives. > >> If there is more than one abstract data type that uses this mechanism, >> client code can not be prevented from mixing up values from the >> different abstractions. (Perhaps this could be fixed by a language >> change allowing BRANDED REFANY?) > > Indeed. > >> --------------------------------------------------------------------- >> My (Rodney's) "safe" proposal: >> >> There is a new type named TAGABLE. It is a subrange of INTEGER, whose >> bounds are implementation-defined. These can be queried by the >> existing FIRST and LAST functions. Similar to CARDINAL, it has all >> the properties of a subrange type but is not the same type as the >> corresponding subrange. >> >> There is a new type constructor TAGGED. If T is any traced or object >> type, including branded and opaque types, then TAGGED T is a new type >> whose value set is the union of the value sets of T and TAGABLE. >> Moreover, >> >> TAGABLE <: TAGGED T >> T <: TAGGED T. >> >> IF T # U, then TAGGED T and TAGGED U are not the same type and have no >> subtype or assignability relation to each other. >> >> The semantics of ISTYPE, NARROW, TYPECASE, and assignability of a type >> to a type are generalized so that their to-be-narrowed operand can >> have a tagged type, and if it does, their to-be-narrowed-to type can >> be TAGABLE. > > Hmm. It seems there is a nasty loophole in your spec. > Consider: > > TYPE T = BRANDED OBJECT END > TYPE U = BRANDED OBJECT END > > These are unrelated types. > > Now, the rules let me take: > > t: TAGGED T > > and obtain: > > i: TAGABLE := NARROW(t, TAGABLE); > > But TAGABLE <: TAGGED U > > so I can do: > > u: TAGGED U := t; > > Is that your intention? > >> >> >> Comments: >> >> Making TAGGED T have no relation to TAGGED U avoids a lot of really >> complicated type equality and subtype rules. The former would be a >> drastic departure from the current state of Modula-3. >> >> It is up to the implementation to decide the bit representation of >> tagged types, including how values of TAGABLE will be distinguished >> from reference values. Though the language would not require it, most >> likely a word the same size as a pointer will be used. Using the lsb >> as the tag bit is an efficient encoding, because in any currently >> conceivable machine, it will be zero for all pointers to heap objects. >> There is no reason pickles would have to use the same representation >> as compiler-generated code. >> >> The implementation should define the bounds of TAGABLE to be whatever >> it can fit in its representation, after removing the values that are >> true pointers. If the lsb is used as a tag, this will no doubt be a >> 31-bit integer on a 32-bit machine and 63-bit integer on a 64-bit >> machine. The language wouldn't even specify whether it is signed, >> although somehow unsigned seems nice to me. If it is unsigned and the >> suggested encodings are used, TAGABLE would have the same bounds as >> CARDINAL, but it really should be a separate type, so as not to >> overconstrain the implementation. >> >> If T is branded, then the effects of branding will propagate to TAGGED >> T, thus allowing independent abstract data types to ensure each one's >> values can't be mixed up with the other's. This will statically >> detect misuses by client code. However, TAGGED T is not a branded >> type. >> >> If T is an opaque type, then TAGGED T can be used to combine the space >> efficiency of tagging with the ability of an opaque type to reveal >> some but not all of its properties. To use this, client code will >> have to narrow a value first, since access to methods/fields could not >> have a definable meaning for a value in TAGABLE. >> >> On the other hand, T could be an opaque subtype of REFANY, thus >> revealing almost nothing about TAGGED T to clients. This would give >> tagged types the existing ability of ensuring statically, that the >> code in a revealed context will never get TAGGED REFANY, thus avoiding >> extra runtime type checks. > > From rodney.m.bates at cox.net Wed Apr 22 18:33:13 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 22 Apr 2009 11:33:13 -0500 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: References: <49EC7A06.5040403@cox.net> <20090421122648.GB25465@topoi.pooq.com> Message-ID: <49EF46C9.6050503@cox.net> Tony Hosking wrote: > I'd prefer something like TAGGEDINT or some such. But I am still not > convinced that the minimalist proposal and this proposal differ in any > significant way. The minimalist proposal forces you to give up some static safety you have in the current language, that the safe proposal allows. In the minimalist proposal, you cannot both use tagged pointers and have any of the following: 1) An abstract data type T can (and today virtually always is) some proper subtype of REFANY. This statically restricts values to this type. In minimalist, T can only be declared REFANY, allowing a client to provide a value that was neither tagged nor of the type the abstraction expects. Instead, the type constraint will be checked at runtime, on every call into the abstraction. And this is a more expensive check than just a tag bit check. Aside from the overhead, going from static to runtime type checking requires an extensive test suite to get somewhere short of the same level of confidence that a mere compile would guarantee. In the safe proposal, T could be replaced by TAGGED T, and the static rules would guarantee its values are always either integer or T, comparable to the current language. 2) If there is more than one abstraction that uses tagged types, minimalist loses static guarantee that they are not mixed up by client code. Since Abs1.T and Abs2.T must both be REFANY, a client can get a value from Abs1 and pass it to Abs2. Again, this is a demotion of static to runtime type checking. In safe, Abs1.T and Abs2.T could be tagged types built from different opaque types, giving the same separation that we get in the current language. 3) The type declared in an abstraction can currently be an opaque subtype of some proper subtype of REFANY. This allows the abstraction writer to give clients the ability to directly access some fields/methods, while hiding others. Once again, the restriction that only REFANY can be tagged makes this impossible in minimalist. I suppose this could be worked around by providing accessors, mutators, and plain procedures in the abstraction, but then these would have to take REFANY too, just making for more instances of loss of static checking. > > On 21 Apr 2009, at 22:26, hendrik at topoi.pooq.com wrote: > >> On Mon, Apr 20, 2009 at 08:35:02AM -0500, Rodney M. Bates wrote: >>> >>> --------------------------------------------------------------------- >>> My (Rodney's) "safe" proposal: >>> >>> There is a new type named TAGABLE. It is a subrange of INTEGER, whose >> >> Please spell it TAGGABLE. TAG doubles its last consonant when adding >> suffixes: TAGGED, TAGGING. >> >> -- hendrik > > From mika at async.caltech.edu Thu Apr 23 01:41:22 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 22 Apr 2009 16:41:22 -0700 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: Your message of "Wed, 22 Apr 2009 11:00:03 CDT." <49EF3F03.5090104@cox.net> Message-ID: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> "Rodney M. Bates" writes: >Tony Hosking wrote: >> On 20 Apr 2009, at 23:35, Rodney M. Bates wrote: >> >>> I am going to try to resummarize the various proposals, as their >>> description has now gotten rather scattered around in all the >>> discussion. >>> --------------------------------------------------------------------- >>> Mika's proposal (I'll call it the "minimalist" propsal): >>> >>> Mika, please correct me if I misrepresent what you are proposing. >>> >>> There are no language changes at all, only changes in implementation. >>> The implementation of the existing type REFANY, and no other type, >>> allows it to have values whose lsb is nonzero. ISTYPE, NARROW, >>> TYPECASE, and narrowing assignments, when and only when applied to >>> REFANY, have their generated code fixed so it checks the lsb, and, if >>> it is nonzero, consider the runtime type check to have failed, in >>> whichever way such a failure is already handled. >>> >>> The only effect is to liberalize the rules unsafe code must follow to >>> avoid undermining the safety of safe code. Only unsafe code can >>> create or detect these misaligned values. Today, it must never return >>> them in a variable of any reference type, lest the four narrowing >>> operations unexpectedly crash. In the proposal, unsafe code would be >>> able to return such values in variables of type REFANY, but not any >>> other type. This is pretty much exactly what I was proposing, yes. Only one point to add, and that is that you need a TYPECODE value. I think Tony and I discussed having all the ISTYPE etc. behave as if the tagged values were of a specific opaque type that cannot be dereferenced, newed, etc., in safe modules. (I.e., revealed as <: REFANY only) This seems conceptually simpler than introducing a "nonexistent" type, and has the same safety properties. >> >> I don't see why we can't have safe creation of the misaligned values >> as per Mika's interface. > >Well, somebody has to implement that interface, and that module will >have to be UNSAFE. >You weren't thinking of implementing it in C were you? ;-) I don't see how to do it "safely" unless you add it to the compiler itself? (Which means it's no longer minimalist!) >> >>> Already, the only things safe code can do with values of REFANY are >>> copy them around (which would happily work on misaligned values) and >>> narrow them. With the implementation of the narrowing operations >>> changed, misaligned values can never escape from REFANY variables. >>> >>> In safe code, there is no way to detect whether a value of type REFANY >>> is misaligned. Doing it by elimination, trying to narrow to any >>> proper subtype of REFANY, is impractical, as there are an unbounded >>> number of REF types to eliminate. >> >> An alternative would be to loosen the language spec to allow >> TYPECODE(REFANY) and use this typecode for tagged references. Then >> one can explicitly test for it without elimination of alternatives. Yes you could do this or use the specific type idea mentioned above. I don't see what harm there is in letting a safe module know that it's holding a tagged value. Nothing it can do with that information anyhow... it can't extract the value. >> >>> If there is more than one abstract data type that uses this mechanism, >>> client code can not be prevented from mixing up values from the >>> different abstractions. (Perhaps this could be fixed by a language >>> change allowing BRANDED REFANY?) >> >> Indeed. Right. As it stands, the clients would have to sort on what's going on inside. No help from compiler or runtime. You can't do anything about what's checkable at runtime, but adding TAGGED could let you check a lot of things at compile time. I still think, though (referring to what's below), that the advantage of not having to change existing "container" code outweighs the cost of checking the LSB (which is likely to be negligble), and I would therefore recommend that the type called "REFANY" be able to hold "TAGGED" values after such a language change. Mika >> >>> --------------------------------------------------------------------- >>> My (Rodney's) "safe" proposal: >>> >>> There is a new type named TAGABLE. It is a subrange of INTEGER, whose >>> bounds are implementation-defined. These can be queried by the >>> existing FIRST and LAST functions. Similar to CARDINAL, it has all >>> the properties of a subrange type but is not the same type as the >>> corresponding subrange. >>> >>> There is a new type constructor TAGGED. If T is any traced or object >>> type, including branded and opaque types, then TAGGED T is a new type >>> whose value set is the union of the value sets of T and TAGABLE. >>> Moreover, >>> >>> TAGABLE <: TAGGED T >>> T <: TAGGED T. >>> >>> IF T # U, then TAGGED T and TAGGED U are not the same type and have no >>> subtype or assignability relation to each other. >>> >>> The semantics of ISTYPE, NARROW, TYPECASE, and assignability of a type >>> to a type are generalized so that their to-be-narrowed operand can >>> have a tagged type, and if it does, their to-be-narrowed-to type can >>> be TAGABLE. >> >> Hmm. It seems there is a nasty loophole in your spec. >> Consider: >> >> TYPE T = BRANDED OBJECT END >> TYPE U = BRANDED OBJECT END >> >> These are unrelated types. >> >> Now, the rules let me take: >> >> t: TAGGED T >> >> and obtain: >> >> i: TAGABLE := NARROW(t, TAGABLE); >> >> But TAGABLE <: TAGGED U >> >> so I can do: >> >> u: TAGGED U := t; >> >> Is that your intention? >> >>> >>> >>> Comments: >>> >>> Making TAGGED T have no relation to TAGGED U avoids a lot of really >>> complicated type equality and subtype rules. The former would be a >>> drastic departure from the current state of Modula-3. >>> >>> It is up to the implementation to decide the bit representation of >>> tagged types, including how values of TAGABLE will be distinguished >>> from reference values. Though the language would not require it, most >>> likely a word the same size as a pointer will be used. Using the lsb >>> as the tag bit is an efficient encoding, because in any currently >>> conceivable machine, it will be zero for all pointers to heap objects. >>> There is no reason pickles would have to use the same representation >>> as compiler-generated code. >>> >>> The implementation should define the bounds of TAGABLE to be whatever >>> it can fit in its representation, after removing the values that are >>> true pointers. If the lsb is used as a tag, this will no doubt be a >>> 31-bit integer on a 32-bit machine and 63-bit integer on a 64-bit >>> machine. The language wouldn't even specify whether it is signed, >>> although somehow unsigned seems nice to me. If it is unsigned and the >>> suggested encodings are used, TAGABLE would have the same bounds as >>> CARDINAL, but it really should be a separate type, so as not to >>> overconstrain the implementation. >>> >>> If T is branded, then the effects of branding will propagate to TAGGED >>> T, thus allowing independent abstract data types to ensure each one's >>> values can't be mixed up with the other's. This will statically >>> detect misuses by client code. However, TAGGED T is not a branded >>> type. >>> >>> If T is an opaque type, then TAGGED T can be used to combine the space >>> efficiency of tagging with the ability of an opaque type to reveal >>> some but not all of its properties. To use this, client code will >>> have to narrow a value first, since access to methods/fields could not >>> have a definable meaning for a value in TAGABLE. >>> >>> On the other hand, T could be an opaque subtype of REFANY, thus >>> revealing almost nothing about TAGGED T to clients. This would give >>> tagged types the existing ability of ensuring statically, that the >>> code in a revealed context will never get TAGGED REFANY, thus avoiding >>> extra runtime type checks. >> >> From mika at async.caltech.edu Thu Apr 23 01:51:10 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 22 Apr 2009 16:51:10 -0700 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: Your message of "Wed, 22 Apr 2009 11:33:13 CDT." <49EF46C9.6050503@cox.net> Message-ID: <200904222351.n3MNpA3v086629@camembert.async.caltech.edu> Rodney, Yes I agree that minimalist doesn't solve your problems as well as TAGGED does. However, if you allow REFANY to hold tagged values in the future (once you have TAGGED in the language), adding TAGGED will be a backward-compatible step on top of minimalist. In my application anything that might want to be TAGGED is today declared as (exactly) REFANY, so I'm happy either way. But of course I realize I am not the only Modula-3 programmer in the world (even if sometimes it does feel a bit like it). Mika "Rodney M. Bates" writes: >Tony Hosking wrote: >> I'd prefer something like TAGGEDINT or some such. But I am still not >> convinced that the minimalist proposal and this proposal differ in any >> significant way. >The minimalist proposal forces you to give up some static safety you have >in the current language, that the safe proposal allows. In the minimalist >proposal, you cannot both use tagged pointers and have any of the >following: > >1) An abstract data type T can (and today virtually always is) some >proper subtype > of REFANY. This statically restricts values to this type. In >minimalist, T can > only be declared REFANY, allowing a client to provide a value that >was neither > tagged nor of the type the abstraction expects. Instead, the type >constraint will be > checked at runtime, on every call into the abstraction. And this >is a more expensive > check than just a tag bit check. Aside from the overhead, going >from static to runtime type checking requires an extensive test suite to get >somewhere short > of the same level of confidence that a mere compile would >guarantee. In the safe > proposal, T could be replaced by TAGGED T, and the static rules >would guarantee > its values are always either integer or T, comparable to the current >language. > >2) If there is more than one abstraction that uses tagged types, >minimalist loses static > guarantee that they are not mixed up by client code. Since Abs1.T >and Abs2.T must > both be REFANY, a client can get a value from Abs1 and pass it to >Abs2. Again, this > is a demotion of static to runtime type checking. In safe, Abs1.T >and Abs2.T could > be tagged types built from different opaque types, giving the same >separation that > we get in the current language. > >3) The type declared in an abstraction can currently be an opaque >subtype of some > proper subtype of REFANY. This allows the abstraction writer to >give clients the > ability to directly access some fields/methods, while hiding >others. Once again, > the restriction that only REFANY can be tagged makes this impossible >in minimalist. > I suppose this could be worked around by providing accessors, >mutators, and plain > procedures in the abstraction, but then these would have to take >REFANY too, just > making for more instances of loss of static checking. >> >> On 21 Apr 2009, at 22:26, hendrik at topoi.pooq.com wrote: >> >>> On Mon, Apr 20, 2009 at 08:35:02AM -0500, Rodney M. Bates wrote: >>>> >>>> --------------------------------------------------------------------- >>>> My (Rodney's) "safe" proposal: >>>> >>>> There is a new type named TAGABLE. It is a subrange of INTEGER, whose >>> >>> Please spell it TAGGABLE. TAG doubles its last consonant when adding >>> suffixes: TAGGED, TAGGING. >>> >>> -- hendrik >> >> From hosking at cs.purdue.edu Thu Apr 23 03:07:25 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 23 Apr 2009 11:07:25 +1000 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> References: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> Message-ID: <690A324D-3F1A-433F-BFC0-78CFF9D22713@cs.purdue.edu> On 23 Apr 2009, at 09:41, Mika Nystrom wrote: > "Rodney M. Bates" writes: >> Tony Hosking wrote: >>> On 20 Apr 2009, at 23:35, Rodney M. Bates wrote: >>> >>>> I am going to try to resummarize the various proposals, as their >>>> description has now gotten rather scattered around in all the >>>> discussion. >>>> --------------------------------------------------------------------- >>>> Mika's proposal (I'll call it the "minimalist" propsal): >>>> >>>> Mika, please correct me if I misrepresent what you are proposing. >>>> >>>> There are no language changes at all, only changes in >>>> implementation. >>>> The implementation of the existing type REFANY, and no other type, >>>> allows it to have values whose lsb is nonzero. ISTYPE, NARROW, >>>> TYPECASE, and narrowing assignments, when and only when applied to >>>> REFANY, have their generated code fixed so it checks the lsb, >>>> and, if >>>> it is nonzero, consider the runtime type check to have failed, in >>>> whichever way such a failure is already handled. >>>> >>>> The only effect is to liberalize the rules unsafe code must >>>> follow to >>>> avoid undermining the safety of safe code. Only unsafe code can >>>> create or detect these misaligned values. Today, it must never >>>> return >>>> them in a variable of any reference type, lest the four narrowing >>>> operations unexpectedly crash. In the proposal, unsafe code >>>> would be >>>> able to return such values in variables of type REFANY, but not any >>>> other type. > > This is pretty much exactly what I was proposing, yes. > > Only one point to add, and that is that you need a TYPECODE value. Yes. I currently have a full-blown implementation in the compiler and run-time that uses RT0.RefanyTypecode as the typecode. Since the only thing that will respond with the typecode are tagged references, and it is not legal to say TYPECODE(REFANY) we can hide that fact in an implementation of the tagged interface where we use TYPECODE(r) = RT0.RefanyTypecode, or ISTYPE(r, RT0.RefanyTypecode). Currently, no other type in the system will respond with that. > I think Tony and I discussed having all the ISTYPE etc. behave as > if the tagged values were of a specific opaque type that cannot be > dereferenced, newed, etc., in safe modules. (I.e., revealed as <: > REFANY only) Done (modulo what typecode to use as described above). > This seems conceptually simpler than introducing a "nonexistent" > type, and has the same safety properties. > >>> >>> I don't see why we can't have safe creation of the misaligned values >>> as per Mika's interface. >> >> Well, somebody has to implement that interface, and that module will >> have to be UNSAFE. >> You weren't thinking of implementing it in C were you? ;-) > > I don't see how to do it "safely" unless you add it to the compiler > itself? (Which means it's no longer minimalist!) It would be hidden behind a safe interface. >>>> Already, the only things safe code can do with values of REFANY are >>>> copy them around (which would happily work on misaligned values) >>>> and >>>> narrow them. With the implementation of the narrowing operations >>>> changed, misaligned values can never escape from REFANY variables. >>>> >>>> In safe code, there is no way to detect whether a value of type >>>> REFANY >>>> is misaligned. Doing it by elimination, trying to narrow to any >>>> proper subtype of REFANY, is impractical, as there are an unbounded >>>> number of REF types to eliminate. >>> >>> An alternative would be to loosen the language spec to allow >>> TYPECODE(REFANY) and use this typecode for tagged references. Then >>> one can explicitly test for it without elimination of alternatives. > > Yes you could do this or use the specific type idea mentioned above. > > I don't see what harm there is in letting a safe module know that > it's holding a tagged value. Nothing it can do with that information > anyhow... it can't extract the value. > >>> >>>> If there is more than one abstract data type that uses this >>>> mechanism, >>>> client code can not be prevented from mixing up values from the >>>> different abstractions. (Perhaps this could be fixed by a language >>>> change allowing BRANDED REFANY?) >>> >>> Indeed. > > Right. As it stands, the clients would have to sort on what's going > on inside. No help from compiler or runtime. You can't do anything > about what's checkable at runtime, but adding TAGGED could let you > check a lot of things at compile time. > > I still think, though (referring to what's below), that the advantage > of not having to change existing "container" code outweighs the > cost of checking the LSB (which is likely to be negligble), and I > would > therefore recommend that the type called "REFANY" be able to hold > "TAGGED" > values after such a language change. Right. > > > Mika > >>> >>>> --------------------------------------------------------------------- >>>> My (Rodney's) "safe" proposal: >>>> >>>> There is a new type named TAGABLE. It is a subrange of INTEGER, >>>> whose >>>> bounds are implementation-defined. These can be queried by the >>>> existing FIRST and LAST functions. Similar to CARDINAL, it has all >>>> the properties of a subrange type but is not the same type as the >>>> corresponding subrange. >>>> >>>> There is a new type constructor TAGGED. If T is any traced or >>>> object >>>> type, including branded and opaque types, then TAGGED T is a new >>>> type >>>> whose value set is the union of the value sets of T and TAGABLE. >>>> Moreover, >>>> >>>> TAGABLE <: TAGGED T >>>> T <: TAGGED T. >>>> >>>> IF T # U, then TAGGED T and TAGGED U are not the same type and >>>> have no >>>> subtype or assignability relation to each other. >>>> >>>> The semantics of ISTYPE, NARROW, TYPECASE, and assignability of a >>>> type >>>> to a type are generalized so that their to-be-narrowed operand can >>>> have a tagged type, and if it does, their to-be-narrowed-to type >>>> can >>>> be TAGABLE. >>> >>> Hmm. It seems there is a nasty loophole in your spec. >>> Consider: >>> >>> TYPE T = BRANDED OBJECT END >>> TYPE U = BRANDED OBJECT END >>> >>> These are unrelated types. >>> >>> Now, the rules let me take: >>> >>> t: TAGGED T >>> >>> and obtain: >>> >>> i: TAGABLE := NARROW(t, TAGABLE); >>> >>> But TAGABLE <: TAGGED U >>> >>> so I can do: >>> >>> u: TAGGED U := t; >>> >>> Is that your intention? >>> >>>> >>>> >>>> Comments: >>>> >>>> Making TAGGED T have no relation to TAGGED U avoids a lot of really >>>> complicated type equality and subtype rules. The former would be a >>>> drastic departure from the current state of Modula-3. >>>> >>>> It is up to the implementation to decide the bit representation of >>>> tagged types, including how values of TAGABLE will be distinguished >>>> from reference values. Though the language would not require it, >>>> most >>>> likely a word the same size as a pointer will be used. Using the >>>> lsb >>>> as the tag bit is an efficient encoding, because in any currently >>>> conceivable machine, it will be zero for all pointers to heap >>>> objects. >>>> There is no reason pickles would have to use the same >>>> representation >>>> as compiler-generated code. >>>> >>>> The implementation should define the bounds of TAGABLE to be >>>> whatever >>>> it can fit in its representation, after removing the values that >>>> are >>>> true pointers. If the lsb is used as a tag, this will no doubt >>>> be a >>>> 31-bit integer on a 32-bit machine and 63-bit integer on a 64-bit >>>> machine. The language wouldn't even specify whether it is signed, >>>> although somehow unsigned seems nice to me. If it is unsigned >>>> and the >>>> suggested encodings are used, TAGABLE would have the same bounds as >>>> CARDINAL, but it really should be a separate type, so as not to >>>> overconstrain the implementation. >>>> >>>> If T is branded, then the effects of branding will propagate to >>>> TAGGED >>>> T, thus allowing independent abstract data types to ensure each >>>> one's >>>> values can't be mixed up with the other's. This will statically >>>> detect misuses by client code. However, TAGGED T is not a branded >>>> type. >>>> >>>> If T is an opaque type, then TAGGED T can be used to combine the >>>> space >>>> efficiency of tagging with the ability of an opaque type to reveal >>>> some but not all of its properties. To use this, client code will >>>> have to narrow a value first, since access to methods/fields >>>> could not >>>> have a definable meaning for a value in TAGABLE. >>>> >>>> On the other hand, T could be an opaque subtype of REFANY, thus >>>> revealing almost nothing about TAGGED T to clients. This would >>>> give >>>> tagged types the existing ability of ensuring statically, that the >>>> code in a revealed context will never get TAGGED REFANY, thus >>>> avoiding >>>> extra runtime type checks. >>> >>> From mika at async.caltech.edu Fri Apr 24 08:54:46 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 23 Apr 2009 23:54:46 -0700 Subject: [M3devel] bug in Wx.ToText, CM3 TEXTs Message-ID: <200904240654.n3O6skJM072255@camembert.async.caltech.edu> Hello Modula-3ers, These CM3 TEXTs simply won't stop dogging me! There's a bug that I just fixed in Wx.ToText. I seem not to have the repository checked out as me again, so could I bother someone else to commit the change? Synopsis -------- Under SRC and P M3, the way you created a new TEXT of a given size was you imported TextF and allocated a TEXT using NEW(TEXT, n + 1) where n is the length of the TEXT you want. Under CM3, you're supposed to call (e.g.) Text8.New(n) Line 171 of Wx.m3 has: PROCEDURE ToText (t: T): TEXT = VAR txt := Text8.Create(t.nFull * ChunkSize + t.next + 1); (* line 171 *) c := t.head; n := 0; BEGIN (The code t.nFull + ... + 1 is copied exactly from the older implementation, and is wrong.) Fix --- The 1 needs to be removed, to make: PROCEDURE ToText (t: T): TEXT = VAR txt := Text8.Create(t.nFull * ChunkSize + t.next); (* line 171 *) c := t.head; n := 0; BEGIN The path is m3-libs/libbuf/src/Wx.m3 I'm surprised no one has noticed this before. Does no one else use Wx? Mika From mika at async.caltech.edu Fri Apr 24 18:57:32 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 24 Apr 2009 09:57:32 -0700 Subject: [M3devel] Sneaky C++isms in m3cc Message-ID: <200904241657.n3OGvWh4000584@camembert.async.caltech.edu> As usual, my quest to switch to CM3 ends up in my attempting (usually not very well) to bootstrap CM3. This time I am trying to build with cm3 5.3.1 on FreeBSD 4.11. The reason for this is that the "FreeBSD4" snapshot on elego does not appear to be a FreeBSD4 snapshot at all. Anyone know what OS this builds on? (Links to the 5.5.0 -min I contributed from a real FreeBSD 4 system are broken, and I can't find the source myself.) But enough of that. I noticed the following in parse.c (under m3cc): 2395 static void 2396 m3cg_set_source_line (void) 2397 { 2398 INTEGER (i); 2399 2400 if (option_source_line_trace) fprintf(stderr, " source line %4ld\n", i); 2401 #ifdef USE_MAPPED_LOCATION 2402 source_location s = linemap_line_start (line_table, i, 80); 2403 input_location = s; 2404 #else 2405 input_line = i; 2406 #endif 2407 } The code on line 2402 is a C++ism. You cannot declare variables in the middle of code in C. Unless it has changed with the new version of C, but it still won't build with older C compilers. (I'm using gcc 2.95.4) Mika From jay.krell at cornell.edu Sat Apr 25 00:02:23 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 24 Apr 2009 22:02:23 +0000 Subject: [M3devel] Sneaky C++isms in m3cc In-Reply-To: <200904241657.n3OGvWh4000584@camembert.async.caltech.edu> References: <200904241657.n3OGvWh4000584@camembert.async.caltech.edu> Message-ID: It's 7.0 or 7.1. file should tell you this. In time it should be renamed I386_FREEBSD. In time maybe I'll get out regular "boot" archives that are version-independent. The Modula-3 code pretty much only interfaces with our own C code, thus making the assembly for our Modula-3 ABI-independent (the part of ABI that is the signatures of open, etc., not the part that is the function call protocol). I'll fix the C++-ism. Well understood. - Jay ---------------------------------------- > To: m3devel at elegosoft.com > Date: Fri, 24 Apr 2009 09:57:32 -0700 > From: mika at async.caltech.edu > CC: mika at camembert.async.caltech.edu > Subject: [M3devel] Sneaky C++isms in m3cc > > > As usual, my quest to switch to CM3 ends up in my attempting (usually > not very well) to bootstrap CM3. This time I am trying to build with > cm3 5.3.1 on FreeBSD 4.11. > > The reason for this is that the "FreeBSD4" snapshot on elego does > not appear to be a FreeBSD4 snapshot at all. Anyone know what OS > this builds on? (Links to the 5.5.0 -min I contributed from a real > FreeBSD 4 system are broken, and I can't find the source myself.) > > But enough of that. I noticed the following in parse.c (under m3cc): > > 2395 static void > 2396 m3cg_set_source_line (void) > 2397 { > 2398 INTEGER (i); > 2399 > 2400 if (option_source_line_trace) fprintf(stderr, " source line %4ld\n", i); > 2401 #ifdef USE_MAPPED_LOCATION > 2402 source_location s = linemap_line_start (line_table, i, 80); > 2403 input_location = s; > 2404 #else > 2405 input_line = i; > 2406 #endif > 2407 } > > The code on line 2402 is a C++ism. You cannot declare variables > in the middle of code in C. Unless it has changed with the new > version of C, but it still won't build with older C compilers. (I'm > using gcc 2.95.4) > > Mika > From mika at async.caltech.edu Sat Apr 25 00:12:20 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 24 Apr 2009 15:12:20 -0700 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? Message-ID: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> Hi Modula-3ers, I'm trying to boot CM3 on FreeBSD 4.11 right now. Yes, I know it's an old system, but really, the older, the better. Once I have it running on 4.11, I'll have a binary archive that should work on *any* FreeBSD system from 4.x up to 7.x, not just the latest releases. My problems are not with FreeBSD. Well to some extent they are. I had to turn off pthreads: FreeBSD 4 has only a partial implementation, from what I can tell (in libc_r, not libpthreads) No, what's going on is I am trying to boot with CM3 5.3.1, which was the most recent binary I was able to get running on my FreeBSD 4 system. I inserted lots and lots of "LONGINT = INTEGER" in the code, but I'm still running into this one: -> linking cm3 UtilsPosix.mo: In function `UtilsPosix__MakeRelative': /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:23: undefined reference to `ThreadF__handlerStack' /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:23: undefined reference to `ThreadF__handlerStack' /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:33: undefined reference to `ThreadF__handlerStack' /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:50: undefined reference to `ThreadF__handlerStack' /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:60: undefined reference to `ThreadF__handlerStack' Builder.mo:/home/mika/cm3-cvs/cm3/m3-sys/cm3/FreeBSD4/Builder.m3:188: more undefined references to `ThreadF__handlerStack' follow Fatal Error: package build failed No matter what I try... I tried to make ThreadF.handlerStack invariantly equal to ThreadPosix.self.context.handlers... it won't link. Somehow it's not letting me slip in a "handlerStack" in the interface? Anyone have an idea for workarounds? Mika From mika at async.caltech.edu Sat Apr 25 00:20:00 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 24 Apr 2009 15:20:00 -0700 Subject: [M3devel] Suspicious code in Cstdio.i3 for FreeBSD Message-ID: <200904242220.n3OMK0K3016010@camembert.async.caltech.edu> This code looks a bit suspicious: FILE = RECORD p : unsigned_char_star; (* current position in (some) buffer *) r : int; (* read space left for getc() *) w : int; (* write space left for putc() *) flags : short_int; (* flags, below; this FILE is free if 0 *) file : short_int; (* fileno, if Unix descriptor, else -1 *) bf : SBUF; (* the buffer (at least 1 byte, if !NULL) *) lbfsize : int; (* 0 or -_bf._size, for inline putc *) (* operations *) cookie : void_star; (* cookie passed to io functions *) xxclose: void_star; xxread : void_star; xxseek : void_star; xxwrite: void_star; (* separate buffer for long sequences of ungetc() *) ub : SBUF; (* ungetc buffer *) up : unsigned_char_star; (* saved _p when _p is doing ungetc data *) ur : int; (* saved _r when _r is counting ungetc data *) (* tricks to meet minimum requirements even when malloc() fails *) ubuf : ARRAY[0..2] OF unsigned_char; (* guarantee an ungetc() buffer *) nbuf : ARRAY[0..0] OF unsigned_char; (* guarantee a getc() buffer *) (* separate buffer for fgetln() when line crosses buffer boundary *) lb : SBUF; (* buffer for fgetln() *) (* Unix stdio files get aligned to block boundaries on fseek() *) blksize : int; (* stat.st_blksize (may be != _bf._size) *) offset : off_t; (* current lseek offset *) pad1 : int; (* assume high 4 bytes of offset are 0 *) END; Note the "offset" and "pad1". Now... off_t = int64_t; int64_t = BITS 64 FOR Ctypes.long_long; Is this right or is there a bit too much padding here? Is the padding also assuming little-endianness? Hmm... Mika From jay.krell at cornell.edu Sat Apr 25 00:22:53 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 24 Apr 2009 22:22:53 +0000 Subject: [M3devel] Suspicious code in Cstdio.i3 for FreeBSD In-Reply-To: <200904242220.n3OMK0K3016010@camembert.async.caltech.edu> References: <200904242220.n3OMK0K3016010@camembert.async.caltech.edu> Message-ID: I believe this is all dead anyway. - Jay ---------------------------------------- > To: m3devel at elegosoft.com > Date: Fri, 24 Apr 2009 15:20:00 -0700 > From: mika at async.caltech.edu > CC: mika at camembert.async.caltech.edu > Subject: [M3devel] Suspicious code in Cstdio.i3 for FreeBSD > > > This code looks a bit suspicious: > > FILE = RECORD > p : unsigned_char_star; (* current position in (some) buffer *) > r : int; (* read space left for getc() *) > w : int; (* write space left for putc() *) > flags : short_int; (* flags, below; this FILE is free if 0 *) > file : short_int; (* fileno, if Unix descriptor, else -1 *) > bf : SBUF; (* the buffer (at least 1 byte, if !NULL) *) > lbfsize : int; (* 0 or -_bf._size, for inline putc *) > > (* operations *) > cookie : void_star; (* cookie passed to io functions *) > xxclose: void_star; > xxread : void_star; > xxseek : void_star; > xxwrite: void_star; > > (* separate buffer for long sequences of ungetc() *) > ub : SBUF; (* ungetc buffer *) > up : unsigned_char_star; (* saved _p when _p is doing ungetc data *) > ur : int; (* saved _r when _r is counting ungetc data *) > > (* tricks to meet minimum requirements even when malloc() fails *) > ubuf : ARRAY[0..2] OF unsigned_char; (* guarantee an ungetc() buffer *) > nbuf : ARRAY[0..0] OF unsigned_char; (* guarantee a getc() buffer *) > > (* separate buffer for fgetln() when line crosses buffer boundary *) > lb : SBUF; (* buffer for fgetln() *) > > (* Unix stdio files get aligned to block boundaries on fseek() *) > blksize : int; (* stat.st_blksize (may be != _bf._size) *) > offset : off_t; (* current lseek offset *) > pad1 : int; (* assume high 4 bytes of offset are 0 *) > > END; > > > Note the "offset" and "pad1". > > Now... > > off_t = int64_t; > > int64_t = BITS 64 FOR Ctypes.long_long; > > Is this right or is there a bit too much padding here? > > Is the padding also assuming little-endianness? Hmm... > > > Mika From jay.krell at cornell.edu Sat Apr 25 00:23:36 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 24 Apr 2009 22:23:36 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> References: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> Message-ID: ouch, really, no adequate pthreads here? Well, I can still give you an archive to try, but less certain it will work. I never test the user thread stuff.. - Jay ---------------------------------------- > To: m3devel at elegosoft.com > Date: Fri, 24 Apr 2009 15:12:20 -0700 > From: mika at async.caltech.edu > CC: mika at camembert.async.caltech.edu > Subject: [M3devel] help booting CM3 on FreeBSD 4.11? > > Hi Modula-3ers, > > I'm trying to boot CM3 on FreeBSD 4.11 right now. > > Yes, I know it's an old system, but really, the older, the better. > Once I have it running on 4.11, I'll have a binary archive that > should work on *any* FreeBSD system from 4.x up to 7.x, not just > the latest releases. > > My problems are not with FreeBSD. Well to some extent they are. > I had to turn off pthreads: FreeBSD 4 has only a partial implementation, > from what I can tell (in libc_r, not libpthreads) > > No, what's going on is I am trying to boot with CM3 5.3.1, which was the > most recent binary I was able to get running on my FreeBSD 4 system. > > I inserted lots and lots of "LONGINT = INTEGER" in the code, but I'm > still running into this one: > > -> linking cm3 > UtilsPosix.mo: In function `UtilsPosix__MakeRelative': > /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:23: undefined reference to `ThreadF__handlerStack' > /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:23: undefined reference to `ThreadF__handlerStack' > /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:33: undefined reference to `ThreadF__handlerStack' > /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:50: undefined reference to `ThreadF__handlerStack' > /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:60: undefined reference to `ThreadF__handlerStack' > Builder.mo:/home/mika/cm3-cvs/cm3/m3-sys/cm3/FreeBSD4/Builder.m3:188: more undefined references to `ThreadF__handlerStack' follow > Fatal Error: package build failed > > No matter what I try... I tried to make ThreadF.handlerStack > invariantly equal to ThreadPosix.self.context.handlers... it won't > link. Somehow it's not letting me slip in a "handlerStack" in the > interface? > > Anyone have an idea for workarounds? > > Mika From jay.krell at cornell.edu Sat Apr 25 00:26:43 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 24 Apr 2009 22:26:43 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> References: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> Message-ID: You shouldn't have to muck with LONGINT actually. When you bootstrap, you use your existing libm3 and m3core. And you build sysutils, m3front, m3middle, m3quake, cm3, etc. -- none of which should be using LONGINT. upgrade.py and upgrade.sh get this right. If LONGINT has crept into those packages, that would be a problem. But LONGINT in m3core and libm3 can/does exist and is not a problem. I'll fix handlerStack for you in a sec. Would help if you had pthreads though. - Jay ---------------------------------------- > To: m3devel at elegosoft.com > Date: Fri, 24 Apr 2009 15:12:20 -0700 > From: mika at async.caltech.edu > CC: mika at camembert.async.caltech.edu > Subject: [M3devel] help booting CM3 on FreeBSD 4.11? > > Hi Modula-3ers, > > I'm trying to boot CM3 on FreeBSD 4.11 right now. > > Yes, I know it's an old system, but really, the older, the better. > Once I have it running on 4.11, I'll have a binary archive that > should work on *any* FreeBSD system from 4.x up to 7.x, not just > the latest releases. > > My problems are not with FreeBSD. Well to some extent they are. > I had to turn off pthreads: FreeBSD 4 has only a partial implementation, > from what I can tell (in libc_r, not libpthreads) > > No, what's going on is I am trying to boot with CM3 5.3.1, which was the > most recent binary I was able to get running on my FreeBSD 4 system. > > I inserted lots and lots of "LONGINT = INTEGER" in the code, but I'm > still running into this one: > > -> linking cm3 > UtilsPosix.mo: In function `UtilsPosix__MakeRelative': > /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:23: undefined reference to `ThreadF__handlerStack' > /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:23: undefined reference to `ThreadF__handlerStack' > /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:33: undefined reference to `ThreadF__handlerStack' > /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:50: undefined reference to `ThreadF__handlerStack' > /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:60: undefined reference to `ThreadF__handlerStack' > Builder.mo:/home/mika/cm3-cvs/cm3/m3-sys/cm3/FreeBSD4/Builder.m3:188: more undefined references to `ThreadF__handlerStack' follow > Fatal Error: package build failed > > No matter what I try... I tried to make ThreadF.handlerStack > invariantly equal to ThreadPosix.self.context.handlers... it won't > link. Somehow it's not letting me slip in a "handlerStack" in the > interface? > > Anyone have an idea for workarounds? > > Mika From jay.krell at cornell.edu Sat Apr 25 00:34:45 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 24 Apr 2009 22:34:45 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> References: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> Message-ID: > I'll fix handlerStack for you in a sec. No, nevermind that. Just use your installed m3core/libm3 and you don't need it "fixed". You already have it. You aren't bootstrapping in the right order I presume. Try upgrade.sh or upgrade.py. They build the current compiler against the existing runtime. Oh, I guess you'll hit a problem in sysutils. It uses Cerrno which is relatively new. You can just comment that out -- assume there is no error. sysutils should maybe carry its own errno wrapper because of this. Trivial. I've hit it multiple times building on Darwin from older distributions. - Jay From jay.krell at cornell.edu Sat Apr 25 00:40:41 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 24 Apr 2009 22:40:41 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> References: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> Message-ID: > > Would help if you had pthreads though. IF you have a working-enough pthreads, no matter what library they are in, take a look at: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-FreeBSD4-1.tar.gz It's a little gross -- one directory with LOTS of files. And a few subdirectories you don't need. Be sure to look at the start of the Makefile and possibly adjust it. There are some *.sh files, redundant with the Makefile. The output of this is just cm3. You can use that to then build up the system from the bottom of the dependeny tree and on up -- m3cc, m3core, libm3, etc. do-cm3-core.sh/do-cm3-core.py should do that. This is different than "upgrade", which uses an existing m3core/libm3. This is how I do cross builds, both to existing systems and new systems. It has worked several times for me. Most often from a Cygwin host but maybe not always, and it isn't Cygwin specific. If you really don't have a working pthreads, well, I'd just have to rebuild this with one edit...maybe I can do that quickly (it'll be -2 if so..), maybe it'll work...maybe... - Jay From mika at async.caltech.edu Sat Apr 25 01:03:13 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 24 Apr 2009 16:03:13 -0700 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: Your message of "Fri, 24 Apr 2009 22:34:45 -0000." Message-ID: <200904242303.n3ON3DO0018052@camembert.async.caltech.edu> yes it sounds like I'm just using the wrong bootstrapping order. I'm going on an old email from Tony, but there were fewer updates back then to worry about. I'll try your version and report back! Thanks! Mika Jay writes: > >> I'll fix handlerStack for you in a sec. > >No, nevermind that. >Just use your installed m3core/libm3 and you don't need it "fixed". >You already have it. > > >You aren't bootstrapping in the right order I presume. >Try upgrade.sh or upgrade.py. >They build the current compiler against the existing runtime. > > >Oh, I guess you'll hit a problem in sysutils. It uses Cerrno which is relative >ly new. >You can just comment that out -- assume there is no error. >sysutils should maybe carry its own errno wrapper because of this. > Trivial. >I've hit it multiple times building on Darwin from older distributions. > > > - Jay > From mika at async.caltech.edu Sat Apr 25 01:05:06 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 24 Apr 2009 16:05:06 -0700 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: Your message of "Fri, 24 Apr 2009 22:40:41 -0000." Message-ID: <200904242305.n3ON56IS018186@camembert.async.caltech.edu> By the way, I take it booting the compiler "old-fashionedly" with PM3 is out of the question? I have a very well-working PM3... reason it's taken me so long to get around to really pushing on updating to CM3... But let me fiddle around for a bit and see if I need you again. Mika Jay writes: > >> >> Would help if you had pthreads though. > > >IF you have a working-enough pthreads, no matter what library they are in, tak >e a look at: > > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-FreeBSD4-1.tar.gz > > > >It's a little gross -- one directory with LOTS of files. >And a few subdirectories you don't need. > > >Be sure to look at the start of the Makefile and possibly adjust it. >There are some *.sh files, redundant with the Makefile. > > >The output of this is just cm3. >You can use that to then build up the system from the bottom of the dependeny >tree and on up -- m3cc, m3core, libm3, etc. do-cm3-core.sh/do-cm3-core.py shou >ld do that. >This is different than "upgrade", which uses an existing m3core/libm3. > >This is how I do cross builds, both to existing systems and new systems. >It has worked several times for me. Most often from a Cygwin host but maybe no >t always, and it isn't Cygwin specific. > > > >If you really don't have a working pthreads, well, I'd just have to rebuild th >is with one edit...maybe I can do that quickly (it'll be -2 if so..), maybe it >'ll work...maybe... > > > - Jay From jay.krell at cornell.edu Sat Apr 25 01:21:49 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 24 Apr 2009 23:21:49 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <200904242305.n3ON56IS018186@camembert.async.caltech.edu> References: Your message of "Fri, 24 Apr 2009 22:40:41 -0000." <200904242305.n3ON56IS018186@camembert.async.caltech.edu> Message-ID: > By the way, I take it booting the compiler "old-fashionedly" with > PM3 is out of the question? What is the PM3 way? The SRC way is out of the question at least (unless you want to /start/ with it and go through a few releases...). I gather that the PM3 was good and could be resusitated. But it is is some work..maybe too much. I gather that PM3 factored out word size and endianness from the IL? And padding/alignment? And jmpbuf size? And whatever else is target-dependent? There isn't much. Not impossible, but seems a bit onerous. padding/alignment actually don't have to be factored out, kind of. They can be made "worst case", as long as the interactions with C are correct. word size and endianness are in the IL but I think only barely. jmpbuf size is easy to factor out at a small perf cost. or again, make it worst case. These "worst cases" are likely to be pretty bad, such that they are ok for building the first compiler, but then you'd want to immediately rebuild it "ideally". jmpbuf size varies from around 16 bytes to over 200 bytes for example. You could also use extern int jmpbufsize; jmpbuf = alloca(jmpbufsize) thereby not blowing stack, but still being slow. Again, fine for bootstrap purposes but it should end there. "aligned procedures" can be factored out easily via acting worst case. Is this what PM3 did though? Shipped one textual IL for all platforms, built m3cc (which doesn't /really/ require having cm3), then built everything from the portable IL, then rebuilt it all again more ideally? I think if a portable distribution format is to be had, maybe go all the way to using a C backend? However that doesn't solve all/many/any of the above problems, given how low level the IL is. - Jay From jay.krell at cornell.edu Sat Apr 25 01:24:30 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 24 Apr 2009 23:24:30 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <200904242303.n3ON3DO0018052@camembert.async.caltech.edu> References: Your message of "Fri, 24 Apr 2009 22:34:45 -0000." <200904242303.n3ON3DO0018052@camembert.async.caltech.edu> Message-ID: The main out of date thing about what Tony did is that sysutils might not have existed at the time. His statement as to "all" the one place to cheat on LONGINT is out of date too, it is used in more than one place, but you don't have do this anyway. You might also try a cross build.. :) - Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Fri, 24 Apr 2009 16:03:13 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] help booting CM3 on FreeBSD 4.11? > > yes it sounds like I'm just using the wrong bootstrapping order. > I'm going on an old email from Tony, but there were fewer updates > back then to worry about. > > I'll try your version and report back! > > Thanks! > > Mika > > Jay writes: >> >>> I'll fix handlerStack for you in a sec. >> >>No, nevermind that. >>Just use your installed m3core/libm3 and you don't need it "fixed". >>You already have it. >> >> >>You aren't bootstrapping in the right order I presume. >>Try upgrade.sh or upgrade.py. >>They build the current compiler against the existing runtime. >> >> >>Oh, I guess you'll hit a problem in sysutils. It uses Cerrno which is relative >>ly new. >>You can just comment that out -- assume there is no error. >>sysutils should maybe carry its own errno wrapper because of this. >> Trivial. >>I've hit it multiple times building on Darwin from older distributions. >> >> >> - Jay >> From jay.krell at cornell.edu Sat Apr 25 01:42:40 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 24 Apr 2009 23:42:40 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: References: Your message of "Fri, 24 Apr 2009 22:40:41 -0000." <200904242305.n3ON56IS018186@camembert.async.caltech.edu> Message-ID: > I said > word size and endianness are in the IL but I think only barely. [I think] Actually the front end lays out all the types, so word size is all over the place. It's actually a little bit bad, because the gcc backend performs the layout too and they have to match, and they don't always.. (x86 aligned double...) - Jay From jay.krell at cornell.edu Sat Apr 25 01:53:09 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 24 Apr 2009 23:53:09 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> References: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> Message-ID: This /might/ help: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-FreeBSD4-1-userthreads.tar.gz Assuming there are a small number of problems though, the best ways to get more rapid turnaround are to do a cross build or at least first make sure userthreads work on more recent FreeBSD. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu; m3devel at elegosoft.com > CC: mika at camembert.async.caltech.edu > Subject: RE: [M3devel] help booting CM3 on FreeBSD 4.11? > Date: Fri, 24 Apr 2009 22:40:41 +0000 > > >> >> Would help if you had pthreads though. > > > IF you have a working-enough pthreads, no matter what library they are in, take a look at: > > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-FreeBSD4-1.tar.gz > > > It's a little gross -- one directory with LOTS of files. > And a few subdirectories you don't need. > > > Be sure to look at the start of the Makefile and possibly adjust it. > There are some *.sh files, redundant with the Makefile. > > > The output of this is just cm3. > You can use that to then build up the system from the bottom of the dependeny tree and on up -- m3cc, m3core, libm3, etc. do-cm3-core.sh/do-cm3-core.py should do that. > This is different than "upgrade", which uses an existing m3core/libm3. > > This is how I do cross builds, both to existing systems and new systems. > It has worked several times for me. Most often from a Cygwin host but maybe not always, and it isn't Cygwin specific. > > > > If you really don't have a working pthreads, well, I'd just have to rebuild this with one edit...maybe I can do that quickly (it'll be -2 if so..), maybe it'll work...maybe... > > > - Jay From jay.krell at cornell.edu Sat Apr 25 02:05:21 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 00:05:21 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: References: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> Message-ID: ps: you'll want something like: C:\dev2\cm3.2\m3-libs\m3core\src>cvs -z3 diff thread.quake Index: thread.quake =================================================================== RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread.quake,v retrieving revision 1.5 diff -r1.5 thread.quake 40c40 < "FreeBSD4" : TRUE, --- > "FreeBSD4" : FALSE, or C:\dev2\cm3.2\m3-libs\m3core\src>grep defined thread.quake if (NO_USER_THREADS contains TARGET) or ((not defined("NOPTHREAD")) and USE_ PTHREADS{TARGET}) cm3 -DNOPTHREAD - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu; m3devel at elegosoft.com > Date: Fri, 24 Apr 2009 23:53:09 +0000 > CC: mika at camembert.async.caltech.edu > Subject: Re: [M3devel] help booting CM3 on FreeBSD 4.11? > > > This /might/ help: > > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-FreeBSD4-1-userthreads.tar.gz > > > Assuming there are a small number of problems though, the best ways to get more rapid turnaround are to do a cross build or at least first make sure userthreads work on more recent FreeBSD. > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: mika at async.caltech.edu; m3devel at elegosoft.com >> CC: mika at camembert.async.caltech.edu >> Subject: RE: [M3devel] help booting CM3 on FreeBSD 4.11? >> Date: Fri, 24 Apr 2009 22:40:41 +0000 >> >> >>> >>> Would help if you had pthreads though. >> >> >> IF you have a working-enough pthreads, no matter what library they are in, take a look at: >> >> >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-FreeBSD4-1.tar.gz >> >> >> It's a little gross -- one directory with LOTS of files. >> And a few subdirectories you don't need. >> >> >> Be sure to look at the start of the Makefile and possibly adjust it. >> There are some *.sh files, redundant with the Makefile. >> >> >> The output of this is just cm3. >> You can use that to then build up the system from the bottom of the dependeny tree and on up -- m3cc, m3core, libm3, etc. do-cm3-core.sh/do-cm3-core.py should do that. >> This is different than "upgrade", which uses an existing m3core/libm3. >> >> This is how I do cross builds, both to existing systems and new systems From mika at async.caltech.edu Sat Apr 25 05:38:17 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 24 Apr 2009 20:38:17 -0700 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: Your message of "Fri, 24 Apr 2009 22:40:41 -0000." Message-ID: <200904250338.n3P3cHlc030469@camembert.async.caltech.edu> Jay (and others), Success! I think.... I was able to build the compiler, after much experimentation, by using Jay's build order and linking with -libc_r. Mentor works, and that's usually a good sign. Jay, your assembly worked too! And as you say, it's much easier to bootstrap with that than to do what I was trying to do (but I did both, several times, just to make sure). I don't know why I was having linking problems with -libc_r earlier. Now it just seems to work. So, pthreads on FreeBSD 4. If I use user threads, it's a different story (which is probably too bad, as I know that user threads work absolutely fine in my old version of CM3): I can build a compiler fine, but the bootstrapped cm3 crashes in the user thread code. Note that exactly the same thing happens whether I bootstrap with the assembly version from Jay or from v. 5.3.4, which I think is what I had. Here we go: Starting program: /usr/local/cm3/pkg/cm3/FreeBSD4/cm3 Program received signal SIGSEGV, Segmentation fault. 16_82568bb in RTHooks.PushEFrame (frame=16_bfbff3f4) at ../src/thread/POSIX/ThreadPosix.m3:1599 1599 f.next := self.context.handlers; (gdb) where #0 16_82568bb in RTHooks.PushEFrame (frame=16_bfbff3f4) at ../src/thread/POSIX/ThreadPosix.m3:1599 #1 16_824c91e in RTType.Calloc (n=1024, n_bytes=4) at ../src/runtime/common/RTType.m3:815 #2 16_824c39a in RTType.Expand (m=RECORD name = 16_82f0e50; is_equal = 16_824c6a6; rehash = 16_824c6e8; initial_size = 1024; full = 512; cnt = 0; max = 1024; mask = 1023; map = NIL; END) at ../src/runtime/common/RTType.m3:724 #3 16_824c26f in RTType.FindSlot (m=RECORD name = 16_82f0e50; is_equal = 16_824c6a6; rehash = 16_824c6e8; initial_size = 1024; full = 512; cnt = 0; max = 1024; mask = 1023; map = NIL; END, key=-1025633461, aux=NIL) at ../src/runtime/common/RTType.m3:699 #4 16_824b007 in RTTypeSRC.AddTypecell (def=16_82eb8b4, m=16_82eb880) at ../src/runtime/common/RTType.m3:163 #5 16_8244d89 in RTLinker.DeclareModuleTypes (m=16_82eb880) at ../src/runtime/common/RTLinker.m3:280 #6 16_8244b52 in RTLinker.FixTypes () at ../src/runtime/common/RTLinker.m3:234 #7 16_82446f9 in RTLinker.AddUnitI (m=16_82eefa0) at ../src/runtime/common/RTLinker.m3:112 #8 16_824478f in RTLinker.AddUnit (b=16_82443e0) at ../src/runtime/common/RTLinker.m3:122 #9 16_8244493 in RTLinker.InitRuntime (p_argc=1, p_argv=16_bfbff68c, p_envp=16_bfbff694, p_instance=NIL) at ../src/runtime/common/RTLinker.m3:42 module "_m3main": missing debug info for global data I'm not able to print self in m3gdb, for some reason. Mika Jay writes: > >> >> Would help if you had pthreads though. > > >IF you have a working-enough pthreads, no matter what library they are in, take a look at: > > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-FreeBSD4-1.tar.gz > > >It's a little gross -- one directory with LOTS of files. >And a few subdirectories you don't need. > > >Be sure to look at the start of the Makefile and possibly adjust it. >There are some *.sh files, redundant with the Makefile. > > >The output of this is just cm3. >You can use that to then build up the system from the bottom of the dependeny tree and on up -- m3cc, m3core, libm3, etc. do-cm3-core.sh/do-cm3-core.py should do that. >This is different than "upgrade", which uses an existing m3core/libm3. > >This is how I do cross builds, both to existing systems and new systems. >It has worked several times for me. Most often from a Cygwin host but maybe not always, and it isn't Cygwin specific. > > > >If you really don't have a working pthreads, well, I'd just have to rebuild this with one edit...maybe I can do that quickly (it'll be -2 if so..), maybe it'll work...maybe... > > > - Jay From mika at async.caltech.edu Sat Apr 25 05:41:04 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 24 Apr 2009 20:41:04 -0700 Subject: [M3devel] inconsistencies in external interfaces Message-ID: <200904250341.n3P3f4O8030634@camembert.async.caltech.edu> All right, here's another little oddity. m3-libs/m3core/src/unix/freebsd-4/Utime.i3 has the following: time_t = int; (* seconds since the Epoch *) ... <*EXTERNAL*> PROCEDURE localtime (clock: long_star): struct_tm_star; Huh? What's the point of declaring time_t if you're not going to use it? (I think it used to be that long_star and time_t resolved to the same type, before the LONGINT work or some other foreign interface updating, but they no longer seem to...) Mika From jay.krell at cornell.edu Sat Apr 25 06:12:54 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 04:12:54 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <200904250338.n3P3cHlc030469@camembert.async.caltech.edu> References: Your message of "Fri, 24 Apr 2009 22:40:41 -0000." <200904250338.n3P3cHlc030469@camembert.async.caltech.edu> Message-ID: Cool. > If I use user threads, it's a different story (which is probably too bad, Oops, right, I forgot, I should have mentioned that, user threads have likely been broken on all platforms for a while. I noticed that on PPC_LINUX. I think it is trivial to fix. Or use pthreads.. - Jay > To: jay.krell at cornell.edu > Date: Fri, 24 Apr 2009 20:38:17 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] help booting CM3 on FreeBSD 4.11? > > Jay (and others), > > Success! I think.... I was able to build the compiler, after much > experimentation, by using Jay's build order and linking with -libc_r. > Mentor works, and that's usually a good sign. > > Jay, your assembly worked too! And as you say, it's much easier to > bootstrap with that than to do what I was trying to do (but I did > both, several times, just to make sure). > > I don't know why I was having linking problems with -libc_r earlier. > Now it just seems to work. So, pthreads on FreeBSD 4. > > If I use user threads, it's a different story (which is probably too bad, > as I know that user threads work absolutely fine in my old version of CM3): > > I can build a compiler fine, but the bootstrapped cm3 crashes in > the user thread code. Note that exactly the same thing happens whether > I bootstrap with the assembly version from Jay or from v. 5.3.4, which > I think is what I had. Here we go: > > Starting program: /usr/local/cm3/pkg/cm3/FreeBSD4/cm3 > > Program received signal SIGSEGV, Segmentation fault. > 16_82568bb in RTHooks.PushEFrame (frame=16_bfbff3f4) at ../src/thread/POSIX/ThreadPosix.m3:1599 > 1599 f.next := self.context.handlers; > (gdb) where > #0 16_82568bb in RTHooks.PushEFrame (frame=16_bfbff3f4) at ../src/thread/POSIX/ThreadPosix.m3:1599 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 25 06:50:44 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 04:50:44 +0000 Subject: [M3devel] inconsistencies in external interfaces In-Reply-To: <200904250341.n3P3f4O8030634@camembert.async.caltech.edu> References: <200904250341.n3P3f4O8030634@camembert.async.caltech.edu> Message-ID: 1) I THINK these files are often a pretty direct translation of /usr/include, dead stuff, comments, and all. Posix often mandates that certain types are certain headers, even if they aren't used by any function in that header. Utime.i3 would declare time_t not necessarily for its own purposes but so that C code (nonsense example but ok): #include int main() { time_t t = 0; /* ... */ } translates "directly" to Modula-3 (ha): IMPORT Utime; VAR t: Utime.time_t := 0 BEGIN (* ... *) END Main. 2) Almost everything in m3core/src/unix is dead anyway, outside of the common directory, and Usysdeps.i3, and the userthread support. Look at the m3makefile. It is mostly if'ed out. The only active platforms using their own full assortment of cloned /usr/include are I386_DARWIN and AMD64_DARWIN..until I get around to them. If OpenDarwin/x86 7.0 will run in a VM, I386_DARWIN will fall soon. AMD64_DARWIN must wait for additional hardware, or someone else to switch it (Tony?) - Jay > To: m3devel at elegosoft.com > Date: Fri, 24 Apr 2009 20:41:04 -0700 > From: mika at async.caltech.edu > Subject: [M3devel] inconsistencies in external interfaces > > > All right, here's another little oddity. > > m3-libs/m3core/src/unix/freebsd-4/Utime.i3 has the following: > > time_t = int; (* seconds since the Epoch *) > > ... > > <*EXTERNAL*> PROCEDURE localtime (clock: long_star): struct_tm_star; > > Huh? What's the point of declaring time_t if you're not going to > use it? > > (I think it used to be that long_star and time_t resolved to the > same type, before the LONGINT work or some other foreign interface > updating, but they no longer seem to...) > > Mika > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sat Apr 25 07:32:37 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 24 Apr 2009 22:32:37 -0700 Subject: [M3devel] inconsistencies in external interfaces In-Reply-To: Your message of "Sat, 25 Apr 2009 04:50:44 -0000." Message-ID: <200904250532.n3P5Wb7V035782@camembert.async.caltech.edu> Well, I hear you, but in this case I doubt it. /usr/include/time.h has struct tm *localtime __P((const time_t *)); and man localtime yields... struct tm * localtime(const time_t *clock); It looks like a manual job to me. Mika Jay writes: >--_7e282a72-e70c-455d-9d62-0c65873ebb2d_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >1) I THINK these files are often a pretty direct translation of /usr/includ= >e=2C dead stuff=2C comments=2C and all. Posix often mandates that certain t= >ypes are certain headers=2C even if they aren't used by any function in tha= >t header. > >=20 > >=20 > >Utime.i3 would declare time_t not necessarily for its own purposes but so t= >hat C code (nonsense example but ok): > >=20 > >=20 > >#include > >=20 > >int main() > >{ > > time_t t =3D 0=3B > > /* ... */ > >} > >=20 > >=20 >translates "directly" to Modula-3 (ha): > >=20 > >=20 > >IMPORT Utime=3B > >VAR > > t: Utime.time_t :=3D 0 > >BEGIN > > (* ... *) > >END Main. > > =20 > >2) Almost everything in m3core/src/unix is dead anyway=2C outside of the co= >mmon directory=2C and Usysdeps.i3=2C and the userthread support. > >Look at the m3makefile. It is mostly if'ed out. > >The only active platforms using their own full assortment of cloned /usr/in= >clude are I386_DARWIN and AMD64_DARWIN..until I get around to them. If Open= >Darwin/x86 7.0 will run in a VM=2C I386_DARWIN will fall soon. AMD64_DARWIN= > must wait for additional hardware=2C or someone else to switch it (Tony?) > >=20 > >=20 > > - Jay > >=20 >> To: m3devel at elegosoft.com >> Date: Fri=2C 24 Apr 2009 20:41:04 -0700 >> From: mika at async.caltech.edu >> Subject: [M3devel] inconsistencies in external interfaces >>=20 >>=20 >> All right=2C here's another little oddity. >>=20 >> m3-libs/m3core/src/unix/freebsd-4/Utime.i3 has the following: >>=20 >> time_t =3D int=3B (* seconds since the Epoch *) >>=20 >> ... >>=20 >> <*EXTERNAL*> PROCEDURE localtime (clock: long_star): struct_tm_star=3B >>=20 >> Huh? What's the point of declaring time_t if you're not going to >> use it? >>=20 >> (I think it used to be that long_star and time_t resolved to the >> same type=2C before the LONGINT work or some other foreign interface >> updating=2C but they no longer seem to...) >>=20 >> Mika >>=20 >>=20 > >--_7e282a72-e70c-455d-9d62-0c65873ebb2d_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >1) I THINK these files are often a pretty direct =3Btranslation of /usr= >/include=2C dead stuff=2C comments=2C and all. Posix often mandates that ce= >rtain types are certain headers=2C even if they aren't used by any function= > in that header.
> =3B
> =3B
>Utime.i3 would =3Bdeclare time_t not necessarily for its own purposes b= >ut so that C code (nonsense example but ok):
> =3B
> =3B
>#include <=3Btime.h>=3B
> =3B
>int main()
>{
> =3B =3Btime_t t =3D 0=3B
> =3B /* ... */
>}
> =3B
> =3B
>translates "directly" to Modula-3 (ha):
> =3B
> =3B
>IMPORT Utime=3B
>VAR
> =3B t: Utime.time_t =3B:=3D 0
>BEGIN
> =3B (* ... *)
>END Main.
> =3B

2) Almost everything in m3core/src/unix is dead anyway=2C = >outside of the common directory=2C and Usysdeps.i3=2C and the userthread su= >pport.
>Look at the m3makefile. It is mostly if'ed out.
>The only active platforms using their own full assortment of cloned /usr/in= >clude are I386_DARWIN and AMD64_DARWIN..until I get around to them. If Open= >Darwin/x86 7.0 will run in a VM=2C I386_DARWIN will fall soon. AMD64_DARWIN= > must wait for additional hardware=2C or someone else to switch it (Tony?)<= >BR> > =3B
> =3B
> =3B- Jay

 =3B
>=3B To: m3devel at elegosoft.com
>=3B= > Date: Fri=2C 24 Apr 2009 20:41:04 -0700
>=3B From: mika at async.caltech= >.edu
>=3B Subject: [M3devel] inconsistencies in external interfaces>>=3B
>=3B
>=3B All right=2C here's another little oddity.>>=3B
>=3B m3-libs/m3core/src/unix/freebsd-4/Utime.i3 has the follo= >wing:
>=3B
>=3B time_t =3D int=3B (* seconds since the Epoch *)<= >BR>>=3B
>=3B ...
>=3B
>=3B <=3B*EXTERNAL*>=3B PROCED= >URE localtime (clock: long_star): struct_tm_star=3B
>=3B
>=3B Hu= >h? What's the point of declaring time_t if you're not going to
>=3B us= >e it?
>=3B
>=3B (I think it used to be that long_star and time_t= > resolved to the
>=3B same type=2C before the LONGINT work or some oth= >er foreign interface
>=3B updating=2C but they no longer seem to...)R>>=3B
>=3B Mika
>=3B
>=3B
>= > >--_7e282a72-e70c-455d-9d62-0c65873ebb2d_-- From mika at async.caltech.edu Sat Apr 25 07:58:23 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 24 Apr 2009 22:58:23 -0700 Subject: [M3devel] Uresource on freebsd 4? Message-ID: <200904250558.n3P5wNE1036977@camembert.async.caltech.edu> Is there any particular reason Uresource no longer exists on FreeBSD4? The m3makefile m3core/src/unix/freebsd-4/m3makefile looks like the following, and Uresource isn't picked up anywhere else: if TRUE Module ("Usignal") Interface ("Uucontext") else Interface ("Udir") Interface ("Uerror") %Interface ("Ugrp") Interface ("Uipc") Interface ("Umman") Module ("Umsg") Interface ("Unix") Interface ("Uprocess") Interface ("Upthread") Interface ("Upwd") Interface ("Uresource") Interface ("Usem") Interface ("Usched") Interface ("Ushm") Module ("Usignal") Interface ("Ustat") Interface ("Usocket") Interface ("Usyslog") Interface ("Utime") Module ("Utypes") Interface ("Uucontext") Interface ("Uugid") Interface ("Uuio") Interface ("Uutsname") end From jay.krell at cornell.edu Sat Apr 25 08:14:28 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 06:14:28 +0000 Subject: [M3devel] Uresource on freebsd 4? In-Reply-To: <200904250558.n3P5wNE1036977@camembert.async.caltech.edu> References: <200904250558.n3P5wNE1036977@camembert.async.caltech.edu> Message-ID: Do you need it? Is there a sufficient common/Uresource.i3? I generally removed whatever isn't used, and made the remainders portable. I can look into restoring more, but what do you need and what is there? (I can look.) - Jay > To: m3devel at elegosoft.com > Date: Fri, 24 Apr 2009 22:58:23 -0700 > From: mika at async.caltech.edu > CC: mika at camembert.async.caltech.edu > Subject: [M3devel] Uresource on freebsd 4? > > > Is there any particular reason Uresource no longer exists on FreeBSD4? > The m3makefile > > m3core/src/unix/freebsd-4/m3makefile > > looks like the following, and Uresource isn't picked up anywhere else: > > if TRUE > > Module ("Usignal") > Interface ("Uucontext") > > else > > Interface ("Udir") > Interface ("Uerror") > %Interface ("Ugrp") > Interface ("Uipc") > Interface ("Umman") > Module ("Umsg") > Interface ("Unix") > Interface ("Uprocess") > Interface ("Upthread") > Interface ("Upwd") > Interface ("Uresource") > Interface ("Usem") > Interface ("Usched") > Interface ("Ushm") > Module ("Usignal") > Interface ("Ustat") > Interface ("Usocket") > Interface ("Usyslog") > Interface ("Utime") > Module ("Utypes") > Interface ("Uucontext") > Interface ("Uugid") > Interface ("Uuio") > Interface ("Uutsname") > > end > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sat Apr 25 08:32:29 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 24 Apr 2009 23:32:29 -0700 Subject: [M3devel] Uresource on freebsd 4? In-Reply-To: Your message of "Sat, 25 Apr 2009 06:14:28 -0000." Message-ID: <200904250632.n3P6WThS038574@camembert.async.caltech.edu> I use it for timing programs (getrusage). Is there another way of doing that in Modula-3? This declaration: <*EXTERNAL*> PROCEDURE getrusage (who: int; VAR rus: struct_rusage): int; I'm sure getrlimit is useful too. These things have been in Modula-3 for a long time... It's the only thing that's missing that I personally use. Except for some disturbances in m3tk things are now compiling for me... Mika Jay writes: >--_55ac72c8-d027-4bd6-a303-434a73dcc5db_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Do you need it? > >Is there a sufficient common/Uresource.i3? > >=20 > >I generally removed whatever isn't used=2C and made the remainders portable= >. > >I can look into restoring more=2C but what do you need and what is there? (= >I can look.) > >=20 > >=20 > > - Jay > >=20 >> To: m3devel at elegosoft.com >> Date: Fri=2C 24 Apr 2009 22:58:23 -0700 >> From: mika at async.caltech.edu >> CC: mika at camembert.async.caltech.edu >> Subject: [M3devel] Uresource on freebsd 4? >>=20 >>=20 >> Is there any particular reason Uresource no longer exists on FreeBSD4? >> The m3makefile >>=20 >> m3core/src/unix/freebsd-4/m3makefile >>=20 >> looks like the following=2C and Uresource isn't picked up anywhere else: >>=20 >> if TRUE >>=20 >> Module ("Usignal") >> Interface ("Uucontext") >>=20 >> else >>=20 >> Interface ("Udir") >> Interface ("Uerror") >> %Interface ("Ugrp") >> Interface ("Uipc") >> Interface ("Umman") >> Module ("Umsg") >> Interface ("Unix") >> Interface ("Uprocess") >> Interface ("Upthread") >> Interface ("Upwd") >> Interface ("Uresource") >> Interface ("Usem") >> Interface ("Usched") >> Interface ("Ushm") >> Module ("Usignal") >> Interface ("Ustat") >> Interface ("Usocket") >> Interface ("Usyslog") >> Interface ("Utime") >> Module ("Utypes") >> Interface ("Uucontext") >> Interface ("Uugid") >> Interface ("Uuio") >> Interface ("Uutsname") >>=20 >> end >>=20 > >--_55ac72c8-d027-4bd6-a303-434a73dcc5db_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >Do you need it?
>Is there a sufficient common/Uresource.i3?
> =3B
>I generally removed whatever isn't used=2C and made the remainders portable= >.
>I can look into restoring more=2C but what do you need and what is there? (= >I can look.)
> =3B
> =3B
> =3B- Jay

 =3B
>=3B To: m3devel at elegosoft.com
>=3B= > Date: Fri=2C 24 Apr 2009 22:58:23 -0700
>=3B From: mika at async.caltech= >.edu
>=3B CC: mika at camembert.async.caltech.edu
>=3B Subject: [M3d= >evel] Uresource on freebsd 4?
>=3B
>=3B
>=3B Is there any = >particular reason Uresource no longer exists on FreeBSD4?
>=3B The m3m= >akefile
>=3B
>=3B m3core/src/unix/freebsd-4/m3makefile
>=3B= >
>=3B looks like the following=2C and Uresource isn't picked up anywh= >ere else:
>=3B
>=3B if TRUE
>=3B
>=3B Module ("Usigna= >l")
>=3B Interface ("Uucontext")
>=3B
>=3B else
>=3B <= >BR>>=3B Interface ("Udir")
>=3B Interface ("Uerror")
>=3B %Inte= >rface ("Ugrp")
>=3B Interface ("Uipc")
>=3B Interface ("Umman")R>>=3B Module ("Umsg")
>=3B Interface ("Unix")
>=3B Interface (= >"Uprocess")
>=3B Interface ("Upthread")
>=3B Interface ("Upwd")R>>=3B Interface ("Uresource")
>=3B Interface ("Usem")
>=3B Int= >erface ("Usched")
>=3B Interface ("Ushm")
>=3B Module ("Usignal")= >
>=3B Interface ("Ustat")
>=3B Interface ("Usocket")
>=3B In= >terface ("Usyslog")
>=3B Interface ("Utime")
>=3B Module ("Utypes= >")
>=3B Interface ("Uucontext")
>=3B Interface ("Uugid")
>= >=3B Interface ("Uuio")
>=3B Interface ("Uutsname")
>=3B
>= >=3B end
>=3B
>= > >--_55ac72c8-d027-4bd6-a303-434a73dcc5db_-- From jay.krell at cornell.edu Sat Apr 25 09:52:31 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 07:52:31 +0000 Subject: [M3devel] Uresource on freebsd 4? In-Reply-To: <200904250632.n3P6WThS038574@camembert.async.caltech.edu> References: Your message of "Sat, 25 Apr 2009 06:14:28 -0000." <200904250632.n3P6WThS038574@camembert.async.caltech.edu> Message-ID: Does something like this suffice? Seconds used by current process as a float (including sub-second resolution). http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/runtime/POSIX/Attic/RTProcessPosix.i3?rev=1.1;content-type=text%2Fplain http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/runtime/POSIX/Attic/RTProcessPosixC.c?rev=1.7;content-type=text%2Fplain Notice it is in Attic. If not, can you write your own similar? The full getrusage has that huge struct.. seems best to not expose the whole thing but have folks write little C wrappers for just what they need. A portable wrapper would copy out all the fields, for "all the fields" defined as all the ones implemented by all systems. Only to have most users probably ignore most of them. Notice the cruft: struct_rusage = RECORD ru_utime: Utime.struct_timeval; (* user time used *) ru_stime: Utime.struct_timeval; (* system time used *) ru_maxrss: long; ru_ixrss: long; (* integral shared text size *) (* Unsupported in Linux 1.0: ru_ismrss: long; (* integral shared memory size*) ******************************) kind of makes you wonder....when the FreeBSD path has stuff commented out because Linux 1.0 doesn't support it, which parts are correct? And is it still correct in FreeBSD 5, 6, 7, 9, 10? (Did it get copied blindly to other directoryes, like maybe Darwin?) I guess the only client used utime and stime (based on the code in the Attic). Mistakes here -- such as commenting out fields that are actually there -- would generally result in stack corruption, which might be ok, on some days, on some systems, with some compilers, with some compiler flags, depending on what is nearby on the stack, and what it gets overwritten with. Very dangerous stuff.. For Win32, lookup GetProcessTimes and GetThreadTimes. getrlimit doesn't look so problematic, at least based on the FreeBSD4 version. (Something is really weird with mail encoding, could be me, using a variety of modern mail clients..) - Jay > To: jay.krell at cornell.edu > Date: Fri, 24 Apr 2009 23:32:29 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Uresource on freebsd 4? > > > I use it for timing programs (getrusage). Is there another way of > doing that in Modula-3? > > This declaration: > > <*EXTERNAL*> PROCEDURE getrusage (who: int; VAR rus: struct_rusage): int; > > I'm sure getrlimit is useful too. > > These things have been in Modula-3 for a long time... > > It's the only thing that's missing that I personally use. Except > for some disturbances in m3tk things are now compiling for me... > > Mika > > > Jay writes: > >--_55ac72c8-d027-4bd6-a303-434a73dcc5db_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Do you need it? > > > >Is there a sufficient common/Uresource.i3? > > > >=20 > > > >I generally removed whatever isn't used=2C and made the remainders portable= > >. > > > >I can look into restoring more=2C but what do you need and what is there? (= > >I can look.) > > > >=20 > > > >=20 > > > > - Jay > > > >=20 > >> To: m3devel at elegosoft.com > >> Date: Fri=2C 24 Apr 2009 22:58:23 -0700 > >> From: mika at async.caltech.edu > >> CC: mika at camembert.async.caltech.edu > >> Subject: [M3devel] Uresource on freebsd 4? > >>=20 > >>=20 > >> Is there any particular reason Uresource no longer exists on FreeBSD4? > >> The m3makefile > >>=20 > >> m3core/src/unix/freebsd-4/m3makefile > >>=20 > >> looks like the following=2C and Uresource isn't picked up anywhere else: > >>=20 > >> if TRUE > >>=20 > >> Module ("Usignal") > >> Interface ("Uucontext") > >>=20 > >> else > >>=20 > >> Interface ("Udir") > >> Interface ("Uerror") > >> %Interface ("Ugrp") > >> Interface ("Uipc") > >> Interface ("Umman") > >> Module ("Umsg") > >> Interface ("Unix") > >> Interface ("Uprocess") > >> Interface ("Upthread") > >> Interface ("Upwd") > >> Interface ("Uresource") > >> Interface ("Usem") > >> Interface ("Usched") > >> Interface ("Ushm") > >> Module ("Usignal") > >> Interface ("Ustat") > >> Interface ("Usocket") > >> Interface ("Usyslog") > >> Interface ("Utime") > >> Module ("Utypes") > >> Interface ("Uucontext") > >> Interface ("Uugid") > >> Interface ("Uuio") > >> Interface ("Uutsname") > >>=20 > >> end > >>=20 > > > >--_55ac72c8-d027-4bd6-a303-434a73dcc5db_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > >Do you need it?
> >Is there a sufficient common/Uresource.i3?
> > =3B
> >I generally removed whatever isn't used=2C and made the remainders portable= > >.
> >I can look into restoring more=2C but what do you need and what is there? (= > >I can look.)
> > =3B
> > =3B
> > =3B- Jay

 =3B
>=3B To: m3devel at elegosoft.com
>=3B= > > Date: Fri=2C 24 Apr 2009 22:58:23 -0700
>=3B From: mika at async.caltech= > >.edu
>=3B CC: mika at camembert.async.caltech.edu
>=3B Subject: [M3d= > >evel] Uresource on freebsd 4?
>=3B
>=3B
>=3B Is there any = > >particular reason Uresource no longer exists on FreeBSD4?
>=3B The m3m= > >akefile
>=3B
>=3B m3core/src/unix/freebsd-4/m3makefile
>=3B= > >
>=3B looks like the following=2C and Uresource isn't picked up anywh= > >ere else:
>=3B
>=3B if TRUE
>=3B
>=3B Module ("Usigna= > >l")
>=3B Interface ("Uucontext")
>=3B
>=3B else
>=3B <= > >BR>>=3B Interface ("Udir")
>=3B Interface ("Uerror")
>=3B %Inte= > >rface ("Ugrp")
>=3B Interface ("Uipc")
>=3B Interface ("Umman") >R>>=3B Module ("Umsg")
>=3B Interface ("Unix")
>=3B Interface (= > >"Uprocess")
>=3B Interface ("Upthread")
>=3B Interface ("Upwd") >R>>=3B Interface ("Uresource")
>=3B Interface ("Usem")
>=3B Int= > >erface ("Usched")
>=3B Interface ("Ushm")
>=3B Module ("Usignal")= > >
>=3B Interface ("Ustat")
>=3B Interface ("Usocket")
>=3B In= > >terface ("Usyslog")
>=3B Interface ("Utime")
>=3B Module ("Utypes= > >")
>=3B Interface ("Uucontext")
>=3B Interface ("Uugid")
>= > >=3B Interface ("Uuio")
>=3B Interface ("Uutsname")
>=3B
>= > >=3B end
>=3B
> >= > > > >--_55ac72c8-d027-4bd6-a303-434a73dcc5db_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 25 10:01:12 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 08:01:12 +0000 Subject: [M3devel] Uresource on freebsd 4? In-Reply-To: <200904250632.n3P6WThS038574@camembert.async.caltech.edu> References: Your message of "Sat, 25 Apr 2009 06:14:28 -0000." <200904250632.n3P6WThS038574@camembert.async.caltech.edu> Message-ID: I should have read the docs first. http://www.opengroup.org/onlinepubs/000095399/basedefs/sys/resource.h.html Only guarantees ru_utime and ru_stime. So maybe a portable wrapper isn't such a bad idea, since it'd only copy back so little. The various time_t, struct timeval, struct tm, struct itimerval, are some of the only system-dependent code/types remaining but maybe I should have to live with them not going away. Maybe. Modula-3 does layer over all of these anyway so more "refactoring" can probably remove them all. (ie: pushing some of the wrapping up to libm3). But if that's adequate -- exposing just ru_utime and ru_stime, then so is probably the old RTProcessPosix. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] Uresource on freebsd 4? Date: Sat, 25 Apr 2009 07:52:31 +0000 Does something like this suffice? Seconds used by current process as a float (including sub-second resolution). http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/runtime/POSIX/Attic/RTProcessPosix.i3?rev=1.1;content-type=text%2Fplain http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/runtime/POSIX/Attic/RTProcessPosixC.c?rev=1.7;content-type=text%2Fplain Notice it is in Attic. If not, can you write your own similar? The full getrusage has that huge struct.. seems best to not expose the whole thing but have folks write little C wrappers for just what they need. A portable wrapper would copy out all the fields, for "all the fields" defined as all the ones implemented by all systems. Only to have most users probably ignore most of them. Notice the cruft: struct_rusage = RECORD ru_utime: Utime.struct_timeval; (* user time used *) ru_stime: Utime.struct_timeval; (* system time used *) ru_maxrss: long; ru_ixrss: long; (* integral shared text size *) (* Unsupported in Linux 1.0: ru_ismrss: long; (* integral shared memory size*) ******************************) kind of makes you wonder....when the FreeBSD path has stuff commented out because Linux 1.0 doesn't support it, which parts are correct? And is it still correct in FreeBSD 5, 6, 7, 9, 10? (Did it get copied blindly to other directoryes, like maybe Darwin?) I guess the only client used utime and stime (based on the code in the Attic). Mistakes here -- such as commenting out fields that are actually there -- would generally result in stack corruption, which might be ok, on some days, on some systems, with some compilers, with some compiler flags, depending on what is nearby on the stack, and what it gets overwritten with. Very dangerous stuff.. For Win32, lookup GetProcessTimes and GetThreadTimes. getrlimit doesn't look so problematic, at least based on the FreeBSD4 version. (Something is really weird with mail encoding, could be me, using a variety of modern mail clients..) - Jay > To: jay.krell at cornell.edu > Date: Fri, 24 Apr 2009 23:32:29 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Uresource on freebsd 4? > > > I use it for timing programs (getrusage). Is there another way of > doing that in Modula-3? > > This declaration: > > <*EXTERNAL*> PROCEDURE getrusage (who: int; VAR rus: struct_rusage): int; > > I'm sure getrlimit is useful too. > > These things have been in Modula-3 for a long time... > > It's the only thing that's missing that I personally use. Except > for some disturbances in m3tk things are now compiling for me... > > Mika > > > Jay writes: > >--_55ac72c8-d027-4bd6-a303-434a73dcc5db_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Do you need it? > > > >Is there a sufficient common/Uresource.i3? > > > >=20 > > > >I generally removed whatever isn't used=2C and made the remainders portable= > >. > > > >I can look into restoring more=2C but what do you need and what is there? (= > >I can look.) > > > >=20 > > > >=20 > > > > - Jay > > > >=20 > >> To: m3devel at elegosoft.com > >> Date: Fri=2C 24 Apr 2009 22:58:23 -0700 > >> From: mika at async.caltech.edu > >> CC: mika at camembert.async.caltech.edu > >> Subject: [M3devel] Uresource on freebsd 4? > >>=20 > >>=20 > >> Is there any particular reason Uresource no longer exists on FreeBSD4? > >> The m3makefile > >>=20 > >> m3core/src/unix/freebsd-4/m3makefile > >>=20 > >> looks like the following=2C and Uresource isn't picked up anywhere else: > >>=20 > >> if TRUE > >>=20 > >> Module ("Usignal") > >> Interface ("Uucontext") > >>=20 > >> else > >>=20 > >> Interface ("Udir") > >> Interface ("Uerror") > >> %Interface ("Ugrp") > >> Interface ("Uipc") > >> Interface ("Umman") > >> Module ("Umsg") > >> Interface ("Unix") > >> Interface ("Uprocess") > >> Interface ("Upthread") > >> Interface ("Upwd") > >> Interface ("Uresource") > >> Interface ("Usem") > >> Interface ("Usched") > >> Interface ("Ushm") > >> Module ("Usignal") > >> Interface ("Ustat") > >> Interface ("Usocket") > >> Interface ("Usyslog") > >> Interface ("Utime") > >> Module ("Utypes") > >> Interface ("Uucontext") > >> Interface ("Uugid") > >> Interface ("Uuio") > >> Interface ("Uutsname") > >>=20 > >> end > >>=20 > > > >--_55ac72c8-d027-4bd6-a303-434a73dcc5db_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > >Do you need it?
> >Is there a sufficient common/Uresource.i3?
> > =3B
> >I generally removed whatever isn't used=2C and made the remainders portable= > >.
> >I can look into restoring more=2C but what do you need and what is there? (= > >I can look.)
> > =3B
> > =3B
> > =3B- Jay

 =3B
>=3B To: m3devel at elegosoft.com
>=3B= > > Date: Fri=2C 24 Apr 2009 22:58:23 -0700
>=3B From: mika at async.caltech= > >.edu
>=3B CC: mika at camembert.async.caltech.edu
>=3B Subject: [M3d= > >evel] Uresource on freebsd 4?
>=3B
>=3B
>=3B Is there any = > >particular reason Uresource no longer exists on FreeBSD4?
>=3B The m3m= > >akefile
>=3B
>=3B m3core/src/unix/freebsd-4/m3makefile
>=3B= > >
>=3B looks like the following=2C and Uresource isn't picked up anywh= > >ere else:
>=3B
>=3B if TRUE
>=3B
>=3B Module ("Usigna= > >l")
>=3B Interface ("Uucontext")
>=3B
>=3B else
>=3B <= > >BR>>=3B Interface ("Udir")
>=3B Interface ("Uerror")
>=3B %Inte= > >rface ("Ugrp")
>=3B Interface ("Uipc")
>=3B Interface ("Umman") >R>>=3B Module ("Umsg")
>=3B Interface ("Unix")
>=3B Interface (= > >"Uprocess")
>=3B Interface ("Upthread")
>=3B Interface ("Upwd") >R>>=3B Interface ("Uresource")
>=3B Interface ("Usem")
>=3B Int= > >erface ("Usched")
>=3B Interface ("Ushm")
>=3B Module ("Usignal")= > >
>=3B Interface ("Ustat")
>=3B Interface ("Usocket")
>=3B In= > >terface ("Usyslog")
>=3B Interface ("Utime")
>=3B Module ("Utypes= > >")
>=3B Interface ("Uucontext")
>=3B Interface ("Uugid")
>= > >=3B Interface ("Uuio")
>=3B Interface ("Uutsname")
>=3B
>= > >=3B end
>=3B
> >= > > > >--_55ac72c8-d027-4bd6-a303-434a73dcc5db_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 25 10:12:23 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 08:12:23 +0000 Subject: [M3devel] FW: Uresource on freebsd 4? In-Reply-To: <200904250632.n3P6WThS038574@camembert.async.caltech.edu> References: Your message of "Sat, 25 Apr 2009 06:14:28 -0000." <200904250632.n3P6WThS038574@camembert.async.caltech.edu> Message-ID: was slightly truncated: >> But if that's adequate -- exposing just ru_utime and ru_stime, then so is probably the old RTProcessPosix. The Linux/*BSD struct rusage documentation suggests they are all identical, so I admit, I was crying wolf/fire without knowing. But Solaris 2.9 documentation suggests ours is/was wrong, but I haven't really checked. It is fairly moot now anyway, unless someone really wants getrusage restored along with its full struct. Surely the options of a) do nothing b) restore RTProcessPosix c) add a new safe/copying wrapper that only return ru_[us]time are more likely.. [truncated deliberatley] -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 25 10:41:20 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 08:41:20 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <200904250338.n3P3cHlc030469@camembert.async.caltech.edu> References: Your message of "Fri, 24 Apr 2009 22:40:41 -0000." <200904250338.n3P3cHlc030469@camembert.async.caltech.edu> Message-ID: > Jay, your assembly worked too! And as you say, it's much easier to As an /experiment/ you might try building that assembly yourself? First you need to cd to m3cc and cm3 -DM3CC_TARGET=foo. My config files probe around for the correct seeming m3cg and use it. And then scripts/python/boot1.py foo. The point of the "experiment" would be see if anyone else can produce these "bootstrap" archives, as a possible first toward elevating their status -- ie: using them as a form of distribution. But not clear if they should be or not -- to what extent os /version/ is a problem and to what extent it should be dealt with, and if that should be via building on the various hosts or these "bootstrap" archives, or something else. You know, ideally, maybe, given time/energy, there'd be regulary produced (daily) "bootstrap" archives for "all" the platforms, "min", and "std". Including maybe even a cm3cg..though that cm3cg would be "Canadian" and seems maybe a dubious thing to depend on working regularly. So, while we might output binary distributions for various "current" platforms, these could be fallbacks for other older/newer versions. As well, esp. if the Canadian cm3cg worked out, these could even be the real distributions -- benefit being that they can all be cross built from one or a few machines -- without having to automate each host platform. Though maybe that's too much to do on one machine. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Apr 26 06:49:38 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Apr 2009 14:49:38 +1000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: References: Your message of "Fri, 24 Apr 2009 22:40:41 -0000." <200904242305.n3ON56IS018186@camembert.async.caltech.edu> Message-ID: <2D59910B-DD11-406E-BA79-C0891F4D7260@cs.purdue.edu> On 25 Apr 2009, at 09:21, Jay wrote: > >> By the way, I take it booting the compiler "old-fashionedly" with >> PM3 is out of the question? > > > What is the PM3 way? > The SRC way is out of the question at least (unless you want to / > start/ with it and go through a few releases...). > > I gather that the PM3 was good and could be resusitated. > But it is is some work..maybe too much. > > I gather that PM3 factored out word size and endianness from the IL? > And padding/alignment? And jmpbuf size? Nope. Same as cm3. > > And whatever else is target-dependent? > There isn't much. > Not impossible, but seems a bit onerous. > > padding/alignment actually don't have to be factored out, kind of. > They can be made "worst case", as long as the interactions with C > are correct. > > word size and endianness are in the IL but I think only barely. > > jmpbuf size is easy to factor out at a small perf cost. > or again, make it worst case. > > > These "worst cases" are likely to be pretty bad, such that they are > ok for building the first compiler, but then you'd want to > immediately rebuild it "ideally". > jmpbuf size varies from around 16 bytes to over 200 bytes for example. > You could also use > extern int jmpbufsize; > jmpbuf = alloca(jmpbufsize) > > > thereby not blowing stack, but still being slow. > Again, fine for bootstrap purposes but it should end there. > > > "aligned procedures" can be factored out easily via acting worst case. > > > Is this what PM3 did though? > Shipped one textual IL for all platforms, built m3cc (which doesn't / > really/ > require having cm3), then built everything from the portable IL, > then rebuilt it all again more ideally? > > I think if a portable distribution format is to be had, maybe go all > the way to using a C backend? However that doesn't solve all/many/ > any of the above problems, given how low level the IL is. > > > - Jay From hosking at cs.purdue.edu Sun Apr 26 06:51:45 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Apr 2009 14:51:45 +1000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: References: Your message of "Fri, 24 Apr 2009 22:40:41 -0000." <200904250338.n3P3cHlc030469@camembert.async.caltech.edu> Message-ID: Broken mostly because updated libraries detect forging of thread contexts (state) for security reasons and blow up. On 25 Apr 2009, at 14:12, Jay wrote: > Cool. > > > If I use user threads, it's a different story (which is probably > too bad, > > Oops, right, I forgot, I should have mentioned that, user threads > have likely been broken on all platforms for a while. I noticed that > on PPC_LINUX. I think it is trivial to fix. Or use pthreads.. > > > - Jay > > > > To: jay.krell at cornell.edu > > Date: Fri, 24 Apr 2009 20:38:17 -0700 > > From: mika at async.caltech.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] help booting CM3 on FreeBSD 4.11? > > > > Jay (and others), > > > > Success! I think.... I was able to build the compiler, after much > > experimentation, by using Jay's build order and linking with - > libc_r. > > Mentor works, and that's usually a good sign. > > > > Jay, your assembly worked too! And as you say, it's much easier to > > bootstrap with that than to do what I was trying to do (but I did > > both, several times, just to make sure). > > > > I don't know why I was having linking problems with -libc_r earlier. > > Now it just seems to work. So, pthreads on FreeBSD 4. > > > > If I use user threads, it's a different story (which is probably > too bad, > > as I know that user threads work absolutely fine in my old version > of CM3): > > > > I can build a compiler fine, but the bootstrapped cm3 crashes in > > the user thread code. Note that exactly the same thing happens > whether > > I bootstrap with the assembly version from Jay or from v. 5.3.4, > which > > I think is what I had. Here we go: > > > > Starting program: /usr/local/cm3/pkg/cm3/FreeBSD4/cm3 > > > > Program received signal SIGSEGV, Segmentation fault. > > 16_82568bb in RTHooks.PushEFrame (frame=16_bfbff3f4) at ../src/ > thread/POSIX/ThreadPosix.m3:1599 > > 1599 f.next := self.context.handlers; > > (gdb) where > > #0 16_82568bb in RTHooks.PushEFrame (frame=16_bfbff3f4) at ../src/ > thread/POSIX/ThreadPosix.m3:1599 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Apr 26 07:22:00 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 25 Apr 2009 22:22:00 -0700 Subject: [M3devel] Performance issues with CM3 Message-ID: <200904260522.n3Q5M01a000401@camembert.async.caltech.edu> Hello again, Now I've managed to get all the code up and running under CM3. I found and committed fixes to a bug in Wx and some code in one of the m3tk libraries that looked like it never was finished in the first place. As I mentioned earlier, I wasn't able to get user threads working in CM3 on FreeBSD 4.11. But with some help from Jay, I was able to get things working with libc_r. Performance, unfortunately, leaves something to be desired. For the first time I've been able to compare timings on identical hardware between the PM3 I was using and the CM3 that's out now. Note that optimization doesn't seem to work..? (Not even -O, much less -O3... the compiler segfaults.) Here's what I get, using no optimization either in PM3 or CM3. The test is my Scheme interpreter generating SQL and Modula-3 code (a bit like the Hibernate system you can get for Java): CPU seconds CM3 PM3 First version 5.269 1.366 Fewer NEWs 2.039 0.440 (code cleanup on my part) TYPECASE hack 1.770 (see below) Some "poor man's profiling" (i.e., ctrl-C'ing in m3gdb) suggests that most of the time is spent either in threading code (this could just be a lousy implementation in libc_r), the garbage collector, or in "ScanTypecase". The only one of these routines I am qualified to do anything about is ScanTypecase. I don't know why the Critical Mass people... .. all over this code. I assume it has something to do with Java. The PM3 code (from SRC?) has this wonderful, concise, efficient bit: PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = VAR t := Get (b); BEGIN IF (a >= RT0u.nTypes) THEN BadType (a) END; IF (a = 0) THEN RETURN TRUE END; RETURN (t.typecode <= a AND a <= t.lastSubTypeTC); END IsSubtype; replaced with the following absolute abomination in CM3: PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = VAR t: RT0.TypeDefn; BEGIN IF (a = RT0.NilTypecode) THEN RETURN TRUE END; t := Get (a); IF (t = NIL) THEN RETURN FALSE; END; IF (t.typecode = b) THEN RETURN TRUE END; WHILE (t.kind = ORD (TK.Obj)) DO IF (t.link_state = 0) THEN FinishTypecell (t, NIL); END; t := LOOPHOLE (t, RT0.ObjectTypeDefn).parent; IF (t = NIL) THEN RETURN FALSE; END; IF (t.typecode = b) THEN RETURN TRUE; END; END; IF (t.traced # 0) THEN RETURN (b = RT0.RefanyTypecode); ELSE RETURN (b = RT0.AddressTypecode); END; END IsSubtype; Furthermore, CM3 has a hook for "ScanTypecase" that's missing in PM3 (the older compiler actually generates code for this): PROCEDURE ScanTypecase (ref: REFANY; x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; BEGIN IF (ref = NIL) THEN RETURN 0; END; tc := TYPECODE (ref); p := x; i := 0; LOOP IF (p.uid = 0) THEN RETURN i; END; IF (p.defn = NIL) THEN p.defn := FindType (p.uid); IF (p.defn = NIL) THEN Fail (RTE.MissingType, RTModule.FromDataAddress(x), LOOPHOLE (p.uid, ADDRESS), NIL); END; END; xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; IF (tc = xc) OR IsSubtype (tc, xc) THEN RETURN i; END; INC (p, ADRSIZE (p^)); INC (i); END; END ScanTypecase; Where to begin? A loop with all kinds of runtime checks of properties that are supposedly known at compile time? IsSubtype (itself a loop) called from inside the loop? I was able to cut out almost all of the typecase activity from my program by using the following code in RTType.m3, which depends on the ADDRESS x never changing (well more specifically never being the same for two TYPECASE statements): TYPE TypeCaseResult = RECORD x : ADDRESS; tc : Typecode; arm : INTEGER; END; CONST TCCachePow = 6; TCCacheSize = Word.Shift(1,TCCachePow); TCMask = TCCacheSize-1; VAR TCCache := ARRAY [0..TCCacheSize-1] OF TypeCaseResult { TypeCaseResult { LOOPHOLE(0,ADDRESS), 0, -1 } , .. }; (* VAR tcScans := 0; tcHits := 0; (* instrumenting counters *) *) PROCEDURE ScanTypecase (ref: REFANY; x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; BEGIN tc := TYPECODE (ref); IF (ref = NIL) THEN RETURN 0; END; WITH hash = Word.And(Word.Times(tc, Word.RightShift(LOOPHOLE(x,Word.T),2)), TCMask), entry = TCCache[hash] DO (*INC(tcScans);*) IF entry.x = x AND entry.tc = tc THEN (*INC(tcHits);*) RETURN entry.arm END; p := x; i := 0; LOOP IF (p.uid = 0) THEN entry.x := x; entry.tc := tc; entry.arm := i; RETURN i; END; IF (p.defn = NIL) THEN p.defn := FindType (p.uid); IF (p.defn = NIL) THEN Fail (RTE.MissingType, RTModule.FromDataAddress(x), LOOPHOLE (p.uid, ADDRESS), NIL); END; END; xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; IF (tc = xc) OR IsSubtype (tc, xc) THEN entry.x := x; entry.tc := tc; entry.arm := i; RETURN i; END; INC (p, ADRSIZE (p^)); INC (i); END; END; END ScanTypecase; I'm guessing the speedup for TYPECASE itself is a factor of at least ten. But it's still a pretty nasty hack. And there is still a lot of IsSubtype activity from narrowing. I suppose that the way the typecodes are generated in CM3 is sufficiently different (meant to be extended at runtime?) from how it was done in PM3 that one can't really go back to the old code. Cardelli's idea of keeping an array of parents up to ROOT plus a "depth" for each type might have merit, though. To see if a is a subtype of b, something like: b = a.ancestors[a.depth-b.depth-1] (* with appropriate range checks *) Would this be easy to put in? I'm not sure how one can be sure that typecodes are done being generated? There's something called RTTypeSRC.FinishObjectTypes .. And PM3 still generates code that's four times faster. Mika From mika at async.caltech.edu Sun Apr 26 07:28:25 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 25 Apr 2009 22:28:25 -0700 Subject: [M3devel] Confusing, but non-critical bug... Message-ID: <200904260528.n3Q5SPcu000732@camembert.async.caltech.edu> So I have a library, built against m3tk. Everything compiles, but when cm3 tries to "ar" the library: new "TypeTranslator.io" -> archiving libsstubgen.a Fatal Error: incomplete library missing compiled interface "M3AST_all.io" imported by: M3AST_SM_F.i3 M3AST_PG.m3 M3AST_SM.m3 TypeNames.m3 AstToVal.m3 AstToType.m3 M3ASTScopeNames.m3 M3AST_PG_M.i3: missing object types: _t1ee311ce imported by: M3AST_PG.m3 M3AST_all.i3: missing object types: _t8eb32ef8 _t9ffde2a4 _ta2581bcc _t52bfa811 _t249b6ddc _t172a75ba _t774a90ea _tc92a7e8c _t1d23b703 _t2812849 _t1796950e _te47b91c _tccbf0da _tb53c334a _tf38721e4 _tbbcfc2cb _teec6ca97 imported by: M3AST_PG.m3 AstToType.m3 AstToVal.m3 M3AST_SM.m3 M3AST_SM_F.i3 missing compiled interface "M3AST_PG_M.io" imported by: M3AST_PG.m3 seconds #times operation 0.06 22 inhaling library link info 0.01 27 checking old link info 0.21 896 merging new link info 0.05 4 garbage collection --------------------------------------------------- 0.34 TOTAL rm m3make.args cd ../src So I add "IMPORT M3AST_all;" to one of my interfaces (it's not used there at all): (1943)trs80:~/t-cm3/mscheme/sstubgen/src>cm3 -x --- building in ../FreeBSD4 --- ignoring override("sstubgen", "/home/mika/t-cm3/mscheme") new source -> compiling TypeTranslator.i3 "../src/TypeTranslator.i3", line 12: warning: not used (M3AST_all) 1 warning encountered new source -> compiling TypeTranslator.m3 "../src/TypeTranslator.m3", line 353: warning: not used (Add) 1 warning encountered new opaque info -> recompiling TypeTranslator.m3 "../src/TypeTranslator.m3", line 353: warning: not used (Add) 1 warning encountered new "TypeTranslator.io" -> archiving libsstubgen.a (1944)trs80:~/t-cm3/mscheme/sstubgen/src> Hmmmmmmmmmmmmm....... is anyone interested in looking at this? As I said, it's non-critical (I can get things working, clearly, even with the bug present), but it's very confusing. I have to import an interface I'm not using...why? Where to begin looking? Mika From mika at async.caltech.edu Sun Apr 26 07:30:01 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 25 Apr 2009 22:30:01 -0700 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: Your message of "Sat, 25 Apr 2009 22:28:05 PDT." <0FB5E4EA-571C-4CB9-8606-92F12B91A40B@gmail.com> Message-ID: <200904260530.n3Q5U1NE000824@camembert.async.caltech.edu> User threads certainly work fine on this machine (see my previous email) with PM3... some would say they work "better"... :-) Jay writes: > >--Apple-Mail-1-423481883 >Content-Type: text/plain; > charset=us-ascii; > format=flowed; > delsp=yes >Content-Transfer-Encoding: 7bit > >I think also due to simple use before init. > > - Jay (phone) > >On Apr 25, 2009, at 9:51 PM, Tony Hosking wrote: > >> Broken mostly because updated libraries detect forging of thread >> contexts (state) for security reasons and blow up. >> >> On 25 Apr 2009, at 14:12, Jay wrote: >> >>> Cool. >>> >>> > If I use user threads, it's a different story (which is probably >>> too bad, >>> >>> Oops, right, I forgot, I should have mentioned that, user threads >>> have likely been broken on all platforms for a while. I noticed >>> that on PPC_LINUX. I > > >--Apple-Mail-1-423481883 >Content-Type: text/html; > charset=utf-8 >Content-Transfer-Encoding: quoted-printable > >
I think also due to simple use = >before init.

 - Jay (phonestyle=3D"-webkit-composition-fill-color: rgba(175, 192, 227, 0.231373); = >-webkit-composition-frame-color: rgba(77, 128, 180, 0.231373); = >">)

On Apr 25, 2009, at 9:51 PM, Tony Hosking = ><hosking at cs.purdue.edu> = >wrote:

apple-content-edited=3D"true">style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >normal; font-variant: normal; font-weight: normal; letter-spacing: = >normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; = >-khtml-line-break: after-white-space; ">style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >normal; font-variant: normal; font-weight: normal; letter-spacing: = >normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">Broken mostly = >because updated libraries detect forging of thread contexts (state) for = >security reasons and blow up.

On = >25 Apr 2009, at 14:12, Jay wrote:

class=3D"Apple-interchange-newline">
class=3D"Apple-style-span" style=3D"border-collapse: separate; color: = >rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >normal; font-variant: normal; font-weight: normal; letter-spacing: = >normal; line-height: normal; orphans: 2; text-align: auto; text-indent: = >0px; text-transform: none; white-space: normal; widows: 2; word-spacing: = >0px; -webkit-border-horizontal-spacing: 0px; = >-webkit-border-vertical-spacing: 0px; = >-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = >auto; -webkit-text-stroke-width: 0; ">
style=3D"font-size: 10pt; font-family: Verdana; = >">Cool.
 
 > If I use user threads, it's a different = >story (which is probably too bad,

Oops, right, I forgot, I should = >have mentioned that, user threads have likely been broken on all = >platforms for a while. I noticed that on PPC_LINUX. = >I

= > >--Apple-Mail-1-423481883-- From mika at async.caltech.edu Sun Apr 26 07:33:08 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 25 Apr 2009 22:33:08 -0700 Subject: [M3devel] FW: Uresource on freebsd 4? In-Reply-To: Your message of "Sat, 25 Apr 2009 08:12:23 -0000." Message-ID: <200904260533.n3Q5X8UW001003@camembert.async.caltech.edu> As far as I'm concerned, I've sucked in all the Uresource junk into interfaces inside my own application, so forget I said anything about it. (One day when I'm ambitious (or get weird segfaults!), I'll write the C wrappers; for now they're just copies of the old PM3 interfaces..) Mika Jay writes: >--_c686b76c-f145-4c40-913c-ad76373e06f4_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >was slightly truncated: > >=20 > > >> But if that's adequate -- exposing just ru_utime and ru_stime=2C then s= >o is probably the old RTProcessPosix. > > > >The Linux/*BSD struct rusage documentation suggests they are all identical= >=2C so I admit=2C I was crying wolf/fire without knowing. > >But Solaris 2.9 documentation suggests ours is/was wrong=2C but I haven't r= >eally checked. > >It is fairly moot now anyway=2C unless someone really wants getrusage resto= >red along with its full struct. Surely the options of a) do nothing b) rest= >ore RTProcessPosix c) add a new safe/copying wrapper that only return ru_[u= >s]time are more likely.. > >=20 > >=20 > > [truncated deliberatley]=20 > >--_c686b76c-f145-4c40-913c-ad76373e06f4_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >was slightly truncated:
> =3B
> =3B>=3B>=3B But if that's adequate -- exposing just ru_utime and r= >u_stime=2C then so is probably the old RTProcessPosix.


>The Linux/*BSD struct rusage documentation suggests they are all identical= >=2C so I admit=2C I was crying wolf/fire without knowing.
>But =3BSolaris 2.9 documentation suggests =3Bours is/was wrong=2C b= >ut I haven't really checked.
>It is fairly moot now anyway=2C unless someone really wants getrusage resto= >red along with its full struct. Surely the options of a) do nothing b) rest= >ore RTProcessPosix c) add a new =3Bsafe/copying wrapper that only retur= >n ru_[us]time are more likely..
> =3B
> =3B
> =3B[truncated deliberatley]
>= > >--_c686b76c-f145-4c40-913c-ad76373e06f4_-- From jay.krell at cornell.edu Sun Apr 26 07:37:04 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 22:37:04 -0700 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <2D59910B-DD11-406E-BA79-C0891F4D7260@cs.purdue.edu> References: Your message of "Fri, 24 Apr 2009 22:40:41 -0000." <200904242305.n3ON56IS018186@camembert.async.caltech.edu> <2D59910B-DD11-406E-BA79-C0891F4D7260@cs.purdue.edu> Message-ID: <3BD2A0FC-BDA0-4C43-A229-B8E042E76BA6@gmail.com> Oh phew. Someone said they played tricks with il, so I thought of beneficial but difficult tricks. Um but what is the CM3 way?(somewhat rhetorical..must stop,see signature..) - Jay (phone!) On Apr 25, 2009, at 9:49 PM, Tony Hosking wrote: > > On 25 Apr 2009, at 09:21, Jay wrote: > >> >>> By the way, I take it booting the compiler "old-fashionedly" with >>> PM3 is out of the question? >> >> >> What is the PM3 way? >> The SRC way is out of the question at least (unless you want to / >> start/ with it and go through a few releases...). >> >> I gather that the PM3 was good and could be resusitated. >> But it is is some work..maybe too much. >> >> I gather that PM3 factored out word size and endianness from the IL? >> And padding/alignment? And jmpbuf size? > > Nope. Same as cm3. > >> >> And whatever else is target-dependent? >> There isn't much. >> Not impossible, but seems a bit onerous. >> >> >> >> >> >> >> >> >> >> >> >> >> >> From jay.krell at cornell.edu Sun Apr 26 07:28:05 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 22:28:05 -0700 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: References: Your message of "Fri, 24 Apr 2009 22:40:41 -0000." <200904250338.n3P3cHlc030469@camembert.async.caltech.edu> Message-ID: <0FB5E4EA-571C-4CB9-8606-92F12B91A40B@gmail.com> I think also due to simple use before init. - Jay (phone) On Apr 25, 2009, at 9:51 PM, Tony Hosking wrote: > Broken mostly because updated libraries detect forging of thread > contexts (state) for security reasons and blow up. > > On 25 Apr 2009, at 14:12, Jay wrote: > >> Cool. >> >> > If I use user threads, it's a different story (which is probably >> too bad, >> >> Oops, right, I forgot, I should have mentioned that, user threads >> have likely been broken on all platforms for a while. I noticed >> that on PPC_LINUX. I -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 26 07:40:34 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 22:40:34 -0700 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <200904260530.n3Q5U1NE000824@camembert.async.caltech.edu> References: <200904260530.n3Q5U1NE000824@camembert.async.caltech.edu> Message-ID: <09E195AF-2D6E-4A76-9328-DC4F29049719@gmail.com> It is easy to fix for many non Linux systems.and possible for Linux. Fairly well worn topic. - Jay (phone) On Apr 25, 2009, at 10:30 PM, Mika Nystrom wrote: > User threads certainly work fine on this machine (see my previous > email) with PM3... some would say they work "better"... :-) > > Jay writes: >> >> --Apple-Mail-1-423481883 >> Content-Type: text/plain; >> charset=us-ascii; >> format=flowed; >> delsp=yes >> Content-Transfer-Encoding: 7bit >> >> I think also due to simple use before init. >> >> - Jay (phone) >> >> On Apr 25, 2009, at 9:51 PM, Tony Hosking >> wrote: >> >>> Broken mostly because updated libraries detect forging of thread >>> contexts (state) for security reasons and blow up. >>> >>> On 25 Apr 2009, at 14:12, Jay wrote: >>> >>>> Cool. >>>> >>>>> If I use user threads, it's a different story (which is probably >>>> too bad, >>>> >>>> Oops, right, I forgot, I should have mentioned that, user threads >>>> have likely been broken on all platforms for a while. I noticed >>>> that on PPC_LINUX. I >> >> >> --Apple-Mail-1-423481883 >> Content-Type: text/html; >> charset=utf-8 >> Content-Transfer-Encoding: quoted-printable >> >>
I think also due to simple use = >> before init.

 - Jay (phone> span" = >> style=3D"-webkit-composition-fill-color: rgba(175, 192, 227, >> 0.231373); = >> -webkit-composition-frame-color: rgba(77, 128, 180, 0.231373); = >> ">)

On Apr 25, 2009, at 9:51 PM, Tony Hosking = >> <hosking at cs.purdue.edu> a>> = >> wrote:

> apple-content-edited=3D"true">> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >> normal; font-variant: normal; font-weight: normal; letter-spacing: = >> normal; line-height: normal; text-align: auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">
> style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; = >> -khtml-line-break: after-white-space; ">> span" = >> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >> normal; font-variant: normal; font-weight: normal; letter-spacing: = >> normal; line-height: normal; text-align: auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">Broken mostly = >> because updated libraries detect forging of thread contexts (state) >> for = >> security reasons and blow up.
 > div>
On = >> 25 Apr 2009, at 14:12, Jay wrote:

> class=3D"Apple-interchange-newline">
> class=3D"Apple-style-span" style=3D"border-collapse: separate; >> color: = >> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >> normal; font-variant: normal; font-weight: normal; letter-spacing: = >> normal; line-height: normal; orphans: 2; text-align: auto; text- >> indent: = >> 0px; text-transform: none; white-space: normal; widows: 2; word- >> spacing: = >> 0px; -webkit-border-horizontal-spacing: 0px; = >> -webkit-border-vertical-spacing: 0px; = >> -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = >> auto; -webkit-text-stroke-width: 0; ">
> style=3D"font-size: 10pt; font-family: Verdana; = >> ">Cool.
 
 > If I use user threads, it's a >> different = >> story (which is probably too bad,

Oops, right, I forgot, I >> should = >> have mentioned that, user threads have likely been broken on all = >> platforms for a while. I noticed that on PPC_LINUX. = >> I

> body>= >> >> --Apple-Mail-1-423481883-- From jay.krell at cornell.edu Sun Apr 26 07:46:05 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 22:46:05 -0700 Subject: [M3devel] FW: Uresource on freebsd 4? In-Reply-To: <200904260533.n3Q5X8UW001003@camembert.async.caltech.edu> References: <200904260533.n3Q5X8UW001003@camembert.async.caltech.edu> Message-ID: <818A2D47-EEB1-4EFB-B779-8237076A4C89@gmail.com> Cool. But reasonable imho to see your code and restore rtprocessposix if it suffices.. Or maybe other. Double check what you have, it is dangerous. - Jay (phone) On Apr 25, 2009, at 10:33 PM, Mika Nystrom wrote: > > As far as I'm concerned, I've sucked in all the Uresource junk into > interfaces inside my own application, so forget I said anything > about it. (One day when I'm ambitious (or get weird segfaults!), > I'll write the C wrappers; for now they're just copies of the old > PM3 interfaces..) > > Mika > > Jay writes: >> >> >> >> >> >> >> >> >> >> From hosking at cs.purdue.edu Sun Apr 26 10:54:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Apr 2009 18:54:57 +1000 Subject: [M3devel] Performance issues with CM3 In-Reply-To: <200904260522.n3Q5M01a000401@camembert.async.caltech.edu> References: <200904260522.n3Q5M01a000401@camembert.async.caltech.edu> Message-ID: On 26 Apr 2009, at 15:22, Mika Nystrom wrote: > > Hello again, > > Now I've managed to get all the code up and running under CM3. I > found and committed fixes to a bug in Wx and some code in one of > the m3tk libraries that looked like it never was finished in the > first place. > > As I mentioned earlier, I wasn't able to get user threads working > in CM3 on FreeBSD 4.11. But with some help from Jay, I was able to > get things working with libc_r. Performance, unfortunately, > leaves something to be desired. > > For the first time I've been able to compare timings on identical > hardware between the PM3 I was using and the CM3 that's out now. > > Note that optimization doesn't seem to work..? (Not even -O, much > less -O3... the compiler segfaults.) Are you passing -gstabs? It should not segfault on -O3 - this is a regression if it does. > Here's what I get, using no optimization either in PM3 or CM3. The > test is my Scheme interpreter generating SQL and Modula-3 code > (a bit like the Hibernate system you can get for Java): > > > CPU seconds CM3 PM3 > First version 5.269 1.366 > Fewer NEWs 2.039 0.440 (code cleanup on my part) > TYPECASE hack 1.770 (see below) > > Some "poor man's profiling" (i.e., ctrl-C'ing in m3gdb) suggests that > most of the time is spent either in threading code (this could just > be a lousy implementation in libc_r), the garbage collector, or in > "ScanTypecase". > > The only one of these routines I am qualified to do anything about is > ScanTypecase. I don't know why the Critical Mass people... colorful > language can one use on m3devel?>.. all over this code. I assume it > has > something to do with Java. > > The PM3 code (from SRC?) has this wonderful, concise, efficient bit: > > PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = > VAR t := Get (b); > BEGIN > IF (a >= RT0u.nTypes) THEN BadType (a) END; > IF (a = 0) THEN RETURN TRUE END; > RETURN (t.typecode <= a AND a <= t.lastSubTypeTC); > END IsSubtype; > > replaced with the following absolute abomination in CM3: > > PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = > VAR t: RT0.TypeDefn; > BEGIN > IF (a = RT0.NilTypecode) THEN RETURN TRUE END; > t := Get (a); > IF (t = NIL) THEN RETURN FALSE; END; > IF (t.typecode = b) THEN RETURN TRUE END; > WHILE (t.kind = ORD (TK.Obj)) DO > IF (t.link_state = 0) THEN FinishTypecell (t, NIL); END; > t := LOOPHOLE (t, RT0.ObjectTypeDefn).parent; > IF (t = NIL) THEN RETURN FALSE; END; > IF (t.typecode = b) THEN RETURN TRUE; END; > END; > IF (t.traced # 0) > THEN RETURN (b = RT0.RefanyTypecode); > ELSE RETURN (b = RT0.AddressTypecode); > END; > END IsSubtype; This is all to support dynamic loading of libraries. > Furthermore, CM3 has a hook for "ScanTypecase" that's missing > in PM3 (the older compiler actually generates code for this): > > PROCEDURE ScanTypecase (ref: REFANY; > x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = > VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; > BEGIN > IF (ref = NIL) THEN RETURN 0; END; > tc := TYPECODE (ref); > p := x; i := 0; > LOOP > IF (p.uid = 0) THEN RETURN i; END; > IF (p.defn = NIL) THEN > p.defn := FindType (p.uid); > IF (p.defn = NIL) THEN > Fail (RTE.MissingType, RTModule.FromDataAddress(x), > LOOPHOLE (p.uid, ADDRESS), NIL); > END; > END; > xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; > IF (tc = xc) OR IsSubtype (tc, xc) THEN RETURN i; END; > INC (p, ADRSIZE (p^)); INC (i); > END; > END ScanTypecase; > > Where to begin? A loop with all kinds of runtime checks of properties > that are supposedly known at compile time? IsSubtype (itself a loop) > called from inside the loop? Not if dynamically loaded! > I was able to cut out almost all of the typecase activity from my > program by using the following code in RTType.m3, which depends on > the ADDRESS x never changing (well more specifically never being > the same for two TYPECASE statements): > > TYPE > TypeCaseResult = RECORD > x : ADDRESS; > tc : Typecode; > arm : INTEGER; > END; > > CONST > TCCachePow = 6; > TCCacheSize = Word.Shift(1,TCCachePow); > TCMask = TCCacheSize-1; > > VAR TCCache := ARRAY [0..TCCacheSize-1] OF TypeCaseResult { > TypeCaseResult { LOOPHOLE(0,ADDRESS), 0, -1 } , > .. > }; > > (* > VAR tcScans := 0; tcHits := 0; (* instrumenting counters *) > *) > > PROCEDURE ScanTypecase (ref: REFANY; > x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = > VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; > BEGIN > tc := TYPECODE (ref); > IF (ref = NIL) THEN RETURN 0; END; > > WITH hash = Word.And(Word.Times(tc, > > Word.RightShift(LOOPHOLE(x,Word.T),2)), > TCMask), > entry = TCCache[hash] DO > (*INC(tcScans);*) > IF entry.x = x AND entry.tc = tc THEN > (*INC(tcHits);*) > RETURN entry.arm > END; > > p := x; i := 0; > LOOP > IF (p.uid = 0) THEN entry.x := x; entry.tc := tc; > entry.arm := i; RETURN i; END; > IF (p.defn = NIL) THEN > p.defn := FindType (p.uid); > IF (p.defn = NIL) THEN > Fail (RTE.MissingType, RTModule.FromDataAddress(x), > LOOPHOLE (p.uid, ADDRESS), NIL); > END; > END; > xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; > IF (tc = xc) OR IsSubtype (tc, xc) THEN entry.x := x; > entry.tc := tc; entry.arm := i; RETURN i; END; > INC (p, ADRSIZE (p^)); INC (i); > END; > END; > END ScanTypecase; > > I'm guessing the speedup for TYPECASE itself is a factor of at least > ten. But it's still a pretty nasty hack. And there is still a lot > of IsSubtype activity from narrowing. > > I suppose that the way the typecodes are generated in CM3 is > sufficiently different (meant to be extended at runtime?) from how > it was done in PM3 that one can't really go back to the old code. > Cardelli's idea of keeping an array of parents up to ROOT plus a > "depth" for each type might have merit, though. > > To see if a is a subtype of b, something like: > > b = a.ancestors[a.depth-b.depth-1] (* with appropriate range checks *) > > Would this be easy to put in? I'm not sure how one can be sure > that typecodes are done being generated? There's something called > RTTypeSRC.FinishObjectTypes .. > > And PM3 still generates code that's four times faster. > > Mika > From hosking at cs.purdue.edu Sun Apr 26 11:08:22 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Apr 2009 19:08:22 +1000 Subject: [M3devel] Confusing, but non-critical bug... In-Reply-To: <200904260528.n3Q5SPcu000732@camembert.async.caltech.edu> References: <200904260528.n3Q5SPcu000732@camembert.async.caltech.edu> Message-ID: <388F44BC-9826-4E4E-AE6B-FD91AE2E9B35@cs.purdue.edu> Definitely something broken in the build. On 26 Apr 2009, at 15:28, Mika Nystrom wrote: > > So I have a library, built against m3tk. Everything compiles, but > when cm3 tries to "ar" the library: > > > new "TypeTranslator.io" -> archiving libsstubgen.a > > Fatal Error: incomplete library > > missing compiled interface "M3AST_all.io" imported by: M3AST_SM_F.i3 > M3AST_PG.m3 M3AST_SM.m3 TypeNames.m3 AstToVal.m3 AstToType.m3 > M3ASTScopeNames.m3 > M3AST_PG_M.i3: missing object types: _t1ee311ce > imported by: M3AST_PG.m3 > M3AST_all.i3: missing object types: _t8eb32ef8 _t9ffde2a4 > _ta2581bcc > _t52bfa811 _t249b6ddc _t172a75ba _t774a90ea _tc92a7e8c > _t1d23b703 > _t2812849 _t1796950e _te47b91c _tccbf0da _tb53c334a _tf38721e4 > _tbbcfc2cb _teec6ca97 > imported by: M3AST_PG.m3 AstToType.m3 AstToVal.m3 M3AST_SM.m3 > M3AST_SM_F.i3 > missing compiled interface "M3AST_PG_M.io" imported by: M3AST_PG.m3 > > seconds #times operation > 0.06 22 inhaling library link info > 0.01 27 checking old link info > 0.21 896 merging new link info > 0.05 4 garbage collection > --------------------------------------------------- > 0.34 TOTAL > > rm m3make.args > cd ../src > > So I add "IMPORT M3AST_all;" to one of my interfaces (it's not used > there at all): > > (1943)trs80:~/t-cm3/mscheme/sstubgen/src>cm3 -x > --- building in ../FreeBSD4 --- > > ignoring override("sstubgen", "/home/mika/t-cm3/mscheme") > > new source -> compiling TypeTranslator.i3 > "../src/TypeTranslator.i3", line 12: warning: not used (M3AST_all) > 1 warning encountered > new source -> compiling TypeTranslator.m3 > "../src/TypeTranslator.m3", line 353: warning: not used (Add) > 1 warning encountered > new opaque info -> recompiling TypeTranslator.m3 > "../src/TypeTranslator.m3", line 353: warning: not used (Add) > 1 warning encountered > new "TypeTranslator.io" -> archiving libsstubgen.a > (1944)trs80:~/t-cm3/mscheme/sstubgen/src> > > Hmmmmmmmmmmmmm....... is anyone interested in looking at this? > As I said, it's non-critical (I can get things working, clearly, > even with the bug present), but it's very confusing. I have to > import an interface I'm not using...why? Where to begin looking? > > Mika From mika at async.caltech.edu Sun Apr 26 20:12:35 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 26 Apr 2009 11:12:35 -0700 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: Your message of "Sun, 26 Apr 2009 18:54:57 +1000." Message-ID: <200904261812.n3QICZYX035390@camembert.async.caltech.edu> Hi Tony, I looked at this more closely, and I was wrong. The compiler doesn't actually segfault on -O. I was using -gstabs+ but switched to -gstabs after your email (doesn't seem to matter). I get a ton of warnings at either optimization level, and there are definitely bugs in the optimizer. The resulting code is generally not correct. (By comparison, I had to turn off PM3's optimizer for only one of the hundred or so packages I build.) Things often fail to compile, even at -O. At -O3, I get one segfault: new source -> compiling TextCommandQueueTbl.i3 cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack exception handling new source -> compiling CommandLoop.m3 cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack exception handling ../src/CommandLoop.m3: In function 'CommandLoop__Run': ../src/CommandLoop.m3:279: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: CommandLoop.mc new source -> compiling CommandLoopDefaultCommand.m3 cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack exception handling new source -> compiling TextCommandTbl.m3 where: 272 (***************************************************************************** 273 * * 274 * Command Loop Main * 275 * * 276 *****************************************************************************) 277 278 279 PROCEDURE Run(self: T; source: Pathname.T := NIL; term: Term.T := NIL) = 280 CONST 281 Comment = SET OF CHAR{'%','#'}; 282 VAR 283 completer := NEW(StdCompleter, loop:=self); 284 line: TEXT; 285 BEGIN 286 IF term = NIL THEN 287 self.term := Term.Default(); 288 ELSE 289 self.term := term; 290 END; 291 LOOP 292 TRY 293 IF source # NIL THEN 294 DoLoad(self.load, TextList.List2("",source), self.term); 295 source := NIL; ... Even at -O, things don't work right. Here's a typical output: new source -> compiling PassiveArb1.m3 "../src/PassiveArb1.m3", line 68: warning: not used (e) "../src/PassiveArb1.m3", line 45: warning: not used (newCon) 2 warnings encountered ../src/PassiveArb1.m3: In function 'PassiveArb1__FApply': ../src/PassiveArb1.m3:81: warning: variable 'M3_Cwb5VA_buyO' might be clobbered by 'longjmp' or 'vfork' ../src/PassiveArb1.m3:81: warning: variable 'M3_Cwb5VA_selO' might be clobbered by 'longjmp' or 'vfork' new source -> compiling PassiveArb2.i3 new source -> compiling ExecRecorder2.i3 new source -> compiling ArbPingPong.i3 new source -> compiling PassiveArb2.m3 ../src/PassiveArb2.m3: In function 'PassiveArb2__Apply': ../src/PassiveArb2.m3:388: warning: variable 'M3_EWPD1K_delta' might be clobbered by 'longjmp' or 'vfork' ../src/PassiveArb2.m3:388: warning: variable 'M3_Cwb5VA_toExec' might be clobbered by 'longjmp' or 'vfork' new source -> compiling Globals.i3 new source -> compiling ActiveArb1.i3 new source -> compiling ActiveArb1.m3 new source -> compiling ExecRecorder.i3 new source -> compiling ExecRecorder.m3 new source -> compiling ExecRec.i3 new source -> compiling ExecRecorder2.m3 new source -> compiling ExecRec.m3 new source -> compiling ArbPingPong.m3 new source -> compiling Main.m3 "../src/Main.m3", line 72: warning: potentially unhandled exception: OSError.E "../src/Main.m3", line 30: warning: potentially unhandled exceptions: Rd.EndOfFile, Rd.Failure, Thread.Alerted "../src/Main.m3", line 31: warning: potentially unhandled exceptions: Thread.Alerted, Wr.Failure "../src/Main.m3", line 32: warning: potentially unhandled exceptions: Thread.Alerted, Wr.Failure "../src/Main.m3", line 33: warning: potentially unhandled exceptions: Thread.Alerted, Wr.Failure "../src/Main.m3", line 118: warning: potentially unhandled exception: OSError.E "../src/Main.m3", line 204: warning: potentially unhandled exception: OSError.E 7 warnings encountered -> linking testtrade /usr/lib/libc.so: WARNING! setkey(3) not present in the system! /usr/lib/libc.so: warning: this program uses gets(), which is unsafe. /usr/lib/libc.so: warning: mktemp() possibly used unsafely; consider using mkstemp() /usr/lib/libc.so: WARNING! des_setkey(3) not present in the system! /usr/lib/libc.so: WARNING! encrypt(3) not present in the system! /usr/lib/libc.so: warning: tmpnam() possibly used unsafely; consider using mkstemp() /usr/lib/libc.so: warning: this program uses f_prealloc(), which is not recommended. /usr/lib/libc.so: WARNING! des_cipher(3) not present in the system! /usr/lib/libc.so: warning: tempnam() possibly used unsafely; consider using mkstemp() Main.mo: In function `Main_M3': ../src/Main.m3:164: undefined reference to `Main__5__1__1__CanStart.198' /home/mika/t-cm3/calarm/twslib/FreeBSD4/libtwslib.so: undefined reference to `TWSReader__RCApply__RD.332' m3_link => 1 linker failed linking: testtrade Fatal Error: package build failed Mika Tony Hosking writes: > >On 26 Apr 2009, at 15:22, Mika Nystrom wrote: > >> >> Hello again, >> >> Now I've managed to get all the code up and running under CM3. I >> found and committed fixes to a bug in Wx and some code in one of >> the m3tk libraries that looked like it never was finished in the >> first place. >> >> As I mentioned earlier, I wasn't able to get user threads working >> in CM3 on FreeBSD 4.11. But with some help from Jay, I was able to >> get things working with libc_r. Performance, unfortunately, >> leaves something to be desired. >> >> For the first time I've been able to compare timings on identical >> hardware between the PM3 I was using and the CM3 that's out now. >> >> Note that optimization doesn't seem to work..? (Not even -O, much >> less -O3... the compiler segfaults.) > >Are you passing -gstabs? It should not segfault on -O3 - this is a >regression if it does. > >> Here's what I get, using no optimization either in PM3 or CM3. The >> test is my Scheme interpreter generating SQL and Modula-3 code >> (a bit like the Hibernate system you can get for Java): >> >> >> CPU seconds CM3 PM3 >> First version 5.269 1.366 >> Fewer NEWs 2.039 0.440 (code cleanup on my part) >> TYPECASE hack 1.770 (see below) >> >> Some "poor man's profiling" (i.e., ctrl-C'ing in m3gdb) suggests that >> most of the time is spent either in threading code (this could just >> be a lousy implementation in libc_r), the garbage collector, or in >> "ScanTypecase". >> >> The only one of these routines I am qualified to do anything about is >> ScanTypecase. I don't know why the Critical Mass people... > colorful >> language can one use on m3devel?>.. all over this code. I assume it >> has >> something to do with Java. >> >> The PM3 code (from SRC?) has this wonderful, concise, efficient bit: >> >> PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = >> VAR t := Get (b); >> BEGIN >> IF (a >= RT0u.nTypes) THEN BadType (a) END; >> IF (a = 0) THEN RETURN TRUE END; >> RETURN (t.typecode <= a AND a <= t.lastSubTypeTC); >> END IsSubtype; >> >> replaced with the following absolute abomination in CM3: >> >> PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = >> VAR t: RT0.TypeDefn; >> BEGIN >> IF (a = RT0.NilTypecode) THEN RETURN TRUE END; >> t := Get (a); >> IF (t = NIL) THEN RETURN FALSE; END; >> IF (t.typecode = b) THEN RETURN TRUE END; >> WHILE (t.kind = ORD (TK.Obj)) DO >> IF (t.link_state = 0) THEN FinishTypecell (t, NIL); END; >> t := LOOPHOLE (t, RT0.ObjectTypeDefn).parent; >> IF (t = NIL) THEN RETURN FALSE; END; >> IF (t.typecode = b) THEN RETURN TRUE; END; >> END; >> IF (t.traced # 0) >> THEN RETURN (b = RT0.RefanyTypecode); >> ELSE RETURN (b = RT0.AddressTypecode); >> END; >> END IsSubtype; > >This is all to support dynamic loading of libraries. > >> Furthermore, CM3 has a hook for "ScanTypecase" that's missing >> in PM3 (the older compiler actually generates code for this): >> >> PROCEDURE ScanTypecase (ref: REFANY; >> x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = >> VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; >> BEGIN >> IF (ref = NIL) THEN RETURN 0; END; >> tc := TYPECODE (ref); >> p := x; i := 0; >> LOOP >> IF (p.uid = 0) THEN RETURN i; END; >> IF (p.defn = NIL) THEN >> p.defn := FindType (p.uid); >> IF (p.defn = NIL) THEN >> Fail (RTE.MissingType, RTModule.FromDataAddress(x), >> LOOPHOLE (p.uid, ADDRESS), NIL); >> END; >> END; >> xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; >> IF (tc = xc) OR IsSubtype (tc, xc) THEN RETURN i; END; >> INC (p, ADRSIZE (p^)); INC (i); >> END; >> END ScanTypecase; >> >> Where to begin? A loop with all kinds of runtime checks of properties >> that are supposedly known at compile time? IsSubtype (itself a loop) >> called from inside the loop? > >Not if dynamically loaded! > >> I was able to cut out almost all of the typecase activity from my >> program by using the following code in RTType.m3, which depends on >> the ADDRESS x never changing (well more specifically never being >> the same for two TYPECASE statements): >> >> TYPE >> TypeCaseResult = RECORD >> x : ADDRESS; >> tc : Typecode; >> arm : INTEGER; >> END; >> >> CONST >> TCCachePow = 6; >> TCCacheSize = Word.Shift(1,TCCachePow); >> TCMask = TCCacheSize-1; >> >> VAR TCCache := ARRAY [0..TCCacheSize-1] OF TypeCaseResult { >> TypeCaseResult { LOOPHOLE(0,ADDRESS), 0, -1 } , >> .. >> }; >> >> (* >> VAR tcScans := 0; tcHits := 0; (* instrumenting counters *) >> *) >> >> PROCEDURE ScanTypecase (ref: REFANY; >> x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = >> VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; >> BEGIN >> tc := TYPECODE (ref); >> IF (ref = NIL) THEN RETURN 0; END; >> >> WITH hash = Word.And(Word.Times(tc, >> >> Word.RightShift(LOOPHOLE(x,Word.T),2)), >> TCMask), >> entry = TCCache[hash] DO >> (*INC(tcScans);*) >> IF entry.x = x AND entry.tc = tc THEN >> (*INC(tcHits);*) >> RETURN entry.arm >> END; >> >> p := x; i := 0; >> LOOP >> IF (p.uid = 0) THEN entry.x := x; entry.tc := tc; >> entry.arm := i; RETURN i; END; >> IF (p.defn = NIL) THEN >> p.defn := FindType (p.uid); >> IF (p.defn = NIL) THEN >> Fail (RTE.MissingType, RTModule.FromDataAddress(x), >> LOOPHOLE (p.uid, ADDRESS), NIL); >> END; >> END; >> xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; >> IF (tc = xc) OR IsSubtype (tc, xc) THEN entry.x := x; >> entry.tc := tc; entry.arm := i; RETURN i; END; >> INC (p, ADRSIZE (p^)); INC (i); >> END; >> END; >> END ScanTypecase; >> >> I'm guessing the speedup for TYPECASE itself is a factor of at least >> ten. But it's still a pretty nasty hack. And there is still a lot >> of IsSubtype activity from narrowing. >> >> I suppose that the way the typecodes are generated in CM3 is >> sufficiently different (meant to be extended at runtime?) from how >> it was done in PM3 that one can't really go back to the old code. >> Cardelli's idea of keeping an array of parents up to ROOT plus a >> "depth" for each type might have merit, though. >> >> To see if a is a subtype of b, something like: >> >> b = a.ancestors[a.depth-b.depth-1] (* with appropriate range checks *) >> >> Would this be easy to put in? I'm not sure how one can be sure >> that typecodes are done being generated? There's something called >> RTTypeSRC.FinishObjectTypes .. >> >> And PM3 still generates code that's four times faster. >> >> Mika >> From mika at async.caltech.edu Sun Apr 26 22:08:00 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 26 Apr 2009 13:08:00 -0700 Subject: [M3devel] Performance issues with CM3 In-Reply-To: Your message of "Sun, 26 Apr 2009 18:54:57 +1000." Message-ID: <200904262008.n3QK80hc040654@camembert.async.caltech.edu> Tony Hosking writes: > >On 26 Apr 2009, at 15:22, Mika Nystrom wrote: > >> >> Hello again, ... >> PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = >> VAR t: RT0.TypeDefn; >> BEGIN >> IF (a = RT0.NilTypecode) THEN RETURN TRUE END; >> t := Get (a); >> IF (t = NIL) THEN RETURN FALSE; END; >> IF (t.typecode = b) THEN RETURN TRUE END; >> WHILE (t.kind = ORD (TK.Obj)) DO >> IF (t.link_state = 0) THEN FinishTypecell (t, NIL); END; >> t := LOOPHOLE (t, RT0.ObjectTypeDefn).parent; >> IF (t = NIL) THEN RETURN FALSE; END; >> IF (t.typecode = b) THEN RETURN TRUE; END; >> END; >> IF (t.traced # 0) >> THEN RETURN (b = RT0.RefanyTypecode); >> ELSE RETURN (b = RT0.AddressTypecode); >> END; >> END IsSubtype; > >This is all to support dynamic loading of libraries. > >> Furthermore, CM3 has a hook for "ScanTypecase" that's missing >> in PM3 (the older compiler actually generates code for this): >> >> PROCEDURE ScanTypecase (ref: REFANY; >> x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = >> VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; >> BEGIN >> IF (ref = NIL) THEN RETURN 0; END; >> tc := TYPECODE (ref); >> p := x; i := 0; >> LOOP >> IF (p.uid = 0) THEN RETURN i; END; >> IF (p.defn = NIL) THEN >> p.defn := FindType (p.uid); >> IF (p.defn = NIL) THEN >> Fail (RTE.MissingType, RTModule.FromDataAddress(x), >> LOOPHOLE (p.uid, ADDRESS), NIL); >> END; >> END; >> xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; >> IF (tc = xc) OR IsSubtype (tc, xc) THEN RETURN i; END; >> INC (p, ADRSIZE (p^)); INC (i); >> END; >> END ScanTypecase; >> >> Where to begin? A loop with all kinds of runtime checks of properties >> that are supposedly known at compile time? IsSubtype (itself a loop) >> called from inside the loop? > >Not if dynamically loaded! > Tony, all right, but the code is still an abomination! The program only gets loaded once (even if dynamically). The TYPECASE might be executed millions, billions, trillions of times... if you execute this code a billion times, those IF statements are only "effective" once and just return the same value 999,999,999 times. Surely this information can be pre-computed at load time and stored somewhere so the IFs don't have to be re-interpreted? I don't know what the best solution is here. Is it really impossible to construct and re-construct the data structures that PM3 uses, or something equivalent? For instance, Cardelli's method of keeping the supertypes of a given type in an array would work fine with dynamic loading. It's almost as fast as the PM3 method but takes a bit more memory. One could limit these arrays to a certain size and then skip to the next array, to make a hybrid between what we have now in CM3 and a full array for every type. Do you think my hash table approach is safe? It's not nearly as elegant as the Cardelli method, but it works really well for a quick and dirty. It's ugly, but it's very fast. Or can the arrays used by the TYPECASEs move during program execution? In any case, with the standard CM3 implementation, my program spends more time in TYPECASE than the whole thing does under PM3. Do we have any code in CM3 that loads new types dynamically? I can see loading code dynamically, but types...? I'm very curious, is there an interface for it that "mortals" can use? If we have the mechanism, might as well put it to work... Another thing that bothers me a bit is that PushEFrame (sp?) seems to take a lot of cycles. Is the use of this routine due to the absence of a "stack walker"? I thought FreeBSD had a working stack walker in the Modula-3 runtime...? The thing about PushEFrame is that it makes the programmer want to avoid procedure calls, which is a real pity. Sussman and Steele's railings against the inefficient procedure calls in PL/I circa 1975 are legendary. (It's true, procedural abstraction is really wonderful.) Mika P.S. My hash table code re-attached in case someone wants to look at it again (instrumenting code commented out): TYPE TypeCaseResult = RECORD x : ADDRESS; tc : Typecode; arm : INTEGER; END; CONST TCCachePow = 6; TCCacheSize = Word.Shift(1,TCCachePow); TCMask = TCCacheSize-1; VAR TCCache := ARRAY [0..TCCacheSize-1] OF TypeCaseResult { TypeCaseResult { LOOPHOLE(0,ADDRESS), 0, -1 } , .. }; (* VAR tcScans := 0; tcHits := 0; *) PROCEDURE ScanTypecase (ref: REFANY; x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; BEGIN tc := TYPECODE (ref); IF (ref = NIL) THEN RETURN 0; END; WITH hash = Word.And(Word.Times(tc, Word.RightShift(LOOPHOLE(x,Word.T),2)), TCMask), entry = TCCache[hash] DO (*INC(tcScans);*) IF entry.x = x AND entry.tc = tc THEN (*INC(tcHits);*) RETURN entry.arm END; p := x; i := 0; LOOP IF (p.uid = 0) THEN entry.x := x; entry.tc := tc; entry.arm := i; RETURN i; END; IF (p.defn = NIL) THEN p.defn := FindType (p.uid); IF (p.defn = NIL) THEN Fail (RTE.MissingType, RTModule.FromDataAddress(x), LOOPHOLE (p.uid, ADDRESS), NIL); END; END; xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; IF (tc = xc) OR IsSubtype (tc, xc) THEN entry.x := x; entry.tc := tc; entry.arm := i; RETURN i; END; INC (p, ADRSIZE (p^)); INC (i); END; END; END ScanTypecase; From hosking at cs.purdue.edu Mon Apr 27 02:04:26 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Apr 2009 10:04:26 +1000 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: <200904261812.n3QICZYX035390@camembert.async.caltech.edu> References: <200904261812.n3QICZYX035390@camembert.async.caltech.edu> Message-ID: <34EE25E2-4DE9-493A-AC88-8D11A8545536@cs.purdue.edu> I am very disturbed about this since it suggests a regression. I had spent a huge amount of time a year or so back making sure the backend would play properly with gcc -O3, but it seems we are now back in a bad place. I'm not sure what changes have occurred to the backend since then, but they would be the prime candidates. Unfortunately, I don't have a lot of time right now to try to debug these -O3 problems, but I do want to fix them since they will eventually impinge on my own work. It would be really good to get our regressions framework back up and running and to put -O3 in there as the default build option -- it seems there have been ongoing Tinderbox problems for a while now, since my SOLgnu regression runs appear to have stopped completely. I'll need to check the logs. On 27 Apr 2009, at 04:12, Mika Nystrom wrote: > Hi Tony, > > I looked at this more closely, and I was wrong. The compiler doesn't > actually segfault on -O. I was using -gstabs+ but switched to -gstabs > after your email (doesn't seem to matter). > > I get a ton of warnings at either optimization level, and there are > definitely bugs in the optimizer. The resulting code is generally > not correct. (By comparison, I had to turn off PM3's optimizer for > only one of the hundred or so packages I build.) Things often fail > to compile, even at -O. > > At -O3, I get one segfault: > > new source -> compiling TextCommandQueueTbl.i3 > cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack > exception handling > new source -> compiling CommandLoop.m3 > cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack > exception handling > ../src/CommandLoop.m3: In function 'CommandLoop__Run': > ../src/CommandLoop.m3:279: internal compiler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > m3_backend => 4 > m3cc (aka cm3cg) failed compiling: CommandLoop.mc > new source -> compiling CommandLoopDefaultCommand.m3 > cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack > exception handling > new source -> compiling TextCommandTbl.m3 > > where: > > 272 > (***************************************************************************** > 273 > * * > 274 * Command Loop > Main * > 275 > * * > 276 > *****************************************************************************) > 277 > 278 > 279 PROCEDURE Run(self: T; source: Pathname.T := NIL; term: > Term.T := NIL) = > 280 CONST > 281 Comment = SET OF CHAR{'%','#'}; > 282 VAR > 283 completer := NEW(StdCompleter, loop:=self); > 284 line: TEXT; > 285 BEGIN > 286 IF term = NIL THEN > 287 self.term := Term.Default(); > 288 ELSE > 289 self.term := term; > 290 END; > 291 LOOP > 292 TRY > 293 IF source # NIL THEN > 294 DoLoad(self.load, TextList.List2("",source), > self.term); > 295 source := NIL; > > ... > > Even at -O, things don't work right. Here's a typical output: > > new source -> compiling PassiveArb1.m3 > "../src/PassiveArb1.m3", line 68: warning: not used (e) > "../src/PassiveArb1.m3", line 45: warning: not used (newCon) > 2 warnings encountered > ../src/PassiveArb1.m3: In function 'PassiveArb1__FApply': > ../src/PassiveArb1.m3:81: warning: variable 'M3_Cwb5VA_buyO' might > be clobbered by 'longjmp' or 'vfork' > ../src/PassiveArb1.m3:81: warning: variable 'M3_Cwb5VA_selO' might > be clobbered by 'longjmp' or 'vfork' > new source -> compiling PassiveArb2.i3 > new source -> compiling ExecRecorder2.i3 > new source -> compiling ArbPingPong.i3 > new source -> compiling PassiveArb2.m3 > ../src/PassiveArb2.m3: In function 'PassiveArb2__Apply': > ../src/PassiveArb2.m3:388: warning: variable 'M3_EWPD1K_delta' might > be clobbered by 'longjmp' or 'vfork' > ../src/PassiveArb2.m3:388: warning: variable 'M3_Cwb5VA_toExec' > might be clobbered by 'longjmp' or 'vfork' > new source -> compiling Globals.i3 > new source -> compiling ActiveArb1.i3 > new source -> compiling ActiveArb1.m3 > new source -> compiling ExecRecorder.i3 > new source -> compiling ExecRecorder.m3 > new source -> compiling ExecRec.i3 > new source -> compiling ExecRecorder2.m3 > new source -> compiling ExecRec.m3 > new source -> compiling ArbPingPong.m3 > new source -> compiling Main.m3 > "../src/Main.m3", line 72: warning: potentially unhandled exception: > OSError.E > "../src/Main.m3", line 30: warning: potentially unhandled > exceptions: Rd.EndOfFile, Rd.Failure, Thread.Alerted > "../src/Main.m3", line 31: warning: potentially unhandled > exceptions: Thread.Alerted, Wr.Failure > "../src/Main.m3", line 32: warning: potentially unhandled > exceptions: Thread.Alerted, Wr.Failure > "../src/Main.m3", line 33: warning: potentially unhandled > exceptions: Thread.Alerted, Wr.Failure > "../src/Main.m3", line 118: warning: potentially unhandled > exception: OSError.E > "../src/Main.m3", line 204: warning: potentially unhandled > exception: OSError.E > 7 warnings encountered > -> linking testtrade > /usr/lib/libc.so: WARNING! setkey(3) not present in the system! > /usr/lib/libc.so: warning: this program uses gets(), which is unsafe. > /usr/lib/libc.so: warning: mktemp() possibly used unsafely; consider > using mkstemp() > /usr/lib/libc.so: WARNING! des_setkey(3) not present in the system! > /usr/lib/libc.so: WARNING! encrypt(3) not present in the system! > /usr/lib/libc.so: warning: tmpnam() possibly used unsafely; consider > using mkstemp() > /usr/lib/libc.so: warning: this program uses f_prealloc(), which is > not recommended. > /usr/lib/libc.so: WARNING! des_cipher(3) not present in the system! > /usr/lib/libc.so: warning: tempnam() possibly used unsafely; > consider using mkstemp() > Main.mo: In function `Main_M3': > ../src/Main.m3:164: undefined reference to `Main__5__1__1__CanStart. > 198' > /home/mika/t-cm3/calarm/twslib/FreeBSD4/libtwslib.so: undefined > reference to `TWSReader__RCApply__RD.332' > m3_link => 1 > linker failed linking: testtrade > Fatal Error: package build failed > > > Mika > > > > Tony Hosking writes: >> >> On 26 Apr 2009, at 15:22, Mika Nystrom wrote: >> >>> >>> Hello again, >>> >>> Now I've managed to get all the code up and running under CM3. I >>> found and committed fixes to a bug in Wx and some code in one of >>> the m3tk libraries that looked like it never was finished in the >>> first place. >>> >>> As I mentioned earlier, I wasn't able to get user threads working >>> in CM3 on FreeBSD 4.11. But with some help from Jay, I was able to >>> get things working with libc_r. Performance, unfortunately, >>> leaves something to be desired. >>> >>> For the first time I've been able to compare timings on identical >>> hardware between the PM3 I was using and the CM3 that's out now. >>> >>> Note that optimization doesn't seem to work..? (Not even -O, much >>> less -O3... the compiler segfaults.) >> >> Are you passing -gstabs? It should not segfault on -O3 - this is a >> regression if it does. >> >>> Here's what I get, using no optimization either in PM3 or CM3. The >>> test is my Scheme interpreter generating SQL and Modula-3 code >>> (a bit like the Hibernate system you can get for Java): >>> >>> >>> CPU seconds CM3 PM3 >>> First version 5.269 1.366 >>> Fewer NEWs 2.039 0.440 (code cleanup on my part) >>> TYPECASE hack 1.770 (see below) >>> >>> Some "poor man's profiling" (i.e., ctrl-C'ing in m3gdb) suggests >>> that >>> most of the time is spent either in threading code (this could just >>> be a lousy implementation in libc_r), the garbage collector, or in >>> "ScanTypecase". >>> >>> The only one of these routines I am qualified to do anything about >>> is >>> ScanTypecase. I don't know why the Critical Mass people... >> colorful >>> language can one use on m3devel?>.. all over this code. I assume it >>> has >>> something to do with Java. >>> >>> The PM3 code (from SRC?) has this wonderful, concise, efficient bit: >>> >>> PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = >>> VAR t := Get (b); >>> BEGIN >>> IF (a >= RT0u.nTypes) THEN BadType (a) END; >>> IF (a = 0) THEN RETURN TRUE END; >>> RETURN (t.typecode <= a AND a <= t.lastSubTypeTC); >>> END IsSubtype; >>> >>> replaced with the following absolute abomination in CM3: >>> >>> PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = >>> VAR t: RT0.TypeDefn; >>> BEGIN >>> IF (a = RT0.NilTypecode) THEN RETURN TRUE END; >>> t := Get (a); >>> IF (t = NIL) THEN RETURN FALSE; END; >>> IF (t.typecode = b) THEN RETURN TRUE END; >>> WHILE (t.kind = ORD (TK.Obj)) DO >>> IF (t.link_state = 0) THEN FinishTypecell (t, NIL); END; >>> t := LOOPHOLE (t, RT0.ObjectTypeDefn).parent; >>> IF (t = NIL) THEN RETURN FALSE; END; >>> IF (t.typecode = b) THEN RETURN TRUE; END; >>> END; >>> IF (t.traced # 0) >>> THEN RETURN (b = RT0.RefanyTypecode); >>> ELSE RETURN (b = RT0.AddressTypecode); >>> END; >>> END IsSubtype; >> >> This is all to support dynamic loading of libraries. >> >>> Furthermore, CM3 has a hook for "ScanTypecase" that's missing >>> in PM3 (the older compiler actually generates code for this): >>> >>> PROCEDURE ScanTypecase (ref: REFANY; >>> x: ADDRESS(*ARRAY [0..] OF Cell*)): >>> INTEGER = >>> VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; >>> BEGIN >>> IF (ref = NIL) THEN RETURN 0; END; >>> tc := TYPECODE (ref); >>> p := x; i := 0; >>> LOOP >>> IF (p.uid = 0) THEN RETURN i; END; >>> IF (p.defn = NIL) THEN >>> p.defn := FindType (p.uid); >>> IF (p.defn = NIL) THEN >>> Fail (RTE.MissingType, RTModule.FromDataAddress(x), >>> LOOPHOLE (p.uid, ADDRESS), NIL); >>> END; >>> END; >>> xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; >>> IF (tc = xc) OR IsSubtype (tc, xc) THEN RETURN i; END; >>> INC (p, ADRSIZE (p^)); INC (i); >>> END; >>> END ScanTypecase; >>> >>> Where to begin? A loop with all kinds of runtime checks of >>> properties >>> that are supposedly known at compile time? IsSubtype (itself a loop) >>> called from inside the loop? >> >> Not if dynamically loaded! >> >>> I was able to cut out almost all of the typecase activity from my >>> program by using the following code in RTType.m3, which depends on >>> the ADDRESS x never changing (well more specifically never being >>> the same for two TYPECASE statements): >>> >>> TYPE >>> TypeCaseResult = RECORD >>> x : ADDRESS; >>> tc : Typecode; >>> arm : INTEGER; >>> END; >>> >>> CONST >>> TCCachePow = 6; >>> TCCacheSize = Word.Shift(1,TCCachePow); >>> TCMask = TCCacheSize-1; >>> >>> VAR TCCache := ARRAY [0..TCCacheSize-1] OF TypeCaseResult { >>> TypeCaseResult { LOOPHOLE(0,ADDRESS), 0, -1 } , >>> .. >>> }; >>> >>> (* >>> VAR tcScans := 0; tcHits := 0; (* instrumenting counters *) >>> *) >>> >>> PROCEDURE ScanTypecase (ref: REFANY; >>> x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = >>> VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; >>> BEGIN >>> tc := TYPECODE (ref); >>> IF (ref = NIL) THEN RETURN 0; END; >>> >>> WITH hash = Word.And(Word.Times(tc, >>> >>> Word.RightShift(LOOPHOLE(x,Word.T),2)), >>> TCMask), >>> entry = TCCache[hash] DO >>> (*INC(tcScans);*) >>> IF entry.x = x AND entry.tc = tc THEN >>> (*INC(tcHits);*) >>> RETURN entry.arm >>> END; >>> >>> p := x; i := 0; >>> LOOP >>> IF (p.uid = 0) THEN entry.x := x; entry.tc := tc; >>> entry.arm := i; RETURN i; END; >>> IF (p.defn = NIL) THEN >>> p.defn := FindType (p.uid); >>> IF (p.defn = NIL) THEN >>> Fail (RTE.MissingType, RTModule.FromDataAddress(x), >>> LOOPHOLE (p.uid, ADDRESS), NIL); >>> END; >>> END; >>> xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; >>> IF (tc = xc) OR IsSubtype (tc, xc) THEN entry.x := x; >>> entry.tc := tc; entry.arm := i; RETURN i; END; >>> INC (p, ADRSIZE (p^)); INC (i); >>> END; >>> END; >>> END ScanTypecase; >>> >>> I'm guessing the speedup for TYPECASE itself is a factor of at least >>> ten. But it's still a pretty nasty hack. And there is still a lot >>> of IsSubtype activity from narrowing. >>> >>> I suppose that the way the typecodes are generated in CM3 is >>> sufficiently different (meant to be extended at runtime?) from how >>> it was done in PM3 that one can't really go back to the old code. >>> Cardelli's idea of keeping an array of parents up to ROOT plus a >>> "depth" for each type might have merit, though. >>> >>> To see if a is a subtype of b, something like: >>> >>> b = a.ancestors[a.depth-b.depth-1] (* with appropriate range >>> checks *) >>> >>> Would this be easy to put in? I'm not sure how one can be sure >>> that typecodes are done being generated? There's something called >>> RTTypeSRC.FinishObjectTypes .. >>> >>> And PM3 still generates code that's four times faster. >>> >>> Mika >>> From mika at async.caltech.edu Mon Apr 27 02:31:42 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 26 Apr 2009 17:31:42 -0700 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: Your message of "Mon, 27 Apr 2009 10:04:26 +1000." <34EE25E2-4DE9-493A-AC88-8D11A8545536@cs.purdue.edu> Message-ID: <200904270031.n3R0VgjC052408@camembert.async.caltech.edu> Tony, it might not be as bad as all that. Well, on one level it is. Things are certainly not perfect. But I am able to operate with m3core built with -O (as well as with -O3). Lots of scary-looking compiler warnings, but things do work. There are just a few programs that won't build. I didn't try "all" in the CM3 dist---only my own programs and m3core (since m3core has the biggest performance impact). With lots of tweaks and adjustments, I now see my code running about 100% slower under CM3 than the same code does under PM3 (on the same machine). This is including my typecase hacks, as described earlier today. I'm guessing most of it is the FreeBSD pthreads implementation in libc_r + the calls to PushEFrame. Mika Tony Hosking writes: >I am very disturbed about this since it suggests a regression. I had >spent a huge amount of time a year or so back making sure the backend >would play properly with gcc -O3, but it seems we are now back in a >bad place. I'm not sure what changes have occurred to the backend >since then, but they would be the prime candidates. Unfortunately, I >don't have a lot of time right now to try to debug these -O3 problems, >but I do want to fix them since they will eventually impinge on my own >work. It would be really good to get our regressions framework back >up and running and to put -O3 in there as the default build option -- >it seems there have been ongoing Tinderbox problems for a while now, >since my SOLgnu regression runs appear to have stopped completely. >I'll need to check the logs. > >On 27 Apr 2009, at 04:12, Mika Nystrom wrote: > >> Hi Tony, >> >> I looked at this more closely, and I was wrong. The compiler doesn't >> actually segfault on -O. I was using -gstabs+ but switched to -gstabs >> after your email (doesn't seem to matter). >> >> I get a ton of warnings at either optimization level, and there are >> definitely bugs in the optimizer. The resulting code is generally >> not correct. (By comparison, I had to turn off PM3's optimizer for >> only one of the hundred or so packages I build.) Things often fail >> to compile, even at -O. >> >> At -O3, I get one segfault: >> >> new source -> compiling TextCommandQueueTbl.i3 >> cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack >> exception handling >> new source -> compiling CommandLoop.m3 >> cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack >> exception handling >> ../src/CommandLoop.m3: In function 'CommandLoop__Run': >> ../src/CommandLoop.m3:279: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> m3_backend => 4 >> m3cc (aka cm3cg) failed compiling: CommandLoop.mc >> new source -> compiling CommandLoopDefaultCommand.m3 >> cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack >> exception handling >> new source -> compiling TextCommandTbl.m3 >> >> where: >> >> 272 >> (***************************************************************************** >> 273 >> * * >> 274 * Command Loop >> Main * >> 275 >> * * >> 276 >> *****************************************************************************) >> 277 >> 278 >> 279 PROCEDURE Run(self: T; source: Pathname.T := NIL; term: >> Term.T := NIL) = >> 280 CONST >> 281 Comment = SET OF CHAR{'%','#'}; >> 282 VAR >> 283 completer := NEW(StdCompleter, loop:=self); >> 284 line: TEXT; >> 285 BEGIN >> 286 IF term = NIL THEN >> 287 self.term := Term.Default(); >> 288 ELSE >> 289 self.term := term; >> 290 END; >> 291 LOOP >> 292 TRY >> 293 IF source # NIL THEN >> 294 DoLoad(self.load, TextList.List2("",source), >> self.term); >> 295 source := NIL; >> >> ... >> >> Even at -O, things don't work right. Here's a typical output: >> >> new source -> compiling PassiveArb1.m3 >> "../src/PassiveArb1.m3", line 68: warning: not used (e) >> "../src/PassiveArb1.m3", line 45: warning: not used (newCon) >> 2 warnings encountered >> ../src/PassiveArb1.m3: In function 'PassiveArb1__FApply': >> ../src/PassiveArb1.m3:81: warning: variable 'M3_Cwb5VA_buyO' might >> be clobbered by 'longjmp' or 'vfork' >> ../src/PassiveArb1.m3:81: warning: variable 'M3_Cwb5VA_selO' might >> be clobbered by 'longjmp' or 'vfork' >> new source -> compiling PassiveArb2.i3 >> new source -> compiling ExecRecorder2.i3 >> new source -> compiling ArbPingPong.i3 >> new source -> compiling PassiveArb2.m3 >> ../src/PassiveArb2.m3: In function 'PassiveArb2__Apply': >> ../src/PassiveArb2.m3:388: warning: variable 'M3_EWPD1K_delta' might >> be clobbered by 'longjmp' or 'vfork' >> ../src/PassiveArb2.m3:388: warning: variable 'M3_Cwb5VA_toExec' >> might be clobbered by 'longjmp' or 'vfork' >> new source -> compiling Globals.i3 >> new source -> compiling ActiveArb1.i3 >> new source -> compiling ActiveArb1.m3 >> new source -> compiling ExecRecorder.i3 >> new source -> compiling ExecRecorder.m3 >> new source -> compiling ExecRec.i3 >> new source -> compiling ExecRecorder2.m3 >> new source -> compiling ExecRec.m3 >> new source -> compiling ArbPingPong.m3 >> new source -> compiling Main.m3 >> "../src/Main.m3", line 72: warning: potentially unhandled exception: >> OSError.E >> "../src/Main.m3", line 30: warning: potentially unhandled >> exceptions: Rd.EndOfFile, Rd.Failure, Thread.Alerted >> "../src/Main.m3", line 31: warning: potentially unhandled >> exceptions: Thread.Alerted, Wr.Failure >> "../src/Main.m3", line 32: warning: potentially unhandled >> exceptions: Thread.Alerted, Wr.Failure >> "../src/Main.m3", line 33: warning: potentially unhandled >> exceptions: Thread.Alerted, Wr.Failure >> "../src/Main.m3", line 118: warning: potentially unhandled >> exception: OSError.E >> "../src/Main.m3", line 204: warning: potentially unhandled >> exception: OSError.E >> 7 warnings encountered >> -> linking testtrade >> /usr/lib/libc.so: WARNING! setkey(3) not present in the system! >> /usr/lib/libc.so: warning: this program uses gets(), which is unsafe. >> /usr/lib/libc.so: warning: mktemp() possibly used unsafely; consider >> using mkstemp() >> /usr/lib/libc.so: WARNING! des_setkey(3) not present in the system! >> /usr/lib/libc.so: WARNING! encrypt(3) not present in the system! >> /usr/lib/libc.so: warning: tmpnam() possibly used unsafely; consider >> using mkstemp() >> /usr/lib/libc.so: warning: this program uses f_prealloc(), which is >> not recommended. >> /usr/lib/libc.so: WARNING! des_cipher(3) not present in the system! >> /usr/lib/libc.so: warning: tempnam() possibly used unsafely; >> consider using mkstemp() >> Main.mo: In function `Main_M3': >> ../src/Main.m3:164: undefined reference to `Main__5__1__1__CanStart. >> 198' >> /home/mika/t-cm3/calarm/twslib/FreeBSD4/libtwslib.so: undefined >> reference to `TWSReader__RCApply__RD.332' >> m3_link => 1 >> linker failed linking: testtrade >> Fatal Error: package build failed >> >> >> Mika >> >> >> >> Tony Hosking writes: >>> >>> On 26 Apr 2009, at 15:22, Mika Nystrom wrote: >>> >>>> >>>> Hello again, >>>> >>>> Now I've managed to get all the code up and running under CM3. I >>>> found and committed fixes to a bug in Wx and some code in one of >>>> the m3tk libraries that looked like it never was finished in the >>>> first place. >>>> >>>> As I mentioned earlier, I wasn't able to get user threads working >>>> in CM3 on FreeBSD 4.11. But with some help from Jay, I was able to >>>> get things working with libc_r. Performance, unfortunately, >>>> leaves something to be desired. >>>> >>>> For the first time I've been able to compare timings on identical >>>> hardware between the PM3 I was using and the CM3 that's out now. >>>> >>>> Note that optimization doesn't seem to work..? (Not even -O, much >>>> less -O3... the compiler segfaults.) >>> >>> Are you passing -gstabs? It should not segfault on -O3 - this is a >>> regression if it does. >>> >>>> Here's what I get, using no optimization either in PM3 or CM3. The >>>> test is my Scheme interpreter generating SQL and Modula-3 code >>>> (a bit like the Hibernate system you can get for Java): >>>> >>>> >>>> CPU seconds CM3 PM3 >>>> First version 5.269 1.366 >>>> Fewer NEWs 2.039 0.440 (code cleanup on my part) >>>> TYPECASE hack 1.770 (see below) >>>> >>>> Some "poor man's profiling" (i.e., ctrl-C'ing in m3gdb) suggests >>>> that >>>> most of the time is spent either in threading code (this could just >>>> be a lousy implementation in libc_r), the garbage collector, or in >>>> "ScanTypecase". >>>> >>>> The only one of these routines I am qualified to do anything about >>>> is >>>> ScanTypecase. I don't know why the Critical Mass people... >>> colorful >>>> language can one use on m3devel?>.. all over this code. I assume it >>>> has >>>> something to do with Java. >>>> >>>> The PM3 code (from SRC?) has this wonderful, concise, efficient bit: >>>> >>>> PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = >>>> VAR t := Get (b); >>>> BEGIN >>>> IF (a >= RT0u.nTypes) THEN BadType (a) END; >>>> IF (a = 0) THEN RETURN TRUE END; >>>> RETURN (t.typecode <= a AND a <= t.lastSubTypeTC); >>>> END IsSubtype; >>>> >>>> replaced with the following absolute abomination in CM3: >>>> >>>> PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = >>>> VAR t: RT0.TypeDefn; >>>> BEGIN >>>> IF (a = RT0.NilTypecode) THEN RETURN TRUE END; >>>> t := Get (a); >>>> IF (t = NIL) THEN RETURN FALSE; END; >>>> IF (t.typecode = b) THEN RETURN TRUE END; >>>> WHILE (t.kind = ORD (TK.Obj)) DO >>>> IF (t.link_state = 0) THEN FinishTypecell (t, NIL); END; >>>> t := LOOPHOLE (t, RT0.ObjectTypeDefn).parent; >>>> IF (t = NIL) THEN RETURN FALSE; END; >>>> IF (t.typecode = b) THEN RETURN TRUE; END; >>>> END; >>>> IF (t.traced # 0) >>>> THEN RETURN (b = RT0.RefanyTypecode); >>>> ELSE RETURN (b = RT0.AddressTypecode); >>>> END; >>>> END IsSubtype; >>> >>> This is all to support dynamic loading of libraries. >>> >>>> Furthermore, CM3 has a hook for "ScanTypecase" that's missing >>>> in PM3 (the older compiler actually generates code for this): >>>> >>>> PROCEDURE ScanTypecase (ref: REFANY; >>>> x: ADDRESS(*ARRAY [0..] OF Cell*)): >>>> INTEGER = >>>> VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; >>>> BEGIN >>>> IF (ref = NIL) THEN RETURN 0; END; >>>> tc := TYPECODE (ref); >>>> p := x; i := 0; >>>> LOOP >>>> IF (p.uid = 0) THEN RETURN i; END; >>>> IF (p.defn = NIL) THEN >>>> p.defn := FindType (p.uid); >>>> IF (p.defn = NIL) THEN >>>> Fail (RTE.MissingType, RTModule.FromDataAddress(x), >>>> LOOPHOLE (p.uid, ADDRESS), NIL); >>>> END; >>>> END; >>>> xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; >>>> IF (tc = xc) OR IsSubtype (tc, xc) THEN RETURN i; END; >>>> INC (p, ADRSIZE (p^)); INC (i); >>>> END; >>>> END ScanTypecase; >>>> >>>> Where to begin? A loop with all kinds of runtime checks of >>>> properties >>>> that are supposedly known at compile time? IsSubtype (itself a loop) >>>> called from inside the loop? >>> >>> Not if dynamically loaded! >>> >>>> I was able to cut out almost all of the typecase activity from my >>>> program by using the following code in RTType.m3, which depends on >>>> the ADDRESS x never changing (well more specifically never being >>>> the same for two TYPECASE statements): >>>> >>>> TYPE >>>> TypeCaseResult = RECORD >>>> x : ADDRESS; >>>> tc : Typecode; >>>> arm : INTEGER; >>>> END; >>>> >>>> CONST >>>> TCCachePow = 6; >>>> TCCacheSize = Word.Shift(1,TCCachePow); >>>> TCMask = TCCacheSize-1; >>>> >>>> VAR TCCache := ARRAY [0..TCCacheSize-1] OF TypeCaseResult { >>>> TypeCaseResult { LOOPHOLE(0,ADDRESS), 0, -1 } , >>>> .. >>>> }; >>>> >>>> (* >>>> VAR tcScans := 0; tcHits := 0; (* instrumenting counters *) >>>> *) >>>> >>>> PROCEDURE ScanTypecase (ref: REFANY; >>>> x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = >>>> VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; >>>> BEGIN >>>> tc := TYPECODE (ref); >>>> IF (ref = NIL) THEN RETURN 0; END; >>>> >>>> WITH hash = Word.And(Word.Times(tc, >>>> >>>> Word.RightShift(LOOPHOLE(x,Word.T),2)), >>>> TCMask), >>>> entry = TCCache[hash] DO >>>> (*INC(tcScans);*) >>>> IF entry.x = x AND entry.tc = tc THEN >>>> (*INC(tcHits);*) >>>> RETURN entry.arm >>>> END; >>>> >>>> p := x; i := 0; >>>> LOOP >>>> IF (p.uid = 0) THEN entry.x := x; entry.tc := tc; >>>> entry.arm := i; RETURN i; END; >>>> IF (p.defn = NIL) THEN >>>> p.defn := FindType (p.uid); >>>> IF (p.defn = NIL) THEN >>>> Fail (RTE.MissingType, RTModule.FromDataAddress(x), >>>> LOOPHOLE (p.uid, ADDRESS), NIL); >>>> END; >>>> END; >>>> xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; >>>> IF (tc = xc) OR IsSubtype (tc, xc) THEN entry.x := x; >>>> entry.tc := tc; entry.arm := i; RETURN i; END; >>>> INC (p, ADRSIZE (p^)); INC (i); >>>> END; >>>> END; >>>> END ScanTypecase; >>>> >>>> I'm guessing the speedup for TYPECASE itself is a factor of at least >>>> ten. But it's still a pretty nasty hack. And there is still a lot >>>> of IsSubtype activity from narrowing. >>>> >>>> I suppose that the way the typecodes are generated in CM3 is >>>> sufficiently different (meant to be extended at runtime?) from how >>>> it was done in PM3 that one can't really go back to the old code. >>>> Cardelli's idea of keeping an array of parents up to ROOT plus a >>>> "depth" for each type might have merit, though. >>>> >>>> To see if a is a subtype of b, something like: >>>> >>>> b = a.ancestors[a.depth-b.depth-1] (* with appropriate range >>>> checks *) >>>> >>>> Would this be easy to put in? I'm not sure how one can be sure >>>> that typecodes are done being generated? There's something called >>>> RTTypeSRC.FinishObjectTypes .. >>>> >>>> And PM3 still generates code that's four times faster. >>>> >>>> Mika >>>> > From hosking at cs.purdue.edu Mon Apr 27 02:26:06 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Apr 2009 10:26:06 +1000 Subject: [M3devel] Performance issues with CM3 In-Reply-To: <200904262008.n3QK80hc040654@camembert.async.caltech.edu> References: <200904262008.n3QK80hc040654@camembert.async.caltech.edu> Message-ID: <7FA8A570-6672-4B29-8349-5A6EFA6F0562@cs.purdue.edu> >>> Tony, all right, but the code is still an abomination! The program > only gets loaded once (even if dynamically). The TYPECASE might > be executed millions, billions, trillions of times... if you > execute this code a billion times, those IF statements are only > "effective" once and just return the same value 999,999,999 times. > Surely this information can be pre-computed at load time and stored > somewhere so the IFs don't have to be re-interpreted? I haven't looked closely at this code but it's been there since the Critical Mass days. The dynamic loading I refer to is for explicit opening and linking of .so files -- not the usual dynamic linking that takes place with .so files resolved at link time. Anyway, perhaps the code can be cleaned up. > I don't know what the best solution is here. Is it really impossible > to construct and re-construct the data structures that PM3 uses, > or something equivalent? I don't know. Possibly. Again, I don't know enough about this corner of the world to answer all of the following questions: > For instance, Cardelli's method of keeping the supertypes of a given > type in an array would work fine with dynamic loading. It's almost > as fast as the PM3 method but takes a bit more memory. One could > limit these arrays to a certain size and then skip to the next > array, to make a hybrid between what we have now in CM3 and a full > array for every type. > > Do you think my hash table approach is safe? It's not nearly as > elegant as the Cardelli method, but it works really well for a quick > and dirty. It's ugly, but it's very fast. Or can the arrays used > by the TYPECASEs move during program execution? > > In any case, with the standard CM3 implementation, my program spends > more time in TYPECASE than the whole thing does under PM3. > > Do we have any code in CM3 that loads new types dynamically? I can > see loading code dynamically, but types...? I'm very curious, is > there an interface for it that "mortals" can use? If we have the > mechanism, might as well put it to work... AFAIK you need to invoke RTLinker.AddUnit after using the native dlopen/dlsym facilities to get the symbol corresponding to the unit being loaded. I've never tried using it but I did have some plans to do so back in my persistence days (when retrieving an instance of an unknown subtype we'd need to also dynamically load its defining module). > Another thing that bothers me a bit is that PushEFrame (sp?) seems to > take a lot of cycles. Is the use of this routine due to the absence > of a "stack walker"? I thought FreeBSD had a working stack walker > in the Modula-3 runtime...? The stack walker is not usable for exception handling, only for printing a stack dump (IIRC). Same was true for PM3. We should do something about using the gcc-backend native stack walking support. Most of the overhead for PushEFrame (as compared to user-threaded PM3) is obtaining the thread-local stack. For user-threaded PM3 it was a compiled in global variable (which obviously breaks for native threads). > The thing about PushEFrame is that it makes the programmer want to > avoid procedure calls, which is a real pity. Sussman and Steele's > railings against the inefficient procedure calls in PL/I circa 1975 > are legendary. (It's true, procedural abstraction is really > wonderful.) I agree. I've maintained the SOLgnu stack walking code for years so that I don't have to pay the overhead of the explicit exception stack. > > > Mika > > P.S. My hash table code re-attached in case someone wants to look at > it > again (instrumenting code commented out): > > TYPE > TypeCaseResult = RECORD > x : ADDRESS; > tc : Typecode; > arm : INTEGER; > END; > > CONST > TCCachePow = 6; > TCCacheSize = Word.Shift(1,TCCachePow); > TCMask = TCCacheSize-1; > > VAR TCCache := ARRAY [0..TCCacheSize-1] OF TypeCaseResult { > TypeCaseResult { LOOPHOLE(0,ADDRESS), 0, -1 } , > .. > }; > > (* > VAR tcScans := 0; tcHits := 0; > *) > > PROCEDURE ScanTypecase (ref: REFANY; > x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = > VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; > BEGIN > tc := TYPECODE (ref); > IF (ref = NIL) THEN RETURN 0; END; > > WITH hash = Word.And(Word.Times(tc, > > Word.RightShift(LOOPHOLE(x,Word.T),2)), > TCMask), > entry = TCCache[hash] DO > (*INC(tcScans);*) > IF entry.x = x AND entry.tc = tc THEN > (*INC(tcHits);*) > RETURN entry.arm > END; > > p := x; i := 0; > LOOP > IF (p.uid = 0) THEN entry.x := x; entry.tc := tc; > entry.arm := i; RETURN i; END; > IF (p.defn = NIL) THEN > p.defn := FindType (p.uid); > IF (p.defn = NIL) THEN > Fail (RTE.MissingType, RTModule.FromDataAddress(x), > LOOPHOLE (p.uid, ADDRESS), NIL); > END; > END; > xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; > IF (tc = xc) OR IsSubtype (tc, xc) THEN entry.x := x; > entry.tc := tc; entry.arm := i; RETURN i; END; > INC (p, ADRSIZE (p^)); INC (i); > END; > END; > END ScanTypecase; > From hosking at cs.purdue.edu Mon Apr 27 02:37:09 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Apr 2009 10:37:09 +1000 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: <200904270031.n3R0VgjC052408@camembert.async.caltech.edu> References: <200904270031.n3R0VgjC052408@camembert.async.caltech.edu> Message-ID: <678F2302-90D4-4F96-9EF6-7DA1167A97BA@cs.purdue.edu> On 27 Apr 2009, at 10:31, Mika Nystrom wrote: > > Tony, it might not be as bad as all that. Well, on one level it > is. Things are certainly not perfect. > > But I am able to operate with m3core built with -O (as well as with > -O3). Lots of scary-looking compiler warnings, but things do work. > There are just a few programs that won't build. I didn't try "all" > in the CM3 dist---only my own programs and m3core (since m3core has > the biggest performance impact). This is weird, since I assume you are targetting x86 which is the same (except I386_DARWIN in my case) as I have used -O3 for without problems previously. I shall have to rebuild everything in cm3 with - O3 to see if I can track down the problems. I can't remember the last time I checked that it all worked, but the CVS logs will probably reveal more (cf my log messages for parse.c in the gcc-based backend). > With lots of tweaks and adjustments, I now see my code running about > 100% slower under CM3 than the same code does under PM3 (on the > same machine). This is including my typecase hacks, as described > earlier today. I'm guessing most of it is the FreeBSD pthreads > implementation in libc_r + the calls to PushEFrame. Yikes! How much of this is module initialization (startup) time? > > > Mika > > Tony Hosking writes: >> I am very disturbed about this since it suggests a regression. I had >> spent a huge amount of time a year or so back making sure the backend >> would play properly with gcc -O3, but it seems we are now back in a >> bad place. I'm not sure what changes have occurred to the backend >> since then, but they would be the prime candidates. Unfortunately, I >> don't have a lot of time right now to try to debug these -O3 >> problems, >> but I do want to fix them since they will eventually impinge on my >> own >> work. It would be really good to get our regressions framework back >> up and running and to put -O3 in there as the default build option -- >> it seems there have been ongoing Tinderbox problems for a while now, >> since my SOLgnu regression runs appear to have stopped completely. >> I'll need to check the logs. >> >> On 27 Apr 2009, at 04:12, Mika Nystrom wrote: >> >>> Hi Tony, >>> >>> I looked at this more closely, and I was wrong. The compiler >>> doesn't >>> actually segfault on -O. I was using -gstabs+ but switched to - >>> gstabs >>> after your email (doesn't seem to matter). >>> >>> I get a ton of warnings at either optimization level, and there are >>> definitely bugs in the optimizer. The resulting code is generally >>> not correct. (By comparison, I had to turn off PM3's optimizer for >>> only one of the hundred or so packages I build.) Things often fail >>> to compile, even at -O. >>> >>> At -O3, I get one segfault: >>> >>> new source -> compiling TextCommandQueueTbl.i3 >>> cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack >>> exception handling >>> new source -> compiling CommandLoop.m3 >>> cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack >>> exception handling >>> ../src/CommandLoop.m3: In function 'CommandLoop__Run': >>> ../src/CommandLoop.m3:279: internal compiler error: Segmentation >>> fault >>> Please submit a full bug report, >>> with preprocessed source if appropriate. >>> See for instructions. >>> m3_backend => 4 >>> m3cc (aka cm3cg) failed compiling: CommandLoop.mc >>> new source -> compiling CommandLoopDefaultCommand.m3 >>> cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack >>> exception handling >>> new source -> compiling TextCommandTbl.m3 >>> >>> where: >>> >>> 272 >>> (***************************************************************************** >>> 273 >>> * * >>> 274 * Command Loop >>> Main * >>> 275 >>> * * >>> 276 >>> *****************************************************************************) >>> 277 >>> 278 >>> 279 PROCEDURE Run(self: T; source: Pathname.T := NIL; term: >>> Term.T := NIL) = >>> 280 CONST >>> 281 Comment = SET OF CHAR{'%','#'}; >>> 282 VAR >>> 283 completer := NEW(StdCompleter, loop:=self); >>> 284 line: TEXT; >>> 285 BEGIN >>> 286 IF term = NIL THEN >>> 287 self.term := Term.Default(); >>> 288 ELSE >>> 289 self.term := term; >>> 290 END; >>> 291 LOOP >>> 292 TRY >>> 293 IF source # NIL THEN >>> 294 DoLoad(self.load, TextList.List2("",source), >>> self.term); >>> 295 source := NIL; >>> >>> ... >>> >>> Even at -O, things don't work right. Here's a typical output: >>> >>> new source -> compiling PassiveArb1.m3 >>> "../src/PassiveArb1.m3", line 68: warning: not used (e) >>> "../src/PassiveArb1.m3", line 45: warning: not used (newCon) >>> 2 warnings encountered >>> ../src/PassiveArb1.m3: In function 'PassiveArb1__FApply': >>> ../src/PassiveArb1.m3:81: warning: variable 'M3_Cwb5VA_buyO' might >>> be clobbered by 'longjmp' or 'vfork' >>> ../src/PassiveArb1.m3:81: warning: variable 'M3_Cwb5VA_selO' might >>> be clobbered by 'longjmp' or 'vfork' >>> new source -> compiling PassiveArb2.i3 >>> new source -> compiling ExecRecorder2.i3 >>> new source -> compiling ArbPingPong.i3 >>> new source -> compiling PassiveArb2.m3 >>> ../src/PassiveArb2.m3: In function 'PassiveArb2__Apply': >>> ../src/PassiveArb2.m3:388: warning: variable 'M3_EWPD1K_delta' might >>> be clobbered by 'longjmp' or 'vfork' >>> ../src/PassiveArb2.m3:388: warning: variable 'M3_Cwb5VA_toExec' >>> might be clobbered by 'longjmp' or 'vfork' >>> new source -> compiling Globals.i3 >>> new source -> compiling ActiveArb1.i3 >>> new source -> compiling ActiveArb1.m3 >>> new source -> compiling ExecRecorder.i3 >>> new source -> compiling ExecRecorder.m3 >>> new source -> compiling ExecRec.i3 >>> new source -> compiling ExecRecorder2.m3 >>> new source -> compiling ExecRec.m3 >>> new source -> compiling ArbPingPong.m3 >>> new source -> compiling Main.m3 >>> "../src/Main.m3", line 72: warning: potentially unhandled exception: >>> OSError.E >>> "../src/Main.m3", line 30: warning: potentially unhandled >>> exceptions: Rd.EndOfFile, Rd.Failure, Thread.Alerted >>> "../src/Main.m3", line 31: warning: potentially unhandled >>> exceptions: Thread.Alerted, Wr.Failure >>> "../src/Main.m3", line 32: warning: potentially unhandled >>> exceptions: Thread.Alerted, Wr.Failure >>> "../src/Main.m3", line 33: warning: potentially unhandled >>> exceptions: Thread.Alerted, Wr.Failure >>> "../src/Main.m3", line 118: warning: potentially unhandled >>> exception: OSError.E >>> "../src/Main.m3", line 204: warning: potentially unhandled >>> exception: OSError.E >>> 7 warnings encountered >>> -> linking testtrade >>> /usr/lib/libc.so: WARNING! setkey(3) not present in the system! >>> /usr/lib/libc.so: warning: this program uses gets(), which is >>> unsafe. >>> /usr/lib/libc.so: warning: mktemp() possibly used unsafely; consider >>> using mkstemp() >>> /usr/lib/libc.so: WARNING! des_setkey(3) not present in the system! >>> /usr/lib/libc.so: WARNING! encrypt(3) not present in the system! >>> /usr/lib/libc.so: warning: tmpnam() possibly used unsafely; consider >>> using mkstemp() >>> /usr/lib/libc.so: warning: this program uses f_prealloc(), which is >>> not recommended. >>> /usr/lib/libc.so: WARNING! des_cipher(3) not present in the system! >>> /usr/lib/libc.so: warning: tempnam() possibly used unsafely; >>> consider using mkstemp() >>> Main.mo: In function `Main_M3': >>> ../src/Main.m3:164: undefined reference to `Main__5__1__1__CanStart. >>> 198' >>> /home/mika/t-cm3/calarm/twslib/FreeBSD4/libtwslib.so: undefined >>> reference to `TWSReader__RCApply__RD.332' >>> m3_link => 1 >>> linker failed linking: testtrade >>> Fatal Error: package build failed >>> >>> >>> Mika >>> >>> >>> >>> Tony Hosking writes: >>>> >>>> On 26 Apr 2009, at 15:22, Mika Nystrom wrote: >>>> >>>>> >>>>> Hello again, >>>>> >>>>> Now I've managed to get all the code up and running under CM3. I >>>>> found and committed fixes to a bug in Wx and some code in one of >>>>> the m3tk libraries that looked like it never was finished in the >>>>> first place. >>>>> >>>>> As I mentioned earlier, I wasn't able to get user threads working >>>>> in CM3 on FreeBSD 4.11. But with some help from Jay, I was able >>>>> to >>>>> get things working with libc_r. Performance, unfortunately, >>>>> leaves something to be desired. >>>>> >>>>> For the first time I've been able to compare timings on identical >>>>> hardware between the PM3 I was using and the CM3 that's out now. >>>>> >>>>> Note that optimization doesn't seem to work..? (Not even -O, much >>>>> less -O3... the compiler segfaults.) >>>> >>>> Are you passing -gstabs? It should not segfault on -O3 - this is a >>>> regression if it does. >>>> >>>>> Here's what I get, using no optimization either in PM3 or CM3. >>>>> The >>>>> test is my Scheme interpreter generating SQL and Modula-3 code >>>>> (a bit like the Hibernate system you can get for Java): >>>>> >>>>> >>>>> CPU seconds CM3 PM3 >>>>> First version 5.269 1.366 >>>>> Fewer NEWs 2.039 0.440 (code cleanup on my part) >>>>> TYPECASE hack 1.770 (see below) >>>>> >>>>> Some "poor man's profiling" (i.e., ctrl-C'ing in m3gdb) suggests >>>>> that >>>>> most of the time is spent either in threading code (this could >>>>> just >>>>> be a lousy implementation in libc_r), the garbage collector, or in >>>>> "ScanTypecase". >>>>> >>>>> The only one of these routines I am qualified to do anything about >>>>> is >>>>> ScanTypecase. I don't know why the Critical Mass people... >>>> colorful >>>>> language can one use on m3devel?>.. all over this code. I >>>>> assume it >>>>> has >>>>> something to do with Java. >>>>> >>>>> The PM3 code (from SRC?) has this wonderful, concise, efficient >>>>> bit: >>>>> >>>>> PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = >>>>> VAR t := Get (b); >>>>> BEGIN >>>>> IF (a >= RT0u.nTypes) THEN BadType (a) END; >>>>> IF (a = 0) THEN RETURN TRUE END; >>>>> RETURN (t.typecode <= a AND a <= t.lastSubTypeTC); >>>>> END IsSubtype; >>>>> >>>>> replaced with the following absolute abomination in CM3: >>>>> >>>>> PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = >>>>> VAR t: RT0.TypeDefn; >>>>> BEGIN >>>>> IF (a = RT0.NilTypecode) THEN RETURN TRUE END; >>>>> t := Get (a); >>>>> IF (t = NIL) THEN RETURN FALSE; END; >>>>> IF (t.typecode = b) THEN RETURN TRUE END; >>>>> WHILE (t.kind = ORD (TK.Obj)) DO >>>>> IF (t.link_state = 0) THEN FinishTypecell (t, NIL); END; >>>>> t := LOOPHOLE (t, RT0.ObjectTypeDefn).parent; >>>>> IF (t = NIL) THEN RETURN FALSE; END; >>>>> IF (t.typecode = b) THEN RETURN TRUE; END; >>>>> END; >>>>> IF (t.traced # 0) >>>>> THEN RETURN (b = RT0.RefanyTypecode); >>>>> ELSE RETURN (b = RT0.AddressTypecode); >>>>> END; >>>>> END IsSubtype; >>>> >>>> This is all to support dynamic loading of libraries. >>>> >>>>> Furthermore, CM3 has a hook for "ScanTypecase" that's missing >>>>> in PM3 (the older compiler actually generates code for this): >>>>> >>>>> PROCEDURE ScanTypecase (ref: REFANY; >>>>> x: ADDRESS(*ARRAY [0..] OF Cell*)): >>>>> INTEGER = >>>>> VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; >>>>> BEGIN >>>>> IF (ref = NIL) THEN RETURN 0; END; >>>>> tc := TYPECODE (ref); >>>>> p := x; i := 0; >>>>> LOOP >>>>> IF (p.uid = 0) THEN RETURN i; END; >>>>> IF (p.defn = NIL) THEN >>>>> p.defn := FindType (p.uid); >>>>> IF (p.defn = NIL) THEN >>>>> Fail (RTE.MissingType, RTModule.FromDataAddress(x), >>>>> LOOPHOLE (p.uid, ADDRESS), NIL); >>>>> END; >>>>> END; >>>>> xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; >>>>> IF (tc = xc) OR IsSubtype (tc, xc) THEN RETURN i; END; >>>>> INC (p, ADRSIZE (p^)); INC (i); >>>>> END; >>>>> END ScanTypecase; >>>>> >>>>> Where to begin? A loop with all kinds of runtime checks of >>>>> properties >>>>> that are supposedly known at compile time? IsSubtype (itself a >>>>> loop) >>>>> called from inside the loop? >>>> >>>> Not if dynamically loaded! >>>> >>>>> I was able to cut out almost all of the typecase activity from my >>>>> program by using the following code in RTType.m3, which depends on >>>>> the ADDRESS x never changing (well more specifically never being >>>>> the same for two TYPECASE statements): >>>>> >>>>> TYPE >>>>> TypeCaseResult = RECORD >>>>> x : ADDRESS; >>>>> tc : Typecode; >>>>> arm : INTEGER; >>>>> END; >>>>> >>>>> CONST >>>>> TCCachePow = 6; >>>>> TCCacheSize = Word.Shift(1,TCCachePow); >>>>> TCMask = TCCacheSize-1; >>>>> >>>>> VAR TCCache := ARRAY [0..TCCacheSize-1] OF TypeCaseResult { >>>>> TypeCaseResult { LOOPHOLE(0,ADDRESS), 0, -1 } , >>>>> .. >>>>> }; >>>>> >>>>> (* >>>>> VAR tcScans := 0; tcHits := 0; (* instrumenting counters *) >>>>> *) >>>>> >>>>> PROCEDURE ScanTypecase (ref: REFANY; >>>>> x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = >>>>> VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; >>>>> BEGIN >>>>> tc := TYPECODE (ref); >>>>> IF (ref = NIL) THEN RETURN 0; END; >>>>> >>>>> WITH hash = Word.And(Word.Times(tc, >>>>> >>>>> Word.RightShift(LOOPHOLE(x,Word.T),2)), >>>>> TCMask), >>>>> entry = TCCache[hash] DO >>>>> (*INC(tcScans);*) >>>>> IF entry.x = x AND entry.tc = tc THEN >>>>> (*INC(tcHits);*) >>>>> RETURN entry.arm >>>>> END; >>>>> >>>>> p := x; i := 0; >>>>> LOOP >>>>> IF (p.uid = 0) THEN entry.x := x; entry.tc := tc; >>>>> entry.arm := i; RETURN i; END; >>>>> IF (p.defn = NIL) THEN >>>>> p.defn := FindType (p.uid); >>>>> IF (p.defn = NIL) THEN >>>>> Fail (RTE.MissingType, RTModule.FromDataAddress(x), >>>>> LOOPHOLE (p.uid, ADDRESS), NIL); >>>>> END; >>>>> END; >>>>> xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; >>>>> IF (tc = xc) OR IsSubtype (tc, xc) THEN entry.x := x; >>>>> entry.tc := tc; entry.arm := i; RETURN i; END; >>>>> INC (p, ADRSIZE (p^)); INC (i); >>>>> END; >>>>> END; >>>>> END ScanTypecase; >>>>> >>>>> I'm guessing the speedup for TYPECASE itself is a factor of at >>>>> least >>>>> ten. But it's still a pretty nasty hack. And there is still a >>>>> lot >>>>> of IsSubtype activity from narrowing. >>>>> >>>>> I suppose that the way the typecodes are generated in CM3 is >>>>> sufficiently different (meant to be extended at runtime?) from how >>>>> it was done in PM3 that one can't really go back to the old code. >>>>> Cardelli's idea of keeping an array of parents up to ROOT plus a >>>>> "depth" for each type might have merit, though. >>>>> >>>>> To see if a is a subtype of b, something like: >>>>> >>>>> b = a.ancestors[a.depth-b.depth-1] (* with appropriate range >>>>> checks *) >>>>> >>>>> Would this be easy to put in? I'm not sure how one can be sure >>>>> that typecodes are done being generated? There's something called >>>>> RTTypeSRC.FinishObjectTypes .. >>>>> >>>>> And PM3 still generates code that's four times faster. >>>>> >>>>> Mika >>>>> >> From rodney.m.bates at cox.net Mon Apr 27 03:05:41 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Sun, 26 Apr 2009 20:05:41 -0500 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: <200904261812.n3QICZYX035390@camembert.async.caltech.edu> References: <200904261812.n3QICZYX035390@camembert.async.caltech.edu> Message-ID: <49F504E5.9000100@cox.net> FWIW, some m3gdb functions don't get the info they need with -gstabs, wereas -gstabx+ gives it to them. Mika Nystrom wrote: > Hi Tony, > > I looked at this more closely, and I was wrong. The compiler doesn't > actually segfault on -O. I was using -gstabs+ but switched to -gstabs > after your email (doesn't seem to matter). > > From mika at async.caltech.edu Mon Apr 27 03:17:24 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 26 Apr 2009 18:17:24 -0700 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: Your message of "Mon, 27 Apr 2009 10:37:09 +1000." <678F2302-90D4-4F96-9EF6-7DA1167A97BA@cs.purdue.edu> Message-ID: <200904270117.n3R1HOMt054469@camembert.async.caltech.edu> Tony Hosking writes: ... >> With lots of tweaks and adjustments, I now see my code running about >> 100% slower under CM3 than the same code does under PM3 (on the >> same machine). This is including my typecase hacks, as described >> earlier today. I'm guessing most of it is the FreeBSD pthreads >> implementation in libc_r + the calls to PushEFrame. > >Yikes! How much of this is module initialization (startup) time? > Ok, I re-checked just to make sure. As far as I know, exactly the same code, no initialization overhead (program's already running): CM3: > (time-call (lambda()(make-standard-stuff "Example"))) 1.309586018207483 > PM3: > (time-call (lambda()(make-standard-stuff "Example"))) 0.5641579627990723 > Bear in mind this is pretty close to a worst-case test for the "delta" between PM3 and CM3. Lots of small procedures, lots of typecases. Well, actually, I can make it worse. Turn on locking in the Scheme environments (so that they could be used by multi-threaded interpreters): CM3: > (time-call (lambda()(make-standard-stuff "Example"))) 2.1610950572649017 > PM3: > (time-call (lambda()(make-standard-stuff "Example"))) 0.6010241508483887 > CM3 without my change to RTType: > (time-call (lambda()(make-standard-stuff "Example"))) 2.2972461158642545 > 250% slower. But it is very demanding on pthreads. Lots of little procedures, lots of typecases, lots of locking. (No contention, though.) Mika P.S. the code in question is a scheme-m3 stub generator; it's making stub interfaces in the tests above. From hosking at cs.purdue.edu Mon Apr 27 03:29:04 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Apr 2009 11:29:04 +1000 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: <200904270117.n3R1HOMt054469@camembert.async.caltech.edu> References: <200904270117.n3R1HOMt054469@camembert.async.caltech.edu> Message-ID: Hmm. Interesting. What about exception scopes? On 27 Apr 2009, at 11:17, Mika Nystrom wrote: > Tony Hosking writes: > ... >>> With lots of tweaks and adjustments, I now see my code running about >>> 100% slower under CM3 than the same code does under PM3 (on the >>> same machine). This is including my typecase hacks, as described >>> earlier today. I'm guessing most of it is the FreeBSD pthreads >>> implementation in libc_r + the calls to PushEFrame. >> >> Yikes! How much of this is module initialization (startup) time? >> > > Ok, I re-checked just to make sure. As far as I know, exactly the > same code, > no initialization overhead (program's already running): > > CM3: > >> (time-call (lambda()(make-standard-stuff "Example"))) > 1.309586018207483 >> > > PM3: > >> (time-call (lambda()(make-standard-stuff "Example"))) > 0.5641579627990723 >> > > Bear in mind this is pretty close to a worst-case test for the > "delta" between > PM3 and CM3. Lots of small procedures, lots of typecases. > > Well, actually, I can make it worse. Turn on locking in the Scheme > environments > (so that they could be used by multi-threaded interpreters): > > CM3: > >> (time-call (lambda()(make-standard-stuff "Example"))) > 2.1610950572649017 >> > > PM3: > >> (time-call (lambda()(make-standard-stuff "Example"))) > 0.6010241508483887 >> > > CM3 without my change to RTType: > >> (time-call (lambda()(make-standard-stuff "Example"))) > 2.2972461158642545 >> > > 250% slower. > > But it is very demanding on pthreads. Lots of little procedures, > lots of typecases, lots of locking. (No contention, though.) > > Mika > > P.S. the code in question is a scheme-m3 stub generator; it's making > stub interfaces in the tests above. From hendrik at topoi.pooq.com Mon Apr 27 04:14:58 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 26 Apr 2009 22:14:58 -0400 Subject: [M3devel] Scheme in m3? In-Reply-To: <200904270117.n3R1HOMt054469@camembert.async.caltech.edu> References: <678F2302-90D4-4F96-9EF6-7DA1167A97BA@cs.purdue.edu> <200904270117.n3R1HOMt054469@camembert.async.caltech.edu> Message-ID: <20090427021457.GB6064@topoi.pooq.com> On Sun, Apr 26, 2009 at 06:17:24PM -0700, Mika Nystrom wrote: > > Well, actually, I can make it worse. Turn on locking in the Scheme environments ... > CM3: > > > (time-call (lambda()(make-standard-stuff "Example"))) > 2.1610950572649017 > > > > PM3: > > > (time-call (lambda()(make-standard-stuff "Example"))) > 0.6010241508483887 > > > A Scheme in M3? What do you do for tail-calls? -- hendrik From mika at async.caltech.edu Mon Apr 27 04:28:42 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 26 Apr 2009 19:28:42 -0700 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: Your message of "Mon, 27 Apr 2009 11:29:04 +1000." Message-ID: <200904270228.n3R2SgLC057723@camembert.async.caltech.edu> How would I know? I'm trying to turn on profiling but it seems to be a bit involved. Involves re-building all the libraries? (cm3 -profile seems to look for FreeBSD4p instead of plain FreeBSD4...) Mika Tony Hosking writes: >Hmm. Interesting. What about exception scopes? > >On 27 Apr 2009, at 11:17, Mika Nystrom wrote: > >> Tony Hosking writes: >> ... >>>> With lots of tweaks and adjustments, I now see my code running about >>>> 100% slower under CM3 than the same code does under PM3 (on the >>>> same machine). This is including my typecase hacks, as described >>>> earlier today. I'm guessing most of it is the FreeBSD pthreads >>>> implementation in libc_r + the calls to PushEFrame. >>> >> Yikes! How much of this is module initialization (startup) time? >>> >> >> Ok, I re-checked just to make sure. As far as I know, exactly the >> same code, >> no initialization overhead (program's already running): >> >> CM3: >> >>> (time-call (lambda()(make-standard-stuff "Example"))) >> 1.309586018207483 >>> >> >> PM3: >> >>> (time-call (lambda()(make-standard-stuff "Example"))) >> 0.5641579627990723 >>> >> >> Bear in mind this is pretty close to a worst-case test for the >> "delta" between >> PM3 and CM3. Lots of small procedures, lots of typecases. >> >> Well, actually, I can make it worse. Turn on locking in the Scheme >> environments >> (so that they could be used by multi-threaded interpreters): >> >> CM3: >> >>> (time-call (lambda()(make-standard-stuff "Example"))) >> 2.1610950572649017 >>> >> >> PM3: >> >>> (time-call (lambda()(make-standard-stuff "Example"))) >> 0.6010241508483887 >>> >> >> CM3 without my change to RTType: >> >>> (time-call (lambda()(make-standard-stuff "Example"))) >> 2.2972461158642545 >>> >> >> 250% slower. >> >> But it is very demanding on pthreads. Lots of little procedures, >> lots of typecases, lots of locking. (No contention, though.) >> >> Mika >> >> P.S. the code in question is a scheme-m3 stub generator; it's making >> stub interfaces in the tests above. > From hosking at cs.purdue.edu Mon Apr 27 04:37:17 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Apr 2009 12:37:17 +1000 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: <200904270228.n3R2SgLC057723@camembert.async.caltech.edu> References: <200904270228.n3R2SgLC057723@camembert.async.caltech.edu> Message-ID: <9AE70027-6818-4404-A4A6-BBEAD31B7935@cs.purdue.edu> I was just wondering if your code has a lot of TRY blocks, which come with the PushEFrame overhead. On 27 Apr 2009, at 12:28, Mika Nystrom wrote: > How would I know? I'm trying to turn on profiling but it seems to > be a > bit involved. Involves re-building all the libraries? > > (cm3 -profile seems to look for FreeBSD4p instead of plain > FreeBSD4...) > > Mika > > Tony Hosking writes: >> Hmm. Interesting. What about exception scopes? >> >> On 27 Apr 2009, at 11:17, Mika Nystrom wrote: >> >>> Tony Hosking writes: >>> ... >>>>> With lots of tweaks and adjustments, I now see my code running >>>>> about >>>>> 100% slower under CM3 than the same code does under PM3 (on the >>>>> same machine). This is including my typecase hacks, as described >>>>> earlier today. I'm guessing most of it is the FreeBSD pthreads >>>>> implementation in libc_r + the calls to PushEFrame. >>>> >>> Yikes! How much of this is module initialization (startup) time? >>>> >>> >>> Ok, I re-checked just to make sure. As far as I know, exactly the >>> same code, >>> no initialization overhead (program's already running): >>> >>> CM3: >>> >>>> (time-call (lambda()(make-standard-stuff "Example"))) >>> 1.309586018207483 >>>> >>> >>> PM3: >>> >>>> (time-call (lambda()(make-standard-stuff "Example"))) >>> 0.5641579627990723 >>>> >>> >>> Bear in mind this is pretty close to a worst-case test for the >>> "delta" between >>> PM3 and CM3. Lots of small procedures, lots of typecases. >>> >>> Well, actually, I can make it worse. Turn on locking in the Scheme >>> environments >>> (so that they could be used by multi-threaded interpreters): >>> >>> CM3: >>> >>>> (time-call (lambda()(make-standard-stuff "Example"))) >>> 2.1610950572649017 >>>> >>> >>> PM3: >>> >>>> (time-call (lambda()(make-standard-stuff "Example"))) >>> 0.6010241508483887 >>>> >>> >>> CM3 without my change to RTType: >>> >>>> (time-call (lambda()(make-standard-stuff "Example"))) >>> 2.2972461158642545 >>>> >>> >>> 250% slower. >>> >>> But it is very demanding on pthreads. Lots of little procedures, >>> lots of typecases, lots of locking. (No contention, though.) >>> >>> Mika >>> >>> P.S. the code in question is a scheme-m3 stub generator; it's making >>> stub interfaces in the tests above. >> From mika at async.caltech.edu Mon Apr 27 04:44:28 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 26 Apr 2009 19:44:28 -0700 Subject: [M3devel] Scheme in m3? In-Reply-To: Your message of "Sun, 26 Apr 2009 22:14:58 EDT." <20090427021457.GB6064@topoi.pooq.com> Message-ID: <200904270244.n3R2iSw8058447@camembert.async.caltech.edu> LOOP! I just copied Peter Norvig's Java code, as a starting point. (JScheme something or other.) Just like his interpreter, mine doesn't implement call-with-current-continuation completely. But normal tail calls are fine. An abbreviated version of eval: PROCEDURE Eval(env : Environment; x : Object) : Object = BEGIN LOOP IF x # NIL AND ISTYPE(x,Symbol) THEN RETURN env.lookup(x) ELSE VAR fn := x.car; BEGIN IF (* special forms *) THEN ... ELSE (* procedure call *) fn := Eval(fn, env); TYPECASE fn OF Closure(c) => x := c.body; (* tail call *) env := NEW(Environment).init(c.params,c.env) ... END END END END END END Eval; Mika hendrik at topoi.pooq.com writes: >On Sun, Apr 26, 2009 at 06:17:24PM -0700, Mika Nystrom wrote: > >> >> Well, actually, I can make it worse. Turn on locking in the Scheme environments >... >> CM3: >> >> > (time-call (lambda()(make-standard-stuff "Example"))) >> 2.1610950572649017 >> > >> >> PM3: >> >> > (time-call (lambda()(make-standard-stuff "Example"))) >> 0.6010241508483887 >> > >> > >A Scheme in M3? What do you do for tail-calls? > >-- hendrik From jay.krell at cornell.edu Mon Apr 27 04:32:12 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 26 Apr 2009 19:32:12 -0700 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: References: <200904270117.n3R1HOMt054469@camembert.async.caltech.edu> Message-ID: I think Tony means do you have many 'try' and hav you tried reducing them? That is where pusheframe comes from (and lock). We can give you back user threads, and probably speed up pthreads on some platforms with __thread instead of pthread_setspecific.on some platforms it exists and is more than just syntactic sugar, I think. I assume typecase can be much faster even with dynamic loading but need to dig, much later. - Jay (phone) On Apr 26, 2009, at 6:29 PM, Tony Hosking wrote: > Hmm. Interesting. What about exception scopes? > > On 27 Apr 2009, at 11:17, Mika Nystrom >>> >>> >> >> >>> >> >>> >> >> >> >>> >> >>> >> >>> >> >> >> >> From mika at async.caltech.edu Mon Apr 27 04:59:32 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 26 Apr 2009 19:59:32 -0700 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: Your message of "Mon, 27 Apr 2009 12:37:17 +1000." <9AE70027-6818-4404-A4A6-BBEAD31B7935@cs.purdue.edu> Message-ID: <200904270259.n3R2xWDX059155@camembert.async.caltech.edu> Ah, yeah... I have to admit it does. Whenever it pushes the stack in Scheme it makes a TRY block so it can print a pretty traceback if anything goes wrong... if something goes wrong deep into a call it prints an error message for every frame in Scheme (not tail calls obviously, see Hendrik's question), concatenating them as it pops out of the frames, until you're back at the REPL. Example: > (define (add1 x) ( + x 1)) add1 > (define (x) (map add1 '(1 2 3 junk))) x > (x) EXCEPTION! expected a double, got: junk (called from) eval (+ x 1) (called from) eval (x) > Hmm.. so if I disable tracebacks my code should get a lot faster. > (time-call (lambda()(make-standard-stuff "Example"))) 1.3191220290027559 > (toggle-tracebacks) #f > (time-call (lambda()(make-standard-stuff "Example"))) 1.1270759491017088 > Neat... sort of. 17% speedup is nothing to sneeze at, but I do like those tracebacks, too. Mika Tony Hosking writes: >I was just wondering if your code has a lot of TRY blocks, which come >with the PushEFrame overhead. > >On 27 Apr 2009, at 12:28, Mika Nystrom wrote: > >> How would I know? I'm trying to turn on profiling but it seems to >> be a >> bit involved. Involves re-building all the libraries? >> >> (cm3 -profile seems to look for FreeBSD4p instead of plain >> FreeBSD4...) >> >> Mika >> >> Tony Hosking writes: >>> Hmm. Interesting. What about exception scopes? >>> >>> On 27 Apr 2009, at 11:17, Mika Nystrom wrote: >>> >>>> Tony Hosking writes: >>>> ... >>>>>> With lots of tweaks and adjustments, I now see my code running >>>>>> about >>>>>> 100% slower under CM3 than the same code does under PM3 (on the >>>>>> same machine). This is including my typecase hacks, as described >>>>>> earlier today. I'm guessing most of it is the FreeBSD pthreads >>>>>> implementation in libc_r + the calls to PushEFrame. >>>>> >>>> Yikes! How much of this is module initialization (startup) time? >>>>> >>>> >>>> Ok, I re-checked just to make sure. As far as I know, exactly the >>>> same code, >>>> no initialization overhead (program's already running): >>>> >>>> CM3: >>>> >>>>> (time-call (lambda()(make-standard-stuff "Example"))) >>>> 1.309586018207483 >>>>> >>>> >>>> PM3: >>>> >>>>> (time-call (lambda()(make-standard-stuff "Example"))) >>>> 0.5641579627990723 >>>>> >>>> >>>> Bear in mind this is pretty close to a worst-case test for the >>>> "delta" between >>>> PM3 and CM3. Lots of small procedures, lots of typecases. >>>> >>>> Well, actually, I can make it worse. Turn on locking in the Scheme >>>> environments >>>> (so that they could be used by multi-threaded interpreters): >>>> >>>> CM3: >>>> >>>>> (time-call (lambda()(make-standard-stuff "Example"))) >>>> 2.1610950572649017 >>>>> >>>> >>>> PM3: >>>> >>>>> (time-call (lambda()(make-standard-stuff "Example"))) >>>> 0.6010241508483887 >>>>> >>>> >>>> CM3 without my change to RTType: >>>> >>>>> (time-call (lambda()(make-standard-stuff "Example"))) >>>> 2.2972461158642545 >>>>> >>>> >>>> 250% slower. >>>> >>>> But it is very demanding on pthreads. Lots of little procedures, >>>> lots of typecases, lots of locking. (No contention, though.) >>>> >>>> Mika >>>> >>>> P.S. the code in question is a scheme-m3 stub generator; it's making >>>> stub interfaces in the tests above. >>> > From jay.krell at cornell.edu Mon Apr 27 04:36:09 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 26 Apr 2009 19:36:09 -0700 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: <200904270228.n3R2SgLC057723@camembert.async.caltech.edu> References: <200904270228.n3R2SgLC057723@camembert.async.caltech.edu> Message-ID: <4F21234C-997C-485D-A02F-FBD85A0E0A57@hotmail.com> It does that, yes, but try hacking it out of the config file. - Jay (phone) On Apr 26, 2009, at 7:28 PM, Mika Nystrom wrote: > How would I know? I'm trying to turn on profiling but it seems to > be a > bit involved. Involves re-building all the libraries? > > (cm3 -profile seems to look for FreeBSD4p instead of plain > FreeBSD4...) > > Mika > > Tony Hosking writes: >> >>>> >>>> >>> >>> >>>> >>> >>>> >>> >>> >>> >>>> >>> >>>> >>> >>>> >>> >>> >>> >>> >> From wagner at elegosoft.com Mon Apr 27 08:46:18 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 27 Apr 2009 08:46:18 +0200 Subject: [M3devel] Fwd: Modula-2 to Modula-3 translator by Aachen University Message-ID: <20090427084618.hnk460mh440c880c@mail.elegosoft.com> Perhaps somebody on the public list knows something... ----- Forwarded message from trijezdci at gmail.com ----- Date: Sun, 26 Apr 2009 15:57:36 +0900 From: Benjamin Kowarsch Reply-To: Benjamin Kowarsch Subject: Modula-2 to Modula-3 translator by Aachen University To: m3-support at elego.de Dear Sirs, I am trying to get the Modula-2 section in the Catalog of Compilers updated and there is one entry of a Modula-2 to Modula-3 translator by Peter Klein at University of Aachen for which all links and email addresses seem to be dead. University of Aachen was unable to give me any information either. I wonder if you know whether this translator is still availabe and if so at which URL, or where his author Peter Klein can be contacted. thank you regards benjamin ----- 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 mika at async.caltech.edu Mon Apr 27 09:50:44 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 27 Apr 2009 00:50:44 -0700 Subject: [M3devel] RuntimeError doesn't work quite as advertised Message-ID: <200904270750.n3R7oiqH071966@camembert.async.caltech.edu> Maybe someone else knows more about this than me... The following program: MODULE Main; IMPORT RuntimeError, IO; PROCEDURE Range() = BEGIN EVAL VAL(-1,CARDINAL) END Range; PROCEDURE Assert() = BEGIN <*ASSERT FALSE*> END Assert; PROCEDURE NilJump() = VAR x : PROCEDURE() := NIL; BEGIN x() END NilJump; PROCEDURE NilDeref() = VAR x : REF INTEGER := NIL; b : INTEGER; BEGIN b := x^ END NilDeref; PROCEDURE NilMethod() = TYPE T = OBJECT METHODS m() END; VAR t : T; BEGIN t.m() END NilMethod; BEGIN WITH ps = ARRAY OF PROCEDURE() { Range, Assert, NilMethod, NilJump, NilDeref } DO FOR i := FIRST(ps) TO LAST(ps) DO TRY ps[i]() EXCEPT RuntimeError.E(e) => IO.Put("RuntimeError: " & RuntimeError.Tag(e) & " \n") END END END END Main. yields the following result: (1053)trs80:~/test/src>../FreeBSD4/prog RuntimeError: An enumeration or subrange value was out of range. RuntimeError: <*ASSERT*> failed. *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x8048a71 = NilMethod + 0x10 in ../src/Main.m3 *** Abort Seems to me I ought to see a few more exceptions and not a crash. I'm happy to investigate a bit more, but does anyone have a clue where to begin? Mika From mika at async.caltech.edu Mon Apr 27 10:31:21 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 27 Apr 2009 01:31:21 -0700 Subject: [M3devel] RuntimeError doesn't work quite as advertised In-Reply-To: Your message of "Mon, 27 Apr 2009 00:50:44 PDT." <200904270750.n3R7oiqH071966@camembert.async.caltech.edu> Message-ID: <200904270831.n3R8VLFe073838@camembert.async.caltech.edu> Ok so I tried the "obvious thing", namely, I changed RTSignal.SegV to do RAISE RuntimeError.E(RuntimeError.T.BadMemoryReference); Somewhat to my surprise, this does the right thing for a null method. But somewhat less surprisingly, it loops for NilJump and NilDeref. Is the machine jumping back and re-executing the same instructions after the signal handler returns? Would all hell break loose if one were to special-case EXCEPT RuntimeError.E to store a thread-local jmp_buf that one does a C-style longjmp to? (With a chain back to any higher RuntimeError.E handlers, I suppose...) Or is there a way to get the exception to work out of the signal handler with the normal exception mechanism? Mika Mika Nystrom writes: > >Maybe someone else knows more about this than me... > >The following program: > >MODULE Main; >IMPORT RuntimeError, IO; > >PROCEDURE Range() = BEGIN EVAL VAL(-1,CARDINAL) END Range; > >PROCEDURE Assert() = BEGIN <*ASSERT FALSE*> END Assert; > >PROCEDURE NilJump() = VAR x : PROCEDURE() := NIL; BEGIN x() END NilJump; > >PROCEDURE NilDeref() = > VAR x : REF INTEGER := NIL; b : INTEGER; > BEGIN b := x^ END NilDeref; > >PROCEDURE NilMethod() = > TYPE T = OBJECT METHODS m() END; > VAR t : T; BEGIN t.m() END NilMethod; > >BEGIN > WITH ps = ARRAY OF PROCEDURE() { Range, Assert, NilMethod, NilJump, NilDeref } DO > FOR i := FIRST(ps) TO LAST(ps) DO > TRY > ps[i]() > EXCEPT > RuntimeError.E(e) => IO.Put("RuntimeError: " & RuntimeError.Tag(e) & " \n") > END > END > END >END Main. > >yields the following result: > >(1053)trs80:~/test/src>../FreeBSD4/prog >RuntimeError: An enumeration or subrange value was out of range. >RuntimeError: <*ASSERT*> failed. > > >*** >*** runtime error: >*** Segmentation violation - possible attempt to dereference NIL >*** pc = 0x8048a71 = NilMethod + 0x10 in ../src/Main.m3 >*** > >Abort > >Seems to me I ought to see a few more exceptions and not a crash. > >I'm happy to investigate a bit more, but does anyone have a clue where >to begin? > > Mika From wagner at elegosoft.com Mon Apr 27 14:24:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 27 Apr 2009 14:24:26 +0200 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <09E195AF-2D6E-4A76-9328-DC4F29049719@gmail.com> References: <200904260530.n3Q5U1NE000824@camembert.async.caltech.edu> <09E195AF-2D6E-4A76-9328-DC4F29049719@gmail.com> Message-ID: <20090427142426.tlx54313ms88sgk0@mail.elegosoft.com> Quoting Jay : > It is easy to fix for many non Linux systems.and possible for Linux. > Fairly well worn topic. Could you please just fix it if it's easy? User threads always worked reliably and very fast on FreeBSD systems. As I stated earlier, I'd deem it a regrettable loss. Thanks in advance, Olaf > - Jay (phone) > > On Apr 25, 2009, at 10:30 PM, Mika Nystrom wrote: > >> User threads certainly work fine on this machine (see my previous >> email) with PM3... some would say they work "better"... :-) >> >> Jay writes: >>> >>> --Apple-Mail-1-423481883 >>> Content-Type: text/plain; >>> charset=us-ascii; >>> format=flowed; >>> delsp=yes >>> Content-Transfer-Encoding: 7bit >>> >>> I think also due to simple use before init. >>> >>> - Jay (phone) >>> >>> On Apr 25, 2009, at 9:51 PM, Tony Hosking wrote: >>> >>>> Broken mostly because updated libraries detect forging of thread >>>> contexts (state) for security reasons and blow up. >>>> >>>> On 25 Apr 2009, at 14:12, Jay wrote: >>>> >>>>> Cool. >>>>> >>>>>> If I use user threads, it's a different story (which is probably >>>>> too bad, >>>>> >>>>> Oops, right, I forgot, I should have mentioned that, user threads >>>>> have likely been broken on all platforms for a while. I noticed >>>>> that on PPC_LINUX. I >>> >>> >>> --Apple-Mail-1-423481883 >>> Content-Type: text/html; >>> charset=utf-8 >>> Content-Transfer-Encoding: quoted-printable >>> >>>
I think also due to simple use = >>> before init.

 - Jay (phone>> style=3D"-webkit-composition-fill-color: rgba(175, 192, 227, 0.231373); = >>> -webkit-composition-frame-color: rgba(77, 128, 180, 0.231373); = >>> ">)
>> apple-content-edited=3D"true">>> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >>> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >>> normal; font-variant: normal; font-weight: normal; letter-spacing: = >>> normal; line-height: normal; text-align: auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; ">
>> style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; = >>> -khtml-line-break: after-white-space; ">>> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >>> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >>> normal; font-variant: normal; font-weight: normal; letter-spacing: = >>> normal; line-height: normal; text-align: auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; ">Broken mostly = >>> because updated libraries detect forging of thread contexts (state) for = >>> security reasons and blow up.

On = >>> 25 Apr 2009, at 14:12, Jay wrote:

>> class=3D"Apple-interchange-newline">
>> class=3D"Apple-style-span" style=3D"border-collapse: separate; color: = >>> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >>> normal; font-variant: normal; font-weight: normal; letter-spacing: = >>> normal; line-height: normal; orphans: 2; text-align: auto; text-indent: = >>> 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: = >>> 0px; -webkit-border-horizontal-spacing: 0px; = >>> -webkit-border-vertical-spacing: 0px; = >>> -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = >>> auto; -webkit-text-stroke-width: 0; ">
>> style=3D"font-size: 10pt; font-family: Verdana; = >>> ">Cool.
 
 > If I use user threads, it's a different = >>> story (which is probably too bad,

Oops, right, I forgot, I should = >>> have mentioned that, user threads have likely been broken on all = >>> platforms for a while. I noticed that on PPC_LINUX. = >>> I

= >>> >>> --Apple-Mail-1-423481883-- -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Mon Apr 27 14:23:41 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Apr 2009 22:23:41 +1000 Subject: [M3devel] RuntimeError doesn't work quite as advertised In-Reply-To: <200904270831.n3R8VLFe073838@camembert.async.caltech.edu> References: <200904270831.n3R8VLFe073838@camembert.async.caltech.edu> Message-ID: <7F78EA61-BF67-4C18-85D4-F0CC5B45276A@cs.purdue.edu> It's probably not generally safe to use RAISE inside a signal handler. There are esoteric rules as to what signal handlers can handle... I think we need to think harder on how best to reflect NIL dereference as a signal. Perhaps we need explicit NIL checks after all... On 27 Apr 2009, at 18:31, Mika Nystrom wrote: > Ok so I tried the "obvious thing", namely, I changed RTSignal.SegV to > do > > RAISE RuntimeError.E(RuntimeError.T.BadMemoryReference); > > Somewhat to my surprise, this does the right thing for a null method. > But somewhat less surprisingly, it loops for NilJump and NilDeref. > Is the machine jumping back and re-executing the same instructions > after the signal handler returns? > > Would all hell break loose if one were to special-case EXCEPT > RuntimeError.E to store a thread-local jmp_buf that one does a > C-style longjmp to? (With a chain back to any higher RuntimeError.E > handlers, I suppose...) Or is there a way to get the exception to > work out of the signal handler with the normal exception mechanism? > > Mika > > Mika Nystrom writes: >> >> Maybe someone else knows more about this than me... >> >> The following program: >> >> MODULE Main; >> IMPORT RuntimeError, IO; >> >> PROCEDURE Range() = BEGIN EVAL VAL(-1,CARDINAL) END Range; >> >> PROCEDURE Assert() = BEGIN <*ASSERT FALSE*> END Assert; >> >> PROCEDURE NilJump() = VAR x : PROCEDURE() := NIL; BEGIN x() END >> NilJump; >> >> PROCEDURE NilDeref() = >> VAR x : REF INTEGER := NIL; b : INTEGER; >> BEGIN b := x^ END NilDeref; >> >> PROCEDURE NilMethod() = >> TYPE T = OBJECT METHODS m() END; >> VAR t : T; BEGIN t.m() END NilMethod; >> >> BEGIN >> WITH ps = ARRAY OF PROCEDURE() { Range, Assert, NilMethod, NilJump, >> NilDeref } DO >> FOR i := FIRST(ps) TO LAST(ps) DO >> TRY >> ps[i]() >> EXCEPT >> RuntimeError.E(e) => IO.Put("RuntimeError: " & >> RuntimeError.Tag(e) & " \n") >> END >> END >> END >> END Main. >> >> yields the following result: >> >> (1053)trs80:~/test/src>../FreeBSD4/prog >> RuntimeError: An enumeration or subrange value was out of range. >> RuntimeError: <*ASSERT*> failed. >> >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL >> *** pc = 0x8048a71 = NilMethod + 0x10 in ../src/Main.m3 >> *** >> >> Abort >> >> Seems to me I ought to see a few more exceptions and not a crash. >> >> I'm happy to investigate a bit more, but does anyone have a clue >> where >> to begin? >> >> Mika From rodney.m.bates at cox.net Mon Apr 27 16:27:39 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 27 Apr 2009 09:27:39 -0500 Subject: [M3devel] Fwd: Modula-2 to Modula-3 translator by Aachen University In-Reply-To: <20090427084618.hnk460mh440c880c@mail.elegosoft.com> References: <20090427084618.hnk460mh440c880c@mail.elegosoft.com> Message-ID: <49F5C0DB.5010409@cox.net> I have a local copy of it, but haven't built/run it in several years. I have used it successfully on two or three conversions in the past. Can we make space at elegosoft? I'm pretty busy moving house now, but could quickly put my current files up, then try in a couple of months to see if it has suffered any bitrot. Olaf Wagner wrote: > Perhaps somebody on the public list knows something... > > ----- Forwarded message from trijezdci at gmail.com ----- > Date: Sun, 26 Apr 2009 15:57:36 +0900 > From: Benjamin Kowarsch > Reply-To: Benjamin Kowarsch > Subject: Modula-2 to Modula-3 translator by Aachen University > To: m3-support at elego.de > > Dear Sirs, > > I am trying to get the Modula-2 section in the Catalog of Compilers > updated and there is one entry of a Modula-2 to Modula-3 translator by > Peter Klein at University of Aachen for which all links and email > addresses seem to be dead. University of Aachen was unable to give me > any information either. > > I wonder if you know whether this translator is still availabe and if > so at which URL, or where his author Peter Klein can be contacted. > > thank you > regards > benjamin > > > ----- End forwarded message ----- > > Rodney Bates rodney.m.bates at cox.net From mika at async.caltech.edu Tue Apr 28 03:18:10 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 27 Apr 2009 18:18:10 -0700 Subject: [M3devel] RuntimeError doesn't work quite as advertised In-Reply-To: Your message of "Mon, 27 Apr 2009 22:23:41 +1000." <7F78EA61-BF67-4C18-85D4-F0CC5B45276A@cs.purdue.edu> Message-ID: <200904280118.n3S1IAQ2021489@camembert.async.caltech.edu> I think it ought to be safe to use siglongjmp. So we could attach a sigjmpbuf to whatever structure PushEFrame builds only when it's doing it for a "RuntimeError", and on a runtime error that's not handled otherwise, we catch the unix signal and call siglongjmp to get back to the exception handler... Here's an example in C: #include #include sigjmp_buf env; void handler(int x) { siglongjmp(env,1); } main() { signal(SIGSEGV, handler); if(sigsetjmp(env,1)) { printf("caught signal\n"); exit(0); } else { printf("initialized env\n"); } { int *a=(void *)0; printf("a is %d\n", *a /* SEGV */); /* not reached */ } } Mika Tony Hosking writes: >It's probably not generally safe to use RAISE inside a signal >handler. There are esoteric rules as to what signal handlers can >handle... > >I think we need to think harder on how best to reflect NIL dereference >as a signal. Perhaps we need explicit NIL checks after all... > >On 27 Apr 2009, at 18:31, Mika Nystrom wrote: > >> Ok so I tried the "obvious thing", namely, I changed RTSignal.SegV to >> do >> >> RAISE RuntimeError.E(RuntimeError.T.BadMemoryReference); >> >> Somewhat to my surprise, this does the right thing for a null method. >> But somewhat less surprisingly, it loops for NilJump and NilDeref. >> Is the machine jumping back and re-executing the same instructions >> after the signal handler returns? >> >> Would all hell break loose if one were to special-case EXCEPT >> RuntimeError.E to store a thread-local jmp_buf that one does a >> C-style longjmp to? (With a chain back to any higher RuntimeError.E >> handlers, I suppose...) Or is there a way to get the exception to >> work out of the signal handler with the normal exception mechanism? >> >> Mika > >> Mika Nystrom writes: >>> >>> Maybe someone else knows more about this than me... >>> >>> The following program: >>> >>> MODULE Main; >>> IMPORT RuntimeError, IO; >>> >>> PROCEDURE Range() = BEGIN EVAL VAL(-1,CARDINAL) END Range; >>> >>> PROCEDURE Assert() = BEGIN <*ASSERT FALSE*> END Assert; >>> >>> PROCEDURE NilJump() = VAR x : PROCEDURE() := NIL; BEGIN x() END >>> NilJump; >>> >>> PROCEDURE NilDeref() = >>> VAR x : REF INTEGER := NIL; b : INTEGER; >>> BEGIN b := x^ END NilDeref; >>> >>> PROCEDURE NilMethod() = >>> TYPE T = OBJECT METHODS m() END; >>> VAR t : T; BEGIN t.m() END NilMethod; >>> >>> BEGIN >>> WITH ps = ARRAY OF PROCEDURE() { Range, Assert, NilMethod, NilJump, >>> NilDeref } DO >>> FOR i := FIRST(ps) TO LAST(ps) DO >>> TRY >>> ps[i]() >>> EXCEPT >>> RuntimeError.E(e) => IO.Put("RuntimeError: " & >>> RuntimeError.Tag(e) & " \n") >>> END >>> END >>> END >>> END Main. >>> >>> yields the following result: >>> >>> (1053)trs80:~/test/src>../FreeBSD4/prog >>> RuntimeError: An enumeration or subrange value was out of range. >>> RuntimeError: <*ASSERT*> failed. >>> >>> >>> *** >>> *** runtime error: >>> *** Segmentation violation - possible attempt to dereference NIL >>> *** pc = 0x8048a71 = NilMethod + 0x10 in ../src/Main.m3 >>> *** >>> >>> Abort >>> >>> Seems to me I ought to see a few more exceptions and not a crash. >>> >>> I'm happy to investigate a bit more, but does anyone have a clue >>> where >>> to begin? >>> >>> Mika From hosking at cs.purdue.edu Tue Apr 28 03:48:34 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 28 Apr 2009 11:48:34 +1000 Subject: [M3devel] RuntimeError doesn't work quite as advertised In-Reply-To: <200904280118.n3S1IAQ2021489@camembert.async.caltech.edu> References: <200904280118.n3S1IAQ2021489@camembert.async.caltech.edu> Message-ID: <186B6F66-B42D-4AB4-8151-470FE0296013@cs.purdue.edu> On 28 Apr 2009, at 11:18, Mika Nystrom wrote: > I think it ought to be safe to use siglongjmp. > > So we could attach a sigjmpbuf to whatever structure PushEFrame > builds only when it's doing it for a "RuntimeError", and on a runtime > error that's not handled otherwise, we catch the unix signal and > call siglongjmp to get back to the exception handler... I'm not sure we can statically determine how a frame will be used. Can someone (Jay?) confirm whether signal handling on platforms without a stack walker are actually already using siglongjmp? I have a feeling this may already be the case. > Here's an example in C: > > #include > #include > > sigjmp_buf env; > > void handler(int x) { siglongjmp(env,1); } > > main() > { > signal(SIGSEGV, handler); > > if(sigsetjmp(env,1)) { > printf("caught signal\n"); > exit(0); > } else { > printf("initialized env\n"); > } > > { > int *a=(void *)0; > printf("a is %d\n", *a /* SEGV */); > /* not reached */ > } > } > > Mika > > > Tony Hosking writes: >> It's probably not generally safe to use RAISE inside a signal >> handler. There are esoteric rules as to what signal handlers can >> handle... >> >> I think we need to think harder on how best to reflect NIL >> dereference >> as a signal. Perhaps we need explicit NIL checks after all... >> >> On 27 Apr 2009, at 18:31, Mika Nystrom wrote: >> >>> Ok so I tried the "obvious thing", namely, I changed RTSignal.SegV >>> to >>> do >>> >>> RAISE RuntimeError.E(RuntimeError.T.BadMemoryReference); >>> >>> Somewhat to my surprise, this does the right thing for a null >>> method. >>> But somewhat less surprisingly, it loops for NilJump and NilDeref. >>> Is the machine jumping back and re-executing the same instructions >>> after the signal handler returns? >>> >>> Would all hell break loose if one were to special-case EXCEPT >>> RuntimeError.E to store a thread-local jmp_buf that one does a >>> C-style longjmp to? (With a chain back to any higher RuntimeError.E >>> handlers, I suppose...) Or is there a way to get the exception to >>> work out of the signal handler with the normal exception mechanism? >>> >>> Mika >> >>> Mika Nystrom writes: >>>> >>>> Maybe someone else knows more about this than me... >>>> >>>> The following program: >>>> >>>> MODULE Main; >>>> IMPORT RuntimeError, IO; >>>> >>>> PROCEDURE Range() = BEGIN EVAL VAL(-1,CARDINAL) END Range; >>>> >>>> PROCEDURE Assert() = BEGIN <*ASSERT FALSE*> END Assert; >>>> >>>> PROCEDURE NilJump() = VAR x : PROCEDURE() := NIL; BEGIN x() END >>>> NilJump; >>>> >>>> PROCEDURE NilDeref() = >>>> VAR x : REF INTEGER := NIL; b : INTEGER; >>>> BEGIN b := x^ END NilDeref; >>>> >>>> PROCEDURE NilMethod() = >>>> TYPE T = OBJECT METHODS m() END; >>>> VAR t : T; BEGIN t.m() END NilMethod; >>>> >>>> BEGIN >>>> WITH ps = ARRAY OF PROCEDURE() { Range, Assert, NilMethod, NilJump, >>>> NilDeref } DO >>>> FOR i := FIRST(ps) TO LAST(ps) DO >>>> TRY >>>> ps[i]() >>>> EXCEPT >>>> RuntimeError.E(e) => IO.Put("RuntimeError: " & >>>> RuntimeError.Tag(e) & " \n") >>>> END >>>> END >>>> END >>>> END Main. >>>> >>>> yields the following result: >>>> >>>> (1053)trs80:~/test/src>../FreeBSD4/prog >>>> RuntimeError: An enumeration or subrange value was out of range. >>>> RuntimeError: <*ASSERT*> failed. >>>> >>>> >>>> *** >>>> *** runtime error: >>>> *** Segmentation violation - possible attempt to dereference NIL >>>> *** pc = 0x8048a71 = NilMethod + 0x10 in ../src/Main.m3 >>>> *** >>>> >>>> Abort >>>> >>>> Seems to me I ought to see a few more exceptions and not a crash. >>>> >>>> I'm happy to investigate a bit more, but does anyone have a clue >>>> where >>>> to begin? >>>> >>>> Mika From jay.krell at cornell.edu Tue Apr 28 03:50:58 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 01:50:58 +0000 Subject: [M3devel] RuntimeError doesn't work quite as advertised In-Reply-To: <200904280118.n3S1IAQ2021489@camembert.async.caltech.edu> References: Your message of "Mon, 27 Apr 2009 22:23:41 +1000." <7F78EA61-BF67-4C18-85D4-F0CC5B45276A@cs.purdue.edu> <200904280118.n3S1IAQ2021489@camembert.async.caltech.edu> Message-ID: 1) Should we just always use sigsetjmp/siglongjmp? Or, getting the signal mask is much extra expense usually unnecesary? (imagine the case of there being a stack walker, where not even setjmp is paid for) Folks aren't supposed to muck with it willy nilly and should expect raising/catching an exception to restore to that which it was at the point of the try? 2) The inlined NULL checks arounds the "barrier" calls: - Aren't they just bloating the code for the unusual case? - Aren't they better left in the barrier functions themselves? - Besides leading to smaller and therefore faster code (except in the usual case of there being a NULL pointer deref, which is always going to be slow anyway), can't this then double or mostly double for a place to fix this? That is, IF, but I doubt this is true, IF every pointer deref goes through a "barrier" function, the exceptions could be raised from them, right? Are the barrier calls placed adequately maybe????? I don't think they are placed for untraced derefs (a fix Tony recently put in) and I imagine you might want those to act the same as traced null derefs. Maybe a pragma??? - Jay > To: hosking at cs.purdue.edu > Date: Mon, 27 Apr 2009 18:18:10 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RuntimeError doesn't work quite as advertised > > I think it ought to be safe to use siglongjmp. > > So we could attach a sigjmpbuf to whatever structure PushEFrame > builds only when it's doing it for a "RuntimeError", and on a runtime > error that's not handled otherwise, we catch the unix signal and > call siglongjmp to get back to the exception handler... > > Here's an example in C: > > #include > #include > > sigjmp_buf env; > > void handler(int x) { siglongjmp(env,1); } > > main() > { > signal(SIGSEGV, handler); > > if(sigsetjmp(env,1)) { > printf("caught signal\n"); > exit(0); > } else { > printf("initialized env\n"); > } > > { > int *a=(void *)0; > printf("a is %d\n", *a /* SEGV */); > /* not reached */ > } > } > > Mika > > > Tony Hosking writes: > >It's probably not generally safe to use RAISE inside a signal > >handler. There are esoteric rules as to what signal handlers can > >handle... > > > >I think we need to think harder on how best to reflect NIL dereference > >as a signal. Perhaps we need explicit NIL checks after all... > > > >On 27 Apr 2009, at 18:31, Mika Nystrom wrote: > > > >> Ok so I tried the "obvious thing", namely, I changed RTSignal.SegV to > >> do > >> > >> RAISE RuntimeError.E(RuntimeError.T.BadMemoryReference); > >> > >> Somewhat to my surprise, this does the right thing for a null method. > >> But somewhat less surprisingly, it loops for NilJump and NilDeref. > >> Is the machine jumping back and re-executing the same instructions > >> after the signal handler returns? > >> > >> Would all hell break loose if one were to special-case EXCEPT > >> RuntimeError.E to store a thread-local jmp_buf that one does a > >> C-style longjmp to? (With a chain back to any higher RuntimeError.E > >> handlers, I suppose...) Or is there a way to get the exception to > >> work out of the signal handler with the normal exception mechanism? > >> > >> Mika > > > >> Mika Nystrom writes: > >>> > >>> Maybe someone else knows more about this than me... > >>> > >>> The following program: > >>> > >>> MODULE Main; > >>> IMPORT RuntimeError, IO; > >>> > >>> PROCEDURE Range() = BEGIN EVAL VAL(-1,CARDINAL) END Range; > >>> > >>> PROCEDURE Assert() = BEGIN <*ASSERT FALSE*> END Assert; > >>> > >>> PROCEDURE NilJump() = VAR x : PROCEDURE() := NIL; BEGIN x() END > >>> NilJump; > >>> > >>> PROCEDURE NilDeref() = > >>> VAR x : REF INTEGER := NIL; b : INTEGER; > >>> BEGIN b := x^ END NilDeref; > >>> > >>> PROCEDURE NilMethod() = > >>> TYPE T = OBJECT METHODS m() END; > >>> VAR t : T; BEGIN t.m() END NilMethod; > >>> > >>> BEGIN > >>> WITH ps = ARRAY OF PROCEDURE() { Range, Assert, NilMethod, NilJump, > >>> NilDeref } DO > >>> FOR i := FIRST(ps) TO LAST(ps) DO > >>> TRY > >>> ps[i]() > >>> EXCEPT > >>> RuntimeError.E(e) => IO.Put("RuntimeError: " & > >>> RuntimeError.Tag(e) & " \n") > >>> END > >>> END > >>> END > >>> END Main. > >>> > >>> yields the following result: > >>> > >>> (1053)trs80:~/test/src>../FreeBSD4/prog > >>> RuntimeError: An enumeration or subrange value was out of range. > >>> RuntimeError: <*ASSERT*> failed. > >>> > >>> > >>> *** > >>> *** runtime error: > >>> *** Segmentation violation - possible attempt to dereference NIL > >>> *** pc = 0x8048a71 = NilMethod + 0x10 in ../src/Main.m3 > >>> *** > >>> > >>> Abort > >>> > >>> Seems to me I ought to see a few more exceptions and not a crash. > >>> > >>> I'm happy to investigate a bit more, but does anyone have a clue > >>> where > >>> to begin? > >>> > >>> Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Apr 28 04:23:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 28 Apr 2009 12:23:57 +1000 Subject: [M3devel] RuntimeError doesn't work quite as advertised In-Reply-To: References: Your message of "Mon, 27 Apr 2009 22:23:41 +1000." <7F78EA61-BF67-4C18-85D4-F0CC5B45276A@cs.purdue.edu> <200904280118.n3S1IAQ2021489@camembert.async.caltech.edu> Message-ID: On 28 Apr 2009, at 11:50, Jay wrote: > 1) Should we just always use sigsetjmp/siglongjmp? > Or, getting the signal mask is much extra expense usually unnecesary? > (imagine the case of there being a stack walker, where not even > setjmp is paid for) > Folks aren't supposed to muck with it willy nilly and should expect > raising/catching an exception to restore to that which it was at the > point of the try? I would have thought so, yes. I thought I had seen use of setjmp/ longjmp instead of _setjmp/_longjmp but it appears some platforms don't restore signal masks (viz. I386_DARWIN). > 2) The inlined NULL checks arounds the "barrier" calls: > - Aren't they just bloating the code for the unusual case? > - Aren't they better left in the barrier functions themselves? > - Besides leading to smaller and therefore faster code (except in > the usual > case of there being a NULL pointer deref, which is always going to > be slow anyway), > can't this then double or mostly double for a place to fix this? > That is, IF, but I doubt this is true, IF every pointer deref goes > through a "barrier" > function, the exceptions could be raised from them, right The point is that we want to do a fast inline check via non-NIL references, so we need to explicitly check for those. This is not the standard NIL check, since it is legal to load NIL from the heap. There are no exceptions to be raised here. The explicit check for loading NIL is only for loads from the heap. Not for stores to the heap. > ? > > > Are the barrier calls placed adequately maybe????? > I don't think they are placed for untraced derefs (a fix Tony > recently put in) > and I imagine you might want those to act the same as traced null > derefs. > Maybe a pragma??? > > > - Jay > > > > To: hosking at cs.purdue.edu > > Date: Mon, 27 Apr 2009 18:18:10 -0700 > > From: mika at async.caltech.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] RuntimeError doesn't work quite as advertised > > > > I think it ought to be safe to use siglongjmp. > > > > So we could attach a sigjmpbuf to whatever structure PushEFrame > > builds only when it's doing it for a "RuntimeError", and on a > runtime > > error that's not handled otherwise, we catch the unix signal and > > call siglongjmp to get back to the exception handler... > > > > Here's an example in C: > > > > #include > > #include > > > > sigjmp_buf env; > > > > void handler(int x) { siglongjmp(env,1); } > > > > main() > > { > > signal(SIGSEGV, handler); > > > > if(sigsetjmp(env,1)) { > > printf("caught signal\n"); > > exit(0); > > } else { > > printf("initialized env\n"); > > } > > > > { > > int *a=(void *)0; > > printf("a is %d\n", *a /* SEGV */); > > /* not reached */ > > } > > } > > > > Mika > > > > > > Tony Hosking writes: > > >It's probably not generally safe to use RAISE inside a signal > > >handler. There are esoteric rules as to what signal handlers can > > >handle... > > > > > >I think we need to think harder on how best to reflect NIL > dereference > > >as a signal. Perhaps we need explicit NIL checks after all... > > > > > >On 27 Apr 2009, at 18:31, Mika Nystrom wrote: > > > > > >> Ok so I tried the "obvious thing", namely, I changed > RTSignal.SegV to > > >> do > > >> > > >> RAISE RuntimeError.E(RuntimeError.T.BadMemoryReference); > > >> > > >> Somewhat to my surprise, this does the right thing for a null > method. > > >> But somewhat less surprisingly, it loops for NilJump and > NilDeref. > > >> Is the machine jumping back and re-executing the same > instructions > > >> after the signal handler returns? > > >> > > >> Would all hell break loose if one were to special-case EXCEPT > > >> RuntimeError.E to store a thread-local jmp_buf that one does a > > >> C-style longjmp to? (With a chain back to any higher > RuntimeError.E > > >> handlers, I suppose...) Or is there a way to get the exception to > > >> work out of the signal handler with the normal exception > mechanism? > > >> > > >> Mika > > > > > >> Mika Nystrom writes: > > >>> > > >>> Maybe someone else knows more about this than me... > > >>> > > >>> The following program: > > >>> > > >>> MODULE Main; > > >>> IMPORT RuntimeError, IO; > > >>> > > >>> PROCEDURE Range() = BEGIN EVAL VAL(-1,CARDINAL) END Range; > > >>> > > >>> PROCEDURE Assert() = BEGIN <*ASSERT FALSE*> END Assert; > > >>> > > >>> PROCEDURE NilJump() = VAR x : PROCEDURE() := NIL; BEGIN x() END > > >>> NilJump; > > >>> > > >>> PROCEDURE NilDeref() = > > >>> VAR x : REF INTEGER := NIL; b : INTEGER; > > >>> BEGIN b := x^ END NilDeref; > > >>> > > >>> PROCEDURE NilMethod() = > > >>> TYPE T = OBJECT METHODS m() END; > > >>> VAR t : T; BEGIN t.m() END NilMethod; > > >>> > > >>> BEGIN > > >>> WITH ps = ARRAY OF PROCEDURE() { Range, Assert, NilMethod, > NilJump, > > >>> NilDeref } DO > > >>> FOR i := FIRST(ps) TO LAST(ps) DO > > >>> TRY > > >>> ps[i]() > > >>> EXCEPT > > >>> RuntimeError.E(e) => IO.Put("RuntimeError: " & > > >>> RuntimeError.Tag(e) & " \n") > > >>> END > > >>> END > > >>> END > > >>> END Main. > > >>> > > >>> yields the following result: > > >>> > > >>> (1053)trs80:~/test/src>../FreeBSD4/prog > > >>> RuntimeError: An enumeration or subrange value was out of range. > > >>> RuntimeError: <*ASSERT*> failed. > > >>> > > >>> > > >>> *** > > >>> *** runtime error: > > >>> *** Segmentation violation - possible attempt to dereference NIL > > >>> *** pc = 0x8048a71 = NilMethod + 0x10 in ../src/Main.m3 > > >>> *** > > >>> > > >>> Abort > > >>> > > >>> Seems to me I ought to see a few more exceptions and not a > crash. > > >>> > > >>> I'm happy to investigate a bit more, but does anyone have a clue > > >>> where > > >>> to begin? > > >>> > > >>> Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Apr 28 08:29:37 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 28 Apr 2009 08:29:37 +0200 Subject: [M3devel] CM3 release build regression tests not terminating Message-ID: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> Hi, does anybody know what's keeping the release-build tests for tinderbox from terminating? I've got lots of stalled regression process trees on my system, and the tinderbox display indicates that none of the release builds seem to succeed. Has anybody changed anything in the scripts? On a closer look, upgrade seems to be stuck in the installer: % ps -axwww 25310 PID TT STAT TIME COMMAND 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/luthien/current -o Jay, did you change any config files recently? Regression tests seemed to have been running again for some days, and then stopped again. I'll try to investigate further this evening, but must leave now for other work... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Tue Apr 28 08:45:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 28 Apr 2009 16:45:29 +1000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> Message-ID: <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> Yes, I had noticed this too. On 28 Apr 2009, at 16:29, Olaf Wagner wrote: > Hi, > > does anybody know what's keeping the release-build tests for tinderbox > from terminating? I've got lots of stalled regression process trees on > my system, and the tinderbox display indicates that none of the > release > builds seem to succeed. Has anybody changed anything in the scripts? > > On a closer look, upgrade seems to be stuck in the installer: > > % ps -axwww 25310 > PID TT STAT TIME COMMAND > 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ > pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ > luthien/current -o > > Jay, did you change any config files recently? > Regression tests seemed to have been running again for some days, > and then > stopped again. > > I'll try to investigate further this evening, but must leave now for > other work... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From jay.krell at cornell.edu Tue Apr 28 09:45:14 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 07:45:14 +0000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> Message-ID: I've never been able to get the tinderbox stuff to work for me. I'll try again. Nothing much from me lately -- pthreads movement to C, and then back. >> Jay, did you change any config files recently? FreeBSD config file changes on 2009-04-13. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: wagner at elegosoft.com > Date: Tue, 28 Apr 2009 16:45:29 +1000 > CC: m3devel at elegosoft.com; manderson at elegosoft.com > Subject: Re: [M3devel] CM3 release build regression tests not terminating > > Yes, I had noticed this too. > > On 28 Apr 2009, at 16:29, Olaf Wagner wrote: > >> Hi, >> >> does anybody know what's keeping the release-build tests for tinderbox >> from terminating? I've got lots of stalled regression process trees on >> my system, and the tinderbox display indicates that none of the >> release >> builds seem to succeed. Has anybody changed anything in the scripts? >> >> On a closer look, upgrade seems to be stuck in the installer: >> >> % ps -axwww 25310 >> PID TT STAT TIME COMMAND >> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >> luthien/current -o >> >> Jay, did you change any config files recently? >> Regression tests seemed to have been running again for some days, >> and then >> stopped again. >> >> I'll try to investigate further this evening, but must leave now for >> other work... >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >> Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> > From jay.krell at cornell.edu Tue Apr 28 10:03:13 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 08:03:13 +0000 Subject: [M3devel] how to find dependent .so files? Message-ID: Normally we have: /usr/local/cm3/bin/someexe /usr/local/cm3/lib/libfoo.so symlink to ../pkg/foo/target/libfoo.so /usr/local/cm3/lib/libbar.so symlink to ../pkg/bar/target/libbar.so Linking from someexe to $ORIGIN/../lib works, ok. But from libfoo to libbar requires $ORIGIN/../../../lib. or $ORIGIN/../../bar/target. Currently on FreeBSD I set the runpath to $ORIGIN/../lib:$ORIGIN/../../../lib or maybe $ORIGIN/../lib:$ORIGIN/../../lib:$ORIGIN/../../../lib I want to claim this is working, but there are unresolved Tinderbox problems. Let's assume for now it does. I find something as long as "../../.." starts feeling dangerous. It could land somewhere unrelated. I'd prefer a shorter runpath like just $ORIGIN/../lib. To fix this I propose one of two changes. 1) Reverse the symlink relationship: replace /usr/local/cm3/lib/libfoo.so symlink to ../pkg/foo/target/libfoo.so with /usr/local/cm3/lib/libfoo.so real file /usr/local/cm3/pkg/foo/target/libfoo.so symlink to previous This is kind of model changing. There is a package store and all files do really ship into it. Shorter more convenient paths are a higher level construct. I guess. It's a nice model, kind of, but also inconvenient. or 2) Make them hardlinks. Does that work? It seems less model changing. Sort of. It's really extremely similar to previous, except that the package store remains rather self contained. Meanwhile, shipped non-public binaries: /usr/local/cm3/pkg/someexe/target/someexe would would not work. I think they exist though, e.g. obliq. Maybe ship them to /usr/local/cm3/lib? NT386 isn't relevant, so go ahead apply symlinks/hardlinks to the problem pretty arbitrarily I think. There all the .so files (.dll) are in \cm3\bin next to the .exes. The searchpath for .dlls and .exes is roughly the same. NTFS has always had hardlinks. NTFS as of Vista has symlinks. FAT does not have either. Cygwin supports symlinks anywhere via higher level mechanisms (either its own files or usermode Explorer "shortcuts" (think of Mac "aliases")). - Jay From jay.krell at cornell.edu Tue Apr 28 11:14:47 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 09:14:47 +0000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> Message-ID: Well, on FreeBSD 7.0, I get as far as: ew source -> compiling EnvUtils.i3 libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" ew source -> compiling EnvUtils.m3 libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" ew source -> compiling FingerprintFmt.i3 libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" ew source -> compiling TextUtils.i3 libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" Yeah, I understand, I have libc.so.7. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; wagner at elegosoft.com > Date: Tue, 28 Apr 2009 07:45:14 +0000 > CC: m3devel at elegosoft.com; manderson at elegosoft.com > Subject: Re: [M3devel] CM3 release build regression tests not terminating > > > I've never been able to get the tinderbox stuff to work for me. > I'll try again. > Nothing much from me lately -- pthreads movement to C, and then back. > >>> Jay, did you change any config files recently? > > FreeBSD config file changes on 2009-04-13. > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: wagner at elegosoft.com >> Date: Tue, 28 Apr 2009 16:45:29 +1000 >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: Re: [M3devel] CM3 release build regression tests not terminating >> >> Yes, I had noticed this too. >> >> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >> >>> Hi, >>> >>> does anybody know what's keeping the release-build tests for tinderbox >>> from terminating? I've got lots of stalled regression process trees on >>> my system, and the tinderbox display indicates that none of the >>> release >>> builds seem to succeed. Has anybody changed anything in the scripts? >>> >>> On a closer look, upgrade seems to be stuck in the installer: >>> >>> % ps -axwww 25310 >>> PID TT STAT TIME COMMAND >>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>> luthien/current -o >>> >>> Jay, did you change any config files recently? >>> Regression tests seemed to have been running again for some days, >>> and then >>> stopped again. >>> >>> I'll try to investigate further this evening, but must leave now for >>> other work... >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> >> From wagner at elegosoft.com Tue Apr 28 11:40:00 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 28 Apr 2009 11:40:00 +0200 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> Message-ID: <20090428114000.kghi05wbw484cook@mail.elegosoft.com> Quoting Jay : > > Well, on FreeBSD 7.0, I get as far as: > > ew source -> compiling EnvUtils.i3 > libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" > ew source -> compiling EnvUtils.m3 > libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" > ew source -> compiling FingerprintFmt.i3 > libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" > ew source -> compiling TextUtils.i3 > libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" > > Yeah, I understand, I have libc.so.7. You need to install the FreeBSD compat packages for backward compatibility. Should work fine then (until cminstall hangs?). Olaf > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu; wagner at elegosoft.com >> Date: Tue, 28 Apr 2009 07:45:14 +0000 >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: Re: [M3devel] CM3 release build regression tests not terminating >> >> >> I've never been able to get the tinderbox stuff to work for me. >> I'll try again. >> Nothing much from me lately -- pthreads movement to C, and then back. >> >>>> Jay, did you change any config files recently? >> >> FreeBSD config file changes on 2009-04-13. >> >> - Jay >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: wagner at elegosoft.com >>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>> >>> Yes, I had noticed this too. >>> >>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>> >>>> Hi, >>>> >>>> does anybody know what's keeping the release-build tests for tinderbox >>>> from terminating? I've got lots of stalled regression process trees on >>>> my system, and the tinderbox display indicates that none of the >>>> release >>>> builds seem to succeed. Has anybody changed anything in the scripts? >>>> >>>> On a closer look, upgrade seems to be stuck in the installer: >>>> >>>> % ps -axwww 25310 >>>> PID TT STAT TIME COMMAND >>>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>>> luthien/current -o >>>> >>>> Jay, did you change any config files recently? >>>> Regression tests seemed to have been running again for some days, >>>> and then >>>> stopped again. >>>> >>>> I'll try to investigate further this evening, but must leave now for >>>> other work... >>>> >>>> Olaf >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>> Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>> 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>> Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> >>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 28 11:45:32 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 28 Apr 2009 11:45:32 +0200 Subject: [M3devel] Fwd: Modula-2 to Modula-3 translator by Aachen University In-Reply-To: <49F5C0DB.5010409@cox.net> References: <20090427084618.hnk460mh440c880c@mail.elegosoft.com> <49F5C0DB.5010409@cox.net> Message-ID: <20090428114532.sy26ftrzdgc448kw@mail.elegosoft.com> Hi Michael, could you take care of that and host Rodney's archives on birch with public access? If you drop me the URL, I'll insert it into the CM3 and/or modula3.org pages then. Thanks in advance, Olaf Quoting "Rodney M. Bates" : > I have a local copy of it, but haven't built/run it in several years. > I have used it successfully on two or three conversions in the past. > Can we make space at elegosoft? I'm pretty busy moving house now, > but could quickly put my current files up, then try in a couple of > months to see if it has suffered any bitrot. > > Olaf Wagner wrote: >> Perhaps somebody on the public list knows something... >> >> ----- Forwarded message from trijezdci at gmail.com ----- >> Date: Sun, 26 Apr 2009 15:57:36 +0900 >> From: Benjamin Kowarsch >> Reply-To: Benjamin Kowarsch >> Subject: Modula-2 to Modula-3 translator by Aachen University >> To: m3-support at elego.de >> >> Dear Sirs, >> >> I am trying to get the Modula-2 section in the Catalog of Compilers >> updated and there is one entry of a Modula-2 to Modula-3 translator by >> Peter Klein at University of Aachen for which all links and email >> addresses seem to be dead. University of Aachen was unable to give me >> any information either. >> >> I wonder if you know whether this translator is still availabe and if >> so at which URL, or where his author Peter Klein can be contacted. >> >> thank you >> regards >> benjamin >> >> >> ----- End forwarded message ----- >> >> > Rodney Bates > rodney.m.bates at cox.net -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 28 11:58:56 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 09:58:56 +0000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <20090428114000.kghi05wbw484cook@mail.elegosoft.com> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> Message-ID: Right, now it hangs having printed..I know this looks a bit of nonsense..stuff from right around: M3_BACKEND_MODE = "3" % -- defines how the frontend, backend, and assembler interact % "0" -- don't call m3_backend, M3CG produces object code % "1" -- don't call m3_backend, M3CG produces assembly code % "2" -- call m3_backend, it produces object code % "3" -- call m3_backend, it produces assembly code however, this is noticably pretty close to the last BEGIN_CONFIG. Maybe the carriage returns confused it. I'll see.. I did introduce them recently by accident. gdb reported some errors and no symbols in the callstack having connected to it, on FreeBSD. If need be I can try debugging it on another system.. (aside, philosophy: all text processing code should treat \n, \r, and \r\n in put the same, unless you are writing a terminal driver, then \r has a separate meaning useful for implementing spinners..) - Jay ---------------------------------------- > Date: Tue, 28 Apr 2009 11:40:00 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com > Subject: RE: [M3devel] CM3 release build regression tests not terminating > > Quoting Jay : > >> >> Well, on FreeBSD 7.0, I get as far as: >> >> ew source -> compiling EnvUtils.i3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" >> ew source -> compiling EnvUtils.m3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" >> ew source -> compiling FingerprintFmt.i3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" >> ew source -> compiling TextUtils.i3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" >> >> Yeah, I understand, I have libc.so.7. > > You need to install the FreeBSD compat packages for backward > compatibility. Should work fine then (until cminstall hangs?). > > Olaf > >> >> - Jay >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>> >>> >>> I've never been able to get the tinderbox stuff to work for me. >>> I'll try again. >>> Nothing much from me lately -- pthreads movement to C, and then back. >>> >>>>> Jay, did you change any config files recently? >>> >>> FreeBSD config file changes on 2009-04-13. >>> >>> - Jay >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> To: wagner at elegosoft.com >>>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>>> >>>> Yes, I had noticed this too. >>>> >>>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>>> >>>>> Hi, >>>>> >>>>> does anybody know what's keeping the release-build tests for tinderbox >>>>> from terminating? I've got lots of stalled regression process trees on >>>>> my system, and the tinderbox display indicates that none of the >>>>> release >>>>> builds seem to succeed. Has anybody changed anything in the scripts? >>>>> >>>>> On a closer look, upgrade seems to be stuck in the installer: >>>>> >>>>> % ps -axwww 25310 >>>>> PID TT STAT TIME COMMAND >>>>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>>>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>>>> luthien/current -o >>>>> >>>>> Jay, did you change any config files recently? >>>>> Regression tests seemed to have been running again for some days, >>>>> and then >>>>> stopped again. >>>>> >>>>> I'll try to investigate further this evening, but must leave now for >>>>> other work... >>>>> >>>>> Olaf >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>>> Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>> 45 86 95 >>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>>> Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>> DE163214194 >>>>> >>>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 28 12:14:37 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 10:14:37 +0000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <20090428114000.kghi05wbw484cook@mail.elegosoft.com> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> Message-ID: It creates a file named "df-k" and hangs here: (gdb) where #0 0x080f417f in select () #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, writefds=0x28127138, exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/FreeBSD4/select.c:13 #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, M3_CEtG8K_timeout=0xbfbfe6d8) at ThreadPosix.m3:714 #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, M3_AicXUJ_alertable=0 '\0') at ThreadPosix.m3:555 #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at ThreadPosix.m3:539 #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at ProcessPosix.m3:294 #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at System.m3:527 #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, M3_EkfbeH_env=0x0, M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at OSPOSIX.m3:19 #10 0x0804c31c in Main__DoIt () at Main.m3:122 #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at RTLinker.m3:395 #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at RTLinker.m3:109 #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at RTLinker.m3:118 #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at _m3main.mc:4 Notice it using user threads, so old m3core/libm3. df doesn't appear to be any longer running. Why it prints about the backend mode, I don't know. (and yes, I get it -- df -k is directly related to GetDiskSpace..if this is how one checks diskspace on Unix...I think we should punt, unless posix actually specifies the precise output format of this command it is very reliably parsed...) - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com > Subject: RE: [M3devel] CM3 release build regression tests not terminating > Date: Tue, 28 Apr 2009 09:58:56 +0000 > > > Right, now it hangs having printed..I know this looks a bit of nonsense..stuff from right around: > > > M3_BACKEND_MODE = "3" > % -- defines how the frontend, backend, and assembler interact > % "0" -- don't call m3_backend, M3CG produces object code > % "1" -- don't call m3_backend, M3CG produces assembly code > % "2" -- call m3_backend, it produces object code > % "3" -- call m3_backend, it produces assembly code > > > however, this is noticably pretty close to the last BEGIN_CONFIG. > > Maybe the carriage returns confused it. I'll see.. > I did introduce them recently by accident. > gdb reported some errors and no symbols in the callstack having connected to it, on FreeBSD. If need be I can try debugging it on another system.. > > > (aside, philosophy: all text processing code should treat \n, \r, and \r\n in put the same, unless you are writing a terminal driver, then \r has a separate meaning useful for implementing spinners..) > > > - Jay > > > ---------------------------------------- >> Date: Tue, 28 Apr 2009 11:40:00 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: RE: [M3devel] CM3 release build regression tests not terminating >> >> Quoting Jay : >> >>> >>> Well, on FreeBSD 7.0, I get as far as: >>> >>> ew source -> compiling EnvUtils.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" >>> ew source -> compiling EnvUtils.m3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" >>> ew source -> compiling FingerprintFmt.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" >>> ew source -> compiling TextUtils.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" >>> >>> Yeah, I understand, I have libc.so.7. >> >> You need to install the FreeBSD compat packages for backward >> compatibility. Should work fine then (until cminstall hangs?). >> >> Olaf >> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>>> >>>> >>>> I've never been able to get the tinderbox stuff to work for me. >>>> I'll try again. >>>> Nothing much from me lately -- pthreads movement to C, and then back. >>>> >>>>>> Jay, did you change any config files recently? >>>> >>>> FreeBSD config file changes on 2009-04-13. >>>> >>>> - Jay >>>> >>>> ---------------------------------------- >>>>> From: hosking at cs.purdue.edu >>>>> To: wagner at elegosoft.com >>>>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>>>> >>>>> Yes, I had noticed this too. >>>>> >>>>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> does anybody know what's keeping the release-build tests for tinderbox >>>>>> from terminating? I've got lots of stalled regression process trees on >>>>>> my system, and the tinderbox display indicates that none of the >>>>>> release >>>>>> builds seem to succeed. Has anybody changed anything in the scripts? >>>>>> >>>>>> On a closer look, upgrade seems to be stuck in the installer: >>>>>> >>>>>> % ps -axwww 25310 >>>>>> PID TT STAT TIME COMMAND >>>>>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>>>>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>>>>> luthien/current -o >>>>>> >>>>>> Jay, did you change any config files recently? >>>>>> Regression tests seemed to have been running again for some days, >>>>>> and then >>>>>> stopped again. >>>>>> >>>>>> I'll try to investigate further this evening, but must leave now for >>>>>> other work... >>>>>> >>>>>> Olaf >>>>>> -- >>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>>>> Germany >>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>>> 45 86 95 >>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>>>> Berlin >>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>> DE163214194 >>>>>> >>>>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 28 12:48:55 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 28 Apr 2009 12:48:55 +0200 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> Message-ID: <20090428124855.paxjik1misgc00ow@mail.elegosoft.com> Quoting Jay : > > It creates a file named "df-k" and hangs here: > > (gdb) where > #0 0x080f417f in select () > #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, writefds=0x28127138, > exceptfds=0x28127148, timeout=0xbfbfe6d8) at > ../src/runtime/FreeBSD4/select.c:13 > #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, > M3_CEtG8K_timeout=0xbfbfe6d8) > at ThreadPosix.m3:714 > #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 > #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, > M3_AicXUJ_alertable=0 '\0') > at ThreadPosix.m3:555 > #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at > ThreadPosix.m3:539 > #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at > ProcessPosix.m3:294 > #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at System.m3:527 > #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, > M3_EkfbeH_env=0x0, > M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 > #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at > OSPOSIX.m3:19 > #10 0x0804c31c in Main__DoIt () at Main.m3:122 > #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 > #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at > RTLinker.m3:395 > #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at > RTLinker.m3:109 > #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at > RTLinker.m3:118 > #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at > _m3main.mc:4 > > Notice it using user threads, so old m3core/libm3. > df doesn't appear to be any longer running. > Why it prints about the backend mode, I don't know. > > (and yes, I get it -- df -k is directly related to GetDiskSpace..if > this is how one checks diskspace on Unix...I think we should punt, > unless posix actually specifies the precise output format of this > command it is very reliably parsed...) You mean it's trying to _read_ df-k, which should have been created by the packaging scripts? If so, it's my fault; it should not try to read a file that isn't there. Or do you really mean it's hanging when trying to create that file? Creating df-k should be pretty straight forward on any POSIX system, as long as the file system isn't corrupt. Olaf > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: RE: [M3devel] CM3 release build regression tests not terminating >> Date: Tue, 28 Apr 2009 09:58:56 +0000 >> >> >> Right, now it hangs having printed..I know this looks a bit of >> nonsense..stuff from right around: >> >> >> M3_BACKEND_MODE = "3" >> % -- defines how the frontend, backend, and assembler interact >> % "0" -- don't call m3_backend, M3CG produces object code >> % "1" -- don't call m3_backend, M3CG produces assembly code >> % "2" -- call m3_backend, it produces object code >> % "3" -- call m3_backend, it produces assembly code >> >> >> however, this is noticably pretty close to the last BEGIN_CONFIG. >> >> Maybe the carriage returns confused it. I'll see.. >> I did introduce them recently by accident. >> gdb reported some errors and no symbols in the callstack having >> connected to it, on FreeBSD. If need be I can try debugging it on >> another system.. >> >> >> (aside, philosophy: all text processing code should treat \n, \r, >> and \r\n in put the same, unless you are writing a terminal driver, >> then \r has a separate meaning useful for implementing spinners..) >> >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Tue, 28 Apr 2009 11:40:00 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: RE: [M3devel] CM3 release build regression tests not terminating >>> >>> Quoting Jay : >>> >>>> >>>> Well, on FreeBSD 7.0, I get as far as: >>>> >>>> ew source -> compiling EnvUtils.i3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> ew source -> compiling EnvUtils.m3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> ew source -> compiling FingerprintFmt.i3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> ew source -> compiling TextUtils.i3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> >>>> Yeah, I understand, I have libc.so.7. >>> >>> You need to install the FreeBSD compat packages for backward >>> compatibility. Should work fine then (until cminstall hangs?). >>> >>> Olaf >>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>>>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>>>> >>>>> >>>>> I've never been able to get the tinderbox stuff to work for me. >>>>> I'll try again. >>>>> Nothing much from me lately -- pthreads movement to C, and then back. >>>>> >>>>>>> Jay, did you change any config files recently? >>>>> >>>>> FreeBSD config file changes on 2009-04-13. >>>>> >>>>> - Jay >>>>> >>>>> ---------------------------------------- >>>>>> From: hosking at cs.purdue.edu >>>>>> To: wagner at elegosoft.com >>>>>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>>> terminating >>>>>> >>>>>> Yes, I had noticed this too. >>>>>> >>>>>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> does anybody know what's keeping the release-build tests for tinderbox >>>>>>> from terminating? I've got lots of stalled regression process trees on >>>>>>> my system, and the tinderbox display indicates that none of the >>>>>>> release >>>>>>> builds seem to succeed. Has anybody changed anything in the scripts? >>>>>>> >>>>>>> On a closer look, upgrade seems to be stuck in the installer: >>>>>>> >>>>>>> % ps -axwww 25310 >>>>>>> PID TT STAT TIME COMMAND >>>>>>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>>>>>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>>>>>> luthien/current -o >>>>>>> >>>>>>> Jay, did you change any config files recently? >>>>>>> Regression tests seemed to have been running again for some days, >>>>>>> and then >>>>>>> stopped again. >>>>>>> >>>>>>> I'll try to investigate further this evening, but must leave now for >>>>>>> other work... >>>>>>> >>>>>>> Olaf >>>>>>> -- >>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>>>>> Germany >>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>>>> 45 86 95 >>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>>>>> Berlin >>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>>> DE163214194 >>>>>>> >>>>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From michael.anderson at elego.de Tue Apr 28 12:58:00 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Tue, 28 Apr 2009 12:58:00 +0200 Subject: [M3devel] Fwd: Modula-2 to Modula-3 translator by Aachen University In-Reply-To: <20090428114532.sy26ftrzdgc448kw@mail.elegosoft.com> References: <20090427084618.hnk460mh440c880c@mail.elegosoft.com> <49F5C0DB.5010409@cox.net> <20090428114532.sy26ftrzdgc448kw@mail.elegosoft.com> Message-ID: <20090428125800.4y2x5a4m8kk4ssoo@mail.elegosoft.com> Hi Rodney, If you'd like to upload the archives to birch:/var/www/m2tom3/ , I'll get a public area set up for them. Cheers, -Mike Zitat von Olaf Wagner : > Hi Michael, > > could you take care of that and host Rodney's archives on birch > with public access? If you drop me the URL, I'll insert it into > the CM3 and/or modula3.org pages then. > > Thanks in advance, > > Olaf > > Quoting "Rodney M. Bates" : > >> I have a local copy of it, but haven't built/run it in several years. >> I have used it successfully on two or three conversions in the past. >> Can we make space at elegosoft? I'm pretty busy moving house now, >> but could quickly put my current files up, then try in a couple of >> months to see if it has suffered any bitrot. >> >> Olaf Wagner wrote: >>> Perhaps somebody on the public list knows something... >>> >>> ----- Forwarded message from trijezdci at gmail.com ----- >>> Date: Sun, 26 Apr 2009 15:57:36 +0900 >>> From: Benjamin Kowarsch >>> Reply-To: Benjamin Kowarsch >>> Subject: Modula-2 to Modula-3 translator by Aachen University >>> To: m3-support at elego.de >>> >>> Dear Sirs, >>> >>> I am trying to get the Modula-2 section in the Catalog of Compilers >>> updated and there is one entry of a Modula-2 to Modula-3 translator by >>> Peter Klein at University of Aachen for which all links and email >>> addresses seem to be dead. University of Aachen was unable to give me >>> any information either. >>> >>> I wonder if you know whether this translator is still availabe and if >>> so at which URL, or where his author Peter Klein can be contacted. >>> >>> thank you >>> regards >>> benjamin >>> >>> >>> ----- End forwarded message ----- >>> >>> >> Rodney Bates >> rodney.m.bates at cox.net > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From hosking at cs.purdue.edu Tue Apr 28 13:11:42 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 28 Apr 2009 21:11:42 +1000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> Message-ID: <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> What could possibly have changed here. It used to work fine on multiple platforms. On 28 Apr 2009, at 20:14, Jay wrote: > > It creates a file named "df-k" and hangs here: > > (gdb) where > #0 0x080f417f in select () > #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, > writefds=0x28127138, > exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ > FreeBSD4/select.c:13 > #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, > M3_CEtG8K_timeout=0xbfbfe6d8) > at ThreadPosix.m3:714 > #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 > #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, > M3_AicXUJ_alertable=0 '\0') > at ThreadPosix.m3:555 > #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at > ThreadPosix.m3:539 > #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at > ProcessPosix.m3:294 > #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at > System.m3:527 > #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, > M3_EkfbeH_env=0x0, > M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 > #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at > OSPOSIX.m3:19 > #10 0x0804c31c in Main__DoIt () at Main.m3:122 > #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 > #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at > RTLinker.m3:395 > #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at > RTLinker.m3:109 > #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at > RTLinker.m3:118 > #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at > _m3main.mc:4 > > Notice it using user threads, so old m3core/libm3. > df doesn't appear to be any longer running. > Why it prints about the backend mode, I don't know. > > (and yes, I get it -- df -k is directly related to GetDiskSpace..if > this is how one checks diskspace on Unix...I think we should punt, > unless posix actually specifies the precise output format of this > command it is very reliably parsed...) > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: RE: [M3devel] CM3 release build regression tests not >> terminating >> Date: Tue, 28 Apr 2009 09:58:56 +0000 >> >> >> Right, now it hangs having printed..I know this looks a bit of >> nonsense..stuff from right around: >> >> >> M3_BACKEND_MODE = "3" >> % -- defines how the frontend, backend, and assembler interact >> % "0" -- don't call m3_backend, M3CG produces object code >> % "1" -- don't call m3_backend, M3CG produces assembly code >> % "2" -- call m3_backend, it produces object code >> % "3" -- call m3_backend, it produces assembly code >> >> >> however, this is noticably pretty close to the last BEGIN_CONFIG. >> >> Maybe the carriage returns confused it. I'll see.. >> I did introduce them recently by accident. >> gdb reported some errors and no symbols in the callstack having >> connected to it, on FreeBSD. If need be I can try debugging it on >> another system.. >> >> >> (aside, philosophy: all text processing code should treat \n, \r, >> and \r\n in put the same, unless you are writing a terminal driver, >> then \r has a separate meaning useful for implementing spinners..) >> >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Tue, 28 Apr 2009 11:40:00 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: RE: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> Quoting Jay : >>> >>>> >>>> Well, on FreeBSD 7.0, I get as far as: >>>> >>>> ew source -> compiling EnvUtils.i3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> ew source -> compiling EnvUtils.m3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> ew source -> compiling FingerprintFmt.i3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> ew source -> compiling TextUtils.i3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> >>>> Yeah, I understand, I have libc.so.7. >>> >>> You need to install the FreeBSD compat packages for backward >>> compatibility. Should work fine then (until cminstall hangs?). >>> >>> Olaf >>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>>>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>> terminating >>>>> >>>>> >>>>> I've never been able to get the tinderbox stuff to work for me. >>>>> I'll try again. >>>>> Nothing much from me lately -- pthreads movement to C, and then >>>>> back. >>>>> >>>>>>> Jay, did you change any config files recently? >>>>> >>>>> FreeBSD config file changes on 2009-04-13. >>>>> >>>>> - Jay >>>>> >>>>> ---------------------------------------- >>>>>> From: hosking at cs.purdue.edu >>>>>> To: wagner at elegosoft.com >>>>>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>>> terminating >>>>>> >>>>>> Yes, I had noticed this too. >>>>>> >>>>>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> does anybody know what's keeping the release-build tests for >>>>>>> tinderbox >>>>>>> from terminating? I've got lots of stalled regression process >>>>>>> trees on >>>>>>> my system, and the tinderbox display indicates that none of the >>>>>>> release >>>>>>> builds seem to succeed. Has anybody changed anything in the >>>>>>> scripts? >>>>>>> >>>>>>> On a closer look, upgrade seems to be stuck in the installer: >>>>>>> >>>>>>> % ps -axwww 25310 >>>>>>> PID TT STAT TIME COMMAND >>>>>>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>>>>>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>>>>>> luthien/current -o >>>>>>> >>>>>>> Jay, did you change any config files recently? >>>>>>> Regression tests seemed to have been running again for some >>>>>>> days, >>>>>>> and then >>>>>>> stopped again. >>>>>>> >>>>>>> I'll try to investigate further this evening, but must leave >>>>>>> now for >>>>>>> other work... >>>>>>> >>>>>>> Olaf >>>>>>> -- >>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>>>>> Germany >>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>>> 23 >>>>>>> 45 86 95 >>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>>>>> Berlin >>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>>> DE163214194 >>>>>>> >>>>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 28 13:17:29 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 11:17:29 +0000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> Message-ID: The changes went in two weeks ago 4/14, were they definitely working? I can try it again, hopefully without the full tinderbox stuff. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 28 Apr 2009 21:11:42 +1000 > CC: m3devel at elegosoft.com; manderson at elegosoft.com > Subject: Re: [M3devel] CM3 release build regression tests not terminating > > What could possibly have changed here. It used to work fine on > multiple platforms. > > On 28 Apr 2009, at 20:14, Jay wrote: > >> >> It creates a file named "df-k" and hangs here: >> >> (gdb) where >> #0 0x080f417f in select () >> #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, >> writefds=0x28127138, >> exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ >> FreeBSD4/select.c:13 >> #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, >> M3_CEtG8K_timeout=0xbfbfe6d8) >> at ThreadPosix.m3:714 >> #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 >> #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, >> M3_AicXUJ_alertable=0 '\0') >> at ThreadPosix.m3:555 >> #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at >> ThreadPosix.m3:539 >> #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at >> ProcessPosix.m3:294 >> #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at >> System.m3:527 >> #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, >> M3_EkfbeH_env=0x0, >> M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 >> #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at >> OSPOSIX.m3:19 >> #10 0x0804c31c in Main__DoIt () at Main.m3:122 >> #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 >> #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at >> RTLinker.m3:395 >> #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at >> RTLinker.m3:109 >> #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at >> RTLinker.m3:118 >> #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at >> _m3main.mc:4 >> >> Notice it using user threads, so old m3core/libm3. >> df doesn't appear to be any longer running. >> Why it prints about the backend mode, I don't know. >> >> (and yes, I get it -- df -k is directly related to GetDiskSpace..if >> this is how one checks diskspace on Unix...I think we should punt, >> unless posix actually specifies the precise output format of this >> command it is very reliably parsed...) >> >> - Jay >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com >>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: RE: [M3devel] CM3 release build regression tests not >>> terminating >>> Date: Tue, 28 Apr 2009 09:58:56 +0000 >>> >>> >>> Right, now it hangs having printed..I know this looks a bit of >>> nonsense..stuff from right around: >>> >>> >>> M3_BACKEND_MODE = "3" >>> % -- defines how the frontend, backend, and assembler interact >>> % "0" -- don't call m3_backend, M3CG produces object code >>> % "1" -- don't call m3_backend, M3CG produces assembly code >>> % "2" -- call m3_backend, it produces object code >>> % "3" -- call m3_backend, it produces assembly code >>> >>> >>> however, this is noticably pretty close to the last BEGIN_CONFIG. >>> >>> Maybe the carriage returns confused it. I'll see.. >>> I did introduce them recently by accident. >>> gdb reported some errors and no symbols in the callstack having >>> connected to it, on FreeBSD. If need be I can try debugging it on >>> another system.. >>> >>> >>> (aside, philosophy: all text processing code should treat \n, \r, >>> and \r\n in put the same, unless you are writing a terminal driver, >>> then \r has a separate meaning useful for implementing spinners..) >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> Date: Tue, 28 Apr 2009 11:40:00 +0200 >>>> From: wagner at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>>> Subject: RE: [M3devel] CM3 release build regression tests not >>>> terminating >>>> >>>> Quoting Jay : >>>> >>>>> >>>>> Well, on FreeBSD 7.0, I get as far as: >>>>> >>>>> ew source -> compiling EnvUtils.i3 >>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>> required by "cm3cg" >>>>> ew source -> compiling EnvUtils.m3 >>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>> required by "cm3cg" >>>>> ew source -> compiling FingerprintFmt.i3 >>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>> required by "cm3cg" >>>>> ew source -> compiling TextUtils.i3 >>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>> required by "cm3cg" >>>>> >>>>> Yeah, I understand, I have libc.so.7. >>>> >>>> You need to install the FreeBSD compat packages for backward >>>> compatibility. Should work fine then (until cminstall hangs?). >>>> >>>> Olaf >>>> >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>>>>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>>> terminating >>>>>> >>>>>> >>>>>> I've never been able to get the tinderbox stuff to work for me. >>>>>> I'll try again. >>>>>> Nothing much from me lately -- pthreads movement to C, and then >>>>>> back. >>>>>> >>>>>>>> Jay, did you change any config files recently? >>>>>> >>>>>> FreeBSD config file changes on 2009-04-13. >>>>>> >>>>>> - Jay >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: hosking at cs.purdue.edu >>>>>>> To: wagner at elegosoft.com >>>>>>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>>>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>>>> terminating >>>>>>> >>>>>>> Yes, I had noticed this too. >>>>>>> >>>>>>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> does anybody know what's keeping the release-build tests for >>>>>>>> tinderbox >>>>>>>> from terminating? I've got lots of stalled regression process >>>>>>>> trees on >>>>>>>> my system, and the tinderbox display indicates that none of the >>>>>>>> release >>>>>>>> builds seem to succeed. Has anybody changed anything in the >>>>>>>> scripts? >>>>>>>> >>>>>>>> On a closer look, upgrade seems to be stuck in the installer: >>>>>>>> >>>>>>>> % ps -axwww 25310 >>>>>>>> PID TT STAT TIME COMMAND >>>>>>>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>>>>>>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>>>>>>> luthien/current -o >>>>>>>> >>>>>>>> Jay, did you change any config files recently? >>>>>>>> Regression tests seemed to have been running again for some >>>>>>>> days, >>>>>>>> and then >>>>>>>> stopped again. >>>>>>>> >>>>>>>> I'll try to investigate further this evening, but must leave >>>>>>>> now for >>>>>>>> other work... >>>>>>>> >>>>>>>> Olaf >>>>>>>> -- >>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>>>>>> Germany >>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>>>> 23 >>>>>>>> 45 86 95 >>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>>>>>> Berlin >>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>>>> DE163214194 >>>>>>>> >>>>>>> >>>> >>>> >>>> >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 28 13:43:40 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 11:43:40 +0000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> Message-ID: Just a reminder, I THINK the hang is almost entirely in a 5.4 system. At least it is in m3core 5.4. And current sysutils/cminstall. And probably 5.4 cm3cg but I don't know for certain yet. Look at the stack below. Do we really care? I haven't tested if it hangs against current compiler/runtime. Here is a suggestion -- ok, bootstrapping from 5.4 is reasonable -- build the compiler -- but must tinderbox include running cminstall build against 5.4? I could be wrong, misobserving, whatever. I can go and fix user threads and see if cminstall hangs with that -- there is an issue of being inefficient wrt waitpid(nohang vs. 0). It is very easy to reproduce. Install 5.4 (which tinderbox does). Do a normal bootstrap thing -- skip m3core, libm3, but otherwise build up to cminstall. And then gdb --args cminstall -dumpcfg wait a sec, control-c. I'm assuming, but haven't tested, that it works ok against current. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com; manderson at elegosoft.com > Subject: RE: [M3devel] CM3 release build regression tests not terminating > Date: Tue, 28 Apr 2009 11:17:29 +0000 > > > The changes went in two weeks ago 4/14, were they definitely working? > I can try it again, hopefully without the full tinderbox stuff. > > - Jay > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Tue, 28 Apr 2009 21:11:42 +1000 >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: Re: [M3devel] CM3 release build regression tests not terminating >> >> What could possibly have changed here. It used to work fine on >> multiple platforms. >> >> On 28 Apr 2009, at 20:14, Jay wrote: >> >>> >>> It creates a file named "df-k" and hangs here: >>> >>> (gdb) where >>> #0 0x080f417f in select () >>> #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, >>> writefds=0x28127138, >>> exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ >>> FreeBSD4/select.c:13 >>> #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, >>> M3_CEtG8K_timeout=0xbfbfe6d8) >>> at ThreadPosix.m3:714 >>> #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 >>> #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, >>> M3_AicXUJ_alertable=0 '\0') >>> at ThreadPosix.m3:555 >>> #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at >>> ThreadPosix.m3:539 >>> #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at >>> ProcessPosix.m3:294 >>> #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at >>> System.m3:527 >>> #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, >>> M3_EkfbeH_env=0x0, >>> M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 >>> #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at >>> OSPOSIX.m3:19 >>> #10 0x0804c31c in Main__DoIt () at Main.m3:122 >>> #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 >>> #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at >>> RTLinker.m3:395 >>> #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at >>> RTLinker.m3:109 >>> #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at >>> RTLinker.m3:118 >>> #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at >>> _m3main.mc:4 >>> >>> Notice it using user threads, so old m3core/libm3. >>> df doesn't appear to be any longer running. >>> Why it prints about the backend mode, I don't know. >>> >>> (and yes, I get it -- df -k is directly related to GetDiskSpace..if >>> this is how one checks diskspace on Unix...I think we should punt, >>> unless posix actually specifies the precise output format of this >>> command it is very reliably parsed...) >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: wagner at elegosoft.com >>>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>>> Subject: RE: [M3devel] CM3 release build regression tests not >>>> terminating >>>> Date: Tue, 28 Apr 2009 09:58:56 +0000 >>>> >>>> >>>> Right, now it hangs having printed..I know this looks a bit of >>>> nonsense..stuff from right around: >>>> >>>> >>>> M3_BACKEND_MODE = "3" >>>> % -- defines how the frontend, backend, and assembler interact >>>> % "0" -- don't call m3_backend, M3CG produces object code >>>> % "1" -- don't call m3_backend, M3CG produces assembly code >>>> % "2" -- call m3_backend, it produces object code >>>> % "3" -- call m3_backend, it produces assembly code >>>> >>>> >>>> however, this is noticably pretty close to the last BEGIN_CONFIG. >>>> >>>> Maybe the carriage returns confused it. I'll see.. >>>> I did introduce them recently by accident. >>>> gdb reported some errors and no symbols in the callstack having >>>> connected to it, on FreeBSD. If need be I can try debugging it on >>>> another system.. >>>> >>>> >>>> (aside, philosophy: all text processing code should treat \n, \r, >>>> and \r\n in put the same, unless you are writing a terminal driver, >>>> then \r has a separate meaning useful for implementing spinners..) >>>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> Date: Tue, 28 Apr 2009 11:40:00 +0200 >>>>> From: wagner at elegosoft.com >>>>> To: jay.krell at cornell.edu >>>>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>>>> Subject: RE: [M3devel] CM3 release build regression tests not >>>>> terminating >>>>> >>>>> Quoting Jay : >>>>> >>>>>> >>>>>> Well, on FreeBSD 7.0, I get as far as: >>>>>> >>>>>> ew source -> compiling EnvUtils.i3 >>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>> required by "cm3cg" >>>>>> ew source -> compiling EnvUtils.m3 >>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>> required by "cm3cg" >>>>>> ew source -> compiling FingerprintFmt.i3 >>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>> required by "cm3cg" >>>>>> ew source -> compiling TextUtils.i3 >>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>> required by "cm3cg" >>>>>> >>>>>> Yeah, I understand, I have libc.so.7. >>>>> >>>>> You need to install the FreeBSD compat packages for backward >>>>> compatibility. Should work fine then (until cminstall hangs?). >>>>> >>>>> Olaf >>>>> >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>>>>>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>>>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>>>> terminating >>>>>>> >>>>>>> >>>>>>> I've never been able to get the tinderbox stuff to work for me. >>>>>>> I'll try again. >>>>>>> Nothing much from me lately -- pthreads movement to C, and then >>>>>>> back. >>>>>>> >>>>>>>>> Jay, did you change any config files recently? >>>>>>> >>>>>>> FreeBSD config file changes on 2009-04-13. >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: hosking at cs.purdue.edu >>>>>>>> To: wagner at elegosoft.com >>>>>>>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>>>>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>>>>> terminating >>>>>>>> >>>>>>>> Yes, I had noticed this too. >>>>>>>> >>>>>>>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> does anybody know what's keeping the release-build tests for >>>>>>>>> tinderbox >>>>>>>>> from terminating? I've got lots of stalled regression process >>>>>>>>> trees on >>>>>>>>> my system, and the tinderbox display indicates that none of the >>>>>>>>> release >>>>>>>>> builds seem to succeed. Has anybody changed anything in the >>>>>>>>> scripts? >>>>>>>>> >>>>>>>>> On a closer look, upgrade seems to be stuck in the installer: >>>>>>>>> >>>>>>>>> % ps -axwww 25310 >>>>>>>>> PID TT STAT TIME COMMAND >>>>>>>>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>>>>>>>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>>>>>>>> luthien/current -o >>>>>>>>> >>>>>>>>> Jay, did you change any config files recently? >>>>>>>>> Regression tests seemed to have been running again for some >>>>>>>>> days, >>>>>>>>> and then >>>>>>>>> stopped again. >>>>>>>>> >>>>>>>>> I'll try to investigate further this evening, but must leave >>>>>>>>> now for >>>>>>>>> other work... >>>>>>>>> >>>>>>>>> Olaf >>>>>>>>> -- >>>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>>>>>>> Germany >>>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>>>>> 23 >>>>>>>>> 45 86 95 >>>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>>>>>>> Berlin >>>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>>>>> DE163214194 >>>>>>>>> >>>>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 28 13:45:43 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 11:45:43 +0000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> Message-ID: once you control-c in gdb it completes with an error the df-k file is zero length.. I can poke more... but I doubt we care about the 5.4 mix.. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Tue, 28 Apr 2009 11:43:40 +0000 > CC: m3devel at elegosoft.com; manderson at elegosoft.com > Subject: Re: [M3devel] CM3 release build regression tests not terminating > > > Just a reminder, I THINK the hang is almost entirely in a 5.4 system. > At least it is in m3core 5.4. > And current sysutils/cminstall. > And probably 5.4 cm3cg but I don't know for certain yet. > Look at the stack below. > Do we really care? > > > I haven't tested if it hangs against current compiler/runtime. > > > Here is a suggestion -- ok, bootstrapping from 5.4 is reasonable -- build the compiler -- but must tinderbox include running cminstall build against 5.4? > > > I could be wrong, misobserving, whatever. > I can go and fix user threads and see if cminstall hangs with that -- there is an issue of being inefficient wrt waitpid(nohang vs. 0). > > > It is very easy to reproduce. > Install 5.4 (which tinderbox does). > Do a normal bootstrap thing -- skip m3core, libm3, but otherwise build up to cminstall. And then gdb --args cminstall -dumpcfg wait a sec, control-c. > > I'm assuming, but haven't tested, that it works ok against current. > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: RE: [M3devel] CM3 release build regression tests not terminating >> Date: Tue, 28 Apr 2009 11:17:29 +0000 >> >> >> The changes went in two weeks ago 4/14, were they definitely working? >> I can try it again, hopefully without the full tinderbox stuff. >> >> - Jay >> >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Tue, 28 Apr 2009 21:11:42 +1000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>> >>> What could possibly have changed here. It used to work fine on >>> multiple platforms. >>> >>> On 28 Apr 2009, at 20:14, Jay wrote: >>> >>>> >>>> It creates a file named "df-k" and hangs here: >>>> >>>> (gdb) where >>>> #0 0x080f417f in select () >>>> #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, >>>> writefds=0x28127138, >>>> exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ >>>> FreeBSD4/select.c:13 >>>> #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, >>>> M3_CEtG8K_timeout=0xbfbfe6d8) >>>> at ThreadPosix.m3:714 >>>> #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 >>>> #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, >>>> M3_AicXUJ_alertable=0 '\0') >>>> at ThreadPosix.m3:555 >>>> #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at >>>> ThreadPosix.m3:539 >>>> #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at >>>> ProcessPosix.m3:294 >>>> #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at >>>> System.m3:527 >>>> #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, >>>> M3_EkfbeH_env=0x0, >>>> M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 >>>> #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at >>>> OSPOSIX.m3:19 >>>> #10 0x0804c31c in Main__DoIt () at Main.m3:122 >>>> #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 >>>> #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at >>>> RTLinker.m3:395 >>>> #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at >>>> RTLinker.m3:109 >>>> #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at >>>> RTLinker.m3:118 >>>> #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at >>>> _m3main.mc:4 >>>> >>>> Notice it using user threads, so old m3core/libm3. >>>> df doesn't appear to be any longer running. >>>> Why it prints about the backend mode, I don't know. >>>> >>>> (and yes, I get it -- df -k is directly related to GetDiskSpace..if >>>> this is how one checks diskspace on Unix...I think we should punt, >>>> unless posix actually specifies the precise output format of this >>>> command it is very reliably parsed...) >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: wagner at elegosoft.com >>>>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>>>> Subject: RE: [M3devel] CM3 release build regression tests not >>>>> terminating >>>>> Date: Tue, 28 Apr 2009 09:58:56 +0000 >>>>> >>>>> >>>>> Right, now it hangs having printed..I know this looks a bit of >>>>> nonsense..stuff from right around: >>>>> >>>>> >>>>> M3_BACKEND_MODE = "3" >>>>> % -- defines how the frontend, backend, and assembler interact >>>>> % "0" -- don't call m3_backend, M3CG produces object code >>>>> % "1" -- don't call m3_backend, M3CG produces assembly code >>>>> % "2" -- call m3_backend, it produces object code >>>>> % "3" -- call m3_backend, it produces assembly code >>>>> >>>>> >>>>> however, this is noticably pretty close to the last BEGIN_CONFIG. >>>>> >>>>> Maybe the carriage returns confused it. I'll see.. >>>>> I did introduce them recently by accident. >>>>> gdb reported some errors and no symbols in the callstack having >>>>> connected to it, on FreeBSD. If need be I can try debugging it on >>>>> another system.. >>>>> >>>>> >>>>> (aside, philosophy: all text processing code should treat \n, \r, >>>>> and \r\n in put the same, unless you are writing a terminal driver, >>>>> then \r has a separate meaning useful for implementing spinners..) >>>>> >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ---------------------------------------- >>>>>> Date: Tue, 28 Apr 2009 11:40:00 +0200 >>>>>> From: wagner at elegosoft.com >>>>>> To: jay.krell at cornell.edu >>>>>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>>>>> Subject: RE: [M3devel] CM3 release build regression tests not >>>>>> terminating >>>>>> >>>>>> Quoting Jay : >>>>>> >>>>>>> >>>>>>> Well, on FreeBSD 7.0, I get as far as: >>>>>>> >>>>>>> ew source -> compiling EnvUtils.i3 >>>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>>> required by "cm3cg" >>>>>>> ew source -> compiling EnvUtils.m3 >>>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>>> required by "cm3cg" >>>>>>> ew source -> compiling FingerprintFmt.i3 >>>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>>> required by "cm3cg" >>>>>>> ew source -> compiling TextUtils.i3 >>>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>>> required by "cm3cg" >>>>>>> >>>>>>> Yeah, I understand, I have libc.so.7. >>>>>> >>>>>> You need to install the FreeBSD compat packages for backward >>>>>> compatibility. Should work fine then (until cminstall hangs?). >>>>>> >>>>>> Olaf >>>>>> >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: jay.krell at cornell.edu >>>>>>>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>>>>>>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>>>>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>>>>> terminating >>>>>>>> >>>>>>>> >>>>>>>> I've never been able to get the tinderbox stuff to work for me. >>>>>>>> I'll try again. >>>>>>>> Nothing much from me lately -- pthreads movement to C, and then >>>>>>>> back. >>>>>>>> >>>>>>>>>> Jay, did you change any config files recently? >>>>>>>> >>>>>>>> FreeBSD config file changes on 2009-04-13. >>>>>>>> >>>>>>>> - Jay >>>>>>>> >>>>>>>> ---------------------------------------- >>>>>>>>> From: hosking at cs.purdue.edu >>>>>>>>> To: wagner at elegosoft.com >>>>>>>>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>>>>>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>>>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>>>>>> terminating >>>>>>>>> >>>>>>>>> Yes, I had noticed this too. >>>>>>>>> >>>>>>>>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> does anybody know what's keeping the release-build tests for >>>>>>>>>> tinderbox >>>>>>>>>> from terminating? I've got lots of stalled regression process >>>>>>>>>> trees on >>>>>>>>>> my system, and the tinderbox display indicates that none of the >>>>>>>>>> release >>>>>>>>>> builds seem to succeed. Has anybody changed anything in the >>>>>>>>>> scripts? >>>>>>>>>> >>>>>>>>>> On a closer look, upgrade seems to be stuck in the installer: >>>>>>>>>> >>>>>>>>>> % ps -axwww 25310 >>>>>>>>>> PID TT STAT TIME COMMAND >>>>>>>>>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>>>>>>>>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>>>>>>>>> luthien/current -o >>>>>>>>>> >>>>>>>>>> Jay, did you change any config files recently? >>>>>>>>>> Regression tests seemed to have been running again for some >>>>>>>>>> days, >>>>>>>>>> and then >>>>>>>>>> stopped again. >>>>>>>>>> >>>>>>>>>> I'll try to investigate further this evening, but must leave >>>>>>>>>> now for >>>>>>>>>> other work... >>>>>>>>>> >>>>>>>>>> Olaf >>>>>>>>>> -- >>>>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>>>>>>>> Germany >>>>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>>>>>> 23 >>>>>>>>>> 45 86 95 >>>>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>>>>>>>> Berlin >>>>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>>>>>> DE163214194 >>>>>>>>>> >>>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 28 13:49:32 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 28 Apr 2009 21:49:32 +1000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> Message-ID: <9AC96562-7045-418A-A069-84EE8613498A@cs.purdue.edu> Sounds about right. 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 28 Apr 2009, at 21:17, Jay wrote: > > The changes went in two weeks ago 4/14, were they definitely working? > I can try it again, hopefully without the full tinderbox stuff. > > - Jay > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Tue, 28 Apr 2009 21:11:42 +1000 >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: Re: [M3devel] CM3 release build regression tests not >> terminating >> >> What could possibly have changed here. It used to work fine on >> multiple platforms. >> >> On 28 Apr 2009, at 20:14, Jay wrote: >> >>> >>> It creates a file named "df-k" and hangs here: >>> >>> (gdb) where >>> #0 0x080f417f in select () >>> #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, >>> writefds=0x28127138, >>> exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ >>> FreeBSD4/select.c:13 >>> #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, >>> M3_CEtG8K_timeout=0xbfbfe6d8) >>> at ThreadPosix.m3:714 >>> #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 >>> #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, >>> M3_AicXUJ_alertable=0 '\0') >>> at ThreadPosix.m3:555 >>> #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at >>> ThreadPosix.m3:539 >>> #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at >>> ProcessPosix.m3:294 >>> #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at >>> System.m3:527 >>> #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, >>> M3_EkfbeH_env=0x0, >>> M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 >>> #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at >>> OSPOSIX.m3:19 >>> #10 0x0804c31c in Main__DoIt () at Main.m3:122 >>> #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 >>> #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at >>> RTLinker.m3:395 >>> #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at >>> RTLinker.m3:109 >>> #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at >>> RTLinker.m3:118 >>> #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at >>> _m3main.mc:4 >>> >>> Notice it using user threads, so old m3core/libm3. >>> df doesn't appear to be any longer running. >>> Why it prints about the backend mode, I don't know. >>> >>> (and yes, I get it -- df -k is directly related to GetDiskSpace..if >>> this is how one checks diskspace on Unix...I think we should punt, >>> unless posix actually specifies the precise output format of this >>> command it is very reliably parsed...) >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: wagner at elegosoft.com >>>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>>> Subject: RE: [M3devel] CM3 release build regression tests not >>>> terminating >>>> Date: Tue, 28 Apr 2009 09:58:56 +0000 >>>> >>>> >>>> Right, now it hangs having printed..I know this looks a bit of >>>> nonsense..stuff from right around: >>>> >>>> >>>> M3_BACKEND_MODE = "3" >>>> % -- defines how the frontend, backend, and assembler interact >>>> % "0" -- don't call m3_backend, M3CG produces object code >>>> % "1" -- don't call m3_backend, M3CG produces assembly code >>>> % "2" -- call m3_backend, it produces object code >>>> % "3" -- call m3_backend, it produces assembly code >>>> >>>> >>>> however, this is noticably pretty close to the last BEGIN_CONFIG. >>>> >>>> Maybe the carriage returns confused it. I'll see.. >>>> I did introduce them recently by accident. >>>> gdb reported some errors and no symbols in the callstack having >>>> connected to it, on FreeBSD. If need be I can try debugging it on >>>> another system.. >>>> >>>> >>>> (aside, philosophy: all text processing code should treat \n, \r, >>>> and \r\n in put the same, unless you are writing a terminal driver, >>>> then \r has a separate meaning useful for implementing spinners..) >>>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> Date: Tue, 28 Apr 2009 11:40:00 +0200 >>>>> From: wagner at elegosoft.com >>>>> To: jay.krell at cornell.edu >>>>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>>>> Subject: RE: [M3devel] CM3 release build regression tests not >>>>> terminating >>>>> >>>>> Quoting Jay : >>>>> >>>>>> >>>>>> Well, on FreeBSD 7.0, I get as far as: >>>>>> >>>>>> ew source -> compiling EnvUtils.i3 >>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>> required by "cm3cg" >>>>>> ew source -> compiling EnvUtils.m3 >>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>> required by "cm3cg" >>>>>> ew source -> compiling FingerprintFmt.i3 >>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>> required by "cm3cg" >>>>>> ew source -> compiling TextUtils.i3 >>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>> required by "cm3cg" >>>>>> >>>>>> Yeah, I understand, I have libc.so.7. >>>>> >>>>> You need to install the FreeBSD compat packages for backward >>>>> compatibility. Should work fine then (until cminstall hangs?). >>>>> >>>>> Olaf >>>>> >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>>>>>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>>>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>>>> terminating >>>>>>> >>>>>>> >>>>>>> I've never been able to get the tinderbox stuff to work for me. >>>>>>> I'll try again. >>>>>>> Nothing much from me lately -- pthreads movement to C, and then >>>>>>> back. >>>>>>> >>>>>>>>> Jay, did you change any config files recently? >>>>>>> >>>>>>> FreeBSD config file changes on 2009-04-13. >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: hosking at cs.purdue.edu >>>>>>>> To: wagner at elegosoft.com >>>>>>>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>>>>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>>>>> terminating >>>>>>>> >>>>>>>> Yes, I had noticed this too. >>>>>>>> >>>>>>>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> does anybody know what's keeping the release-build tests for >>>>>>>>> tinderbox >>>>>>>>> from terminating? I've got lots of stalled regression process >>>>>>>>> trees on >>>>>>>>> my system, and the tinderbox display indicates that none of >>>>>>>>> the >>>>>>>>> release >>>>>>>>> builds seem to succeed. Has anybody changed anything in the >>>>>>>>> scripts? >>>>>>>>> >>>>>>>>> On a closer look, upgrade seems to be stuck in the installer: >>>>>>>>> >>>>>>>>> % ps -axwww 25310 >>>>>>>>> PID TT STAT TIME COMMAND >>>>>>>>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>>>>>>>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3- >>>>>>>>> inst/ >>>>>>>>> luthien/current -o >>>>>>>>> >>>>>>>>> Jay, did you change any config files recently? >>>>>>>>> Regression tests seemed to have been running again for some >>>>>>>>> days, >>>>>>>>> and then >>>>>>>>> stopped again. >>>>>>>>> >>>>>>>>> I'll try to investigate further this evening, but must leave >>>>>>>>> now for >>>>>>>>> other work... >>>>>>>>> >>>>>>>>> Olaf >>>>>>>>> -- >>>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>>>>>>> Germany >>>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>>>>> 23 >>>>>>>>> 45 86 95 >>>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | >>>>>>>>> Sitz: >>>>>>>>> Berlin >>>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt- >>>>>>>>> IdNr: >>>>>>>>> DE163214194 >>>>>>>>> >>>>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Apr 28 14:13:17 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 12:13:17 +0000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <9AC96562-7045-418A-A069-84EE8613498A@cs.purdue.edu> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> <9AC96562-7045-418A-A069-84EE8613498A@cs.purdue.edu> Message-ID: Tony can you clarify? Things stopped working two weeks ago? Or things were working until more recently? It seems like the select call never returns. Whatever is going on, it troubles debugging tools. gdb won't follow the children..which is probably ok, they aren't the problem. truss can't be control-c'ed, but can be killed. "info locals" in gdb often hangs and I have to pkill gdb. Not that info locals ever works well, but it usually doesn't hang gdb. I started putting in RTIO calls. WaitForAll's finishes one Wait call but then hangs on the next. I think we should not run cminstall against 5.4 runtime. Enable user threads as some related scenario.. - Jay ________________________________ > CC: m3devel at elegosoft.com; manderson at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] CM3 release build regression tests not terminating > Date: Tue, 28 Apr 2009 21:49:32 +1000 > > Sounds about right. > > 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 28 Apr 2009, at 21:17, Jay wrote: > > > The changes went in two weeks ago 4/14, were they definitely working? > I can try it again, hopefully without the full tinderbox stuff. > > - Jay > > > ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 28 Apr 2009 21:11:42 +1000 > CC: m3devel at elegosoft.com; manderson at elegosoft.com > Subject: Re: [M3devel] CM3 release build regression tests not terminating > > What could possibly have changed here. It used to work fine on > multiple platforms. > > On 28 Apr 2009, at 20:14, Jay wrote: > > > It creates a file named "df-k" and hangs here: > > (gdb) where > #0 0x080f417f in select () > #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, > writefds=0x28127138, > exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ > FreeBSD4/select.c:13 > #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, > M3_CEtG8K_timeout=0xbfbfe6d8) > at ThreadPosix.m3:714 > #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 > #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, > M3_AicXUJ_alertable=0 '\0') > at ThreadPosix.m3:555 > #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at > ThreadPosix.m3:539 > #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at > ProcessPosix.m3:294 > #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at > System.m3:527 > #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, > M3_EkfbeH_env=0x0, > M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 > #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at > OSPOSIX.m3:19 > #10 0x0804c31c in Main__DoIt () at Main.m3:122 > #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 > #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at > RTLinker.m3:395 > #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at > RTLinker.m3:109 > #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at > RTLinker.m3:118 > #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at > _m3main.mc:4 > > Notice it using user threads, so old m3core/libm3. > df doesn't appear to be any longer running. > Why it prints about the backend mode, I don't know. > > (and yes, I get it -- df -k is directly related to GetDiskSpace..if > this is how one checks diskspace on Unix...I think we should punt, > unless posix actually specifies the precise output format of this > command it is very reliably parsed...) > > - Jay > > > ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com > Subject: RE: [M3devel] CM3 release build regression tests not > terminating > Date: Tue, 28 Apr 2009 09:58:56 +0000 > > > Right, now it hangs having printed..I know this looks a bit of > nonsense..stuff from right around: > > > M3_BACKEND_MODE = "3" > % -- defines how the frontend, backend, and assembler interact > % "0" -- don't call m3_backend, M3CG produces object code > % "1" -- don't call m3_backend, M3CG produces assembly code > % "2" -- call m3_backend, it produces object code > % "3" -- call m3_backend, it produces assembly code > > > however, this is noticably pretty close to the last BEGIN_CONFIG. > > Maybe the carriage returns confused it. I'll see.. > I did introduce them recently by accident. > gdb reported some errors and no symbols in the callstack having > connected to it, on FreeBSD. If need be I can try debugging it on > another system.. > > > (aside, philosophy: all text processing code should treat \n, \r, > and \r\n in put the same, unless you are writing a terminal driver, > then \r has a separate meaning useful for implementing spinners..) > > > - Jay > > > ---------------------------------------- > Date: Tue, 28 Apr 2009 11:40:00 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com > Subject: RE: [M3devel] CM3 release build regression tests not > terminating > > Quoting Jay : > > > Well, on FreeBSD 7.0, I get as far as: > > ew source -> compiling EnvUtils.i3 > libexec/ld-elf.so.1: Shared object "libc.so.6" not found, > required by "cm3cg" > ew source -> compiling EnvUtils.m3 > libexec/ld-elf.so.1: Shared object "libc.so.6" not found, > required by "cm3cg" > ew source -> compiling FingerprintFmt.i3 > libexec/ld-elf.so.1: Shared object "libc.so.6" not found, > required by "cm3cg" > ew source -> compiling TextUtils.i3 > libexec/ld-elf.so.1: Shared object "libc.so.6" not found, > required by "cm3cg" > > Yeah, I understand, I have libc.so.7. > > You need to install the FreeBSD compat packages for backward > compatibility. Should work fine then (until cminstall hangs?). > > Olaf > > > - Jay > > > ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; wagner at elegosoft.com > Date: Tue, 28 Apr 2009 07:45:14 +0000 > CC: m3devel at elegosoft.com; manderson at elegosoft.com > Subject: Re: [M3devel] CM3 release build regression tests not > terminating > > > I've never been able to get the tinderbox stuff to work for me. > I'll try again. > Nothing much from me lately -- pthreads movement to C, and then > back. > > Jay, did you change any config files recently? > > FreeBSD config file changes on 2009-04-13. > > - Jay > > ---------------------------------------- > From: hosking at cs.purdue.edu > To: wagner at elegosoft.com > Date: Tue, 28 Apr 2009 16:45:29 +1000 > CC: m3devel at elegosoft.com; manderson at elegosoft.com > Subject: Re: [M3devel] CM3 release build regression tests not > terminating > > Yes, I had noticed this too. > > On 28 Apr 2009, at 16:29, Olaf Wagner wrote: > > Hi, > > does anybody know what's keeping the release-build tests for > tinderbox > from terminating? I've got lots of stalled regression process > trees on > my system, and the tinderbox display indicates that none of the > release > builds seem to succeed. Has anybody changed anything in the > scripts? > > On a closer look, upgrade seems to be stuck in the installer: > > % ps -axwww 25310 > PID TT STAT TIME COMMAND > 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ > pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ > luthien/current -o > > Jay, did you change any config files recently? > Regression tests seemed to have been running again for some > days, > and then > stopped again. > > I'll try to investigate further this evening, but must leave > now for > other work... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 > 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > > From vapier at gentoo.org Tue Apr 28 15:00:26 2009 From: vapier at gentoo.org (Mike Frysinger) Date: Tue, 28 Apr 2009 09:00:26 -0400 Subject: [M3devel] how to find dependent .so files? In-Reply-To: References: Message-ID: <200904280900.27606.vapier@gentoo.org> On Tuesday 28 April 2009 04:03:13 Jay wrote: > Normally we have: > > /usr/local/cm3/bin/someexe > /usr/local/cm3/lib/libfoo.so symlink to ../pkg/foo/target/libfoo.so > /usr/local/cm3/lib/libbar.so symlink to ../pkg/bar/target/libbar.so > > Linking from someexe to $ORIGIN/../lib works, ok. > But from libfoo to libbar requires $ORIGIN/../../../lib. > or $ORIGIN/../../bar/target. what's wrong with just $ORIGIN ? they're in the same directory already. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From jay.krell at cornell.edu Tue Apr 28 15:15:06 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 13:15:06 +0000 Subject: [M3devel] how to find dependent .so files? In-Reply-To: <200904280900.27606.vapier@gentoo.org> References: <200904280900.27606.vapier@gentoo.org> Message-ID: If you take one of my suggestions, then yes you can do that for .sos. But $ORIGIN/../lib is one generic perhaps inefficient runpath for .sos and executables, and hypothetically also for non-public shipped executables (with my suggestion that they go to lib, if they don't already), that's why. The next step is just to smush lib and bin together, as is done on NT386. Probably people won't like that, keep files out of $PATH. I don't believe $ORIGIN works asis. if /cm3/lib/libfoo.so symlinks to /cm3/pkg/foo/target/libfoo.so then $ORIGIN is /cm3/pkg/foo/target, not /cm3/lib. I'd like to be wrong here but I don't think I am. So reversing the symlinks or making them hardlinks is ok? - Jay ---------------------------------------- > From: vapier at gentoo.org > To: m3devel at elegosoft.com > Date: Tue, 28 Apr 2009 09:00:26 -0400 > CC: jay.krell at cornell.edu > Subject: Re: [M3devel] how to find dependent .so files? > > On Tuesday 28 April 2009 04:03:13 Jay wrote: >> Normally we have: >> >> /usr/local/cm3/bin/someexe >> /usr/local/cm3/lib/libfoo.so symlink to ../pkg/foo/target/libfoo.so >> /usr/local/cm3/lib/libbar.so symlink to ../pkg/bar/target/libbar.so >> >> Linking from someexe to $ORIGIN/../lib works, ok. >> But from libfoo to libbar requires $ORIGIN/../../../lib. >> or $ORIGIN/../../bar/target. > > what's wrong with just $ORIGIN ? they're in the same directory already. > -mike From jay.krell at cornell.edu Tue Apr 28 16:15:50 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 14:15:50 +0000 Subject: [M3devel] manual initialization order? Message-ID: Um, if initializers are so acceptable (I'm skeptical, but everyone here disagrees with me..) and circularities are not allowed (that helps I guess..but is it really true? the garbage collector uses threads, the threading library allocates traced references..I sense circularity...)...why does RTLinker manually pick an initialization order? This is fragile. (* initialize the rest of the modules we'll be calling *) AddUnit (RTLinkerX.RTLinker_I3); (* myself! *) AddUnit (RTLinkerX.RT0_I3); AddUnit (RTLinkerX.RTSignal_I3); AddUnit (RTLinkerX.RTParams_I3); AddUnit (RTLinkerX.RTDebug_I3); AddUnit (RTLinkerX.RTError_I3); AddUnit (RTLinkerX.RTHeapRep_I3); AddUnit (RTLinkerX.ThreadF_I3); AddUnit (RTLinkerX.RTHeapInfo_I3); AddUnit (RTLinkerX.RTIO_I3); AddUnit (RTLinkerX.RTCollectorSRC_I3); AddUnit (RTLinkerX.Word_I3); (* finally, initialize the runtime. *) RTSignal.InstallHandlers (); RTParams.Init (); RTHeapRep.Init (); ThreadF.Init (); RTDebug.Init (); RTHeapInfo.Init (); IF RTParams.IsPresent("tracelinker") THEN traceInit := TRUE; END; AddUnit (RTLinkerX.RTDebug_M3); AddUnit (RTLinkerX.RTError_M3); AddUnit (RTLinkerX.RTType_M3); AddUnit (RTLinkerX.RTPacking_M3); AddUnit (RTLinkerX.RTTipe_M3); AddUnit (RTLinkerX.RTException_M3); From rcoleburn at scires.com Tue Apr 28 17:25:52 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 28 Apr 2009 11:25:52 -0400 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> Message-ID: <49F6E76E.1E75.00D7.1@scires.com> >>> Jay jay.krell at cornell.edu> 4/28/2009 5:58 AM >> ( mailto:jay.krell at cornell.edu> ) (aside, philosophy: all text processing code should treat \n, \r, and \r\n in put the same, unless you are writing a terminal driver, then \r has a separate meaning useful for implementing spinners..) - Jay That may be a nice philosophy, but we can't implement it because in practice not everybody adheres to it. I have written extensive text processing code that has to differentiate between these variants in order to properly interface with and interpret I/O from other systems. --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 mika at async.caltech.edu Tue Apr 28 17:36:44 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 28 Apr 2009 08:36:44 -0700 Subject: [M3devel] Text processing Message-ID: <200904281536.n3SFaiNs060605@camembert.async.caltech.edu> Speaking of text processing, I was very surprised at the bug I found in Wx the other day (and checked in a fix for). I'm 99% certain my fix is correct, but I'm very surprised no one found this bug before. Wx was inserting spurious nulls at the end of every generated TEXT. Is it possible someone is using this interface and depending on the buggy behavior? m3ide and m3browser import it. Mika From rcoleburn at scires.com Tue Apr 28 17:49:35 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 28 Apr 2009 11:49:35 -0400 Subject: [M3devel] Text processing In-Reply-To: <200904281536.n3SFaiNs060605@camembert.async.caltech.edu> References: <200904281536.n3SFaiNs060605@camembert.async.caltech.edu> Message-ID: <49F6ECFD.1E75.00D7.1@scires.com> There is a bug in CM3IDE that may be the result of this problem. I'll need to get your fix and try it. --Randy >>> Mika Nystrom 4/28/2009 11:36 AM >>> Speaking of text processing, I was very surprised at the bug I found in Wx the other day (and checked in a fix for). I'm 99% certain my fix is correct, but I'm very surprised no one found this bug before. Wx was inserting spurious nulls at the end of every generated TEXT. Is it possible someone is using this interface and depending on the buggy behavior? m3ide and m3browser import it. Mika 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 mika at async.caltech.edu Tue Apr 28 18:26:24 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 28 Apr 2009 09:26:24 -0700 Subject: [M3devel] Text processing In-Reply-To: Your message of "Tue, 28 Apr 2009 11:49:35 EDT." <49F6ECFD.1E75.00D7.1@scires.com> Message-ID: <200904281626.n3SGQO92063132@camembert.async.caltech.edu> Hmm cm3ide has its own Wx. It doesn't use that? It looks different from the standard one in cm3. In the *standard* one, that is, m3-libs/libbuf/src/Wx.m3, the fix is the following: PROCEDURE ToText (t: T): TEXT = VAR txt := Text8.Create(t.nFull * ChunkSize + t.next); c := t.head; n := 0; BEGIN There used to be a "+ 1" in the call to Text8.Create. It's crud from converting from the old array TEXTs. I've already checked this in to the cm3 distribution. Mika "Randy Coleburn" writes: >This is a MIME message. If you are reading this text, you may want to >consider changing to a mail reader or gateway that understands how to >properly handle MIME multipart messages. > >--=__Part6C44DF9F.0__= >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: quoted-printable > >There is a bug in CM3IDE that may be the result of this problem. I'll = >need to get your fix and try it. >--Randy > >>>> Mika Nystrom 4/28/2009 11:36 AM >>> > >Speaking of text processing, I was very surprised at the bug I found >in Wx the other day (and checked in a fix for). I'm 99% certain my >fix is correct, but I'm very surprised no one found this bug before. > >Wx was inserting spurious nulls at the end of every generated TEXT. > >Is it possible someone is using this interface and depending on the >buggy behavior? m3ide and m3browser import it. > > Mika > > >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. > > >--=__Part6C44DF9F.0__= >Content-Type: text/html; charset=US-ASCII >Content-Transfer-Encoding: quoted-printable >Content-Description: HTML > > >"> > > >
There is a bug in CM3IDE that may be the result of this problem. = > I'll need to get your fix and try it.
>
--Randy

>>> Mika Nystrom <mika at async.caltech.edu>= >; 4/28/2009 11:36 AM >>>

Speaking of text processing, I = >was very surprised at the bug I found
in Wx the other day (and checked = >in a fix for).  I'm 99% certain my
fix is correct, but I'm very = >surprised no one found this bug before.

Wx was inserting spurious = >nulls at the end of every generated TEXT.

Is it possible someone is = >using this interface and depending on the
buggy behavior?  m3ide = >and m3browser import it.

     Mika

= > > >--=__Part6C44DF9F.0__=-- From jay.krell at cornell.edu Tue Apr 28 18:30:11 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 16:30:11 +0000 Subject: [M3devel] Text processing In-Reply-To: <200904281626.n3SGQO92063132@camembert.async.caltech.edu> References: Your message of "Tue, 28 Apr 2009 11:49:35 EDT." <49F6ECFD.1E75.00D7.1@scires.com> <200904281626.n3SGQO92063132@camembert.async.caltech.edu> Message-ID: Are the nulls included in the length? If so, that'd be a likely bug. If not, it'd be a /possible/ feature. Seriously. I deal with "lengthed" strings a lot, but my "duplicate" and "concat" functions add them, and don't put them in the length, for interop with all the other code out there.. But it is a little sleazy my pattern and we do have explicit functions for C interop. - Jay ---------------------------------------- > To: rcoleburn at scires.com > Date: Tue, 28 Apr 2009 09:26:24 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Text processing > > Hmm cm3ide has its own Wx. It doesn't use that? It looks different > from the standard one in cm3. > > In the *standard* one, that is, m3-libs/libbuf/src/Wx.m3, > the fix is the following: > > PROCEDURE ToText (t: T): TEXT = > VAR txt := Text8.Create(t.nFull * ChunkSize + t.next); > c := t.head; n := 0; > BEGIN > > There used to be a "+ 1" in the call to Text8.Create. It's crud > from converting from the old array TEXTs. > > I've already checked this in to the cm3 distribution. > > Mika > > "Randy Coleburn" writes: >>This is a MIME message. If you are reading this text, you may want to >>consider changing to a mail reader or gateway that understands how to >>properly handle MIME multipart messages. >> >>--=__Part6C44DF9F.0__= >>Content-Type: text/plain; charset=US-ASCII >>Content-Transfer-Encoding: quoted-printable >> >>There is a bug in CM3IDE that may be the result of this problem. I'll = >>need to get your fix and try it. >>--Randy >> >>>>> Mika Nystrom 4/28/2009 11:36 AM>>> >> >>Speaking of text processing, I was very surprised at the bug I found >>in Wx the other day (and checked in a fix for). I'm 99% certain my >>fix is correct, but I'm very surprised no one found this bug before. >> >>Wx was inserting spurious nulls at the end of every generated TEXT. >> >>Is it possible someone is using this interface and depending on the >>buggy behavior? m3ide and m3browser import it. >> >> Mika >> >> >>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. >> >> >>--=__Part6C44DF9F.0__= >>Content-Type: text/html; charset=US-ASCII >>Content-Transfer-Encoding: quoted-printable >>Content-Description: HTML >> >> >>>>"> >> >> >> There is a bug in CM3IDE that may be the result of this problem. = >> I'll need to get your fix and try it. >> --Randy >>> Mika Nystrom = >>; 4/28/2009 11:36 AM>>> Speaking of text processing, I = >>was very surprised at the bug I found in Wx the other day (and checked = >>in a fix for). I'm 99% certain my fix is correct, but I'm very = >>surprised no one found this bug before. Wx was inserting spurious = >>nulls at the end of every generated TEXT. Is it possible someone is = >>using this interface and depending on the buggy behavior? m3ide = >>and m3browser import it. Mika = >> >> >>--=__Part6C44DF9F.0__=-- From jay.krell at cornell.edu Tue Apr 28 18:32:16 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 16:32:16 +0000 Subject: [M3devel] __thread? Message-ID: Mika, please let me know what this does for you, on the old FreeBSD 4.x? Probably it'll give some compiler errors, but if not, excellent. Our usess of pthread_get/setspecific should use __thread where it is available. Below is FreeBSD/i386 7.0. Nice and efficient (even better with -O2). Actually, "everyone", I'm interested in this. Probably we should do a little local autoconfery in the m3core m3makefile. If the below program compiles/links, use __thread, else pthread_get/setspecific. Another option is determine that it is widely supported and use #if or find out if there are specific #ifs associated with it. I know Cygwin doesn't support it. [jay at jkfbsd1 ~]$ cat 1.c #include __thread int a,b,c,d; int main() { printf("%p%p%p%p\n", &a,&b,&c,&d); return 0; } [jay at jkfbsd1 ~]$ gcc -S 1.c [jay at jkfbsd1 ~]$ cat 1.s .file "1.c" .section .rodata .LC0: .string "%p%p%p%p\n" .text .p2align 4,,15 .globl main .type main, @function main: leal 4(%esp), %ecx andl $-16, %esp pushl -4(%ecx) pushl %ebp movl %esp, %ebp pushl %ecx subl $20, %esp movl %gs:0, %eax leal d at NTPOFF(%eax), %eax movl %eax, 16(%esp) movl %gs:0, %eax leal c at NTPOFF(%eax), %eax movl %eax, 12(%esp) movl %gs:0, %eax leal b at NTPOFF(%eax), %eax movl %eax, 8(%esp) movl %gs:0, %eax leal a at NTPOFF(%eax), %eax movl %eax, 4(%esp) movl $.LC0, (%esp) call printf movl $0, %eax addl $20, %esp popl %ecx popl %ebp leal -4(%ecx), %esp ret .size main, .-main .globl a .section .tbss,"awT", at nobits ... - Jay From jay.krell at cornell.edu Tue Apr 28 18:38:09 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 16:38:09 +0000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <49F6E76E.1E75.00D7.1@scires.com> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <49F6E76E.1E75.00D7.1@scires.com> Message-ID: Randy just because everyone else does it poorly does not generally tie your hands. I said on input, not on output. Output does often tie your hands. Or do they actually have different meanings? That'd be wierd. The only useful semantic difference I've ever seen is that carriagereturn alone can be used to implement little spinnies. Otherwise, all three sequences have identical meaning. And various code out there does treat them identically, just not necessarily does one code treat them all the same, you have to at worst find three programs to find the same treatment. We /can/ implement it, anywhere we have text processing code. Reading quake files. I think it already does. It was just a red herring. Libraries that return "lines". You know, one common pattern is on Unix to split on \n and on NT to split on \r\n. Well, that means the same code deals in one format one platform, one on the other, and just acts wierdly when presented with the "wrong" format. There's no reason it can't just act platform independent and treat both formats always correctly. The compiler frontend must do this, based on experience and reasonable expectations. Most C compilers these days ditto. - Jay ________________________________ > Date: Tue, 28 Apr 2009 11:25:52 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 release build regression tests not terminating > > > > > > > >>>> Jay jay.krell at cornell.edu> 4/28/2009 5:58 AM>>%204/28/2009%205:58%20AM%20>>> > > (aside, philosophy: all text processing code should treat \n, \r, and \r\n in put the same, unless you are writing a terminal driver, then \r has a separate meaning useful for implementing spinners..) > - Jay > > That may be a nice philosophy, but we can't implement it because in practice not everybody adheres to it. I have written extensive text processing code that has to differentiate between these variants in order to properly interface with and interpret I/O from other systems. > > --Randy From jay.krell at cornell.edu Tue Apr 28 18:54:03 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 16:54:03 +0000 Subject: [M3devel] user threads Message-ID: User threads seem to work on on FreeBSD/x86 7.0. Mika can you report back the perf cm3 vs. pm3? Still, kernel threads have been around a long time and imho should be strongly favored.. Kernel threads should be a /little/ faster than they were -- PushEFrame removed from successful heap allocations. And should be further improvable via __thread where it is supported -- probably not FreeBSD 4.x, sometimes older is not better. :) I've temporarily switched FreeBSD/x86 to userthreads by default but I think that's just an experiment and should be undone shortly, maybe work out some other story for easily switching between them, or just keep the existing story of "you get to rebuild everything". Tony, can you look into GetGCRatio? I removed the call to it. The "fatal" pragma invokes PushEFrame apparently. We should now "fix" Win32 and pthreads to not have GetActivation initialize on-demand, just leave Init to initialize always. This should shave a few more cycles from PushEFrame. - Jay From mika at async.caltech.edu Tue Apr 28 18:55:00 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 28 Apr 2009 09:55:00 -0700 Subject: [M3devel] Text processing In-Reply-To: Your message of "Tue, 28 Apr 2009 16:30:11 -0000." Message-ID: <200904281655.n3SGt0iJ064555@camembert.async.caltech.edu> I think whenever Modula-3 TEXTs are represented as arrays (including *all* m3 TEXTs in SRC and P M3), there's a null at the end. It's not included in the "length of the string" but obviously it *is* included in the "length of the array". That's precisely the source of the bug. The old version allocates "length of string plus one", which is the wrong number to pass to the new interfaces (which don't expose the trailing zero, but keep it, just the same). Yes, the idea is you can pass Modula-3 TEXTs freely (cheaply) to C routines. Well, you used to be able to, before TEXTs were "improved" by Critical Mass. The code would have been something like this...? IMPORT TextF; VAR txt : TEXT; ... some_c_function(ADR(txt[0])) ... No I don't miss this feature much. There are other improvements that bug me a lot more. But this is all about to be fixed with the new Text implementation, right? :-) Mika Jay writes: > >Are the nulls included in the length? > >If so, that'd be a likely bug. If not, it'd be a /possible/ feature. Seriously >. >I deal with "lengthed" strings a lot, but my "duplicate" and "concat" function >s add them, and don't put them in the length, for interop with all the other c >ode out there.. >But it is a little sleazy my pattern and we do have explicit functions for C i >nterop. > > > - Jay > > >---------------------------------------- >> To: rcoleburn at scires.com >> Date: Tue, 28 Apr 2009 09:26:24 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Text processing >> >> Hmm cm3ide has its own Wx. It doesn't use that? It looks different >> from the standard one in cm3. >> >> In the *standard* one, that is, m3-libs/libbuf/src/Wx.m3, >> the fix is the following: >> >> PROCEDURE ToText (t: T): TEXT = >> VAR txt := Text8.Create(t.nFull * ChunkSize + t.next); >> c := t.head; n := 0; >> BEGIN >> >> There used to be a "+ 1" in the call to Text8.Create. It's crud >> from converting from the old array TEXTs. >> >> I've already checked this in to the cm3 distribution. >> >> Mika >> >> "Randy Coleburn" writes: >>>This is a MIME message. If you are reading this text, you may want to >>>consider changing to a mail reader or gateway that understands how to >>>properly handle MIME multipart messages. >>> >>>--=__Part6C44DF9F.0__= >>>Content-Type: text/plain; charset=US-ASCII >>>Content-Transfer-Encoding: quoted-printable >>> >>>There is a bug in CM3IDE that may be the result of this problem. I'll = >>>need to get your fix and try it. >>>--Randy >>> >>>>>> Mika Nystrom 4/28/2009 11:36 AM>>> >>> >>>Speaking of text processing, I was very surprised at the bug I found >>>in Wx the other day (and checked in a fix for). I'm 99% certain my >>>fix is correct, but I'm very surprised no one found this bug before. >>> >>>Wx was inserting spurious nulls at the end of every generated TEXT. >>> >>>Is it possible someone is using this interface and depending on the >>>buggy behavior? m3ide and m3browser import it. >>> >>> Mika >>> >>> >>>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. >>> >>> >>>--=__Part6C44DF9F.0__= >>>Content-Type: text/html; charset=US-ASCII >>>Content-Transfer-Encoding: quoted-printable >>>Content-Description: HTML >>> >>> >>>>>"> >>> > >>> >>> >There is a bug in CM3IDE that may be the result of this problem. = >>> I'll need to get your fix and try it. >>> >--Randy > >>>> Mika Nystrom = >>>; 4/28/2009 11:36 AM>>> > >Speaking of text processing, I = >>>was very surprised at the bug I found >in Wx the other day (and checked = >>>in a fix for). I'm 99% certain my >fix is correct, but I'm very = >>>surprised no one found this bug before. > >Wx was inserting spurious = >>>nulls at the end of every generated TEXT. > >Is it possible someone is = >>>using this interface and depending on the >buggy behavior? m3ide = >>>and m3browser import it. > > Mika > >= >>> >>> >>>--=__Part6C44DF9F.0__=-- From wagner at elegosoft.com Tue Apr 28 19:39:39 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 28 Apr 2009 19:39:39 +0200 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> <9AC96562-7045-418A-A069-84EE8613498A@cs.purdue.edu> Message-ID: <20090428193939.f037r1dkowg0ks4o@mail.elegosoft.com> Hi Jay, thanks for reverting the offending changes to the installer. I'm sure they were working OK when I tested them locally, and they looked innocent enough. Sigh. Perhaps not worth to pursue the installer issues further though. Have you found out why it hangs though? I haven't really understood the problem yet. Sorry for the disturbances, Olaf Quoting Jay : > Tony can you clarify? Things stopped working two weeks ago? > Or things were working until more recently? > > It seems like the select call never returns. > Whatever is going on, it troubles debugging tools. > gdb won't follow the children..which is probably ok, they aren't the problem. > truss can't be control-c'ed, but can be killed. > "info locals" in gdb often hangs and I have to pkill gdb. > Not that info locals ever works well, but it usually doesn't hang gdb. > I started putting in RTIO calls. > WaitForAll's finishes one Wait call but then hangs on the next. > > I think we should not run cminstall against 5.4 runtime. > Enable user threads as some related scenario.. > > > - Jay > > > ________________________________ >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Subject: Re: [M3devel] CM3 release build regression tests not terminating >> Date: Tue, 28 Apr 2009 21:49:32 +1000 >> >> Sounds about right. >> >> 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 28 Apr 2009, at 21:17, Jay wrote: >> >> >> The changes went in two weeks ago 4/14, were they definitely working? >> I can try it again, hopefully without the full tinderbox stuff. >> >> - Jay >> >> >> ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Tue, 28 Apr 2009 21:11:42 +1000 >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: Re: [M3devel] CM3 release build regression tests not terminating >> >> What could possibly have changed here. It used to work fine on >> multiple platforms. >> >> On 28 Apr 2009, at 20:14, Jay wrote: >> >> >> It creates a file named "df-k" and hangs here: >> >> (gdb) where >> #0 0x080f417f in select () >> #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, >> writefds=0x28127138, >> exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ >> FreeBSD4/select.c:13 >> #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, >> M3_CEtG8K_timeout=0xbfbfe6d8) >> at ThreadPosix.m3:714 >> #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 >> #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, >> M3_AicXUJ_alertable=0 '\0') >> at ThreadPosix.m3:555 >> #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at >> ThreadPosix.m3:539 >> #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at >> ProcessPosix.m3:294 >> #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at >> System.m3:527 >> #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, >> M3_EkfbeH_env=0x0, >> M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 >> #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at >> OSPOSIX.m3:19 >> #10 0x0804c31c in Main__DoIt () at Main.m3:122 >> #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 >> #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at >> RTLinker.m3:395 >> #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at >> RTLinker.m3:109 >> #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at >> RTLinker.m3:118 >> #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at >> _m3main.mc:4 >> >> Notice it using user threads, so old m3core/libm3. >> df doesn't appear to be any longer running. >> Why it prints about the backend mode, I don't know. >> >> (and yes, I get it -- df -k is directly related to GetDiskSpace..if >> this is how one checks diskspace on Unix...I think we should punt, >> unless posix actually specifies the precise output format of this >> command it is very reliably parsed...) >> >> - Jay >> >> >> ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: RE: [M3devel] CM3 release build regression tests not >> terminating >> Date: Tue, 28 Apr 2009 09:58:56 +0000 >> >> >> Right, now it hangs having printed..I know this looks a bit of >> nonsense..stuff from right around: >> >> >> M3_BACKEND_MODE = "3" >> % -- defines how the frontend, backend, and assembler interact >> % "0" -- don't call m3_backend, M3CG produces object code >> % "1" -- don't call m3_backend, M3CG produces assembly code >> % "2" -- call m3_backend, it produces object code >> % "3" -- call m3_backend, it produces assembly code >> >> >> however, this is noticably pretty close to the last BEGIN_CONFIG. >> >> Maybe the carriage returns confused it. I'll see.. >> I did introduce them recently by accident. >> gdb reported some errors and no symbols in the callstack having >> connected to it, on FreeBSD. If need be I can try debugging it on >> another system.. >> >> >> (aside, philosophy: all text processing code should treat \n, \r, >> and \r\n in put the same, unless you are writing a terminal driver, >> then \r has a separate meaning useful for implementing spinners..) >> >> >> - Jay >> >> >> ---------------------------------------- >> Date: Tue, 28 Apr 2009 11:40:00 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: RE: [M3devel] CM3 release build regression tests not >> terminating >> >> Quoting Jay : >> >> >> Well, on FreeBSD 7.0, I get as far as: >> >> ew source -> compiling EnvUtils.i3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >> required by "cm3cg" >> ew source -> compiling EnvUtils.m3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >> required by "cm3cg" >> ew source -> compiling FingerprintFmt.i3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >> required by "cm3cg" >> ew source -> compiling TextUtils.i3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >> required by "cm3cg" >> >> Yeah, I understand, I have libc.so.7. >> >> You need to install the FreeBSD compat packages for backward >> compatibility. Should work fine then (until cminstall hangs?). >> >> Olaf >> >> >> - Jay >> >> >> ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu; wagner at elegosoft.com >> Date: Tue, 28 Apr 2009 07:45:14 +0000 >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: Re: [M3devel] CM3 release build regression tests not >> terminating >> >> >> I've never been able to get the tinderbox stuff to work for me. >> I'll try again. >> Nothing much from me lately -- pthreads movement to C, and then >> back. >> >> Jay, did you change any config files recently? >> >> FreeBSD config file changes on 2009-04-13. >> >> - Jay >> >> ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: wagner at elegosoft.com >> Date: Tue, 28 Apr 2009 16:45:29 +1000 >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: Re: [M3devel] CM3 release build regression tests not >> terminating >> >> Yes, I had noticed this too. >> >> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >> >> Hi, >> >> does anybody know what's keeping the release-build tests for >> tinderbox >> from terminating? I've got lots of stalled regression process >> trees on >> my system, and the tinderbox display indicates that none of the >> release >> builds seem to succeed. Has anybody changed anything in the >> scripts? >> >> On a closer look, upgrade seems to be stuck in the installer: >> >> % ps -axwww 25310 >> PID TT STAT TIME COMMAND >> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >> luthien/current -o >> >> Jay, did you change any config files recently? >> Regression tests seemed to have been running again for some >> days, >> and then >> stopped again. >> >> I'll try to investigate further this evening, but must leave >> now for >> other work... >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >> Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >> 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> >> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 hendrik at topoi.pooq.com Tue Apr 28 19:59:17 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 28 Apr 2009 13:59:17 -0400 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <49F6E76E.1E75.00D7.1@scires.com> Message-ID: <20090428175916.GA9048@topoi.pooq.com> On Tue, Apr 28, 2009 at 04:38:09PM +0000, Jay wrote: > > Randy just because everyone else does it poorly does not generally tie your hands. > I said on input, not on output. > Output does often tie your hands. There are situations wheere you need to recognize multiple ways of representing newline without normalizing them. If you are writing an editor for text that is under revision control, and you standardize newlines on input, and then write it out in any consistent convention, you run the risk that revision control will think that huge numbers of lines have been changed. Of course, they have been, but not intentionally. -- hendrik From neels at elego.de Tue Apr 28 21:14:18 2009 From: neels at elego.de (Neels J Hofmeyr) Date: Tue, 28 Apr 2009 21:14:18 +0200 Subject: [M3devel] Modula-2 to Modula-3 translator by Aachen University In-Reply-To: <3d6568a70904252357u3c69dc3do136fcb2a27ffd9ea@mail.gmail.com> References: <3d6568a70904252354n2688dee9k3459399ab59b2495@mail.gmail.com> <3d6568a70904252357u3c69dc3do136fcb2a27ffd9ea@mail.gmail.com> Message-ID: <49F7558A.8060904@elego.de> Benjamin Kowarsch wrote: > Dear Sirs, > > I am trying to get the Modula-2 section in the Catalog of Compilers > updated and there is one entry of a Modula-2 to Modula-3 translator by > Peter Klein at University of Aachen for which all links and email > addresses seem to be dead. University of Aachen was unable to give me > any information either. > > I wonder if you know whether this translator is still availabe and if > so at which URL, or where his author Peter Klein can be contacted. > > thank you > regards > benjamin Sorry, don't know anything about it/him. Anyone else? ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From hosking at cs.purdue.edu Tue Apr 28 23:41:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 29 Apr 2009 07:41:19 +1000 Subject: [M3devel] manual initialization order? In-Reply-To: References: Message-ID: <557AEC0D-E50B-4A74-95B3-37AC2123878D@cs.purdue.edu> Indeed it is fragile, but necessary to bootstrap the system. On 29 Apr 2009, at 00:15, Jay wrote: > > Um, if initializers are so acceptable (I'm skeptical, but everyone > here disagrees with me..) and circularities are not allowed (that > helps I guess..but is it really true? the garbage collector uses > threads, the threading library allocates traced references..I sense > circularity...)...why does RTLinker manually pick an initialization > order? This is fragile. > > > (* initialize the rest of the modules we'll be calling *) > AddUnit (RTLinkerX.RTLinker_I3); (* myself! *) > AddUnit (RTLinkerX.RT0_I3); > AddUnit (RTLinkerX.RTSignal_I3); > AddUnit (RTLinkerX.RTParams_I3); > AddUnit (RTLinkerX.RTDebug_I3); > AddUnit (RTLinkerX.RTError_I3); > AddUnit (RTLinkerX.RTHeapRep_I3); > AddUnit (RTLinkerX.ThreadF_I3); > AddUnit (RTLinkerX.RTHeapInfo_I3); > AddUnit (RTLinkerX.RTIO_I3); > AddUnit (RTLinkerX.RTCollectorSRC_I3); > AddUnit (RTLinkerX.Word_I3); > > > > (* finally, initialize the runtime. *) > RTSignal.InstallHandlers (); > RTParams.Init (); > RTHeapRep.Init (); > ThreadF.Init (); > RTDebug.Init (); > RTHeapInfo.Init (); > IF RTParams.IsPresent("tracelinker") THEN > traceInit := TRUE; > END; > > > AddUnit (RTLinkerX.RTDebug_M3); > AddUnit (RTLinkerX.RTError_M3); > AddUnit (RTLinkerX.RTType_M3); > AddUnit (RTLinkerX.RTPacking_M3); > AddUnit (RTLinkerX.RTTipe_M3); > AddUnit (RTLinkerX.RTException_M3); From hosking at cs.purdue.edu Tue Apr 28 23:51:49 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 29 Apr 2009 07:51:49 +1000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> <9AC96562-7045-418A-A069-84EE8613498A@cs.purdue.edu> Message-ID: <2565931E-F3F3-4832-8582-C1D227B556DA@cs.purdue.edu> Whatever changed in the last 24 hours has my tinderbox runs completing now. On 28 Apr 2009, at 22:13, Jay wrote: > > Tony can you clarify? Things stopped working two weeks ago? > Or things were working until more recently? > > > > It seems like the select call never returns. > Whatever is going on, it troubles debugging tools. > gdb won't follow the children..which is probably ok, they aren't the > problem. > truss can't be control-c'ed, but can be killed. > "info locals" in gdb often hangs and I have to pkill gdb. > Not that info locals ever works well, but it usually doesn't hang gdb. > I started putting in RTIO calls. > WaitForAll's finishes one Wait call but then hangs on the next. > > > I think we should not run cminstall against 5.4 runtime. > Enable user threads as some related scenario.. > > > - Jay > > > ________________________________ >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Subject: Re: [M3devel] CM3 release build regression tests not >> terminating >> Date: Tue, 28 Apr 2009 21:49:32 +1000 >> >> Sounds about right. >> >> 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 28 Apr 2009, at 21:17, Jay wrote: >> >> >> The changes went in two weeks ago 4/14, were they definitely working? >> I can try it again, hopefully without the full tinderbox stuff. >> >> - Jay >> >> >> ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Tue, 28 Apr 2009 21:11:42 +1000 >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: Re: [M3devel] CM3 release build regression tests not >> terminating >> >> What could possibly have changed here. It used to work fine on >> multiple platforms. >> >> On 28 Apr 2009, at 20:14, Jay wrote: >> >> >> It creates a file named "df-k" and hangs here: >> >> (gdb) where >> #0 0x080f417f in select () >> #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, >> writefds=0x28127138, >> exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ >> FreeBSD4/select.c:13 >> #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, >> M3_CEtG8K_timeout=0xbfbfe6d8) >> at ThreadPosix.m3:714 >> #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 >> #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, >> M3_AicXUJ_alertable=0 '\0') >> at ThreadPosix.m3:555 >> #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at >> ThreadPosix.m3:539 >> #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at >> ProcessPosix.m3:294 >> #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at >> System.m3:527 >> #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, >> M3_EkfbeH_env=0x0, >> M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 >> #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at >> OSPOSIX.m3:19 >> #10 0x0804c31c in Main__DoIt () at Main.m3:122 >> #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 >> #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at >> RTLinker.m3:395 >> #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at >> RTLinker.m3:109 >> #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at >> RTLinker.m3:118 >> #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at >> _m3main.mc:4 >> >> Notice it using user threads, so old m3core/libm3. >> df doesn't appear to be any longer running. >> Why it prints about the backend mode, I don't know. >> >> (and yes, I get it -- df -k is directly related to GetDiskSpace..if >> this is how one checks diskspace on Unix...I think we should punt, >> unless posix actually specifies the precise output format of this >> command it is very reliably parsed...) >> >> - Jay >> >> >> ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: RE: [M3devel] CM3 release build regression tests not >> terminating >> Date: Tue, 28 Apr 2009 09:58:56 +0000 >> >> >> Right, now it hangs having printed..I know this looks a bit of >> nonsense..stuff from right around: >> >> >> M3_BACKEND_MODE = "3" >> % -- defines how the frontend, backend, and assembler interact >> % "0" -- don't call m3_backend, M3CG produces object code >> % "1" -- don't call m3_backend, M3CG produces assembly code >> % "2" -- call m3_backend, it produces object code >> % "3" -- call m3_backend, it produces assembly code >> >> >> however, this is noticably pretty close to the last BEGIN_CONFIG. >> >> Maybe the carriage returns confused it. I'll see.. >> I did introduce them recently by accident. >> gdb reported some errors and no symbols in the callstack having >> connected to it, on FreeBSD. If need be I can try debugging it on >> another system.. >> >> >> (aside, philosophy: all text processing code should treat \n, \r, >> and \r\n in put the same, unless you are writing a terminal driver, >> then \r has a separate meaning useful for implementing spinners..) >> >> >> - Jay >> >> >> ---------------------------------------- >> Date: Tue, 28 Apr 2009 11:40:00 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: RE: [M3devel] CM3 release build regression tests not >> terminating >> >> Quoting Jay : >> >> >> Well, on FreeBSD 7.0, I get as far as: >> >> ew source -> compiling EnvUtils.i3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >> required by "cm3cg" >> ew source -> compiling EnvUtils.m3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >> required by "cm3cg" >> ew source -> compiling FingerprintFmt.i3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >> required by "cm3cg" >> ew source -> compiling TextUtils.i3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >> required by "cm3cg" >> >> Yeah, I understand, I have libc.so.7. >> >> You need to install the FreeBSD compat packages for backward >> compatibility. Should work fine then (until cminstall hangs?). >> >> Olaf >> >> >> - Jay >> >> >> ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu; wagner at elegosoft.com >> Date: Tue, 28 Apr 2009 07:45:14 +0000 >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: Re: [M3devel] CM3 release build regression tests not >> terminating >> >> >> I've never been able to get the tinderbox stuff to work for me. >> I'll try again. >> Nothing much from me lately -- pthreads movement to C, and then >> back. >> >> Jay, did you change any config files recently? >> >> FreeBSD config file changes on 2009-04-13. >> >> - Jay >> >> ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: wagner at elegosoft.com >> Date: Tue, 28 Apr 2009 16:45:29 +1000 >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: Re: [M3devel] CM3 release build regression tests not >> terminating >> >> Yes, I had noticed this too. >> >> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >> >> Hi, >> >> does anybody know what's keeping the release-build tests for >> tinderbox >> from terminating? I've got lots of stalled regression process >> trees on >> my system, and the tinderbox display indicates that none of the >> release >> builds seem to succeed. Has anybody changed anything in the >> scripts? >> >> On a closer look, upgrade seems to be stuck in the installer: >> >> % ps -axwww 25310 >> PID TT STAT TIME COMMAND >> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >> luthien/current -o >> >> Jay, did you change any config files recently? >> Regression tests seemed to have been running again for some >> days, >> and then >> stopped again. >> >> I'll try to investigate further this evening, but must leave >> now for >> other work... >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >> Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >> 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> >> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 29 01:10:47 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 23:10:47 +0000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <20090428193939.f037r1dkowg0ks4o@mail.elegosoft.com> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> <9AC96562-7045-418A-A069-84EE8613498A@cs.purdue.edu> <20090428193939.f037r1dkowg0ks4o@mail.elegosoft.com> Message-ID: > Have you found out why it hangs though? I haven't really understood > the problem yet. No. But you understand this is against a 5.4 runtime, right? Is that really so interesting? Can you consider: a) using system() and/or b) removing "bootstrapped cminstall" from the automation. Just make it work with current and don't worry about 5.4 or lastrel. and/or c) Or wait and put it back after current release when lastrel becomes 5.8. You know, I think you'd want to exercise lastrel/5.4 as little as possible in getting current working and I think using cminstall goes past that. It is subjective though. I haven't actually tested the code with current yet, oops. - Jay ---------------------------------------- > Date: Tue, 28 Apr 2009 19:39:39 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 release build regression tests not terminating > > Hi Jay, > > thanks for reverting the offending changes to the installer. > I'm sure they were working OK when I tested them locally, and they > looked innocent enough. Sigh. Perhaps not worth to pursue the installer > issues further though. > > Have you found out why it hangs though? I haven't really understood > the problem yet. > > Sorry for the disturbances, > > Olaf > > Quoting Jay : > >> Tony can you clarify? Things stopped working two weeks ago? >> Or things were working until more recently? >> >> It seems like the select call never returns. >> Whatever is going on, it troubles debugging tools. >> gdb won't follow the children..which is probably ok, they aren't the problem. >> truss can't be control-c'ed, but can be killed. >> "info locals" in gdb often hangs and I have to pkill gdb. >> Not that info locals ever works well, but it usually doesn't hang gdb. >> I started putting in RTIO calls. >> WaitForAll's finishes one Wait call but then hangs on the next. >> >> I think we should not run cminstall against 5.4 runtime. >> Enable user threads as some related scenario.. >> >> >> - Jay >> >> >> ________________________________ >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>> Date: Tue, 28 Apr 2009 21:49:32 +1000 >>> >>> Sounds about right. >>> >>> 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 28 Apr 2009, at 21:17, Jay wrote: >>> >>> >>> The changes went in two weeks ago 4/14, were they definitely working? >>> I can try it again, hopefully without the full tinderbox stuff. >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Tue, 28 Apr 2009 21:11:42 +1000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>> >>> What could possibly have changed here. It used to work fine on >>> multiple platforms. >>> >>> On 28 Apr 2009, at 20:14, Jay wrote: >>> >>> >>> It creates a file named "df-k" and hangs here: >>> >>> (gdb) where >>> #0 0x080f417f in select () >>> #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, >>> writefds=0x28127138, >>> exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ >>> FreeBSD4/select.c:13 >>> #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, >>> M3_CEtG8K_timeout=0xbfbfe6d8) >>> at ThreadPosix.m3:714 >>> #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 >>> #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, >>> M3_AicXUJ_alertable=0 '\0') >>> at ThreadPosix.m3:555 >>> #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at >>> ThreadPosix.m3:539 >>> #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at >>> ProcessPosix.m3:294 >>> #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at >>> System.m3:527 >>> #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, >>> M3_EkfbeH_env=0x0, >>> M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 >>> #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at >>> OSPOSIX.m3:19 >>> #10 0x0804c31c in Main__DoIt () at Main.m3:122 >>> #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 >>> #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at >>> RTLinker.m3:395 >>> #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at >>> RTLinker.m3:109 >>> #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at >>> RTLinker.m3:118 >>> #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at >>> _m3main.mc:4 >>> >>> Notice it using user threads, so old m3core/libm3. >>> df doesn't appear to be any longer running. >>> Why it prints about the backend mode, I don't know. >>> >>> (and yes, I get it -- df -k is directly related to GetDiskSpace..if >>> this is how one checks diskspace on Unix...I think we should punt, >>> unless posix actually specifies the precise output format of this >>> command it is very reliably parsed...) >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com >>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: RE: [M3devel] CM3 release build regression tests not >>> terminating >>> Date: Tue, 28 Apr 2009 09:58:56 +0000 >>> >>> >>> Right, now it hangs having printed..I know this looks a bit of >>> nonsense..stuff from right around: >>> >>> >>> M3_BACKEND_MODE = "3" >>> % -- defines how the frontend, backend, and assembler interact >>> % "0" -- don't call m3_backend, M3CG produces object code >>> % "1" -- don't call m3_backend, M3CG produces assembly code >>> % "2" -- call m3_backend, it produces object code >>> % "3" -- call m3_backend, it produces assembly code >>> >>> >>> however, this is noticably pretty close to the last BEGIN_CONFIG. >>> >>> Maybe the carriage returns confused it. I'll see.. >>> I did introduce them recently by accident. >>> gdb reported some errors and no symbols in the callstack having >>> connected to it, on FreeBSD. If need be I can try debugging it on >>> another system.. >>> >>> >>> (aside, philosophy: all text processing code should treat \n, \r, >>> and \r\n in put the same, unless you are writing a terminal driver, >>> then \r has a separate meaning useful for implementing spinners..) >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> Date: Tue, 28 Apr 2009 11:40:00 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: RE: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> Quoting Jay : >>> >>> >>> Well, on FreeBSD 7.0, I get as far as: >>> >>> ew source -> compiling EnvUtils.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> ew source -> compiling EnvUtils.m3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> ew source -> compiling FingerprintFmt.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> ew source -> compiling TextUtils.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> >>> Yeah, I understand, I have libc.so.7. >>> >>> You need to install the FreeBSD compat packages for backward >>> compatibility. Should work fine then (until cminstall hangs?). >>> >>> Olaf >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> >>> I've never been able to get the tinderbox stuff to work for me. >>> I'll try again. >>> Nothing much from me lately -- pthreads movement to C, and then >>> back. >>> >>> Jay, did you change any config files recently? >>> >>> FreeBSD config file changes on 2009-04-13. >>> >>> - Jay >>> >>> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: wagner at elegosoft.com >>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> Yes, I had noticed this too. >>> >>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>> >>> Hi, >>> >>> does anybody know what's keeping the release-build tests for >>> tinderbox >>> from terminating? I've got lots of stalled regression process >>> trees on >>> my system, and the tinderbox display indicates that none of the >>> release >>> builds seem to succeed. Has anybody changed anything in the >>> scripts? >>> >>> On a closer look, upgrade seems to be stuck in the installer: >>> >>> % ps -axwww 25310 >>> PID TT STAT TIME COMMAND >>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>> luthien/current -o >>> >>> Jay, did you change any config files recently? >>> Regression tests seemed to have been running again for some >>> days, >>> and then >>> stopped again. >>> >>> I'll try to investigate further this evening, but must leave >>> now for >>> other work... >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>> 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> >>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Apr 29 01:11:47 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 23:11:47 +0000 Subject: [M3devel] __thread? Message-ID: Angle brackets tend to get broken in my emails, very annoying, that should have stdio.h. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: __thread? > Date: Tue, 28 Apr 2009 16:32:16 +0000 > > > Mika, please let me know what this does for you, on the old FreeBSD 4.x? > > [jay at jkfbsd1 ~]$ cat 1.c > #include From jay.krell at cornell.edu Wed Apr 29 03:20:36 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 28 Apr 2009 18:20:36 -0700 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <20090428175916.GA9048@topoi.pooq.com> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <49F6E76E.1E75.00D7.1@scires.com> <20090428175916.GA9048@topoi.pooq.com> Message-ID: <9D57919B-69BA-4BEC-9319-5AC51E6CB6F1@hotmail.com> You can normalize the 'presentation' while maintaining the multiple forms..just because two things look the same on screen does mean they are the same, for better and worse. Most but not all code can be 'reasonable' and allow either or a mix. Just giving guidance for folks, subjective, as a user and implementer.. - Jay (phone) On Apr 28, 2009, at 10:59 AM, hendrik at topoi.pooq.com wrote: > On Tue, Apr 28, 2009 at 04:38:09PM +0000, Jay wrote: >> >> Randy just because everyone else does it poorly does not generally >> tie your hands. >> I said on input, not on output. >> Output does often tie your hands. > > There are situations wheere you need to recognize multiple ways of > representing newline without normalizing them. > > If you are writing an editor for text that is under revision control, > and you standardize newlines on input, and then write it out in any > consistent convention, you run the risk that revision control will > think > that huge numbers of lines have been changed. Of course, they have > been, but not intentionally. > > -- hendrik > From jay.krell at cornell.edu Wed Apr 29 03:57:23 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 28 Apr 2009 18:57:23 -0700 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <2565931E-F3F3-4832-8582-C1D227B556DA@cs.purdue.edu> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> <9AC96562-7045-418A-A069-84EE8613498A@cs.purdue.edu> <2565931E-F3F3-4832-8582-C1D227B556DA@cs.purdue.edu> Message-ID: <4FBC0000-EF60-4890-B125-7CB566813931@hotmail.com> Was it broken for two weeks, or shorter? - Jay (phone) On Apr 28, 2009, at 2:51 PM, Tony Hosking wrote: > Whatever changed in the last 24 hours has my tinderbox runs > completing now. > > On 28 Apr 2009, at 22:13, Jay wrote: > >> >> Tony can you clarify? Things stopped working two weeks ago? >> Or things were working until more recently? >> >> >> >> It seems like the select call never returns. >> Whatever is going on, it troubles debugging tools. >> gdb won't follow the children..which is probably ok, they aren't >> the problem. >> truss can't be control-c'ed, but can be killed. >> "info locals" in gdb often hangs and I have to pkill gdb. >> Not that info locals ever works well, but it usually doesn't hang >> gdb. >> I started putting in RTIO calls. >> WaitForAll's finishes one Wait call but then hangs on the next. >> >> >> I think we should not run cminstall against 5.4 runtime. >> Enable user threads as some related scenario.. >> >> >> - Jay >> >> >> ________________________________ >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Subject: Re: [M3devel] CM3 release build regression tests not >>> terminating >>> Date: Tue, 28 Apr 2009 21:49:32 +1000 >>> >>> Sounds about right. >>> >>> 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 28 Apr 2009, at 21:17, Jay wrote: >>> >>> >>> The changes went in two weeks ago 4/14, were they definitely >>> working? >>> I can try it again, hopefully without the full tinderbox stuff. >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Tue, 28 Apr 2009 21:11:42 +1000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> What could possibly have changed here. It used to work fine on >>> multiple platforms. >>> >>> On 28 Apr 2009, at 20:14, Jay wrote: >>> >>> >>> It creates a file named "df-k" and hangs here: >>> >>> (gdb) where >>> #0 0x080f417f in select () >>> #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, >>> writefds=0x28127138, >>> exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ >>> FreeBSD4/select.c:13 >>> #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, >>> M3_CEtG8K_timeout=0xbfbfe6d8) >>> at ThreadPosix.m3:714 >>> #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 >>> #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, >>> M3_AicXUJ_alertable=0 '\0') >>> at ThreadPosix.m3:555 >>> #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at >>> ThreadPosix.m3:539 >>> #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at >>> ProcessPosix.m3:294 >>> #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at >>> System.m3:527 >>> #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, >>> M3_EkfbeH_env=0x0, >>> M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 >>> #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at >>> OSPOSIX.m3:19 >>> #10 0x0804c31c in Main__DoIt () at Main.m3:122 >>> #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 >>> #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at >>> RTLinker.m3:395 >>> #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at >>> RTLinker.m3:109 >>> #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at >>> RTLinker.m3:118 >>> #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at >>> _m3main.mc:4 >>> >>> Notice it using user threads, so old m3core/libm3. >>> df doesn't appear to be any longer running. >>> Why it prints about the backend mode, I don't know. >>> >>> (and yes, I get it -- df -k is directly related to GetDiskSpace..if >>> this is how one checks diskspace on Unix...I think we should punt, >>> unless posix actually specifies the precise output format of this >>> command it is very reliably parsed...) >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com >>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: RE: [M3devel] CM3 release build regression tests not >>> terminating >>> Date: Tue, 28 Apr 2009 09:58:56 +0000 >>> >>> >>> Right, now it hangs having printed..I know this looks a bit of >>> nonsense..stuff from right around: >>> >>> >>> M3_BACKEND_MODE = "3" >>> % -- defines how the frontend, backend, and assembler interact >>> % "0" -- don't call m3_backend, M3CG produces object code >>> % "1" -- don't call m3_backend, M3CG produces assembly code >>> % "2" -- call m3_backend, it produces object code >>> % "3" -- call m3_backend, it produces assembly code >>> >>> >>> however, this is noticably pretty close to the last BEGIN_CONFIG. >>> >>> Maybe the carriage returns confused it. I'll see.. >>> I did introduce them recently by accident. >>> gdb reported some errors and no symbols in the callstack having >>> connected to it, on FreeBSD. If need be I can try debugging it on >>> another system.. >>> >>> >>> (aside, philosophy: all text processing code should treat \n, \r, >>> and \r\n in put the same, unless you are writing a terminal driver, >>> then \r has a separate meaning useful for implementing spinners..) >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> Date: Tue, 28 Apr 2009 11:40:00 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: RE: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> Quoting Jay : >>> >>> >>> Well, on FreeBSD 7.0, I get as far as: >>> >>> ew source -> compiling EnvUtils.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> ew source -> compiling EnvUtils.m3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> ew source -> compiling FingerprintFmt.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> ew source -> compiling TextUtils.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> >>> Yeah, I understand, I have libc.so.7. >>> >>> You need to install the FreeBSD compat packages for backward >>> compatibility. Should work fine then (until cminstall hangs?). >>> >>> Olaf >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> >>> I've never been able to get the tinderbox stuff to work for me. >>> I'll try again. >>> Nothing much from me lately -- pthreads movement to C, and then >>> back. >>> >>> Jay, did you change any config files recently? >>> >>> FreeBSD config file changes on 2009-04-13. >>> >>> - Jay >>> >>> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: wagner at elegosoft.com >>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> Yes, I had noticed this too. >>> >>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>> >>> Hi, >>> >>> does anybody know what's keeping the release-build tests for >>> tinderbox >>> from terminating? I've got lots of stalled regression process >>> trees on >>> my system, and the tinderbox display indicates that none of the >>> release >>> builds seem to succeed. Has anybody changed anything in the >>> scripts? >>> >>> On a closer look, upgrade seems to be stuck in the installer: >>> >>> % ps -axwww 25310 >>> PID TT STAT TIME COMMAND >>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>> luthien/current -o >>> >>> Jay, did you change any config files recently? >>> Regression tests seemed to have been running again for some >>> days, >>> and then >>> stopped again. >>> >>> I'll try to investigate further this evening, but must leave >>> now for >>> other work... >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>> 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> >>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 29 03:35:28 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 28 Apr 2009 18:35:28 -0700 Subject: [M3devel] manual initialization order? In-Reply-To: <557AEC0D-E50B-4A74-95B3-37AC2123878D@cs.purdue.edu> References: <557AEC0D-E50B-4A74-95B3-37AC2123878D@cs.purdue.edu> Message-ID: Ok I figured it might be. These modules should probably be disallowed from having any initializers, via a pragma. Require it all to be more explicit, in init. - Jay (phone) On Apr 28, 2009, at 2:41 PM, Tony Hosking wrote: > Indeed it is fragile, but necessary to bootstrap the system. > > On 29 Apr 2009, at 00:15, Jay wrote: > >> >> Um, if initializers are so acceptable (I'm skeptical, but everyone >> here disagrees with me..) and circularities are not allowed (that >> helps I guess..but is it really true? the garbage collector uses >> threads, the threading library allocates traced references..I sense >> circularity...)...why does RTLinker manually pick an initialization >> order? This is fragile. >> >> >> (* initialize the rest of the modules we'll be calling *) >> AddUnit (RTLinkerX.RTLinker_I3); (* myself! *) >> AddUnit (RTLinkerX.RT0_I3); >> AddUnit (RTLinkerX.RTSignal_I3); >> AddUnit (RTLinkerX.RTParams_I3); >> AddUnit (RTLinkerX.RTDebug_I3); >> AddUnit (RTLinkerX.RTError_I3); >> AddUnit (RTLinkerX.RTHeapRep_I3); >> AddUnit (RTLinkerX.ThreadF_I3); >> AddUnit (RTLinkerX.RTHeapInfo_I3); >> AddUnit (RTLinkerX.RTIO_I3); >> AddUnit (RTLinkerX.RTCollectorSRC_I3); >> AddUnit (RTLinkerX.Word_I3); >> >> >> >> (* finally, initialize the runtime. *) >> RTSignal.InstallHandlers (); >> RTParams.Init (); >> RTHeapRep.Init (); >> ThreadF.Init (); >> RTDebug.Init (); >> RTHeapInfo.Init (); >> IF RTParams.IsPresent("tracelinker") THEN >> traceInit := TRUE; >> END; >> >> >> AddUnit (RTLinkerX.RTDebug_M3); >> AddUnit (RTLinkerX.RTError_M3); >> AddUnit (RTLinkerX.RTType_M3); >> AddUnit (RTLinkerX.RTPacking_M3); >> AddUnit (RTLinkerX.RTTipe_M3); >> AddUnit (RTLinkerX.RTException_M3); > > From wagner at elegosoft.com Wed Apr 29 08:20:06 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 29 Apr 2009 08:20:06 +0200 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <2565931E-F3F3-4832-8582-C1D227B556DA@cs.purdue.edu> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> <9AC96562-7045-418A-A069-84EE8613498A@cs.purdue.edu> <2565931E-F3F3-4832-8582-C1D227B556DA@cs.purdue.edu> Message-ID: <20090429082006.pchddoojkw8kckgk@mail.elegosoft.com> Quoting Tony Hosking : > Whatever changed in the last 24 hours has my tinderbox runs completing now. Hm. The process doesn't hang anymore; I get the following errors though: (1) === package m3-libs/unittest-numeric === +++ /home/wagner/tmp/cm3/luthien/cm3/bin/cm3 -build -override -DROOT='/u/cm3/cm 3-ws/luthien-2009-04-29-01-30-32/cm3' +++ --- building in FreeBSD4 --- unable to read ../src/m3overrides, options "-override" and "-x" ignored. "/u/cm3/cm3-ws/luthien-2009-04-29-01-30-32/cm3/m3-libs/unittest-numeric/src/m3ma kefile", line 1: quake runtime error: unable to open "/home/wagner/tmp/cm3/luthi en/cm3/pkg/libm3/FreeBSD4/.M3EXPORTS" for reading --procedure-- -line- -file--- import -- include_dir 1 /u/cm3/cm3-ws/luthien-2009-04-29-01-30-32/cm3/m3-libs/uni ttest-numeric/src/m3makefile 5 /u/cm3/cm3-ws/luthien-2009-04-29-01-30-32/cm3/m3-libs/uni ttest-numeric/FreeBSD4/m3make.args Fatal Error: package build failed ==> m3-libs/unittest-numeric done (2) === package m3-sys/cm3ide === +++ /home/wagner/tmp/cm3/luthien/cm3/bin/cm3 -build -override -DROOT='/u/cm3/cm 3-ws/luthien-2009-04-29-01-30-32/cm3' +++ --- building in FreeBSD4 --- "/u/cm3/cm3-ws/luthien-2009-04-29-01-30-32/cm3/m3-sys/cm3ide/src/m3makefile", li ne 9: quake runtime error: unable to open "/u/cm3/cm3-ws/luthien-2009-04-29-01-3 0-32/cm3/m3-libs/tcp/FreeBSD4/.M3EXPORTS" for reading --procedure-- -line- -file--- import -- include_dir 9 /u/cm3/cm3-ws/luthien-2009-04-29-01-30-32/cm3/m3-sys/cm3i de/src/m3makefile 6 /u/cm3/cm3-ws/luthien-2009-04-29-01-30-32/cm3/m3-sys/cm3i de/FreeBSD4/m3make.args Fatal Error: package build failed ==> m3-sys/cm3ide done (3) === package m3-comm/stubgen === +++ /home/wagner/tmp/cm3/luthien/cm3/bin/cm3 -build -override -DROOT='/u/cm3/cm 3-ws/luthien-2009-04-29-01-30-32/cm3' +++ --- building in FreeBSD4 --- new source -> compiling Value.i3 new source -> compiling Type.i3 new source -> compiling ValueProc.i3 new source -> compiling Protocol.i3 new source -> compiling TypeNames.i3 new source -> compiling TypeNames.m3 new source -> compiling StubUtils.i3 new source -> compiling Type.m3 "../src/Type.m3", line 291: types are not assignable 1 error encountered new source -> compiling Value.m3 new source -> compiling AstToType.i3 new source -> compiling AstToVal.i3 new source -> compiling AstToVal.m3 new source -> compiling StubCode.i3 new source -> compiling FRefRefTbl.i3 new source -> compiling AstToType.m3 new source -> compiling ModuleStubCode.i3 new source -> compiling IntfStubCode.i3 new source -> compiling CodeForType.i3 new source -> compiling StubCode.m3 new source -> compiling CodeForType.m3 new source -> compiling ModuleStubCode.m3 new source -> compiling IntfStubCode.m3 new source -> compiling StubGenTool.i3 new source -> compiling StubGenTool.m3 new source -> compiling StubUtils.m3 new source -> compiling FRefRefTbl.m3 new source -> compiling Main.m3 new exporters -> recompiling ValueProc.i3 new exporters -> recompiling Type.i3 new opaque info -> recompiling TypeNames.m3 new opaque info -> recompiling AstToVal.m3 new opaque info -> recompiling AstToType.m3 new opaque info -> recompiling StubGenTool.m3 compilation failed => not building program "stubgen" Fatal Error: package build failed *** execution of /home/wagner/tmp/cm3/luthien/cm3/bin/cm3 -build -override -DROOT='/u/cm3/cm3-ws/luthien-2009-04-29-01-30-32/cm3' failed *** real 82m36.775s user 25m38.739s sys 14m12.884s Tinderbox currently does not show any success, too. It seems that still more is amiss. Olaf > > On 28 Apr 2009, at 22:13, Jay wrote: > >> >> Tony can you clarify? Things stopped working two weeks ago? >> Or things were working until more recently? >> >> >> >> It seems like the select call never returns. >> Whatever is going on, it troubles debugging tools. >> gdb won't follow the children..which is probably ok, they aren't >> the problem. >> truss can't be control-c'ed, but can be killed. >> "info locals" in gdb often hangs and I have to pkill gdb. >> Not that info locals ever works well, but it usually doesn't hang gdb. >> I started putting in RTIO calls. >> WaitForAll's finishes one Wait call but then hangs on the next. >> >> >> I think we should not run cminstall against 5.4 runtime. >> Enable user threads as some related scenario.. >> >> >> - Jay >> >> >> ________________________________ >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>> Date: Tue, 28 Apr 2009 21:49:32 +1000 >>> >>> Sounds about right. >>> >>> 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 28 Apr 2009, at 21:17, Jay wrote: >>> >>> >>> The changes went in two weeks ago 4/14, were they definitely working? >>> I can try it again, hopefully without the full tinderbox stuff. >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Tue, 28 Apr 2009 21:11:42 +1000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>> >>> What could possibly have changed here. It used to work fine on >>> multiple platforms. >>> >>> On 28 Apr 2009, at 20:14, Jay wrote: >>> >>> >>> It creates a file named "df-k" and hangs here: >>> >>> (gdb) where >>> #0 0x080f417f in select () >>> #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, >>> writefds=0x28127138, >>> exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ >>> FreeBSD4/select.c:13 >>> #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, >>> M3_CEtG8K_timeout=0xbfbfe6d8) >>> at ThreadPosix.m3:714 >>> #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 >>> #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, >>> M3_AicXUJ_alertable=0 '\0') >>> at ThreadPosix.m3:555 >>> #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at >>> ThreadPosix.m3:539 >>> #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at >>> ProcessPosix.m3:294 >>> #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at >>> System.m3:527 >>> #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, >>> M3_EkfbeH_env=0x0, >>> M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 >>> #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at >>> OSPOSIX.m3:19 >>> #10 0x0804c31c in Main__DoIt () at Main.m3:122 >>> #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 >>> #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at >>> RTLinker.m3:395 >>> #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at >>> RTLinker.m3:109 >>> #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at >>> RTLinker.m3:118 >>> #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at >>> _m3main.mc:4 >>> >>> Notice it using user threads, so old m3core/libm3. >>> df doesn't appear to be any longer running. >>> Why it prints about the backend mode, I don't know. >>> >>> (and yes, I get it -- df -k is directly related to GetDiskSpace..if >>> this is how one checks diskspace on Unix...I think we should punt, >>> unless posix actually specifies the precise output format of this >>> command it is very reliably parsed...) >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com >>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: RE: [M3devel] CM3 release build regression tests not >>> terminating >>> Date: Tue, 28 Apr 2009 09:58:56 +0000 >>> >>> >>> Right, now it hangs having printed..I know this looks a bit of >>> nonsense..stuff from right around: >>> >>> >>> M3_BACKEND_MODE = "3" >>> % -- defines how the frontend, backend, and assembler interact >>> % "0" -- don't call m3_backend, M3CG produces object code >>> % "1" -- don't call m3_backend, M3CG produces assembly code >>> % "2" -- call m3_backend, it produces object code >>> % "3" -- call m3_backend, it produces assembly code >>> >>> >>> however, this is noticably pretty close to the last BEGIN_CONFIG. >>> >>> Maybe the carriage returns confused it. I'll see.. >>> I did introduce them recently by accident. >>> gdb reported some errors and no symbols in the callstack having >>> connected to it, on FreeBSD. If need be I can try debugging it on >>> another system.. >>> >>> >>> (aside, philosophy: all text processing code should treat \n, \r, >>> and \r\n in put the same, unless you are writing a terminal driver, >>> then \r has a separate meaning useful for implementing spinners..) >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> Date: Tue, 28 Apr 2009 11:40:00 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: RE: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> Quoting Jay : >>> >>> >>> Well, on FreeBSD 7.0, I get as far as: >>> >>> ew source -> compiling EnvUtils.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> ew source -> compiling EnvUtils.m3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> ew source -> compiling FingerprintFmt.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> ew source -> compiling TextUtils.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> >>> Yeah, I understand, I have libc.so.7. >>> >>> You need to install the FreeBSD compat packages for backward >>> compatibility. Should work fine then (until cminstall hangs?). >>> >>> Olaf >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> >>> I've never been able to get the tinderbox stuff to work for me. >>> I'll try again. >>> Nothing much from me lately -- pthreads movement to C, and then >>> back. >>> >>> Jay, did you change any config files recently? >>> >>> FreeBSD config file changes on 2009-04-13. >>> >>> - Jay >>> >>> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: wagner at elegosoft.com >>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> Yes, I had noticed this too. >>> >>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>> >>> Hi, >>> >>> does anybody know what's keeping the release-build tests for >>> tinderbox >>> from terminating? I've got lots of stalled regression process >>> trees on >>> my system, and the tinderbox display indicates that none of the >>> release >>> builds seem to succeed. Has anybody changed anything in the >>> scripts? >>> >>> On a closer look, upgrade seems to be stuck in the installer: >>> >>> % ps -axwww 25310 >>> PID TT STAT TIME COMMAND >>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>> luthien/current -o >>> >>> Jay, did you change any config files recently? >>> Regression tests seemed to have been running again for some >>> days, >>> and then >>> stopped again. >>> >>> I'll try to investigate further this evening, but must leave >>> now for >>> other work... >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>> 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> >>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 mika at async.caltech.edu Wed Apr 29 08:22:35 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 28 Apr 2009 23:22:35 -0700 Subject: [M3devel] [M3commit] how to switch userthreads on/off In-Reply-To: Your message of "Wed, 29 Apr 2009 00:06:02 -0000." Message-ID: <200904290622.n3T6MZBR003219@camembert.async.caltech.edu> Jay writes: ... > >Maybe just leave it as an option in m3core's m3makefile and people can twiddle it if they want and rebuild the entire system like it is today? >That is a bit onerous, but maybe it's all userthreads deserve? >? > > >Anyone who actually wanted to switch back and forth (Mika) would just have two installs and two source trees? > > > - Jay I just want to clarify. I'm not really that interested in switching back and forth. I'm just a little disturbed by the sometimes huge performance loss due to the introduction of kernel threads. I knew that this would happen in certain highly multithreaded applications, but I'm surprised it happens in a more or less single-threaded application. I think I've just been spoiled by 10 years of using SRCM3 and PM3 for FreeBSD w/o kernel threads in the sense that I've learned that using LOCK has essentially no cost. On a shared-memory multiprocessor, I really don't expect that to remain the case... physics won't allow it. So now I just have to go through my code and find all the places where I lock too much and remove them. But the memory allocator and garbage collector do it too, no? I also think that this idea of being able to use either is great. Mainly single-threaded programs should definitely not use kernel threads! As for reaching the "thread locals", there is one slightly crazy idea that one could borrow from Sussman and Steele: add another implicit argument to every Modula-3 routine. In that argument, pass a pointer to the thread locals. For EXTERNAL calls (in or out), make it NIL (somehow, maybe involving pragmas), and in that case (only), use the pthreads routines to access the thread locals. Ok so it sounds kind of nuts, but with this approach you could avoid locking or even calling into the pthreads libs almost entirely for a single-threaded program. You could even have a thread-local memory allocator that would only lock when it needs to request memory from the "global allocator"... in fact there are lots of things you can do with this sort of thing. Dynamically scoped variables in Scheme (a la MacLisp?) is what they originally proposed it for but then they suggested all kinds of tricks related to continuations with it. Mika From mika at async.caltech.edu Wed Apr 29 08:53:32 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 28 Apr 2009 23:53:32 -0700 Subject: [M3devel] user threads In-Reply-To: Your message of "Tue, 28 Apr 2009 16:54:03 -0000." Message-ID: <200904290653.n3T6rW8b004699@camembert.async.caltech.edu> Ok, it works! Numbers: Timings in milliseconds, three samples, filesystem "warmed up" by doing one dummy run before launching the real ones. -unsafe means that I use non-locking Scheme environments, otherwise they lock for every variable update. ave CM3 last week, kernel threads, -unsafe 1460 1482 1437 1460 CM3 last week, kernel threads, 2392 2402 2376 2390 CM3 this week, kernel threads, -unsafe 1455 1458 1490 1468 (*) CM3 this week, user threads, -unsafe 914 934 914 921 CM3 this week, user threads, 967 965 986 973 PM3 -unsafe 678 657 682 672 PM3 709 714 700 708 (*) not entirely sure this got linked correctly. Mika Jay writes: > >User threads seem to work on on FreeBSD/x86 7.0. >Mika can you report back the perf cm3 vs. pm3? >Still, kernel threads have been around a long time and imho should be strongly favored.. > > >Kernel threads should be a /little/ faster than they were -- PushEFrame removed from successful heap allocations. And should be further improvable via __thread where it is supported -- probably not FreeBSD 4. >x, sometimes older is not better. :) > > >I've temporarily switched FreeBSD/x86 to userthreads by default but I think that's just an experiment and should be undone shortly, maybe work out some other story for easily switching between them, or just k >eep the existing story of "you get to rebuild everything". > > >Tony, can you look into GetGCRatio? I removed the call to it. The "fatal" pragma invokes PushEFrame apparently. > > >We should now "fix" Win32 and pthreads to not have GetActivation initialize on-demand, just leave Init to initialize always. This should shave a few more cycles from PushEFrame. > > > - Jay From mika at async.caltech.edu Wed Apr 29 08:58:16 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 28 Apr 2009 23:58:16 -0700 Subject: [M3devel] user threads In-Reply-To: Your message of "Tue, 28 Apr 2009 23:53:32 PDT." <200904290653.n3T6rW8b004699@camembert.async.caltech.edu> Message-ID: <200904290658.n3T6wGl3004945@camembert.async.caltech.edu> By the way, *all* my CM3 timings have my Typecase modification, which isn't checked in to the distribution. I think they would all be about 400 ms slower if they didn't have that. A bit of "poor man's profiling" shows the program still spending quite some time in RTType.IsSubtype (called from CheckIsType). I think that accounts for most of the remaining difference between PM3 and CM3. Mika Mika Nystrom writes: >Ok, it works! > >Numbers: > >Timings in milliseconds, three samples, filesystem "warmed up" by >doing one dummy run before launching the real ones. > >-unsafe means that I use non-locking Scheme environments, otherwise >they lock for every variable update. > ave >CM3 last week, kernel threads, -unsafe 1460 1482 1437 1460 >CM3 last week, kernel threads, 2392 2402 2376 2390 >CM3 this week, kernel threads, -unsafe 1455 1458 1490 1468 (*) >CM3 this week, user threads, -unsafe 914 934 914 921 >CM3 this week, user threads, 967 965 986 973 >PM3 -unsafe 678 657 682 672 >PM3 709 714 700 708 > >(*) not entirely sure this got linked correctly. > > Mika > > >Jay writes: >> >>User threads seem to work on on FreeBSD/x86 7.0. >>Mika can you report back the perf cm3 vs. pm3? >>Still, kernel threads have been around a long time and imho should be strongly favored.. >> >> >>Kernel threads should be a /little/ faster than they were -- PushEFrame removed from successful heap allocations. And should be further improvable via __thread where it is supported -- probably not FreeBSD 4 >. >>x, sometimes older is not better. :) >> >> >>I've temporarily switched FreeBSD/x86 to userthreads by default but I think that's just an experiment and should be undone shortly, maybe work out some other story for easily switching between them, or just >k >>eep the existing story of "you get to rebuild everything". >> >> >>Tony, can you look into GetGCRatio? I removed the call to it. The "fatal" pragma invokes PushEFrame apparently. >> >> >>We should now "fix" Win32 and pthreads to not have GetActivation initialize on-demand, just leave Init to initialize always. This should shave a few more cycles from PushEFrame. >> >> >> - Jay From jay.krell at cornell.edu Wed Apr 29 09:05:10 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 29 Apr 2009 07:05:10 +0000 Subject: [M3devel] user threads In-Reply-To: <200904290653.n3T6rW8b004699@camembert.async.caltech.edu> References: Your message of "Tue, 28 Apr 2009 16:54:03 -0000." <200904290653.n3T6rW8b004699@camembert.async.caltech.edu> Message-ID: Mika, thanks. Want to try the next variation? look at m3-libs/m3core/src/thread/PTHREAD/ThreadPThreadC.c. See THREAD_LOCAL, THREAD_LOCAL_SLOW, THREAD_LOCAL_FAST? Try switching THREAD_LOCAL to use THREAD_LOCAL_FAST instead of _SLOW. On FreeBSD 5.x or newer. It won't compile for 4.x we know. Thanks, - Jay > To: jay.krell at cornell.edu > Date: Tue, 28 Apr 2009 23:53:32 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] user threads > > Ok, it works! > > Numbers: > > Timings in milliseconds, three samples, filesystem "warmed up" by > doing one dummy run before launching the real ones. > > -unsafe means that I use non-locking Scheme environments, otherwise > they lock for every variable update. > ave > CM3 last week, kernel threads, -unsafe 1460 1482 1437 1460 > CM3 last week, kernel threads, 2392 2402 2376 2390 > CM3 this week, kernel threads, -unsafe 1455 1458 1490 1468 (*) > CM3 this week, user threads, -unsafe 914 934 914 921 > CM3 this week, user threads, 967 965 986 973 > PM3 -unsafe 678 657 682 672 > PM3 709 714 700 708 > > (*) not entirely sure this got linked correctly. > > Mika > > > Jay writes: > > > >User threads seem to work on on FreeBSD/x86 7.0. > >Mika can you report back the perf cm3 vs. pm3? > >Still, kernel threads have been around a long time and imho should be strongly favored.. > > > > > >Kernel threads should be a /little/ faster than they were -- PushEFrame removed from successful heap allocations. And should be further improvable via __thread where it is supported -- probably not FreeBSD 4. > >x, sometimes older is not better. :) > > > > > >I've temporarily switched FreeBSD/x86 to userthreads by default but I think that's just an experiment and should be undone shortly, maybe work out some other story for easily switching between them, or just k > >eep the existing story of "you get to rebuild everything". > > > > > >Tony, can you look into GetGCRatio? I removed the call to it. The "fatal" pragma invokes PushEFrame apparently. > > > > > >We should now "fix" Win32 and pthreads to not have GetActivation initialize on-demand, just leave Init to initialize always. This should shave a few more cycles from PushEFrame. > > > > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Apr 29 09:18:42 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 29 Apr 2009 00:18:42 -0700 Subject: [M3devel] user threads In-Reply-To: Your message of "Tue, 28 Apr 2009 23:58:16 PDT." <200904290658.n3T6wGl3004945@camembert.async.caltech.edu> Message-ID: <200904290718.n3T7Ig6b005836@camembert.async.caltech.edu> Of course I just realized this typecase business doesn't work. Not thread-safe. The numbers for CM3 are worse than I write... sigh, ok, back to the drawing board. Mika Nystrom writes: >By the way, *all* my CM3 timings have my Typecase modification, >which isn't checked in to the distribution. I think they would all >be about 400 ms slower if they didn't have that. > >A bit of "poor man's profiling" shows the program still spending >quite some time in RTType.IsSubtype (called from CheckIsType). >I think that accounts for most of the remaining difference between >PM3 and CM3. > > Mika > >Mika Nystrom writes: >>Ok, it works! >> >>Numbers: >> >>Timings in milliseconds, three samples, filesystem "warmed up" by >>doing one dummy run before launching the real ones. >> >>-unsafe means that I use non-locking Scheme environments, otherwise >>they lock for every variable update. >> ave >>CM3 last week, kernel threads, -unsafe 1460 1482 1437 1460 >>CM3 last week, kernel threads, 2392 2402 2376 2390 >>CM3 this week, kernel threads, -unsafe 1455 1458 1490 1468 (*) >>CM3 this week, user threads, -unsafe 914 934 914 921 >>CM3 this week, user threads, 967 965 986 973 >>PM3 -unsafe 678 657 682 672 >>PM3 709 714 700 708 >> >>(*) not entirely sure this got linked correctly. >> >> Mika >> >> >>Jay writes: >>> >>>User threads seem to work on on FreeBSD/x86 7.0. >>>Mika can you report back the perf cm3 vs. pm3? >>>Still, kernel threads have been around a long time and imho should be strongly favored.. >>> >>> >>>Kernel threads should be a /little/ faster than they were -- PushEFrame removed from successful heap allocations. And should be further improvable via __thread where it is supported -- probably not FreeBSD >4 >>. >>>x, sometimes older is not better. :) >>> >>> >>>I've temporarily switched FreeBSD/x86 to userthreads by default but I think that's just an experiment and should be undone shortly, maybe work out some other story for easily switching between them, or just > >>k >>>eep the existing story of "you get to rebuild everything". >>> >>> >>>Tony, can you look into GetGCRatio? I removed the call to it. The "fatal" pragma invokes PushEFrame apparently. >>> >>> >>>We should now "fix" Win32 and pthreads to not have GetActivation initialize on-demand, just leave Init to initialize always. This should shave a few more cycles from PushEFrame. >>> >>> >>> - Jay From jay.krell at cornell.edu Wed Apr 29 09:26:05 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 29 Apr 2009 07:26:05 +0000 Subject: [M3devel] [M3commit] how to switch userthreads on/off In-Reply-To: <200904290622.n3T6MZBR003219@camembert.async.caltech.edu> References: Your message of "Wed, 29 Apr 2009 00:06:02 -0000." <200904290622.n3T6MZBR003219@camembert.async.caltech.edu> Message-ID: > But the memory allocator and garbage collector do it too, no? Right, the garbage collector runs a separate thread. > As for reaching the "thread locals", there is one slightly crazy > idea that one could borrow from Sussman and Steele: add another > implicit argument to every Modula-3 routine. In that argument, > pass a pointer to the thread locals. For EXTERNAL calls (in or This is basically how it works already on many systems. Just not FreeBSD <5, where there's no kernel thread support for managing the register at thread switch time. Look at the assembly code for __thread on FreeBSD 5. Notice that they do dedicate a register to thread locals. So it is about the same as what you propose, but better because they use a wierdo (segment) register that otherwise was unused. (Most other architectures can afford to give up a regular register. The "better" part is specific to x86 having so few registers.) I'm hoping to lay most of the blame on FreeBSD 4.x pthread_get/setspecific. But there is still setjmp lurking in there, even on PM3, no matter user or pthreads. Do you have numbers for FreeBSD 5 PM3 vs. CM3 pthreads? __thread should be faster than pthread_get/setspecific, but pthread_get/setspecific are probably also way better with kernel threads vs. FreeBSD 4 usermode pthreads.. Olaf, your recall that FreeBSD userthreads were "fast"..is that based on FreeBSD 4.x by chance? Maybe they don't have much advantage on any other system? You know...FreeBSD 4.x pthreads are also userthreads, not really a fair comparison maybe with other pthreads implementations and maybe give pthreads a bad name? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 29 14:27:48 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 29 Apr 2009 12:27:48 +0000 Subject: [M3devel] coping with low memory/resources? Message-ID: coping with low memory/resources? We have code that does like r := pthread_do_something() assert(r == 0); where for example: [EAGAIN] The system lacked the necessary resources (other than memory) to initialise another mutex. [ENOMEM] Insufficient memory exists to initialise the mutex. I'll fix it to raise an out of memory exception for ENOMEM. Ok. But what about EAGAIN? Retry? That is what "again" means, right? In an infinite loop? Or just a few times? You know -- overall system might be low but other parts might reduce, or the Modula-3 code itself might be hogging resources and retry might just sit there forever. Raise some other exception? For now I'll leave it asserting. - Jay From jay.krell at cornell.edu Wed Apr 29 16:12:37 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 29 Apr 2009 14:12:37 +0000 Subject: [M3devel] any limitations on __thread? Message-ID: Anyone have expertise on __thread? In particular, on Windows there is a close analog __declspec(thread) that generally would seem to work and work well, except that, per documentation, prior to Vista, it doesn't work if you are loaded with LoadLibrary (dlopen), only if the main executable uses your .so, directly or indirectly. To me that's a pretty big limitation so I wouldn't use it. I haven't seen any documentation on __thread giving this caveat though so it seems ok to use. I changed m3core to use it if sample code seems to compile, link, and execute correctly with it. - Jay From mika at async.caltech.edu Wed Apr 29 18:22:36 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 29 Apr 2009 09:22:36 -0700 Subject: [M3devel] [M3commit] how to switch userthreads on/off In-Reply-To: Your message of "Wed, 29 Apr 2009 07:26:05 -0000." Message-ID: <200904291622.n3TGMaEA031447@camembert.async.caltech.edu> Jay: I understand now. I should do more research first. libc_r is a user-level threads package, and not a very good one at that. The built-into-Modula-3 threads offer all the same facilities as FreeBSD's libc_r, as well as much higher performance. In view of that, I think it's great that you've resurrected CM3's user threads. No reason not to use them on FreeBSD4. Now to test on FreeBSD5. I still don't quite understand why kernel threads should be faster than user threads. But since all I have at the moment is libc_r, I can't back up my doubts with any numbers. Mika Jay writes: >--_2ce3dd88-b4b7-4b0b-8d3d-405d9122c9e1_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > But the memory allocator and garbage collector do it too=2C no?=20 > >=20 > >=20 > >Right=2C the garbage collector runs a separate thread. > >=20 > > > > As for reaching the "thread locals"=2C there is one slightly crazy=20 > > idea that one could borrow from Sussman and Steele: add another=20 > > implicit argument to every Modula-3 routine. In that argument=2C=20 > > pass a pointer to the thread locals. For EXTERNAL calls (in or=20 > > >=20 > >This is basically how it works already on many systems. > >Just not FreeBSD <5=2C where there's no kernel thread support for managing > >the register at thread switch time. > >=20 > >Look at the assembly code for __thread on FreeBSD 5. > >=20 > >Notice that they do dedicate a register to thread locals. > >So it is about the same as what you propose=2C but better because they use = >a wierdo (segment) register that otherwise was unused. (Most other architec= >tures can afford to give up a regular register. The "better" part is specif= >ic to x86 having so few registers.) > >=20 > >=20 > >I'm hoping to lay most of the blame on FreeBSD 4.x pthread_get/setspecific. > >But there is still setjmp lurking in there=2C even on PM3=2C no matter user= > or pthreads. > >=20 > >=20 > >Do you have numbers for FreeBSD 5 PM3 vs. CM3 pthreads? > >__thread should be faster than pthread_get/setspecific=2C but pthread_get/s= >etspecific are probably also way better with kernel threads vs. FreeBSD 4 u= >sermode pthreads.. > >=20 > >=20 > >Olaf=2C your recall that FreeBSD userthreads were "fast"..is that based on = >FreeBSD 4.x by chance? Maybe they don't have much advantage on any other sy= >stem? > >You know...FreeBSD 4.x pthreads are also userthreads=2C not really a fair c= >omparison maybe with other pthreads implementations and maybe give pthreads= > a bad name? > >=20 > >=20 > > - Jay > >=20 > >--_2ce3dd88-b4b7-4b0b-8d3d-405d9122c9e1_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > > =3B>=3B But the memory allocator and garbage collector do it too=2C = >no?
> =3B
> =3B
>Right=2C the garbage collector runs a separate thread.
> =3B
>
 =3B>=3B As for reaching the "thread locals"=2C there is one slig= >htly crazy
 =3B>=3B idea that one could borrow from Sussman and S= >teele: add another
 =3B>=3B implicit argument to every Modula-3 r= >outine. In that argument=2C
 =3B>=3B pass a pointer to the thread= > locals. For EXTERNAL calls (in or

> =3B
>This is basically how it works already on many systems.
>Just not FreeBSD <=3B5=2C where there's no kernel thread support for mana= >ging
>the register at thread switch time.
> =3B
>Look at the assembly code for __thread on FreeBSD 5.
> =3B
>Notice that they do dedicate a register to thread locals.
>So it is about the same as what you propose=2C but better because they = >=3Buse a wierdo (segment) register that otherwise was unused. (Most other a= >rchitectures can afford to give up a regular register. The "better" part is= > specific to x86 having so few registers.)
> =3B
> =3B
>I'm hoping to lay most of the blame on FreeBSD 4.x pthread_get/setspecific.= >
>But there is still setjmp lurking in there=2C even on PM3=2C no matter user= > or pthreads.
> =3B
> =3B
>Do you have numbers for FreeBSD 5 PM3 vs. CM3 pthreads?
>__thread should be faster than pthread_get/setspecific=2C but pthread_get/s= >etspecific are probably also way better with kernel threads vs. =3BFree= >BSD 4 usermode pthreads..
> =3B
> =3B
>Olaf=2C =3Byour recall that FreeBSD userthreads were =3B"fast"..is = >that based on FreeBSD 4.x by chance? Maybe they don't have much advantage o= >n any other system?
>You know...FreeBSD 4.x pthreads are also userthreads=2C not really a fair c= >omparison maybe with other pthreads implementations and maybe give pthreads= > a bad name?
> =3B
> =3B
> =3B- Jay
> =3B
>= > >--_2ce3dd88-b4b7-4b0b-8d3d-405d9122c9e1_-- From hosking at cs.purdue.edu Wed Apr 29 20:00:09 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 30 Apr 2009 04:00:09 +1000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <4FBC0000-EF60-4890-B125-7CB566813931@hotmail.com> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> <9AC96562-7045-418A-A069-84EE8613498A@cs.purdue.edu> <2565931E-F3F3-4832-8582-C1D227B556DA@cs.purdue.edu> <4FBC0000-EF60-4890-B125-7CB566813931@hotmail.com> Message-ID: I'd say about 2 weeks. On 29 Apr 2009, at 11:57, jay.krell at cornell.edu wrote: > Was it broken for two weeks, or shorter? > > - Jay (phone) > > On Apr 28, 2009, at 2:51 PM, Tony Hosking > wrote: > >> Whatever changed in the last 24 hours has my tinderbox runs >> completing now. >> >> On 28 Apr 2009, at 22:13, Jay wrote: >> >>> >>> Tony can you clarify? Things stopped working two weeks ago? >>> Or things were working until more recently? >>> >>> >>> >>> It seems like the select call never returns. >>> Whatever is going on, it troubles debugging tools. >>> gdb won't follow the children..which is probably ok, they aren't >>> the problem. >>> truss can't be control-c'ed, but can be killed. >>> "info locals" in gdb often hangs and I have to pkill gdb. >>> Not that info locals ever works well, but it usually doesn't hang >>> gdb. >>> I started putting in RTIO calls. >>> WaitForAll's finishes one Wait call but then hangs on the next. >>> >>> >>> I think we should not run cminstall against 5.4 runtime. >>> Enable user threads as some related scenario.. >>> >>> >>> - Jay >>> >>> >>> ________________________________ >>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>> From: hosking at cs.purdue.edu >>>> To: jay.krell at cornell.edu >>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>> terminating >>>> Date: Tue, 28 Apr 2009 21:49:32 +1000 >>>> >>>> Sounds about right. >>>> >>>> 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 28 Apr 2009, at 21:17, Jay wrote: >>>> >>>> >>>> The changes went in two weeks ago 4/14, were they definitely >>>> working? >>>> I can try it again, hopefully without the full tinderbox stuff. >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> To: jay.krell at cornell.edu >>>> Date: Tue, 28 Apr 2009 21:11:42 +1000 >>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>> terminating >>>> >>>> What could possibly have changed here. It used to work fine on >>>> multiple platforms. >>>> >>>> On 28 Apr 2009, at 20:14, Jay wrote: >>>> >>>> >>>> It creates a file named "df-k" and hangs here: >>>> >>>> (gdb) where >>>> #0 0x080f417f in select () >>>> #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, >>>> writefds=0x28127138, >>>> exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ >>>> FreeBSD4/select.c:13 >>>> #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, >>>> M3_CEtG8K_timeout=0xbfbfe6d8) >>>> at ThreadPosix.m3:714 >>>> #3 0x080c993b in ThreadPosix__InternalYield () at >>>> ThreadPosix.m3:985 >>>> #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, >>>> M3_AicXUJ_alertable=0 '\0') >>>> at ThreadPosix.m3:555 >>>> #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at >>>> ThreadPosix.m3:539 >>>> #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at >>>> ProcessPosix.m3:294 >>>> #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at >>>> System.m3:527 >>>> #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, >>>> M3_EkfbeH_env=0x0, >>>> M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 >>>> #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at >>>> OSPOSIX.m3:19 >>>> #10 0x0804c31c in Main__DoIt () at Main.m3:122 >>>> #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 >>>> #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at >>>> RTLinker.m3:395 >>>> #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at >>>> RTLinker.m3:109 >>>> #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at >>>> RTLinker.m3:118 >>>> #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) >>>> at >>>> _m3main.mc:4 >>>> >>>> Notice it using user threads, so old m3core/libm3. >>>> df doesn't appear to be any longer running. >>>> Why it prints about the backend mode, I don't know. >>>> >>>> (and yes, I get it -- df -k is directly related to GetDiskSpace..if >>>> this is how one checks diskspace on Unix...I think we should punt, >>>> unless posix actually specifies the precise output format of this >>>> command it is very reliably parsed...) >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: wagner at elegosoft.com >>>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>>> Subject: RE: [M3devel] CM3 release build regression tests not >>>> terminating >>>> Date: Tue, 28 Apr 2009 09:58:56 +0000 >>>> >>>> >>>> Right, now it hangs having printed..I know this looks a bit of >>>> nonsense..stuff from right around: >>>> >>>> >>>> M3_BACKEND_MODE = "3" >>>> % -- defines how the frontend, backend, and assembler interact >>>> % "0" -- don't call m3_backend, M3CG produces object code >>>> % "1" -- don't call m3_backend, M3CG produces assembly code >>>> % "2" -- call m3_backend, it produces object code >>>> % "3" -- call m3_backend, it produces assembly code >>>> >>>> >>>> however, this is noticably pretty close to the last BEGIN_CONFIG. >>>> >>>> Maybe the carriage returns confused it. I'll see.. >>>> I did introduce them recently by accident. >>>> gdb reported some errors and no symbols in the callstack having >>>> connected to it, on FreeBSD. If need be I can try debugging it on >>>> another system.. >>>> >>>> >>>> (aside, philosophy: all text processing code should treat \n, \r, >>>> and \r\n in put the same, unless you are writing a terminal driver, >>>> then \r has a separate meaning useful for implementing spinners..) >>>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>> Date: Tue, 28 Apr 2009 11:40:00 +0200 >>>> From: wagner at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>>> Subject: RE: [M3devel] CM3 release build regression tests not >>>> terminating >>>> >>>> Quoting Jay : >>>> >>>> >>>> Well, on FreeBSD 7.0, I get as far as: >>>> >>>> ew source -> compiling EnvUtils.i3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> ew source -> compiling EnvUtils.m3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> ew source -> compiling FingerprintFmt.i3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> ew source -> compiling TextUtils.i3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> >>>> Yeah, I understand, I have libc.so.7. >>>> >>>> You need to install the FreeBSD compat packages for backward >>>> compatibility. Should work fine then (until cminstall hangs?). >>>> >>>> Olaf >>>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>> terminating >>>> >>>> >>>> I've never been able to get the tinderbox stuff to work for me. >>>> I'll try again. >>>> Nothing much from me lately -- pthreads movement to C, and then >>>> back. >>>> >>>> Jay, did you change any config files recently? >>>> >>>> FreeBSD config file changes on 2009-04-13. >>>> >>>> - Jay >>>> >>>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> To: wagner at elegosoft.com >>>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>> terminating >>>> >>>> Yes, I had noticed this too. >>>> >>>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>>> >>>> Hi, >>>> >>>> does anybody know what's keeping the release-build tests for >>>> tinderbox >>>> from terminating? I've got lots of stalled regression process >>>> trees on >>>> my system, and the tinderbox display indicates that none of the >>>> release >>>> builds seem to succeed. Has anybody changed anything in the >>>> scripts? >>>> >>>> On a closer look, upgrade seems to be stuck in the installer: >>>> >>>> % ps -axwww 25310 >>>> PID TT STAT TIME COMMAND >>>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>>> luthien/current -o >>>> >>>> Jay, did you change any config files recently? >>>> Regression tests seemed to have been running again for some >>>> days, >>>> and then >>>> stopped again. >>>> >>>> I'll try to investigate further this evening, but must leave >>>> now for >>>> other work... >>>> >>>> Olaf >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>> Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>> 23 >>>> 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>> Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Wed Apr 29 20:04:22 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 30 Apr 2009 04:04:22 +1000 Subject: [M3devel] user threads In-Reply-To: <200904290653.n3T6rW8b004699@camembert.async.caltech.edu> References: <200904290653.n3T6rW8b004699@camembert.async.caltech.edu> Message-ID: <736196D3-6AA1-49C4-80E8-4EEB05B38CFC@cs.purdue.edu> Mika, it is not surprising that your lock-on-every variable update will cost a lot in any non-user-level threading scheme. You should consider using different mechanisms for this degree of locking in Scheme (based on some of the non-blocking lock implementations for Java perhaps). I don't expect any implementation of locking for a multi-core/-processor will ever perform as well as user-level threads. On 29 Apr 2009, at 16:53, Mika Nystrom wrote: > Ok, it works! > > Numbers: > > Timings in milliseconds, three samples, filesystem "warmed up" by > doing one dummy run before launching the real ones. > > -unsafe means that I use non-locking Scheme environments, otherwise > they lock for every variable update. > ave > CM3 last week, kernel threads, -unsafe 1460 1482 1437 1460 > CM3 last week, kernel threads, 2392 2402 2376 2390 > CM3 this week, kernel threads, -unsafe 1455 1458 1490 1468 (*) > CM3 this week, user threads, -unsafe 914 934 914 921 > CM3 this week, user threads, 967 965 986 973 > PM3 -unsafe 678 657 682 672 > PM3 709 714 700 708 > > (*) not entirely sure this got linked correctly. > > Mika > > > Jay writes: >> >> User threads seem to work on on FreeBSD/x86 7.0. >> Mika can you report back the perf cm3 vs. pm3? >> Still, kernel threads have been around a long time and imho should >> be strongly favored.. >> >> >> Kernel threads should be a /little/ faster than they were -- >> PushEFrame removed from successful heap allocations. And should be >> further improvable via __thread where it is supported -- probably >> not FreeBSD 4. >> x, sometimes older is not better. :) >> >> >> I've temporarily switched FreeBSD/x86 to userthreads by default but >> I think that's just an experiment and should be undone shortly, >> maybe work out some other story for easily switching between them, >> or just k >> eep the existing story of "you get to rebuild everything". >> >> >> Tony, can you look into GetGCRatio? I removed the call to it. The >> "fatal" pragma invokes PushEFrame apparently. >> >> >> We should now "fix" Win32 and pthreads to not have GetActivation >> initialize on-demand, just leave Init to initialize always. This >> should shave a few more cycles from PushEFrame. >> >> >> - Jay From hosking at cs.purdue.edu Wed Apr 29 20:05:22 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 30 Apr 2009 04:05:22 +1000 Subject: [M3devel] user threads In-Reply-To: References: Your message of "Tue, 28 Apr 2009 16:54:03 -0000." <200904290653.n3T6rW8b004699@camembert.async.caltech.edu> Message-ID: <92CEDBEA-5C93-402F-A3C0-6AEAFAB4665B@cs.purdue.edu> Jay, I think you are trying to optimize the unoptimizable if I understand that Mika uses locking as heavily as he seems to. On 29 Apr 2009, at 17:05, Jay wrote: > Mika, thanks. Want to try the next variation? look at m3-libs/m3core/ > src/thread/PTHREAD/ThreadPThreadC.c. > See THREAD_LOCAL, THREAD_LOCAL_SLOW, THREAD_LOCAL_FAST? Try > switching THREAD_LOCAL to use THREAD_LOCAL_FAST instead of _SLOW. On > FreeBSD 5.x or newer. > It won't compile for 4.x we know. > > Thanks, > - Jay > > > > To: jay.krell at cornell.edu > > Date: Tue, 28 Apr 2009 23:53:32 -0700 > > From: mika at async.caltech.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] user threads > > > > Ok, it works! > > > > Numbers: > > > > Timings in milliseconds, three samples, filesystem "warmed up" by > > doing one dummy run before launching the real ones. > > > > -unsafe means that I use non-locking Scheme environments, otherwise > > they lock for every variable update. > > ave > > CM3 last week, kernel threads, -unsafe 1460 1482 1437 1460 > > CM3 last week, kernel threads, 2392 2402 2376 2390 > > CM3 this week, kernel threads, -unsafe 1455 1458 1490 1468 (*) > > CM3 this week, user threads, -unsafe 914 934 914 921 > > CM3 this week, user threads, 967 965 986 973 > > PM3 -unsafe 678 657 682 672 > > PM3 709 714 700 708 > > > > (*) not entirely sure this got linked correctly. > > > > Mika > > > > > > Jay writes: > > > > > >User threads seem to work on on FreeBSD/x86 7.0. > > >Mika can you report back the perf cm3 vs. pm3? > > >Still, kernel threads have been around a long time and imho > should be strongly favored.. > > > > > > > > >Kernel threads should be a /little/ faster than they were -- > PushEFrame removed from successful heap allocations. And should be > further improvable via __thread where it is supported -- probably > not FreeBSD 4. > > >x, sometimes older is not better. :) > > > > > > > > >I've temporarily switched FreeBSD/x86 to userthreads by default > but I think that's just an experiment and should be undone shortly, > maybe work out some other story for easily switching between them, > or just k > > >eep the existing story of "you get to rebuild everything". > > > > > > > > >Tony, can you look into GetGCRatio? I removed the call to it. The > "fatal" pragma invokes PushEFrame apparently. > > > > > > > > >We should now "fix" Win32 and pthreads to not have GetActivation > initialize on-demand, just leave Init to initialize always. This > should shave a few more cycles from PushEFrame. > > > > > > > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Apr 29 20:12:12 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 30 Apr 2009 04:12:12 +1000 Subject: [M3devel] Fwd: Output from "cron" command References: <200904291321.n3TDLGNt022671@niagara.cs.purdue.edu> Message-ID: Now I am getting compile errors. Recent checkins are culpable. Begin forwarded message: > From: Tony Hosking > Date: 29 April 2009 23:21:16 GMT+10:00 > To: hosking at cs.purdue.edu > Subject: Output from "cron" command > > Your "cron" job on niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/cron.sh > > produced the following output: > > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-10-30-05 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSUSER= > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara release-build" > > creating log file /tmp/build-cm3-20090429-063007-_Laq8F/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.04.29 06:30:07 -- checkout in progress. > [start checkout 2009.04.29 06:30:09] > cd /tmp/build-cm3-20090429-063007-_Laq8F/build > cvs return value: 0 > [end checkout 2009.04.29 06:49:37] > CHECKOUT_RETURN = 0 > -- > 2009.04.29 06:49:41 -- compile in progress. > [start compile 2009.04.29 06:49:41] > compile return value: 0 > [end compile 2009.04.29 08:10:32] > COMPILE_RETURN = 1 > *** COMPILE FAILED > removing build tree /tmp/build-cm3-20090429-063007-_Laq8F ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-12-12-22 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSUSER= > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" > > creating log file /tmp/build-cm3-20090429-081224-i9aWYM/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.04.29 08:12:24 -- checkout in progress. > [start checkout 2009.04.29 08:12:26] > cd /tmp/build-cm3-20090429-081224-i9aWYM/build > cvs return value: 0 > [end checkout 2009.04.29 08:32:34] > CHECKOUT_RETURN = 0 > -- > 2009.04.29 08:32:38 -- compile in progress. > [start compile 2009.04.29 08:32:38] > compile return value: 0 > [end compile 2009.04.29 09:19:20] > COMPILE_RETURN = 0 > 2009.04.29 09:19:24 -- tests in progress. > [start run-tests 2009.04.29 09:19:24] > cd /tmp/build-cm3-20090429-081224-i9aWYM/build > [end run-tests 2009.04.29 09:19:24] > TESTS_RETURN = 0 > 2009.04.29 09:19:24 -- checkout, compile and test run done. > > --- > > removing build tree /tmp/build-cm3-20090429-081224-i9aWYM ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > done. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Apr 29 20:32:25 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 29 Apr 2009 11:32:25 -0700 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: Your message of "Thu, 30 Apr 2009 04:12:12 +1000." Message-ID: <200904291832.n3TIWPNo038139@camembert.async.caltech.edu> I found I had made a typo in my m3tk check-in. Is there an easy way to see what the error is? Mika Tony Hosking writes: > >--Apple-Mail-6-728527402 >Content-Type: text/plain; > charset=US-ASCII; > format=flowed >Content-Transfer-Encoding: 7bit > >Now I am getting compile errors. Recent checkins are culpable. > >Begin forwarded message: > >> From: Tony Hosking >> Date: 29 April 2009 23:21:16 GMT+10:00 >> To: hosking at cs.purdue.edu >> Subject: Output from "cron" command >> >> Your "cron" job on niagara.cs.purdue.edu >> $HOME/cm3/scripts/regression/cron.sh >> >> produced the following output: >> >> TESTHOSTNAME=niagara >> WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-10-30-05 >> LASTREL=5.4.0 >> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >> CM3_OSTYPE=POSIX >> CM3_TARGET=SOLgnu >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> CM3CVSSERVER=birch.elegosoft.com >> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> CM3CVSUSER= >> testing ssh birch.elegosoft.com.. >> ssh birch.elegosoft.com ok >> Building cm3. >> Tinderbox Tree: "cm3" >> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >> >> creating log file /tmp/build-cm3-20090429-063007-_Laq8F/log.txt >> >> --- >> >> checkout, compile and test of cm3 ... >> 2009.04.29 06:30:07 -- checkout in progress. >> [start checkout 2009.04.29 06:30:09] >> cd /tmp/build-cm3-20090429-063007-_Laq8F/build >> cvs return value: 0 >> [end checkout 2009.04.29 06:49:37] >> CHECKOUT_RETURN = 0 >> -- >> 2009.04.29 06:49:41 -- compile in progress. >> [start compile 2009.04.29 06:49:41] >> compile return value: 0 >> [end compile 2009.04.29 08:10:32] >> COMPILE_RETURN = 1 >> *** COMPILE FAILED >> removing build tree /tmp/build-cm3-20090429-063007-_Laq8F ... >> cleaning CM3 workspaces... >> /homes/hosking/work/cm3-ws/niagara-* >> >> cleaning regression test log files... >> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >> >> cleaning m3test log files... >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >> >> cleaning snapshot files... >> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >> >> cleaning package reports... >> /tmp/cm3-pkg-report-SOLgnu-*.html >> >> TESTHOSTNAME=niagara >> WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-12-12-22 >> LASTREL=5.4.0 >> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >> CM3_OSTYPE=POSIX >> CM3_TARGET=SOLgnu >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> CM3CVSSERVER=birch.elegosoft.com >> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> CM3CVSUSER= >> testing ssh birch.elegosoft.com.. >> ssh birch.elegosoft.com ok >> Building cm3. >> Tinderbox Tree: "cm3" >> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >> >> creating log file /tmp/build-cm3-20090429-081224-i9aWYM/log.txt >> >> --- >> >> checkout, compile and test of cm3 ... >> 2009.04.29 08:12:24 -- checkout in progress. >> [start checkout 2009.04.29 08:12:26] >> cd /tmp/build-cm3-20090429-081224-i9aWYM/build >> cvs return value: 0 >> [end checkout 2009.04.29 08:32:34] >> CHECKOUT_RETURN = 0 >> -- >> 2009.04.29 08:32:38 -- compile in progress. >> [start compile 2009.04.29 08:32:38] >> compile return value: 0 >> [end compile 2009.04.29 09:19:20] >> COMPILE_RETURN = 0 >> 2009.04.29 09:19:24 -- tests in progress. >> [start run-tests 2009.04.29 09:19:24] >> cd /tmp/build-cm3-20090429-081224-i9aWYM/build >> [end run-tests 2009.04.29 09:19:24] >> TESTS_RETURN = 0 >> 2009.04.29 09:19:24 -- checkout, compile and test run done. >> >> --- >> >> removing build tree /tmp/build-cm3-20090429-081224-i9aWYM ... >> cleaning CM3 workspaces... >> /homes/hosking/work/cm3-ws/niagara-* >> >> cleaning regression test log files... >> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >> >> cleaning m3test log files... >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >> >> cleaning snapshot files... >> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >> >> cleaning package reports... >> /tmp/cm3-pkg-report-SOLgnu-*.html >> >> done. > > >--Apple-Mail-6-728527402 >Content-Type: text/html; > charset=US-ASCII >Content-Transfer-Encoding: quoted-printable > >-webkit-line-break: after-white-space; ">
apple-content-edited=3D"true">style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >normal; font-variant: normal; font-weight: normal; letter-spacing: = >normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; = >-khtml-line-break: after-white-space; ">style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >normal; font-variant: normal; font-weight: normal; letter-spacing: = >normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">class=3D"Apple-style-span" style=3D"border-collapse: separate; = >border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; = >font-size: 12px; font-style: normal; font-variant: normal; font-weight: = >normal; letter-spacing: normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">class=3D"Apple-style-span" style=3D"border-collapse: separate; = >border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; = >font-size: 12px; font-style: normal; font-variant: normal; font-weight: = >normal; letter-spacing: normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">class=3D"Apple-style-span" style=3D"border-collapse: separate; = >border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; = >font-size: 12px; font-style: normal; font-variant: normal; font-weight: = >normal; letter-spacing: normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">class=3D"Apple-style-span" style=3D"border-collapse: separate; = >border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; = >font-size: 12px; font-style: normal; font-variant: normal; font-weight: = >normal; letter-spacing: normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">class=3D"Apple-style-span" style=3D"border-collapse: separate; = >border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; = >font-size: 12px; font-style: normal; font-variant: normal; font-weight: = >normal; letter-spacing: normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">class=3D"Apple-style-span" style=3D"border-collapse: separate; = >border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; = >font-size: 12px; font-style: normal; font-variant: normal; font-weight: = >normal; letter-spacing: normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">class=3D"Apple-style-span" style=3D"border-collapse: separate; = >border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; = >font-size: 12px; font-style: normal; font-variant: normal; font-weight: = >normal; letter-spacing: normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">
Now I am = >getting compile errors.  Recent checkins are = >culpable.
iv>

Begin forwarded message:

class=3D"Apple-interchange-newline">
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >margin-left: 0px; ">style=3D"font: 12.0px Helvetica; color: #000000">From: = >Helvetica">Tony Hosking <href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu>iv>
margin-left: 0px; ">style=3D"font: 12.0px Helvetica; color: #000000">Date: = >Helvetica">29 April 2009 23:21:16 GMT+10:00
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >margin-left: 0px; ">style=3D"font: 12.0px Helvetica; color: #000000">To: face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.eduv>
margin-left: 0px; ">style=3D"font: 12.0px Helvetica; color: #000000">Subject: = >Helvetica">Output from "cron" command
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >margin-left: 0px; min-height: 14px; ">
Your "cron" = >job on = >niagara.cs.purdue.edu
$HOME/cm3/scripts/regression/cron.sh

produ= >ced the following = >output:

TESTHOSTNAME=3Dniagara
WS=3D/homes/hosking/work/cm3-ws/n= >iagara-2009-04-29-10-30-05
LASTREL=3D5.4.0
INSTROOT_REL=3D/homes/hos= >king/work/cm3-inst/niagara/rel-5.4.0
INSTROOT_POK=3D/homes/hosking/work= >/cm3-inst/niagara/prev-ok
INSTROOT_LOK=3D/homes/hosking/work/cm3-inst/n= >iagara/last-ok
INSTROOT_CUR=3D/homes/hosking/work/cm3-inst/niagara/curr= >ent
CM3_OSTYPE=3DPOSIX
CM3_TARGET=3DSOLgnu
BINDISTMIN=3D/homes/ho= >sking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
CM3CVSSERVER=3Dbirch.elegosof= >t.com
CM3CVSROOT=3Dbirch.elegosoft.com:/usr/cvs
BINDISTMIN_NAME=3Dcm= >3-min-POSIX-SOLgnu-5.4.0.tgz
BINDISTMIN=3D/homes/hosking/work/cm3-min-P= >OSIX-SOLgnu-5.4.0.tgz
CM3CVSUSER=3D
testing ssh = >birch.elegosoft.com..
ssh birch.elegosoft.com ok
Building = >cm3.
Tinderbox Tree:   "cm3"
Buildname: = >       "SOLgnu SunOS 5.10 niagara = >release-build"

creating log file = >/tmp/build-cm3-20090429-063007-_Laq8F/log.txt

---

checkout, = >compile and test of cm3 ...
2009.04.29 06:30:07 -- checkout in = >progress.
[start checkout 2009.04.29 06:30:09]
cd = >/tmp/build-cm3-20090429-063007-_Laq8F/build
cvs return value: = >0
[end checkout 2009.04.29 06:49:37]
CHECKOUT_RETURN =3D = 0
--
2009.04.29 06:49:41 -- compile in progress.
[start compile = >2009.04.29 06:49:41]
compile return value: 0
[end compile = >2009.04.29 08:10:32]
COMPILE_RETURN =3D 1
*** COMPILE = >FAILED
removing build tree /tmp/build-cm3-20090429-063007-_Laq8F = >...
cleaning CM3 = >workspaces...
/homes/hosking/work/cm3-ws/niagara-*

cleaning = >regression test log = >files...
/homes/hosking/tmp/cm3/niagara/cm3-rlog-*

cleaning = >m3test log = >files...
/homes/hosking/tmp/cm3/niagara/m3tests-*.stdout

/homes/= >hosking/tmp/cm3/niagara/m3tests-*.stderr

/homes/hosking/tmp/cm3/nia= >gara/m3tests-*.stderr.extract

cleaning snapshot = >files...
/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz>
cleaning package = >reports...
/tmp/cm3-pkg-report-SOLgnu-*.html

TESTHOSTNAME=3Dniag= >ara
WS=3D/homes/hosking/work/cm3-ws/niagara-2009-04-29-12-12-22
LAST= >REL=3D5.4.0
INSTROOT_REL=3D/homes/hosking/work/cm3-inst/niagara/rel-5.4= >.0
INSTROOT_POK=3D/homes/hosking/work/cm3-inst/niagara/prev-ok
INSTR= >OOT_LOK=3D/homes/hosking/work/cm3-inst/niagara/last-ok
INSTROOT_CUR=3D/= >homes/hosking/work/cm3-inst/niagara/current
CM3_OSTYPE=3DPOSIX
CM3_T= >ARGET=3DSOLgnu
BINDISTMIN=3D/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.= >4.0.tgz
CM3CVSSERVER=3Dbirch.elegosoft.com
CM3CVSROOT=3Dbirch.elegos= >oft.com:/usr/cvs
BINDISTMIN_NAME=3Dcm3-min-POSIX-SOLgnu-5.4.0.tgz
BI= >NDISTMIN=3D/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
CM3CVSUSE= >R=3D
testing ssh birch.elegosoft.com..
ssh birch.elegosoft.com = >ok
Building cm3.
Tinderbox Tree:   "cm3"
Buildname: = >       "SOLgnu SunOS 5.10 niagara = >lastok-build"

creating log file = >/tmp/build-cm3-20090429-081224-i9aWYM/log.txt

---

checkout, = >compile and test of cm3 ...
2009.04.29 08:12:24 -- checkout in = >progress.
[start checkout 2009.04.29 08:12:26]
cd = >/tmp/build-cm3-20090429-081224-i9aWYM/build
cvs return value: = >0
[end checkout 2009.04.29 08:32:34]
CHECKOUT_RETURN =3D = >0
--
2009.04.29 08:32:38 -- compile in progress.
[start compile = >2009.04.29 08:32:38]
compile return value: 0
[end compile = >2009.04.29 09:19:20]
COMPILE_RETURN =3D 0
2009.04.29 09:19:24 -- = >tests in progress.
[start run-tests 2009.04.29 09:19:24]
cd = >/tmp/build-cm3-20090429-081224-i9aWYM/build
[end run-tests 2009.04.29 = >09:19:24]
TESTS_RETURN =3D 0
2009.04.29 09:19:24 -- checkout, = compile and test run done.

---

removing build tree = >/tmp/build-cm3-20090429-081224-i9aWYM ...
cleaning CM3 = >workspaces...
/homes/hosking/work/cm3-ws/niagara-*

cleaning = >regression test log = >files...
/homes/hosking/tmp/cm3/niagara/cm3-rlog-*

cleaning = >m3test log = >files...
/homes/hosking/tmp/cm3/niagara/m3tests-*.stdout

/homes/= >hosking/tmp/cm3/niagara/m3tests-*.stderr

/homes/hosking/tmp/cm3/nia= >gara/m3tests-*.stderr.extract

cleaning snapshot = >files...
/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz>
cleaning package = >reports...
/tmp/cm3-pkg-report-SOLgnu-*.html

done.
ockquote>

= > >--Apple-Mail-6-728527402-- From hosking at cs.purdue.edu Wed Apr 29 20:33:01 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 30 Apr 2009 04:33:01 +1000 Subject: [M3devel] [M3commit] how to switch userthreads on/off In-Reply-To: <200904290622.n3T6MZBR003219@camembert.async.caltech.edu> References: <200904290622.n3T6MZBR003219@camembert.async.caltech.edu> Message-ID: <69291A6D-E915-41C9-B4FB-AB7F5CF398EE@cs.purdue.edu> Mika, With the current implementation of M3 MUTEX 1-1 as pthread mutex you are bound to have significant overhead for any locking code even in single-threaded apps. We need to move towards a thin-lock implementation for mutex (as used in modern Java implementations) to avoid overhead for uncontended locks. It's not too hard to implement. The idea is to represent a mutex as a tagged word. The word contains either NIL, the thread holding the lock, or a pointer to a full-blown (inflated) pthread mutex. We can use GC and other opportunities to deflate locks as needs. Checking the tag requires a CAS. There are other techniques that further eliminate the CAS for the uncontended case. But, generally, you should consider LOCK to be a fairly high-overhead operation for now. 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 29 Apr 2009, at 16:22, Mika Nystrom wrote: > Jay writes: > ... >> >> Maybe just leave it as an option in m3core's m3makefile and people >> can twiddle it if they want and rebuild the entire system like it >> is today? >> That is a bit onerous, but maybe it's all userthreads deserve? >> ? >> >> >> Anyone who actually wanted to switch back and forth (Mika) would >> just have two installs and two source trees? >> >> >> - Jay > > I just want to clarify. I'm not really that interested in switching > back and forth. I'm just a little disturbed by the sometimes huge > performance loss due to the introduction of kernel threads. I knew > that this would happen in certain highly multithreaded applications, > but I'm surprised it happens in a more or less single-threaded > application. > > I think I've just been spoiled by 10 years of using SRCM3 and PM3 > for FreeBSD w/o kernel threads in the sense that I've learned that > using LOCK has essentially no cost. On a shared-memory > multiprocessor, > I really don't expect that to remain the case... physics won't allow > it. So now I just have to go through my code and find all the places > where I lock too much and remove them. > > But the memory allocator and garbage collector do it too, no? > > I also think that this idea of being able to use either is great. > Mainly single-threaded programs should definitely not use kernel > threads! > > As for reaching the "thread locals", there is one slightly crazy > idea that one could borrow from Sussman and Steele: add another > implicit argument to every Modula-3 routine. In that argument, > pass a pointer to the thread locals. For EXTERNAL calls (in or > out), make it NIL (somehow, maybe involving pragmas), and in that > case (only), use the pthreads routines to access the thread locals. > Ok so it sounds kind of nuts, but with this approach you could avoid > locking or even calling into the pthreads libs almost entirely for > a single-threaded program. You could even have a thread-local > memory allocator that would only lock when it needs to request > memory from the "global allocator"... in fact there are lots of > things you can do with this sort of thing. Dynamically scoped > variables in Scheme (a la MacLisp?) is what they originally proposed > it for but then they suggested all kinds of tricks related to > continuations with it. > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Apr 29 20:34:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 30 Apr 2009 04:34:07 +1000 Subject: [M3devel] [M3commit] how to switch userthreads on/off In-Reply-To: <200904290622.n3T6MZBR003219@camembert.async.caltech.edu> References: <200904290622.n3T6MZBR003219@camembert.async.caltech.edu> Message-ID: <6F6E80BC-1DF9-4121-834B-370567EA21D5@cs.purdue.edu> There is no lock in the fast path for traced allocation. GC has some locking that I am working on improving/eliminating. Watch this space. On 29 Apr 2009, at 16:22, Mika Nystrom wrote: > Jay writes: > ... >> >> Maybe just leave it as an option in m3core's m3makefile and people >> can twiddle it if they want and rebuild the entire system like it >> is today? >> That is a bit onerous, but maybe it's all userthreads deserve? >> ? >> >> >> Anyone who actually wanted to switch back and forth (Mika) would >> just have two installs and two source trees? >> >> >> - Jay > > I just want to clarify. I'm not really that interested in switching > back and forth. I'm just a little disturbed by the sometimes huge > performance loss due to the introduction of kernel threads. I knew > that this would happen in certain highly multithreaded applications, > but I'm surprised it happens in a more or less single-threaded > application. > > I think I've just been spoiled by 10 years of using SRCM3 and PM3 > for FreeBSD w/o kernel threads in the sense that I've learned that > using LOCK has essentially no cost. On a shared-memory > multiprocessor, > I really don't expect that to remain the case... physics won't allow > it. So now I just have to go through my code and find all the places > where I lock too much and remove them. > > But the memory allocator and garbage collector do it too, no? > > I also think that this idea of being able to use either is great. > Mainly single-threaded programs should definitely not use kernel > threads! > > As for reaching the "thread locals", there is one slightly crazy > idea that one could borrow from Sussman and Steele: add another > implicit argument to every Modula-3 routine. In that argument, > pass a pointer to the thread locals. For EXTERNAL calls (in or > out), make it NIL (somehow, maybe involving pragmas), and in that > case (only), use the pthreads routines to access the thread locals. > Ok so it sounds kind of nuts, but with this approach you could avoid > locking or even calling into the pthreads libs almost entirely for > a single-threaded program. You could even have a thread-local > memory allocator that would only lock when it needs to request > memory from the "global allocator"... in fact there are lots of > things you can do with this sort of thing. Dynamically scoped > variables in Scheme (a la MacLisp?) is what they originally proposed > it for but then they suggested all kinds of tricks related to > continuations with it. > > Mika From hosking at cs.purdue.edu Wed Apr 29 20:35:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 30 Apr 2009 04:35:07 +1000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <200904291832.n3TIWPNo038139@camembert.async.caltech.edu> References: <200904291832.n3TIWPNo038139@camembert.async.caltech.edu> Message-ID: Tinderbox... On 30 Apr 2009, at 04:32, Mika Nystrom wrote: > > I found I had made a typo in my m3tk check-in. Is there an easy > way to see what the error is? > > Mika > > Tony Hosking writes: >> >> --Apple-Mail-6-728527402 >> Content-Type: text/plain; >> charset=US-ASCII; >> format=flowed >> Content-Transfer-Encoding: 7bit >> >> Now I am getting compile errors. Recent checkins are culpable. >> >> Begin forwarded message: >> >>> From: Tony Hosking >>> Date: 29 April 2009 23:21:16 GMT+10:00 >>> To: hosking at cs.purdue.edu >>> Subject: Output from "cron" command >>> >>> Your "cron" job on niagara.cs.purdue.edu >>> $HOME/cm3/scripts/regression/cron.sh >>> >>> produced the following output: >>> >>> TESTHOSTNAME=niagara >>> WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-10-30-05 >>> LASTREL=5.4.0 >>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>> CM3_OSTYPE=POSIX >>> CM3_TARGET=SOLgnu >>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> CM3CVSSERVER=birch.elegosoft.com >>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> CM3CVSUSER= >>> testing ssh birch.elegosoft.com.. >>> ssh birch.elegosoft.com ok >>> Building cm3. >>> Tinderbox Tree: "cm3" >>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>> >>> creating log file /tmp/build-cm3-20090429-063007-_Laq8F/log.txt >>> >>> --- >>> >>> checkout, compile and test of cm3 ... >>> 2009.04.29 06:30:07 -- checkout in progress. >>> [start checkout 2009.04.29 06:30:09] >>> cd /tmp/build-cm3-20090429-063007-_Laq8F/build >>> cvs return value: 0 >>> [end checkout 2009.04.29 06:49:37] >>> CHECKOUT_RETURN = 0 >>> -- >>> 2009.04.29 06:49:41 -- compile in progress. >>> [start compile 2009.04.29 06:49:41] >>> compile return value: 0 >>> [end compile 2009.04.29 08:10:32] >>> COMPILE_RETURN = 1 >>> *** COMPILE FAILED >>> removing build tree /tmp/build-cm3-20090429-063007-_Laq8F ... >>> cleaning CM3 workspaces... >>> /homes/hosking/work/cm3-ws/niagara-* >>> >>> cleaning regression test log files... >>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>> >>> cleaning m3test log files... >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>> >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>> >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>> >>> cleaning snapshot files... >>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>> >>> cleaning package reports... >>> /tmp/cm3-pkg-report-SOLgnu-*.html >>> >>> TESTHOSTNAME=niagara >>> WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-12-12-22 >>> LASTREL=5.4.0 >>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>> CM3_OSTYPE=POSIX >>> CM3_TARGET=SOLgnu >>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> CM3CVSSERVER=birch.elegosoft.com >>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> CM3CVSUSER= >>> testing ssh birch.elegosoft.com.. >>> ssh birch.elegosoft.com ok >>> Building cm3. >>> Tinderbox Tree: "cm3" >>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>> >>> creating log file /tmp/build-cm3-20090429-081224-i9aWYM/log.txt >>> >>> --- >>> >>> checkout, compile and test of cm3 ... >>> 2009.04.29 08:12:24 -- checkout in progress. >>> [start checkout 2009.04.29 08:12:26] >>> cd /tmp/build-cm3-20090429-081224-i9aWYM/build >>> cvs return value: 0 >>> [end checkout 2009.04.29 08:32:34] >>> CHECKOUT_RETURN = 0 >>> -- >>> 2009.04.29 08:32:38 -- compile in progress. >>> [start compile 2009.04.29 08:32:38] >>> compile return value: 0 >>> [end compile 2009.04.29 09:19:20] >>> COMPILE_RETURN = 0 >>> 2009.04.29 09:19:24 -- tests in progress. >>> [start run-tests 2009.04.29 09:19:24] >>> cd /tmp/build-cm3-20090429-081224-i9aWYM/build >>> [end run-tests 2009.04.29 09:19:24] >>> TESTS_RETURN = 0 >>> 2009.04.29 09:19:24 -- checkout, compile and test run done. >>> >>> --- >>> >>> removing build tree /tmp/build-cm3-20090429-081224-i9aWYM ... >>> cleaning CM3 workspaces... >>> /homes/hosking/work/cm3-ws/niagara-* >>> >>> cleaning regression test log files... >>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>> >>> cleaning m3test log files... >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>> >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>> >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>> >>> cleaning snapshot files... >>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>> >>> cleaning package reports... >>> /tmp/cm3-pkg-report-SOLgnu-*.html >>> >>> done. >> >> >> --Apple-Mail-6-728527402 >> Content-Type: text/html; >> charset=US-ASCII >> Content-Transfer-Encoding: quoted-printable >> >> > space; = >> -webkit-line-break: after-white-space; ">
> apple-content-edited=3D"true">> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >> normal; font-variant: normal; font-weight: normal; letter-spacing: = >> normal; line-height: normal; text-align: auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">
> style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; = >> -khtml-line-break: after-white-space; ">> span" = >> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >> normal; font-variant: normal; font-weight: normal; letter-spacing: = >> normal; line-height: normal; text-align: auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >> Helvetica; = >> font-size: 12px; font-style: normal; font-variant: normal; font- >> weight: = >> normal; letter-spacing: normal; line-height: normal; text-align: >> auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >> Helvetica; = >> font-size: 12px; font-style: normal; font-variant: normal; font- >> weight: = >> normal; letter-spacing: normal; line-height: normal; text-align: >> auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >> Helvetica; = >> font-size: 12px; font-style: normal; font-variant: normal; font- >> weight: = >> normal; letter-spacing: normal; line-height: normal; text-align: >> auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >> Helvetica; = >> font-size: 12px; font-style: normal; font-variant: normal; font- >> weight: = >> normal; letter-spacing: normal; line-height: normal; text-align: >> auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >> Helvetica; = >> font-size: 12px; font-style: normal; font-variant: normal; font- >> weight: = >> normal; letter-spacing: normal; line-height: normal; text-align: >> auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >> Helvetica; = >> font-size: 12px; font-style: normal; font-variant: normal; font- >> weight: = >> normal; letter-spacing: normal; line-height: normal; text-align: >> auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >> Helvetica; = >> font-size: 12px; font-style: normal; font-variant: normal; font- >> weight: = >> normal; letter-spacing: normal; line-height: normal; text-align: >> auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">
Now I am = >> getting compile errors.  Recent checkins are = >> culpable.
> span>> iv>

Begin forwarded message:

> class=3D"Apple-interchange-newline">
> type=3D"cite">
> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >> margin-left: 0px; ">> color=3D"#000000" = >> style=3D"font: 12.0px Helvetica; color: #000000">From: = >> > 12.0px = >> Helvetica">Tony Hosking <> href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu>> font>> iv>
> 0px; = >> margin-left: 0px; ">> color=3D"#000000" = >> style=3D"font: 12.0px Helvetica; color: #000000">Date: = >> > 12.0px = >> Helvetica">29 April 2009 23:21:16 GMT+10:00
> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >> margin-left: 0px; ">> color=3D"#000000" = >> style=3D"font: 12.0px Helvetica; color: #000000">To: > font>> face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">> href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu> font>> v>
> 0px; = >> margin-left: 0px; ">> color=3D"#000000" = >> style=3D"font: 12.0px Helvetica; color: #000000">Subject: = >> > 12.0px = >> Helvetica">Output from "cron" command
> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >> margin-left: 0px; min-height: 14px; ">
Your >> "cron" = >> job on = >> niagara.cs.purdue.edu
$HOME/cm3/scripts/regression/ >> cron.sh

produ= >> ced the following = >> output:

TESTHOSTNAME=3Dniagara
WS=3D/homes/hosking/work/ >> cm3-ws/n= >> iagara-2009-04-29-10-30-05
LASTREL=3D5.4.0
INSTROOT_REL=3D/ >> homes/hos= >> king/work/cm3-inst/niagara/rel-5.4.0
INSTROOT_POK=3D/homes/ >> hosking/work= >> /cm3-inst/niagara/prev-ok
INSTROOT_LOK=3D/homes/hosking/work/cm3- >> inst/n= >> iagara/last-ok
INSTROOT_CUR=3D/homes/hosking/work/cm3-inst/ >> niagara/curr= >> ent
CM3_OSTYPE=3DPOSIX
CM3_TARGET=3DSOLgnu
BINDISTMIN=3D/ >> homes/ho= >> sking/work/cm3-min-POSIX- >> SOLgnu-5.4.0.tgz
CM3CVSSERVER=3Dbirch.elegosof= >> t.com
CM3CVSROOT=3Dbirch.elegosoft.com:/usr/ >> cvs
BINDISTMIN_NAME=3Dcm= >> 3-min-POSIX-SOLgnu-5.4.0.tgz
BINDISTMIN=3D/homes/hosking/work/ >> cm3-min-P= >> OSIX-SOLgnu-5.4.0.tgz
CM3CVSUSER=3D
testing ssh = >> birch.elegosoft.com..
ssh birch.elegosoft.com ok
Building = >> cm3.
Tinderbox Tree:   "cm3"
Buildname: = >>        "SOLgnu SunOS 5.10 >> niagara = >> release-build"

creating log file = >> /tmp/build-cm3-20090429-063007-_Laq8F/log.txt

--- >>

checkout, = >> compile and test of cm3 ...
2009.04.29 06:30:07 -- checkout in = >> progress.
[start checkout 2009.04.29 06:30:09]
cd = >> /tmp/build-cm3-20090429-063007-_Laq8F/build
cvs return value: = >> 0
[end checkout 2009.04.29 06:49:37]
CHECKOUT_RETURN =3D = > 0
--
2009.04.29 06:49:41 -- compile in progress.
[start > compile = >> 2009.04.29 06:49:41]
compile return value: 0
[end compile = >> 2009.04.29 08:10:32]
COMPILE_RETURN =3D 1
*** COMPILE = >> FAILED
removing build tree /tmp/build-cm3-20090429-063007-_Laq8F = >> ...
cleaning CM3 = >> workspaces...
/homes/hosking/work/cm3-ws/niagara- >> *

cleaning = >> regression test log = >> files...
/homes/hosking/tmp/cm3/niagara/cm3-rlog- >> *

cleaning = >> m3test log = >> files...
/homes/hosking/tmp/cm3/niagara/m3tests-*.stdout

/ >> homes/= >> hosking/tmp/cm3/niagara/m3tests-*.stderr

/homes/hosking/tmp/ >> cm3/nia= >> gara/m3tests-*.stderr.extract

cleaning snapshot = >> files...
/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >> *.tgz>>
cleaning package = >> reports...
/tmp/cm3-pkg-report-SOLgnu- >> *.html

TESTHOSTNAME=3Dniag= >> ara
WS=3D/homes/hosking/work/cm3-ws/ >> niagara-2009-04-29-12-12-22
LAST= >> REL=3D5.4.0
INSTROOT_REL=3D/homes/hosking/work/cm3-inst/niagara/ >> rel-5.4= >> .0
INSTROOT_POK=3D/homes/hosking/work/cm3-inst/niagara/prev- >> ok
INSTR= >> OOT_LOK=3D/homes/hosking/work/cm3-inst/niagara/last- >> ok
INSTROOT_CUR=3D/= >> homes/hosking/work/cm3-inst/niagara/ >> current
CM3_OSTYPE=3DPOSIX
CM3_T= >> ARGET=3DSOLgnu
BINDISTMIN=3D/homes/hosking/work/cm3-min-POSIX- >> SOLgnu-5.= >> 4.0 >> .tgz >>
CM3CVSSERVER=3Dbirch.elegosoft.com
CM3CVSROOT=3Dbirch.elegos= >> oft.com:/usr/cvs
BINDISTMIN_NAME=3Dcm3-min-POSIX- >> SOLgnu-5.4.0.tgz
BI= >> NDISTMIN=3D/homes/hosking/work/cm3-min-POSIX- >> SOLgnu-5.4.0.tgz
CM3CVSUSE= >> R=3D
testing ssh birch.elegosoft.com..
ssh >> birch.elegosoft.com = >> ok
Building cm3.
Tinderbox Tree: >>   "cm3"
Buildname: = >>        "SOLgnu SunOS 5.10 >> niagara = >> lastok-build"

creating log file = >> /tmp/build-cm3-20090429-081224-i9aWYM/log.txt

--- >>

checkout, = >> compile and test of cm3 ...
2009.04.29 08:12:24 -- checkout in = >> progress.
[start checkout 2009.04.29 08:12:26]
cd = >> /tmp/build-cm3-20090429-081224-i9aWYM/build
cvs return value: = >> 0
[end checkout 2009.04.29 08:32:34]
CHECKOUT_RETURN =3D = >> 0
--
2009.04.29 08:32:38 -- compile in progress.
[start >> compile = >> 2009.04.29 08:32:38]
compile return value: 0
[end compile = >> 2009.04.29 09:19:20]
COMPILE_RETURN =3D 0
2009.04.29 09:19:24 >> -- = >> tests in progress.
[start run-tests 2009.04.29 09:19:24]
cd = >> /tmp/build-cm3-20090429-081224-i9aWYM/build
[end run-tests >> 2009.04.29 = >> 09:19:24]
TESTS_RETURN =3D 0
2009.04.29 09:19:24 -- checkout, = > compile and test run done.

---

removing build tree = >> /tmp/build-cm3-20090429-081224-i9aWYM ...
cleaning CM3 = >> workspaces...
/homes/hosking/work/cm3-ws/niagara- >> *

cleaning = >> regression test log = >> files...
/homes/hosking/tmp/cm3/niagara/cm3-rlog- >> *

cleaning = >> m3test log = >> files...
/homes/hosking/tmp/cm3/niagara/m3tests-*.stdout

/ >> homes/= >> hosking/tmp/cm3/niagara/m3tests-*.stderr

/homes/hosking/tmp/ >> cm3/nia= >> gara/m3tests-*.stderr.extract

cleaning snapshot = >> files...
/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >> *.tgz>>
cleaning package = >> reports...
/tmp/cm3-pkg-report-SOLgnu-*.html

done.
> div>> ockquote>

= >> >> --Apple-Mail-6-728527402-- From mika at async.caltech.edu Wed Apr 29 20:46:03 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 29 Apr 2009 11:46:03 -0700 Subject: [M3devel] user threads In-Reply-To: Your message of "Thu, 30 Apr 2009 04:04:22 +1000." <736196D3-6AA1-49C4-80E8-4EEB05B38CFC@cs.purdue.edu> Message-ID: <200904291846.n3TIk3F6038926@camembert.async.caltech.edu> Tony, no of course it's not surprising. -unsafe removes the lock-on-every update (in the global environment---pushed environments are always "unsafe"). In fact since there are hardly any updates in the global environment, it's locking on reading that's hurting. [Tony, I'm curious how you'd go about implementing the sort of "non-blocking lock" you mention.] But what Jay has pointed out is that what I labeled as "kernel threads" in the attached table aren't kernel threads at all but libc_r threads, which provide the same facilities (as far as I know) as M3's "user threads". In this case M3's user threads are simply superior to what the system provides. Much superior. I think if possible "M3 user threads" should definitely be the default on FreeBSD4 and earlier, rather than "system user threads". I think people who want to implement coroutines and occam-like things with threads would also be happy if user threads were very easy to enable. Although I agree they should certainly not normally be the default and it is probably unnecessary to be able to enable them at runtime. A compile/link-time option would be nice though.... Rather than having to recompile the whole M3 distribution, that is. I know of two important classes of applications where user threads are likely to be superior to kernel threads: 1. occam-like things, as described above. Not uncommon in hardware circles! 2. applications that use RMI (e.g., Network Objects) to communicate between separate runtimes that are mapped exactly one runtime to each physical core. For case 2, readers may be interested in the following report: http://caltechcstr.library.caltech.edu/218/ Mika Tony Hosking writes: >Mika, it is not surprising that your lock-on-every variable update >will cost a lot in any non-user-level threading scheme. You should >consider using different mechanisms for this degree of locking in >Scheme (based on some of the non-blocking lock implementations for >Java perhaps). I don't expect any implementation of locking for a >multi-core/-processor will ever perform as well as user-level threads. > >On 29 Apr 2009, at 16:53, Mika Nystrom wrote: > >> Ok, it works! >> >> Numbers: >> >> Timings in milliseconds, three samples, filesystem "warmed up" by >> doing one dummy run before launching the real ones. >> >> -unsafe means that I use non-locking Scheme environments, otherwise >> they lock for every variable update. >> ave >> CM3 last week, kernel threads, -unsafe 1460 1482 1437 1460 >> CM3 last week, kernel threads, 2392 2402 2376 2390 >> CM3 this week, kernel threads, -unsafe 1455 1458 1490 1468 (*) >> CM3 this week, user threads, -unsafe 914 934 914 921 >> CM3 this week, user threads, 967 965 986 973 >> PM3 -unsafe 678 657 682 672 >> PM3 709 714 700 708 >> >> (*) not entirely sure this got linked correctly. >> >> Mika >> >> >> Jay writes: >>> >>> User threads seem to work on on FreeBSD/x86 7.0. >>> Mika can you report back the perf cm3 vs. pm3? >>> Still, kernel threads have been around a long time and imho should >>> be strongly favored.. >>> >>> >>> Kernel threads should be a /little/ faster than they were -- >>> PushEFrame removed from successful heap allocations. And should be >>> further improvable via __thread where it is supported -- probably >>> not FreeBSD 4. >>> x, sometimes older is not better. :) >>> >>> >>> I've temporarily switched FreeBSD/x86 to userthreads by default but >>> I think that's just an experiment and should be undone shortly, >>> maybe work out some other story for easily switching between them, >>> or just k >>> eep the existing story of "you get to rebuild everything". >>> >>> >>> Tony, can you look into GetGCRatio? I removed the call to it. The >>> "fatal" pragma invokes PushEFrame apparently. >>> >>> >>> We should now "fix" Win32 and pthreads to not have GetActivation >>> initialize on-demand, just leave Init to initialize always. This >>> should shave a few more cycles from PushEFrame. >>> >>> >>> - Jay From hosking at cs.purdue.edu Wed Apr 29 20:58:06 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 30 Apr 2009 04:58:06 +1000 Subject: [M3devel] user threads In-Reply-To: <200904291846.n3TIk3F6038926@camembert.async.caltech.edu> References: <200904291846.n3TIk3F6038926@camembert.async.caltech.edu> Message-ID: On 30 Apr 2009, at 04:46, Mika Nystrom wrote: > Tony, no of course it's not surprising. -unsafe removes the > lock-on-every update (in the global environment---pushed environments > are always "unsafe"). In fact since there are hardly any updates > in the global environment, it's locking on reading that's hurting. > > [Tony, I'm curious how you'd go about implementing the sort of > "non-blocking lock" you mention.] > > But what Jay has pointed out is that what I labeled as "kernel > threads" in the attached table aren't kernel threads at all but > libc_r threads, which provide the same facilities (as far as I know) > as M3's "user threads". In this case M3's user threads are simply > superior to what the system provides. Much superior. Ah, understood. > I think if possible "M3 user threads" should definitely be the > default on FreeBSD4 and earlier, rather than "system user threads". Fair enough. Old thread libraries were pretty substandard. > I think people who want to implement coroutines and occam-like > things with threads would also be happy if user threads were very > easy to enable. Although I agree they should certainly not normally > be the default and it is probably unnecessary to be able to enable > them at runtime. A compile/link-time option would be nice though.... > Rather than having to recompile the whole M3 distribution, that is. For a systems programming language like Modula-3 I think the general expectation should be that m3-thread = system thread (i.e., something scheduled on a physical processor by the operating system). Anyone wanting Occam-like things and co-routines should think hard about what they need and devise a scheme for multi-plexing them on each of the processors. Perhaps it could be made available as a library. > I know of two important classes of applications where user threads > are likely to be superior to kernel threads: > > 1. occam-like things, as described above. Not uncommon in hardware > circles! But on modern hardware we'd need them to be scheduled across multiple processors. > 2. applications that use RMI (e.g., Network Objects) to communicate > between separate runtimes that are mapped exactly one runtime > to each physical core. Hmm, perhaps... > > > For case 2, readers may be interested in the following report: > > http://caltechcstr.library.caltech.edu/218/ > > Mika > > Tony Hosking writes: >> Mika, it is not surprising that your lock-on-every variable update >> will cost a lot in any non-user-level threading scheme. You should >> consider using different mechanisms for this degree of locking in >> Scheme (based on some of the non-blocking lock implementations for >> Java perhaps). I don't expect any implementation of locking for a >> multi-core/-processor will ever perform as well as user-level >> threads. >> >> On 29 Apr 2009, at 16:53, Mika Nystrom wrote: >> >>> Ok, it works! >>> >>> Numbers: >>> >>> Timings in milliseconds, three samples, filesystem "warmed up" by >>> doing one dummy run before launching the real ones. >>> >>> -unsafe means that I use non-locking Scheme environments, otherwise >>> they lock for every variable update. >>> ave >>> CM3 last week, kernel threads, -unsafe 1460 1482 1437 1460 >>> CM3 last week, kernel threads, 2392 2402 2376 2390 >>> CM3 this week, kernel threads, -unsafe 1455 1458 1490 1468 (*) >>> CM3 this week, user threads, -unsafe 914 934 914 921 >>> CM3 this week, user threads, 967 965 986 973 >>> PM3 -unsafe 678 657 682 672 >>> PM3 709 714 700 708 >>> >>> (*) not entirely sure this got linked correctly. >>> >>> Mika >>> >>> >>> Jay writes: >>>> >>>> User threads seem to work on on FreeBSD/x86 7.0. >>>> Mika can you report back the perf cm3 vs. pm3? >>>> Still, kernel threads have been around a long time and imho should >>>> be strongly favored.. >>>> >>>> >>>> Kernel threads should be a /little/ faster than they were -- >>>> PushEFrame removed from successful heap allocations. And should be >>>> further improvable via __thread where it is supported -- probably >>>> not FreeBSD 4. >>>> x, sometimes older is not better. :) >>>> >>>> >>>> I've temporarily switched FreeBSD/x86 to userthreads by default but >>>> I think that's just an experiment and should be undone shortly, >>>> maybe work out some other story for easily switching between them, >>>> or just k >>>> eep the existing story of "you get to rebuild everything". >>>> >>>> >>>> Tony, can you look into GetGCRatio? I removed the call to it. The >>>> "fatal" pragma invokes PushEFrame apparently. >>>> >>>> >>>> We should now "fix" Win32 and pthreads to not have GetActivation >>>> initialize on-demand, just leave Init to initialize always. This >>>> should shave a few more cycles from PushEFrame. >>>> >>>> >>>> - Jay From jay.krell at cornell.edu Wed Apr 29 22:01:14 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 29 Apr 2009 20:01:14 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: References: <200904291832.n3TIWPNo038139@camembert.async.caltech.edu> Message-ID: Add this to your favorites or bookmarks or whatever: http://tinderbox.elegosoft.com/tinderbox/cm3/status.html It's not the most friendly but it is ok. Unfortunately the error is just: 12067 NEXT Bus Error - core dumped I'll undo stuff, like __thread mainly. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: mika at async.caltech.edu > Date: Thu, 30 Apr 2009 04:35:07 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Fwd: Output from "cron" command > > Tinderbox... > > On 30 Apr 2009, at 04:32, Mika Nystrom wrote: > >> >> I found I had made a typo in my m3tk check-in. Is there an easy >> way to see what the error is? >> >> Mika >> >> Tony Hosking writes: >>> >>> --Apple-Mail-6-728527402 >>> Content-Type: text/plain; >>> charset=US-ASCII; >>> format=flowed >>> Content-Transfer-Encoding: 7bit >>> >>> Now I am getting compile errors. Recent checkins are culpable. >>> >>> Begin forwarded message: >>> >>>> From: Tony Hosking >>>> Date: 29 April 2009 23:21:16 GMT+10:00 >>>> To: hosking at cs.purdue.edu >>>> Subject: Output from "cron" command >>>> >>>> Your "cron" job on niagara.cs.purdue.edu >>>> $HOME/cm3/scripts/regression/cron.sh >>>> >>>> produced the following output: >>>> >>>> TESTHOSTNAME=niagara >>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-10-30-05 >>>> LASTREL=5.4.0 >>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>> CM3_OSTYPE=POSIX >>>> CM3_TARGET=SOLgnu >>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> CM3CVSSERVER=birch.elegosoft.com >>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> CM3CVSUSER= >>>> testing ssh birch.elegosoft.com.. >>>> ssh birch.elegosoft.com ok >>>> Building cm3. >>>> Tinderbox Tree: "cm3" >>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>> >>>> creating log file /tmp/build-cm3-20090429-063007-_Laq8F/log.txt >>>> >>>> --- >>>> >>>> checkout, compile and test of cm3 ... >>>> 2009.04.29 06:30:07 -- checkout in progress. >>>> [start checkout 2009.04.29 06:30:09] >>>> cd /tmp/build-cm3-20090429-063007-_Laq8F/build >>>> cvs return value: 0 >>>> [end checkout 2009.04.29 06:49:37] >>>> CHECKOUT_RETURN = 0 >>>> -- >>>> 2009.04.29 06:49:41 -- compile in progress. >>>> [start compile 2009.04.29 06:49:41] >>>> compile return value: 0 >>>> [end compile 2009.04.29 08:10:32] >>>> COMPILE_RETURN = 1 >>>> *** COMPILE FAILED >>>> removing build tree /tmp/build-cm3-20090429-063007-_Laq8F ... >>>> cleaning CM3 workspaces... >>>> /homes/hosking/work/cm3-ws/niagara-* >>>> >>>> cleaning regression test log files... >>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>> >>>> cleaning m3test log files... >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>> >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>> >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>> >>>> cleaning snapshot files... >>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>> >>>> cleaning package reports... >>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>> >>>> TESTHOSTNAME=niagara >>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-12-12-22 >>>> LASTREL=5.4.0 >>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>> CM3_OSTYPE=POSIX >>>> CM3_TARGET=SOLgnu >>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> CM3CVSSERVER=birch.elegosoft.com >>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> CM3CVSUSER= >>>> testing ssh birch.elegosoft.com.. >>>> ssh birch.elegosoft.com ok >>>> Building cm3. >>>> Tinderbox Tree: "cm3" >>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>> >>>> creating log file /tmp/build-cm3-20090429-081224-i9aWYM/log.txt >>>> >>>> --- >>>> >>>> checkout, compile and test of cm3 ... >>>> 2009.04.29 08:12:24 -- checkout in progress. >>>> [start checkout 2009.04.29 08:12:26] >>>> cd /tmp/build-cm3-20090429-081224-i9aWYM/build >>>> cvs return value: 0 >>>> [end checkout 2009.04.29 08:32:34] >>>> CHECKOUT_RETURN = 0 >>>> -- >>>> 2009.04.29 08:32:38 -- compile in progress. >>>> [start compile 2009.04.29 08:32:38] >>>> compile return value: 0 >>>> [end compile 2009.04.29 09:19:20] >>>> COMPILE_RETURN = 0 >>>> 2009.04.29 09:19:24 -- tests in progress. >>>> [start run-tests 2009.04.29 09:19:24] >>>> cd /tmp/build-cm3-20090429-081224-i9aWYM/build >>>> [end run-tests 2009.04.29 09:19:24] >>>> TESTS_RETURN = 0 >>>> 2009.04.29 09:19:24 -- checkout, compile and test run done. >>>> >>>> --- >>>> >>>> removing build tree /tmp/build-cm3-20090429-081224-i9aWYM ... >>>> cleaning CM3 workspaces... >>>> /homes/hosking/work/cm3-ws/niagara-* >>>> >>>> cleaning regression test log files... >>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>> >>>> cleaning m3test log files... >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>> >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>> >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>> >>>> cleaning snapshot files... >>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>> >>>> cleaning package reports... >>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>> >>>> done. >>> >>> >>> --Apple-Mail-6-728527402 >>> Content-Type: text/html; >>> charset=US-ASCII >>> Content-Transfer-Encoding: quoted-printable >>> >>>>>> space; = >>> -webkit-line-break: after-white-space; "> >>> apple-content-edited=3D"true">>>> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >>> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >>> normal; font-variant: normal; font-weight: normal; letter-spacing: = >>> normal; line-height: normal; text-align: auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; "> >>> style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; = >>> -khtml-line-break: after-white-space; ">>>> span" = >>> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >>> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >>> normal; font-variant: normal; font-weight: normal; letter-spacing: = >>> normal; line-height: normal; text-align: auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>> Helvetica; = >>> font-size: 12px; font-style: normal; font-variant: normal; font- >>> weight: = >>> normal; letter-spacing: normal; line-height: normal; text-align: >>> auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>> Helvetica; = >>> font-size: 12px; font-style: normal; font-variant: normal; font- >>> weight: = >>> normal; letter-spacing: normal; line-height: normal; text-align: >>> auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>> Helvetica; = >>> font-size: 12px; font-style: normal; font-variant: normal; font- >>> weight: = >>> normal; letter-spacing: normal; line-height: normal; text-align: >>> auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>> Helvetica; = >>> font-size: 12px; font-style: normal; font-variant: normal; font- >>> weight: = >>> normal; letter-spacing: normal; line-height: normal; text-align: >>> auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>> Helvetica; = >>> font-size: 12px; font-style: normal; font-variant: normal; font- >>> weight: = >>> normal; letter-spacing: normal; line-height: normal; text-align: >>> auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>> Helvetica; = >>> font-size: 12px; font-style: normal; font-variant: normal; font- >>> weight: = >>> normal; letter-spacing: normal; line-height: normal; text-align: >>> auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>> Helvetica; = >>> font-size: 12px; font-style: normal; font-variant: normal; font- >>> weight: = >>> normal; letter-spacing: normal; line-height: normal; text-align: >>> auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; "> Now I am = >>> getting compile errors. Recent checkins are = >>> culpable.>>> span>>>> iv> Begin forwarded message: >>> class=3D"Apple-interchange-newline">>>> type=3D"cite"> >>> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >>> margin-left: 0px; ">>>> color=3D"#000000" = >>> style=3D"font: 12.0px Helvetica; color: #000000">From: = >>>>>> 12.0px = >>> Helvetica">Tony Hosking <>>> href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu>>>> font>>>> iv> >>> 0px; = >>> margin-left: 0px; ">>>> color=3D"#000000" = >>> style=3D"font: 12.0px Helvetica; color: #000000">Date: = >>>>>> 12.0px = >>> Helvetica">29 April 2009 23:21:16 GMT+10:00 >>> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >>> margin-left: 0px; ">>>> color=3D"#000000" = >>> style=3D"font: 12.0px Helvetica; color: #000000">To:>>> font>>>> face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">>>> href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu>>> font>>>> v> >>> 0px; = >>> margin-left: 0px; ">>>> color=3D"#000000" = >>> style=3D"font: 12.0px Helvetica; color: #000000">Subject: = >>>>>> 12.0px = >>> Helvetica">Output from "cron" command >>> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >>> margin-left: 0px; min-height: 14px; "> Your >>> "cron" = >>> job on = >>> niagara.cs.purdue.edu $HOME/cm3/scripts/regression/ >>> cron.sh produ= >>> ced the following = >>> output: TESTHOSTNAME=3Dniagara WS=3D/homes/hosking/work/ >>> cm3-ws/n= >>> iagara-2009-04-29-10-30-05 LASTREL=3D5.4.0 INSTROOT_REL=3D/ >>> homes/hos= >>> king/work/cm3-inst/niagara/rel-5.4.0 INSTROOT_POK=3D/homes/ >>> hosking/work= >>> /cm3-inst/niagara/prev-ok INSTROOT_LOK=3D/homes/hosking/work/cm3- >>> inst/n= >>> iagara/last-ok INSTROOT_CUR=3D/homes/hosking/work/cm3-inst/ >>> niagara/curr= >>> ent CM3_OSTYPE=3DPOSIX CM3_TARGET=3DSOLgnu BINDISTMIN=3D/ >>> homes/ho= >>> sking/work/cm3-min-POSIX- >>> SOLgnu-5.4.0.tgz CM3CVSSERVER=3Dbirch.elegosof= >>> t.com CM3CVSROOT=3Dbirch.elegosoft.com:/usr/ >>> cvs BINDISTMIN_NAME=3Dcm= >>> 3-min-POSIX-SOLgnu-5.4.0.tgz BINDISTMIN=3D/homes/hosking/work/ >>> cm3-min-P= >>> OSIX-SOLgnu-5.4.0.tgz CM3CVSUSER=3D testing ssh = >>> birch.elegosoft.com.. ssh birch.elegosoft.com ok Building = >>> cm3. Tinderbox Tree: "cm3" Buildname: = >>> "SOLgnu SunOS 5.10 >>> niagara = >>> release-build" creating log file = >>> /tmp/build-cm3-20090429-063007-_Laq8F/log.txt --- >>> checkout, = >>> compile and test of cm3 ... 2009.04.29 06:30:07 -- checkout in = >>> progress. [start checkout 2009.04.29 06:30:09] cd = >>> /tmp/build-cm3-20090429-063007-_Laq8F/build cvs return value: = >>> 0 [end checkout 2009.04.29 06:49:37] CHECKOUT_RETURN =3D = >> 0 -- 2009.04.29 06:49:41 -- compile in progress. [start >> compile = >>> 2009.04.29 06:49:41] compile return value: 0 [end compile = >>> 2009.04.29 08:10:32] COMPILE_RETURN =3D 1 *** COMPILE = >>> FAILED removing build tree /tmp/build-cm3-20090429-063007-_Laq8F = >>> ... cleaning CM3 = >>> workspaces... /homes/hosking/work/cm3-ws/niagara- >>> * cleaning = >>> regression test log = >>> files... /homes/hosking/tmp/cm3/niagara/cm3-rlog- >>> * cleaning = >>> m3test log = >>> files... /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout / >>> homes/= >>> hosking/tmp/cm3/niagara/m3tests-*.stderr /homes/hosking/tmp/ >>> cm3/nia= >>> gara/m3tests-*.stderr.extract cleaning snapshot = >>> files... /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >>> *.tgz>>>> cleaning package = >>> reports... /tmp/cm3-pkg-report-SOLgnu- >>> *.html TESTHOSTNAME=3Dniag= >>> ara WS=3D/homes/hosking/work/cm3-ws/ >>> niagara-2009-04-29-12-12-22 LAST= >>> REL=3D5.4.0 INSTROOT_REL=3D/homes/hosking/work/cm3-inst/niagara/ >>> rel-5.4= >>> .0 INSTROOT_POK=3D/homes/hosking/work/cm3-inst/niagara/prev- >>> ok INSTR= >>> OOT_LOK=3D/homes/hosking/work/cm3-inst/niagara/last- >>> ok INSTROOT_CUR=3D/= >>> homes/hosking/work/cm3-inst/niagara/ >>> current CM3_OSTYPE=3DPOSIX CM3_T= >>> ARGET=3DSOLgnu BINDISTMIN=3D/homes/hosking/work/cm3-min-POSIX- >>> SOLgnu-5.= >>> 4.0 >>> .tgz >>> CM3CVSSERVER=3Dbirch.elegosoft.com CM3CVSROOT=3Dbirch.elegos= >>> oft.com:/usr/cvs BINDISTMIN_NAME=3Dcm3-min-POSIX- >>> SOLgnu-5.4.0.tgz BI= >>> NDISTMIN=3D/homes/hosking/work/cm3-min-POSIX- >>> SOLgnu-5.4.0.tgz CM3CVSUSE= >>> R=3D testing ssh birch.elegosoft.com.. ssh >>> birch.elegosoft.com = >>> ok Building cm3. Tinderbox Tree: >>> "cm3" Buildname: = >>> "SOLgnu SunOS 5.10 >>> niagara = >>> lastok-build" creating log file = >>> /tmp/build-cm3-20090429-081224-i9aWYM/log.txt --- >>> checkout, = >>> compile and test of cm3 ... 2009.04.29 08:12:24 -- checkout in = >>> progress. [start checkout 2009.04.29 08:12:26] cd = >>> /tmp/build-cm3-20090429-081224-i9aWYM/build cvs return value: = >>> 0 [end checkout 2009.04.29 08:32:34] CHECKOUT_RETURN =3D = >>> 0 -- 2009.04.29 08:32:38 -- compile in progress. [start >>> compile = >>> 2009.04.29 08:32:38] compile return value: 0 [end compile = >>> 2009.04.29 09:19:20] COMPILE_RETURN =3D 0 2009.04.29 09:19:24 >>> -- = >>> tests in progress. [start run-tests 2009.04.29 09:19:24] cd = >>> /tmp/build-cm3-20090429-081224-i9aWYM/build [end run-tests >>> 2009.04.29 = >>> 09:19:24] TESTS_RETURN =3D 0 2009.04.29 09:19:24 -- checkout, = >> compile and test run done. --- removing build tree = >>> /tmp/build-cm3-20090429-081224-i9aWYM ... cleaning CM3 = >>> workspaces... /homes/hosking/work/cm3-ws/niagara- >>> * cleaning = >>> regression test log = >>> files... /homes/hosking/tmp/cm3/niagara/cm3-rlog- >>> * cleaning = >>> m3test log = >>> files... /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout / >>> homes/= >>> hosking/tmp/cm3/niagara/m3tests-*.stderr /homes/hosking/tmp/ >>> cm3/nia= >>> gara/m3tests-*.stderr.extract cleaning snapshot = >>> files... /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >>> *.tgz>>>> cleaning package = >>> reports... /tmp/cm3-pkg-report-SOLgnu-*.html done. >>> div>>>> ockquote> = >>> >>> --Apple-Mail-6-728527402-- > From jay.krell at cornell.edu Wed Apr 29 22:07:48 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 29 Apr 2009 20:07:48 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: References: <200904291832.n3TIWPNo038139@camembert.async.caltech.edu> Message-ID: Actually it looks like I missed I didn't change ThreadPThreadC.c to turn on __thread. Anyway I'll look a bit, did make other changes. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; mika at async.caltech.edu > Date: Wed, 29 Apr 2009 20:01:14 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Fwd: Output from "cron" command > > > Add this to your favorites or bookmarks or whatever: > > > http://tinderbox.elegosoft.com/tinderbox/cm3/status.html > > It's not the most friendly but it is ok. > > > Unfortunately the error is just: > > 12067 NEXT Bus Error - core dumped > > I'll undo stuff, like __thread mainly. > > - Jay > > > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: mika at async.caltech.edu >> Date: Thu, 30 Apr 2009 04:35:07 +1000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Fwd: Output from "cron" command >> >> Tinderbox... >> >> On 30 Apr 2009, at 04:32, Mika Nystrom wrote: >> >>> >>> I found I had made a typo in my m3tk check-in. Is there an easy >>> way to see what the error is? >>> >>> Mika >>> >>> Tony Hosking writes: >>>> >>>> --Apple-Mail-6-728527402 >>>> Content-Type: text/plain; >>>> charset=US-ASCII; >>>> format=flowed >>>> Content-Transfer-Encoding: 7bit >>>> >>>> Now I am getting compile errors. Recent checkins are culpable. >>>> >>>> Begin forwarded message: >>>> >>>>> From: Tony Hosking >>>>> Date: 29 April 2009 23:21:16 GMT+10:00 >>>>> To: hosking at cs.purdue.edu >>>>> Subject: Output from "cron" command >>>>> >>>>> Your "cron" job on niagara.cs.purdue.edu >>>>> $HOME/cm3/scripts/regression/cron.sh >>>>> >>>>> produced the following output: >>>>> >>>>> TESTHOSTNAME=niagara >>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-10-30-05 >>>>> LASTREL=5.4.0 >>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>> CM3_OSTYPE=POSIX >>>>> CM3_TARGET=SOLgnu >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSSERVER=birch.elegosoft.com >>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSUSER= >>>>> testing ssh birch.elegosoft.com.. >>>>> ssh birch.elegosoft.com ok >>>>> Building cm3. >>>>> Tinderbox Tree: "cm3" >>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>> >>>>> creating log file /tmp/build-cm3-20090429-063007-_Laq8F/log.txt >>>>> >>>>> --- >>>>> >>>>> checkout, compile and test of cm3 ... >>>>> 2009.04.29 06:30:07 -- checkout in progress. >>>>> [start checkout 2009.04.29 06:30:09] >>>>> cd /tmp/build-cm3-20090429-063007-_Laq8F/build >>>>> cvs return value: 0 >>>>> [end checkout 2009.04.29 06:49:37] >>>>> CHECKOUT_RETURN = 0 >>>>> -- >>>>> 2009.04.29 06:49:41 -- compile in progress. >>>>> [start compile 2009.04.29 06:49:41] >>>>> compile return value: 0 >>>>> [end compile 2009.04.29 08:10:32] >>>>> COMPILE_RETURN = 1 >>>>> *** COMPILE FAILED >>>>> removing build tree /tmp/build-cm3-20090429-063007-_Laq8F ... >>>>> cleaning CM3 workspaces... >>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>> >>>>> cleaning regression test log files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>> >>>>> cleaning m3test log files... >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>> >>>>> cleaning snapshot files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>> >>>>> cleaning package reports... >>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>> >>>>> TESTHOSTNAME=niagara >>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-12-12-22 >>>>> LASTREL=5.4.0 >>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>> CM3_OSTYPE=POSIX >>>>> CM3_TARGET=SOLgnu >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSSERVER=birch.elegosoft.com >>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSUSER= >>>>> testing ssh birch.elegosoft.com.. >>>>> ssh birch.elegosoft.com ok >>>>> Building cm3. >>>>> Tinderbox Tree: "cm3" >>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>> >>>>> creating log file /tmp/build-cm3-20090429-081224-i9aWYM/log.txt >>>>> >>>>> --- >>>>> >>>>> checkout, compile and test of cm3 ... >>>>> 2009.04.29 08:12:24 -- checkout in progress. >>>>> [start checkout 2009.04.29 08:12:26] >>>>> cd /tmp/build-cm3-20090429-081224-i9aWYM/build >>>>> cvs return value: 0 >>>>> [end checkout 2009.04.29 08:32:34] >>>>> CHECKOUT_RETURN = 0 >>>>> -- >>>>> 2009.04.29 08:32:38 -- compile in progress. >>>>> [start compile 2009.04.29 08:32:38] >>>>> compile return value: 0 >>>>> [end compile 2009.04.29 09:19:20] >>>>> COMPILE_RETURN = 0 >>>>> 2009.04.29 09:19:24 -- tests in progress. >>>>> [start run-tests 2009.04.29 09:19:24] >>>>> cd /tmp/build-cm3-20090429-081224-i9aWYM/build >>>>> [end run-tests 2009.04.29 09:19:24] >>>>> TESTS_RETURN = 0 >>>>> 2009.04.29 09:19:24 -- checkout, compile and test run done. >>>>> >>>>> --- >>>>> >>>>> removing build tree /tmp/build-cm3-20090429-081224-i9aWYM ... >>>>> cleaning CM3 workspaces... >>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>> >>>>> cleaning regression test log files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>> >>>>> cleaning m3test log files... >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>> >>>>> cleaning snapshot files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>> >>>>> cleaning package reports... >>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>> >>>>> done. >>>> >>>> >>>> --Apple-Mail-6-728527402 >>>> Content-Type: text/html; >>>> charset=US-ASCII >>>> Content-Transfer-Encoding: quoted-printable >>>> >>>>>>> space; = >>>> -webkit-line-break: after-white-space; "> >>>> apple-content-edited=3D"true">>>> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >>>> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >>>> normal; font-variant: normal; font-weight: normal; letter-spacing: = >>>> normal; line-height: normal; text-align: auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; "> >>>> style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; = >>>> -khtml-line-break: after-white-space; ">>>> span" = >>>> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >>>> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >>>> normal; font-variant: normal; font-weight: normal; letter-spacing: = >>>> normal; line-height: normal; text-align: auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; "> > Now I am = >>>> getting compile errors. Recent checkins are = >>>> culpable.>>> span>>>> iv> > > > Begin forwarded message: >>>> class=3D"Apple-interchange-newline">>>> type=3D"cite"> > >>>> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >>>> margin-left: 0px; ">>>> color=3D"#000000" = >>>> style=3D"font: 12.0px Helvetica; color: #000000">From: = >>>>>>> 12.0px = >>>> Helvetica">Tony Hosking <>>> href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu>>>> font>>>> iv> >>>> 0px; = >>>> margin-left: 0px; ">>>> color=3D"#000000" = >>>> style=3D"font: 12.0px Helvetica; color: #000000">Date: = >>>>>>> 12.0px = >>>> Helvetica">29 April 2009 23:21:16 GMT+10:00 >>>> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >>>> margin-left: 0px; ">>>> color=3D"#000000" = >>>> style=3D"font: 12.0px Helvetica; color: #000000">To:>>> font>>>> face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">>>> href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu>>> font>>>> v> >>>> 0px; = >>>> margin-left: 0px; ">>>> color=3D"#000000" = >>>> style=3D"font: 12.0px Helvetica; color: #000000">Subject: = >>>>>>> 12.0px = >>>> Helvetica">Output from "cron" command >>>> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >>>> margin-left: 0px; min-height: 14px; "> > > Your >>>> "cron" = >>>> job on = >>>> niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/ >>>> cron.sh > > produ= >>>> ced the following = >>>> output: > > TESTHOSTNAME=3Dniagara > WS=3D/homes/hosking/work/ >>>> cm3-ws/n= >>>> iagara-2009-04-29-10-30-05 > LASTREL=3D5.4.0 > INSTROOT_REL=3D/ >>>> homes/hos= >>>> king/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=3D/homes/ >>>> hosking/work= >>>> /cm3-inst/niagara/prev-ok > INSTROOT_LOK=3D/homes/hosking/work/cm3- >>>> inst/n= >>>> iagara/last-ok > INSTROOT_CUR=3D/homes/hosking/work/cm3-inst/ >>>> niagara/curr= >>>> ent > CM3_OSTYPE=3DPOSIX > CM3_TARGET=3DSOLgnu > BINDISTMIN=3D/ >>>> homes/ho= >>>> sking/work/cm3-min-POSIX- >>>> SOLgnu-5.4.0.tgz > CM3CVSSERVER=3Dbirch.elegosof= >>>> t.com > CM3CVSROOT=3Dbirch.elegosoft.com:/usr/ >>>> cvs > BINDISTMIN_NAME=3Dcm= >>>> 3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=3D/homes/hosking/work/ >>>> cm3-min-P= >>>> OSIX-SOLgnu-5.4.0.tgz > CM3CVSUSER=3D > testing ssh = >>>> birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building = >>>> cm3. > Tinderbox Tree: "cm3" > Buildname: = >>>> "SOLgnu SunOS 5.10 >>>> niagara = >>>> release-build" > > creating log file = >>>> /tmp/build-cm3-20090429-063007-_Laq8F/log.txt > > --- >>>> > > checkout, = >>>> compile and test of cm3 ... > 2009.04.29 06:30:07 -- checkout in = >>>> progress. > [start checkout 2009.04.29 06:30:09] > cd = >>>> /tmp/build-cm3-20090429-063007-_Laq8F/build > cvs return value: = >>>> 0 > [end checkout 2009.04.29 06:49:37] > CHECKOUT_RETURN =3D = >>> 0 > -- > 2009.04.29 06:49:41 -- compile in progress. > [start >>> compile = >>>> 2009.04.29 06:49:41] > compile return value: 0 > [end compile = >>>> 2009.04.29 08:10:32] > COMPILE_RETURN =3D 1 > *** COMPILE = >>>> FAILED > removing build tree /tmp/build-cm3-20090429-063007-_Laq8F = >>>> ... > cleaning CM3 = >>>> workspaces... > /homes/hosking/work/cm3-ws/niagara- >>>> * > > cleaning = >>>> regression test log = >>>> files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog- >>>> * > > cleaning = >>>> m3test log = >>>> files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > / >>>> homes/= >>>> hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/ >>>> cm3/nia= >>>> gara/m3tests-*.stderr.extract > > cleaning snapshot = >>>> files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >>>> *.tgz>>>> > cleaning package = >>>> reports... > /tmp/cm3-pkg-report-SOLgnu- >>>> *.html > > TESTHOSTNAME=3Dniag= >>>> ara > WS=3D/homes/hosking/work/cm3-ws/ >>>> niagara-2009-04-29-12-12-22 > LAST= >>>> REL=3D5.4.0 > INSTROOT_REL=3D/homes/hosking/work/cm3-inst/niagara/ >>>> rel-5.4= >>>> .0 > INSTROOT_POK=3D/homes/hosking/work/cm3-inst/niagara/prev- >>>> ok > INSTR= >>>> OOT_LOK=3D/homes/hosking/work/cm3-inst/niagara/last- >>>> ok > INSTROOT_CUR=3D/= >>>> homes/hosking/work/cm3-inst/niagara/ >>>> current > CM3_OSTYPE=3DPOSIX > CM3_T= >>>> ARGET=3DSOLgnu > BINDISTMIN=3D/homes/hosking/work/cm3-min-POSIX- >>>> SOLgnu-5.= >>>> 4.0 >>>> .tgz >>>> > CM3CVSSERVER=3Dbirch.elegosoft.com > CM3CVSROOT=3Dbirch.elegos= >>>> oft.com:/usr/cvs > BINDISTMIN_NAME=3Dcm3-min-POSIX- >>>> SOLgnu-5.4.0.tgz > BI= >>>> NDISTMIN=3D/homes/hosking/work/cm3-min-POSIX- >>>> SOLgnu-5.4.0.tgz > CM3CVSUSE= >>>> R=3D > testing ssh birch.elegosoft.com.. > ssh >>>> birch.elegosoft.com = >>>> ok > Building cm3. > Tinderbox Tree: >>>> "cm3" > Buildname: = >>>> "SOLgnu SunOS 5.10 >>>> niagara = >>>> lastok-build" > > creating log file = >>>> /tmp/build-cm3-20090429-081224-i9aWYM/log.txt > > --- >>>> > > checkout, = >>>> compile and test of cm3 ... > 2009.04.29 08:12:24 -- checkout in = >>>> progress. > [start checkout 2009.04.29 08:12:26] > cd = >>>> /tmp/build-cm3-20090429-081224-i9aWYM/build > cvs return value: = >>>> 0 > [end checkout 2009.04.29 08:32:34] > CHECKOUT_RETURN =3D = >>>> 0 > -- > 2009.04.29 08:32:38 -- compile in progress. > [start >>>> compile = >>>> 2009.04.29 08:32:38] > compile return value: 0 > [end compile = >>>> 2009.04.29 09:19:20] > COMPILE_RETURN =3D 0 > 2009.04.29 09:19:24 >>>> -- = >>>> tests in progress. > [start run-tests 2009.04.29 09:19:24] > cd = >>>> /tmp/build-cm3-20090429-081224-i9aWYM/build > [end run-tests >>>> 2009.04.29 = >>>> 09:19:24] > TESTS_RETURN =3D 0 > 2009.04.29 09:19:24 -- checkout, = >>> compile and test run done. > > --- > > removing build tree = >>>> /tmp/build-cm3-20090429-081224-i9aWYM ... > cleaning CM3 = >>>> workspaces... > /homes/hosking/work/cm3-ws/niagara- >>>> * > > cleaning = >>>> regression test log = >>>> files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog- >>>> * > > cleaning = >>>> m3test log = >>>> files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > / >>>> homes/= >>>> hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/ >>>> cm3/nia= >>>> gara/m3tests-*.stderr.extract > > cleaning snapshot = >>>> files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >>>> *.tgz>>>> > cleaning package = >>>> reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > done. >>>> div>>>> ockquote> > = >>>> >>>> --Apple-Mail-6-728527402-- >> From mika at async.caltech.edu Wed Apr 29 22:12:09 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 29 Apr 2009 13:12:09 -0700 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: Your message of "Wed, 29 Apr 2009 20:01:14 -0000." Message-ID: <200904292012.n3TKC93h043346@camembert.async.caltech.edu> This one is my fault: 27146 new source -> compiling Type.m3 27147 "../src/Type.m3", line 291: types are not assignable 27148 NEXT 1 error encountered I think I already fixed it, though. Mika Jay writes: > >Add this to your favorites or bookmarks or whatever: > > >http://tinderbox.elegosoft.com/tinderbox/cm3/status.html > >It's not the most friendly but it is ok. > > >Unfortunately the error is just: > >12067 NEXT Bus Error - core dumped > >I'll undo stuff, like __thread mainly. > > - Jay > > > > >---------------------------------------- >> From: hosking at cs.purdue.edu >> To: mika at async.caltech.edu >> Date: Thu, 30 Apr 2009 04:35:07 +1000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Fwd: Output from "cron" command >> >> Tinderbox... >> >> On 30 Apr 2009, at 04:32, Mika Nystrom wrote: >> >>> >>> I found I had made a typo in my m3tk check-in. Is there an easy >>> way to see what the error is? >>> >>> Mika >>> >>> Tony Hosking writes: >>>> >>>> --Apple-Mail-6-728527402 >>>> Content-Type: text/plain; >>>> charset=US-ASCII; >>>> format=flowed >>>> Content-Transfer-Encoding: 7bit >>>> >>>> Now I am getting compile errors. Recent checkins are culpable. >>>> >>>> Begin forwarded message: >>>> >>>>> From: Tony Hosking >>>>> Date: 29 April 2009 23:21:16 GMT+10:00 >>>>> To: hosking at cs.purdue.edu >>>>> Subject: Output from "cron" command >>>>> >>>>> Your "cron" job on niagara.cs.purdue.edu >>>>> $HOME/cm3/scripts/regression/cron.sh >>>>> >>>>> produced the following output: >>>>> >>>>> TESTHOSTNAME=niagara >>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-10-30-05 >>>>> LASTREL=5.4.0 >>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>> CM3_OSTYPE=POSIX >>>>> CM3_TARGET=SOLgnu >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSSERVER=birch.elegosoft.com >>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSUSER= >>>>> testing ssh birch.elegosoft.com.. >>>>> ssh birch.elegosoft.com ok >>>>> Building cm3. >>>>> Tinderbox Tree: "cm3" >>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>> >>>>> creating log file /tmp/build-cm3-20090429-063007-_Laq8F/log.txt >>>>> >>>>> --- >>>>> >>>>> checkout, compile and test of cm3 ... >>>>> 2009.04.29 06:30:07 -- checkout in progress. >>>>> [start checkout 2009.04.29 06:30:09] >>>>> cd /tmp/build-cm3-20090429-063007-_Laq8F/build >>>>> cvs return value: 0 >>>>> [end checkout 2009.04.29 06:49:37] >>>>> CHECKOUT_RETURN = 0 >>>>> -- >>>>> 2009.04.29 06:49:41 -- compile in progress. >>>>> [start compile 2009.04.29 06:49:41] >>>>> compile return value: 0 >>>>> [end compile 2009.04.29 08:10:32] >>>>> COMPILE_RETURN = 1 >>>>> *** COMPILE FAILED >>>>> removing build tree /tmp/build-cm3-20090429-063007-_Laq8F ... >>>>> cleaning CM3 workspaces... >>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>> >>>>> cleaning regression test log files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>> >>>>> cleaning m3test log files... >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>> >>>>> cleaning snapshot files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>> >>>>> cleaning package reports... >>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>> >>>>> TESTHOSTNAME=niagara >>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-12-12-22 >>>>> LASTREL=5.4.0 >>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>> CM3_OSTYPE=POSIX >>>>> CM3_TARGET=SOLgnu >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSSERVER=birch.elegosoft.com >>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSUSER= >>>>> testing ssh birch.elegosoft.com.. >>>>> ssh birch.elegosoft.com ok >>>>> Building cm3. >>>>> Tinderbox Tree: "cm3" >>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>> >>>>> creating log file /tmp/build-cm3-20090429-081224-i9aWYM/log.txt >>>>> >>>>> --- >>>>> >>>>> checkout, compile and test of cm3 ... >>>>> 2009.04.29 08:12:24 -- checkout in progress. >>>>> [start checkout 2009.04.29 08:12:26] >>>>> cd /tmp/build-cm3-20090429-081224-i9aWYM/build >>>>> cvs return value: 0 >>>>> [end checkout 2009.04.29 08:32:34] >>>>> CHECKOUT_RETURN = 0 >>>>> -- >>>>> 2009.04.29 08:32:38 -- compile in progress. >>>>> [start compile 2009.04.29 08:32:38] >>>>> compile return value: 0 >>>>> [end compile 2009.04.29 09:19:20] >>>>> COMPILE_RETURN = 0 >>>>> 2009.04.29 09:19:24 -- tests in progress. >>>>> [start run-tests 2009.04.29 09:19:24] >>>>> cd /tmp/build-cm3-20090429-081224-i9aWYM/build >>>>> [end run-tests 2009.04.29 09:19:24] >>>>> TESTS_RETURN = 0 >>>>> 2009.04.29 09:19:24 -- checkout, compile and test run done. >>>>> >>>>> --- >>>>> >>>>> removing build tree /tmp/build-cm3-20090429-081224-i9aWYM ... >>>>> cleaning CM3 workspaces... >>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>> >>>>> cleaning regression test log files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>> >>>>> cleaning m3test log files... >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>> >>>>> cleaning snapshot files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>> >>>>> cleaning package reports... >>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>> >>>>> done. >>>> >>>> >>>> --Apple-Mail-6-728527402 >>>> Content-Type: text/html; >>>> charset=US-ASCII >>>> Content-Transfer-Encoding: quoted-printable >>>> >>>>>>> space; = >>>> -webkit-line-break: after-white-space; "> >>>> apple-content-edited=3D"true">>>> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >>>> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >>>> normal; font-variant: normal; font-weight: normal; letter-spacing: = >>>> normal; line-height: normal; text-align: auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; "> >>>> style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; = >>>> -khtml-line-break: after-white-space; ">>>> span" = >>>> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >>>> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >>>> normal; font-variant: normal; font-weight: normal; letter-spacing: = >>>> normal; line-height: normal; text-align: auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; "> >Now I am = >>>> getting compile errors. Recent checkins are = >>>> culpable.>>> span>>>> iv> > > >Begin forwarded message: >>>> class=3D"Apple-interchange-newline">>>> type=3D"cite"> > >>>> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >>>> margin-left: 0px; ">>>> color=3D"#000000" = >>>> style=3D"font: 12.0px Helvetica; color: #000000">From: = >>>>>>> 12.0px = >>>> Helvetica">Tony Hosking <>>> href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu>>>> font>>>> iv> >>>> 0px; = >>>> margin-left: 0px; ">>>> color=3D"#000000" = >>>> style=3D"font: 12.0px Helvetica; color: #000000">Date: = >>>>>>> 12.0px = >>>> Helvetica">29 April 2009 23:21:16 GMT+10:00 >>>> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >>>> margin-left: 0px; ">>>> color=3D"#000000" = >>>> style=3D"font: 12.0px Helvetica; color: #000000">To:>>> font>>>> face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">>>> href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu>>> font>>>> >v> >>>> 0px; = >>>> margin-left: 0px; ">>>> color=3D"#000000" = >>>> style=3D"font: 12.0px Helvetica; color: #000000">Subject: = >>>>>>> 12.0px = >>>> Helvetica">Output from "cron" command >>>> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >>>> margin-left: 0px; min-height: 14px; "> > >Your >>>> "cron" = >>>> job on = >>>> niagara.cs.purdue.edu >$HOME/cm3/scripts/regression/ >>>> cron.sh > >produ= >>>> ced the following = >>>> output: > >TESTHOSTNAME=3Dniagara >WS=3D/homes/hosking/work/ >>>> cm3-ws/n= >>>> iagara-2009-04-29-10-30-05 >LASTREL=3D5.4.0 >INSTROOT_REL=3D/ >>>> homes/hos= >>>> king/work/cm3-inst/niagara/rel-5.4.0 >INSTROOT_POK=3D/homes/ >>>> hosking/work= >>>> /cm3-inst/niagara/prev-ok >INSTROOT_LOK=3D/homes/hosking/work/cm3- >>>> inst/n= >>>> iagara/last-ok >INSTROOT_CUR=3D/homes/hosking/work/cm3-inst/ >>>> niagara/curr= >>>> ent >CM3_OSTYPE=3DPOSIX >CM3_TARGET=3DSOLgnu >BINDISTMIN=3D/ >>>> homes/ho= >>>> sking/work/cm3-min-POSIX- >>>> SOLgnu-5.4.0.tgz >CM3CVSSERVER=3Dbirch.elegosof= >>>> t.com >CM3CVSROOT=3Dbirch.elegosoft.com:/usr/ >>>> cvs >BINDISTMIN_NAME=3Dcm= >>>> 3-min-POSIX-SOLgnu-5.4.0.tgz >BINDISTMIN=3D/homes/hosking/work/ >>>> cm3-min-P= >>>> OSIX-SOLgnu-5.4.0.tgz >CM3CVSUSER=3D >testing ssh = >>>> birch.elegosoft.com.. >ssh birch.elegosoft.com ok >Building = >>>> cm3. >Tinderbox Tree: "cm3" >Buildname: = >>>> "SOLgnu SunOS 5.10 >>>> niagara = >>>> release-build" > >creating log file = >>>> /tmp/build-cm3-20090429-063007-_Laq8F/log.txt > >--- >>>> > >checkout, = >>>> compile and test of cm3 ... >2009.04.29 06:30:07 -- checkout in = >>>> progress. >[start checkout 2009.04.29 06:30:09] >cd = >>>> /tmp/build-cm3-20090429-063007-_Laq8F/build >cvs return value: = >>>> 0 >[end checkout 2009.04.29 06:49:37] >CHECKOUT_RETURN =3D = >>> 0 >-- >2009.04.29 06:49:41 -- compile in progress. >[start >>> compile = >>>> 2009.04.29 06:49:41] >compile return value: 0 >[end compile = >>>> 2009.04.29 08:10:32] >COMPILE_RETURN =3D 1 >*** COMPILE = >>>> FAILED >removing build tree /tmp/build-cm3-20090429-063007-_Laq8F = >>>> ... >cleaning CM3 = >>>> workspaces... >/homes/hosking/work/cm3-ws/niagara- >>>> * > >cleaning = >>>> regression test log = >>>> files... >/homes/hosking/tmp/cm3/niagara/cm3-rlog- >>>> * > >cleaning = >>>> m3test log = >>>> files... >/homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > >/ >>>> homes/= >>>> hosking/tmp/cm3/niagara/m3tests-*.stderr > >/homes/hosking/tmp/ >>>> cm3/nia= >>>> gara/m3tests-*.stderr.extract > >cleaning snapshot = >>>> files... >/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >>>> *.tgz>>>> >cleaning package = >>>> reports... >/tmp/cm3-pkg-report-SOLgnu- >>>> *.html > >TESTHOSTNAME=3Dniag= >>>> ara >WS=3D/homes/hosking/work/cm3-ws/ >>>> niagara-2009-04-29-12-12-22 >LAST= >>>> REL=3D5.4.0 >INSTROOT_REL=3D/homes/hosking/work/cm3-inst/niagara/ >>>> rel-5.4= >>>> .0 >INSTROOT_POK=3D/homes/hosking/work/cm3-inst/niagara/prev- >>>> ok >INSTR= >>>> OOT_LOK=3D/homes/hosking/work/cm3-inst/niagara/last- >>>> ok >INSTROOT_CUR=3D/= >>>> homes/hosking/work/cm3-inst/niagara/ >>>> current >CM3_OSTYPE=3DPOSIX >CM3_T= >>>> ARGET=3DSOLgnu >BINDISTMIN=3D/homes/hosking/work/cm3-min-POSIX- >>>> SOLgnu-5.= >>>> 4.0 >>>> .tgz >>>> >CM3CVSSERVER=3Dbirch.elegosoft.com >CM3CVSROOT=3Dbirch.elegos= >>>> oft.com:/usr/cvs >BINDISTMIN_NAME=3Dcm3-min-POSIX- >>>> SOLgnu-5.4.0.tgz >BI= >>>> NDISTMIN=3D/homes/hosking/work/cm3-min-POSIX- >>>> SOLgnu-5.4.0.tgz >CM3CVSUSE= >>>> R=3D >testing ssh birch.elegosoft.com.. >ssh >>>> birch.elegosoft.com = >>>> ok >Building cm3. >Tinderbox Tree: >>>> "cm3" >Buildname: = >>>> "SOLgnu SunOS 5.10 >>>> niagara = >>>> lastok-build" > >creating log file = >>>> /tmp/build-cm3-20090429-081224-i9aWYM/log.txt > >--- >>>> > >checkout, = >>>> compile and test of cm3 ... >2009.04.29 08:12:24 -- checkout in = >>>> progress. >[start checkout 2009.04.29 08:12:26] >cd = >>>> /tmp/build-cm3-20090429-081224-i9aWYM/build >cvs return value: = >>>> 0 >[end checkout 2009.04.29 08:32:34] >CHECKOUT_RETURN =3D = >>>> 0 >-- >2009.04.29 08:32:38 -- compile in progress. >[start >>>> compile = >>>> 2009.04.29 08:32:38] >compile return value: 0 >[end compile = >>>> 2009.04.29 09:19:20] >COMPILE_RETURN =3D 0 >2009.04.29 09:19:24 >>>> -- = >>>> tests in progress. >[start run-tests 2009.04.29 09:19:24] >cd = >>>> /tmp/build-cm3-20090429-081224-i9aWYM/build >[end run-tests >>>> 2009.04.29 = >>>> 09:19:24] >TESTS_RETURN =3D 0 >2009.04.29 09:19:24 -- checkout, = >>> compile and test run done. > >--- > >removing build tree = >>>> /tmp/build-cm3-20090429-081224-i9aWYM ... >cleaning CM3 = >>>> workspaces... >/homes/hosking/work/cm3-ws/niagara- >>>> * > >cleaning = >>>> regression test log = >>>> files... >/homes/hosking/tmp/cm3/niagara/cm3-rlog- >>>> * > >cleaning = >>>> m3test log = >>>> files... >/homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > >/ >>>> homes/= >>>> hosking/tmp/cm3/niagara/m3tests-*.stderr > >/homes/hosking/tmp/ >>>> cm3/nia= >>>> gara/m3tests-*.stderr.extract > >cleaning snapshot = >>>> files... >/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >>>> *.tgz>>>> >cleaning package = >>>> reports... >/tmp/cm3-pkg-report-SOLgnu-*.html > >done. >>>> div>>>> ockquote> >= >>>> >>>> --Apple-Mail-6-728527402-- >> From jay.krell at cornell.edu Wed Apr 29 23:16:24 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 29 Apr 2009 21:16:24 +0000 Subject: [M3devel] [M3commit] how to switch userthreads on/off In-Reply-To: <69291A6D-E915-41C9-B4FB-AB7F5CF398EE@cs.purdue.edu> References: <200904290622.n3T6MZBR003219@camembert.async.caltech.edu> <69291A6D-E915-41C9-B4FB-AB7F5CF398EE@cs.purdue.edu> Message-ID: Really? I mean, partly, definitely. And I was looking at the "inflating" to see how they do conditionv variables. But, as I understand: The first time you enter a lock will be slow in that it will be heap allocate and pthread_mutex_init. (untraced; with implied use of a lock for the untraced heap). (plus pthread_mutex_lock(&init)). The subsequent times you enter a lock will be "slow" in that they will always call pthread_mutex_lock, but that might not be particularly slow, right? It is a function call, granted, but the implementation might/should be very quick in the case of no contention. Like, you know, presumably the pthread implementer, except on the case of FreeBSD 4.x :) is trying to do a pretty good job for everyone. "But I don't have numbers." - Jay ________________________________ > From: hosking at cs.purdue.edu > To: mika at async.caltech.edu > Date: Thu, 30 Apr 2009 04:33:01 +1000 > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] [M3commit] how to switch userthreads on/off > > Mika, > > With the current implementation of M3 MUTEX 1-1 as pthread mutex you are bound to have significant overhead for any locking code even in single-threaded apps. We need to move towards a thin-lock implementation for mutex (as used in modern Java implementations) to avoid overhead for uncontended locks. It's not too hard to implement. The idea is to represent a mutex as a tagged word. The word contains either NIL, the thread holding the lock, or a pointer to a full-blown (inflated) pthread mutex. We can use GC and other opportunities to deflate locks as needs. Checking the tag requires a CAS. There are other techniques that further eliminate the CAS for the uncontended case. But, generally, you should consider LOCK to be a fairly high-overhead operation for now. > > 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 29 Apr 2009, at 16:22, Mika Nystrom wrote: > > Jay writes: > ... > > Maybe just leave it as an option in m3core's m3makefile and people can twiddle it if they want and rebuild the entire system like it is today? > That is a bit onerous, but maybe it's all userthreads deserve? > ? > > > Anyone who actually wanted to switch back and forth (Mika) would just have two installs and two source trees? > > > - Jay > > I just want to clarify. I'm not really that interested in switching > back and forth. I'm just a little disturbed by the sometimes huge > performance loss due to the introduction of kernel threads. I knew > that this would happen in certain highly multithreaded applications, > but I'm surprised it happens in a more or less single-threaded > application. > > I think I've just been spoiled by 10 years of using SRCM3 and PM3 > for FreeBSD w/o kernel threads in the sense that I've learned that > using LOCK has essentially no cost. On a shared-memory multiprocessor, > I really don't expect that to remain the case... physics won't allow > it. So now I just have to go through my code and find all the places > where I lock too much and remove them. > > But the memory allocator and garbage collector do it too, no? > > I also think that this idea of being able to use either is great. > Mainly single-threaded programs should definitely not use kernel > threads! > > As for reaching the "thread locals", there is one slightly crazy > idea that one could borrow from Sussman and Steele: add another > implicit argument to every Modula-3 routine. In that argument, > pass a pointer to the thread locals. For EXTERNAL calls (in or > out), make it NIL (somehow, maybe involving pragmas), and in that > case (only), use the pthreads routines to access the thread locals. > Ok so it sounds kind of nuts, but with this approach you could avoid > locking or even calling into the pthreads libs almost entirely for > a single-threaded program. You could even have a thread-local > memory allocator that would only lock when it needs to request > memory from the "global allocator"... in fact there are lots of > things you can do with this sort of thing. Dynamically scoped > variables in Scheme (a la MacLisp?) is what they originally proposed > it for but then they suggested all kinds of tricks related to > continuations with it. > > Mika > From jay.krell at cornell.edu Wed Apr 29 23:26:42 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 29 Apr 2009 21:26:42 +0000 Subject: [M3devel] user threads In-Reply-To: <200904291846.n3TIk3F6038926@camembert.async.caltech.edu> References: Your message of "Thu, 30 Apr 2009 04:04:22 +1000." <736196D3-6AA1-49C4-80E8-4EEB05B38CFC@cs.purdue.edu> <200904291846.n3TIk3F6038926@camembert.async.caltech.edu> Message-ID: > I think if possible "M3 user threads" should definitely be the > default on FreeBSD4 and earlier, rather than "system user threads". I'm tempted to add FreeBSD5 and possibly 6,7,8. Or I386_FREEBSD to imply>=5 (though it'd also work, slowly, for 4) They would all use the same Unix/*.i3 files (not even copies), take the same code in Target.m3. The only difference would be the default threading model in thread.quake and probably a line in the config file to use -lpthread vs. -lc_r. And the default archive/distribution names, if nothing else is done about them. And MAYBE restore the global for pusheframe -- though that precludes I think leaving FreeBSD1-4 able to use their usermode pthreads. That's a microptimization though, for a dying system(s). On the other hand, there might not be more than one FreeBSD 4 user and he can just edit hits m3core/thread.quake?? Mika maybe you'll collect some pthread numbers on FreeBSD 5 soon and dump 4? - Jay From wagner at elegosoft.com Thu Apr 30 08:42:00 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Apr 2009 08:42:00 +0200 Subject: [M3devel] user threads In-Reply-To: References: <200904291846.n3TIk3F6038926@camembert.async.caltech.edu> Message-ID: <20090430084200.7e7jwrb9pck0wwsk@mail.elegosoft.com> Quoting Tony Hosking : > On 30 Apr 2009, at 04:46, Mika Nystrom wrote: > >> But what Jay has pointed out is that what I labeled as "kernel >> threads" in the attached table aren't kernel threads at all but >> libc_r threads, which provide the same facilities (as far as I know) >> as M3's "user threads". In this case M3's user threads are simply >> superior to what the system provides. Much superior. > > Ah, understood. Threading on FreeBSD has been a sad topic for many years. Actually I think I was among the first who ever got a threading library working on FreeBSD (was it still 1.5 or some 2.x?) for the company I worked for in the 1990s (Point-of-Sale applications). Unfortunately, that system was never sold nor could it be released as open source. There was no official FreeBSD thread support then. Later official solutions were always wanting in functionality or performance. I think in FreeBSD 6 there are not less than three different implementations, all of which have some advantages and disadvantages. But M3 threads were always much faster than any of the FreeBSD libraries. I think the situation may have got better in FreeBSD 7, but I haven't really tried that. >> I think if possible "M3 user threads" should definitely be the >> default on FreeBSD4 and earlier, rather than "system user threads". > > Fair enough. Old thread libraries were pretty substandard. Indeed. And that's exactly why I'm still a `fan' of the M3 threads and think they should not be abandoned and be available for certain applications. Sorry, I couldn't resist to comment on this again :-) I'll return to serious work now and will not feed the M3 mail flood (which is really a good thing as it shows the interest and activity) any more, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 30 10:58:58 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 30 Apr 2009 01:58:58 -0700 Subject: [M3devel] user threads In-Reply-To: Your message of "Wed, 29 Apr 2009 07:05:10 -0000." Message-ID: <200904300858.n3U8wwAM078186@camembert.async.caltech.edu> I have to re-build everything again? It segfaults on my 5.5 system with that change. Btw, here are timings on FreeBSD 5.5 libc_r 1642 ms pthread 1646 ms PM3 504 ms Roughly the same program as before. Slightly different hardware (AM2 I think). Mika Jay writes: >--_57af40c5-3867-4a47-915e-00f808c2e343_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Mika=2C thanks. Want to try the next variation? look at m3-libs/m3core/src/= >thread/PTHREAD/ThreadPThreadC.c. > >See THREAD_LOCAL=2C THREAD_LOCAL_SLOW=2C THREAD_LOCAL_FAST? Try switching T= >HREAD_LOCAL to use THREAD_LOCAL_FAST instead of _SLOW. On FreeBSD 5.x or ne= >wer. > >It won't compile for 4.x we know. > >=20 > >Thanks=2C > > - Jay > >=20 >> To: jay.krell at cornell.edu >> Date: Tue=2C 28 Apr 2009 23:53:32 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] user threads >>=20 >> Ok=2C it works! >>=20 >> Numbers: >>=20 >> Timings in milliseconds=2C three samples=2C filesystem "warmed up" by >> doing one dummy run before launching the real ones. >>=20 >> -unsafe means that I use non-locking Scheme environments=2C otherwise >> they lock for every variable update. >> ave=20 >> CM3 last week=2C kernel threads=2C -unsafe 1460 1482 1437 1460 >> CM3 last week=2C kernel threads=2C 2392 2402 2376 2390 >> CM3 this week=2C kernel threads=2C -unsafe 1455 1458 1490 1468 (*) >> CM3 this week=2C user threads=2C -unsafe 914 934 914 921 >> CM3 this week=2C user threads=2C 967 965 986 973 >> PM3 -unsafe 678 657 682 672 >> PM3 709 714 700 708 >>=20 >> (*) not entirely sure this got linked correctly. >>=20 >> Mika >>=20 >>=20 >> Jay writes: >> > >> >User threads seem to work on on FreeBSD/x86 7.0. >> >Mika can you report back the perf cm3 vs. pm3? >> >Still=2C kernel threads have been around a long time and imho should be = >strongly favored.. >> >=20 >> >=20 >> >Kernel threads should be a /little/ faster than they were -- PushEFrame = >removed from successful heap allocations. And should be further improvable = >via __thread where it is supported -- probably not FreeBSD 4. >> >x=2C sometimes older is not better. :) >> >=20 >> >=20 >> >I've temporarily switched FreeBSD/x86 to userthreads by default but I th= >ink that's just an experiment and should be undone shortly=2C maybe work ou= >t some other story for easily switching between them=2C or just k >> >eep the existing story of "you get to rebuild everything". >> >=20 >> >=20 >> >Tony=2C can you look into GetGCRatio? I removed the call to it. The "fat= >al" pragma invokes PushEFrame apparently. >> >=20 >> >=20 >> >We should now "fix" Win32 and pthreads to not have GetActivation initial= >ize on-demand=2C just leave Init to initialize always. This should shave a = >few more cycles from PushEFrame. >> >=20 >> >=20 >> > - Jay > >--_57af40c5-3867-4a47-915e-00f808c2e343_ >Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > > > > > >Mika=2C =3Bthanks. Want to try the next variation? look at m3-libs/m3co= >re/src/thread/PTHREAD/ThreadPThreadC.c.
>See THREAD_LOCAL=2C THREAD_LOCAL_SLOW=2C THREAD_LOCAL_FAST? Try switching T= >HREAD_LOCAL to use THREAD_LOCAL_FAST instead of _SLOW. On FreeBSD 5.x or&nb= >sp=3Bnewer.
>It won't compile for 4.x we know.
> =3B
>Thanks=2C
> =3B- Jay

 =3B
>=3B To: jay.krell at cornell.edu
>=3B= > Date: Tue=2C 28 Apr 2009 23:53:32 -0700
>=3B From: mika at async.caltech= >.edu
>=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] u= >ser threads
>=3B
>=3B Ok=2C it works!
>=3B
>=3B Numbe= >rs:
>=3B
>=3B Timings in milliseconds=2C three samples=2C filesy= >stem "warmed up" by
>=3B doing one dummy run before launching the real= > ones.
>=3B
>=3B -unsafe means that I use non-locking Scheme env= >ironments=2C otherwise
>=3B they lock for every variable update.
&g= >t=3B ave
>=3B CM3 last week=2C kernel threads=2C -unsafe 1460 1482 14= >37 1460
>=3B CM3 last week=2C kernel threads=2C 2392 2402 2376 2390>>=3B CM3 this week=2C kernel threads=2C -unsafe 1455 1458 1490 1468 (*)<= >BR>>=3B CM3 this week=2C user threads=2C -unsafe 914 934 914 921
>= >=3B CM3 this week=2C user threads=2C 967 965 986 973
>=3B PM3 -unsafe = >678 657 682 672
>=3B PM3 709 714 700 708
>=3B
>=3B (*) not = >entirely sure this got linked correctly.
>=3B
>=3B Mika
>= >=3B
>=3B
>=3B Jay writes:
>=3B >=3B
>=3B >=3BUser= > threads seem to work on on FreeBSD/x86 7.0.
>=3B >=3BMika can you r= >eport back the perf cm3 vs. pm3?
>=3B >=3BStill=2C kernel threads ha= >ve been around a long time and imho should be strongly favored..
>=3B = >>=3B
>=3B >=3B
>=3B >=3BKernel threads should be a /littl= >e/ faster than they were -- PushEFrame removed from successful heap allocat= >ions. And should be further improvable via __thread where it is supported -= >- probably not FreeBSD 4.
>=3B >=3Bx=2C sometimes older is not bette= >r. :)
>=3B >=3B
>=3B >=3B
>=3B >=3BI've temporarily = >switched FreeBSD/x86 to userthreads by default but I think that's just an e= >xperiment and should be undone shortly=2C maybe work out some other story f= >or easily switching between them=2C or just k
>=3B >=3Beep the exist= >ing story of "you get to rebuild everything".
>=3B >=3B
>=3B &= >gt=3B
>=3B >=3BTony=2C can you look into GetGCRatio? I removed the = >call to it. The "fatal" pragma invokes PushEFrame apparently.
>=3B >= >=3B
>=3B >=3B
>=3B >=3BWe should now "fix" Win32 and pthrea= >ds to not have GetActivation initialize on-demand=2C just leave Init to ini= >tialize always. This should shave a few more cycles from PushEFrame.
>= >=3B >=3B
>=3B >=3B
>=3B >=3B - Jay
>= > >--_57af40c5-3867-4a47-915e-00f808c2e343_-- From wagner at elegosoft.com Thu Apr 30 11:05:15 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Apr 2009 11:05:15 +0200 Subject: [M3devel] [M3commit] how to switch userthreads on/off In-Reply-To: References: Your message of "Wed, 29 Apr 2009 00:06:02 -0000." <200904290622.n3T6MZBR003219@camembert.async.caltech.edu> Message-ID: <20090430110515.lnlfuu02v4sso0wo@mail.elegosoft.com> Quoting Jay : > Olaf, your recall that FreeBSD userthreads were "fast"..is that > based on FreeBSD 4.x by chance? Maybe they don't have much advantage > on any other system? > > You know...FreeBSD 4.x pthreads are also userthreads, not really a > fair comparison maybe with other pthreads implementations and maybe > give pthreads a bad name? I'm afraid I cannot provide any exact numbers or test results any more, so the validity of all my comments must be treated very carefully. AFAIR M3 user threads on FreeBSD were fast compared to the system implementation of pthreads even in 4.x. FreeBSD system threads that are `real' kernel threads were introduced later, when the system was incrementally made ready for multi-CPU-support. I think this change has not been completed until 7.0. (All systems after 4.x were much less stable due to this transition.). One of the bottlenecks _may_ have been the malloc implementation. The FreeBSD pthreads implementation in 4.x were indeed user-level threads, but they were not very performant compared to what would have been possible IIRC. There was also an implementation which used process structures as threads ported from Linux (known as Linux-threads). Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 30 11:18:47 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Apr 2009 11:18:47 +0200 Subject: [M3devel] any limitations on __thread? In-Reply-To: References: Message-ID: <20090430111847.0vqnqf8yrs4gkkw4@mail.elegosoft.com> Quoting Jay : > > Anyone have expertise on __thread? > In particular, on Windows there is a close analog __declspec(thread) > that generally would seem to work and work well, except that, per > documentation, prior to Vista, it doesn't work if you are loaded > with LoadLibrary (dlopen), only if the main executable uses your > .so, directly or indirectly. To me that's a pretty big limitation so > I wouldn't use it. I haven't seen any documentation on __thread > giving this caveat though so it seems ok to use. > > I changed m3core to use it if sample code seems to compile, link, > and execute correctly with it. This is done at installation time, I assume? Where is this test located? > > > - 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 Thu Apr 30 12:14:47 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 30 Apr 2009 03:14:47 -0700 Subject: [M3devel] any limitations on __thread? In-Reply-To: <20090430111847.0vqnqf8yrs4gkkw4@mail.elegosoft.com> References: <20090430111847.0vqnqf8yrs4gkkw4@mail.elegosoft.com> Message-ID: <454BD710-4008-4045-B7EB-EF76D823BD49@hotmail.com> It was to be done every time building m3core. Fast enough. I removed it for now. Pic makes it a smaller win, I have no numbers, and broke Tony's build. It would also reduce but not eliminate leak upon dynamic unload, which we should consider anyway. It was in m3core/src/thread/pthread/m3makefile. - Jay (phone) On Apr 30, 2009, at 2:18 AM, Olaf Wagner wrote: > Quoting Jay : > >> >> Anyone have expertise on __thread? >> In particular, on Windows there is a close analog >> __declspec(thread) that generally would seem to work and work >> well, except that, per documentation, prior to Vista, it doesn't >> work if you are loaded with LoadLibrary (dlopen), only if the main >> executable uses your .so, directly or indirectly. To me that's a >> pretty big limitation so I wouldn't use it. I haven't seen any >> documentation on __thread giving this caveat though so it seems ok >> to use. >> >> I changed m3core to use it if sample code seems to compile, link, >> and execute correctly with it. > > This is done at installation time, I assume? > Where is this test located? > >> >> >> - 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 Thu Apr 30 12:17:58 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 30 Apr 2009 03:17:58 -0700 Subject: [M3devel] user threads In-Reply-To: <200904300858.n3U8wwAM078186@camembert.async.caltech.edu> References: <200904300858.n3U8wwAM078186@camembert.async.caltech.edu> Message-ID: <840816F3-68FF-4B8B-A52A-2B6ED8A8BBB1@hotmail.com> No need for clean here. Lets punt threads for now and look at typecase. - Jay (phone) On Apr 30, 2009, at 1:58 AM, Mika Nystrom wrote: > I have to re-build everything again? It segfaults on my 5.5 system > with that > change. > > Btw, here are timings on FreeBSD 5.5 > > libc_r 1642 ms > pthread 1646 ms > PM3 504 ms > > Roughly the same program as before. Slightly different hardware > (AM2 I think). > > Mika > > Jay writes: >> --_57af40c5-3867-4a47-915e-00f808c2e343_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> Mika=2C thanks. Want to try the next variation? look at m3-libs/ >> m3core/src/= >> thread/PTHREAD/ThreadPThreadC.c. >> >> See THREAD_LOCAL=2C THREAD_LOCAL_SLOW=2C THREAD_LOCAL_FAST? Try >> switching T= >> HREAD_LOCAL to use THREAD_LOCAL_FAST instead of _SLOW. On FreeBSD >> 5.x or ne= >> wer. >> >> It won't compile for 4.x we know. >> >> =20 >> >> Thanks=2C >> >> - Jay >> >> =20 >>> To: jay.krell at cornell.edu >>> Date: Tue=2C 28 Apr 2009 23:53:32 -0700 >>> From: mika at async.caltech.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] user threads >>> =20 >>> Ok=2C it works! >>> =20 >>> Numbers: >>> =20 >>> Timings in milliseconds=2C three samples=2C filesystem "warmed up" >>> by >>> doing one dummy run before launching the real ones. >>> =20 >>> -unsafe means that I use non-locking Scheme environments=2C >>> otherwise >>> they lock for every variable update. >>> ave=20 >>> CM3 last week=2C kernel threads=2C -unsafe 1460 1482 1437 1460 >>> CM3 last week=2C kernel threads=2C 2392 2402 2376 2390 >>> CM3 this week=2C kernel threads=2C -unsafe 1455 1458 1490 1468 (*) >>> CM3 this week=2C user threads=2C -unsafe 914 934 914 921 >>> CM3 this week=2C user threads=2C 967 965 986 973 >>> PM3 -unsafe 678 657 682 672 >>> PM3 709 714 700 708 >>> =20 >>> (*) not entirely sure this got linked correctly. >>> =20 >>> Mika >>> =20 >>> =20 >>> Jay writes: >>>> >>>> User threads seem to work on on FreeBSD/x86 7.0. >>>> Mika can you report back the perf cm3 vs. pm3? >>>> Still=2C kernel threads have been around a long time and imho >>>> should be = >> strongly favored.. >>>> =20 >>>> =20 >>>> Kernel threads should be a /little/ faster than they were -- >>>> PushEFrame = >> removed from successful heap allocations. And should be further >> improvable = >> via __thread where it is supported -- probably not FreeBSD 4. >>>> x=2C sometimes older is not better. :) >>>> =20 >>>> =20 >>>> I've temporarily switched FreeBSD/x86 to userthreads by default >>>> but I th= >> ink that's just an experiment and should be undone shortly=2C maybe >> work ou= >> t some other story for easily switching between them=2C or just k >>>> eep the existing story of "you get to rebuild everything". >>>> =20 >>>> =20 >>>> Tony=2C can you look into GetGCRatio? I removed the call to it. >>>> The "fat= >> al" pragma invokes PushEFrame apparently. >>>> =20 >>>> =20 >>>> We should now "fix" Win32 and pthreads to not have GetActivation >>>> initial= >> ize on-demand=2C just leave Init to initialize always. This should >> shave a = >> few more cycles from PushEFrame. >>>> =20 >>>> =20 >>>> - Jay >> >> --_57af40c5-3867-4a47-915e-00f808c2e343_ >> Content-Type: text/html; charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable >> >> >> >> >> >> >> Mika=2C =3Bthanks. Want to try the next variation? look at m3- >> libs/m3co= >> re/src/thread/PTHREAD/ThreadPThreadC.c.
>> See THREAD_LOCAL=2C THREAD_LOCAL_SLOW=2C THREAD_LOCAL_FAST? Try >> switching T= >> HREAD_LOCAL to use THREAD_LOCAL_FAST instead of _SLOW. On FreeBSD >> 5.x or&nb= >> sp=3Bnewer.
>> It won't compile for 4.x we know.
>>  =3B
>> Thanks=2C
>>  =3B- Jay

 =3B
>=3B To: >> jay.krell at cornell.edu
>=3B= >> Date: Tue=2C 28 Apr 2009 23:53:32 -0700
>=3B From: mika at async.caltech >> = >> .edu
>=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: >> [M3devel] u= >> ser threads
>=3B
>=3B Ok=2C it works!
>=3B >>
>=3B Numbe= >> rs:
>=3B
>=3B Timings in milliseconds=2C three >> samples=2C filesy= >> stem "warmed up" by
>=3B doing one dummy run before launching >> the real= >> ones.
>=3B
>=3B -unsafe means that I use non-locking >> Scheme env= >> ironments=2C otherwise
>=3B they lock for every variable >> update.
&g= >> t=3B ave
>=3B CM3 last week=2C kernel threads=2C -unsafe 1460 1482 14 >> = >> 37 1460
>=3B CM3 last week=2C kernel threads=2C 2392 2402 2376 >> 2390>> >=3B CM3 this week=2C kernel threads=2C -unsafe 1455 1458 1490 >>> 1468 (*)<= >> BR>>=3B CM3 this week=2C user threads=2C -unsafe 914 934 914 >> 921
>= >> =3B CM3 this week=2C user threads=2C 967 965 986 973
>=3B PM3 - >> unsafe = >> 678 657 682 672
>=3B PM3 709 714 700 708
>=3B
>=3B >> (*) not = >> entirely sure this got linked correctly.
>=3B
>=3B >> Mika
>= >> =3B
>=3B
>=3B Jay writes:
>=3B >=3B
>=3B >> >=3BUser= >> threads seem to work on on FreeBSD/x86 7.0.
>=3B >=3BMika >> can you r= >> eport back the perf cm3 vs. pm3?
>=3B >=3BStill=2C kernel >> threads ha= >> ve been around a long time and imho should be strongly >> favored..
>=3B = >> >=3B
>=3B >=3B
>=3B >=3BKernel threads should be >> a /littl= >> e/ faster than they were -- PushEFrame removed from successful heap >> allocat= >> ions. And should be further improvable via __thread where it is >> supported -= >> - probably not FreeBSD 4.
>=3B >=3Bx=2C sometimes older is >> not bette= >> r. :)
>=3B >=3B
>=3B >=3B
>=3B >=3BI've >> temporarily = >> switched FreeBSD/x86 to userthreads by default but I think that's >> just an e= >> xperiment and should be undone shortly=2C maybe work out some other >> story f= >> or easily switching between them=2C or just k
>=3B >=3Beep >> the exist= >> ing story of "you get to rebuild everything".
>=3B >=3B >>
>=3B &= >> gt=3B
>=3B >=3BTony=2C can you look into GetGCRatio? I >> removed the = >> call to it. The "fatal" pragma invokes PushEFrame >> apparently.
>=3B >= >> =3B
>=3B >=3B
>=3B >=3BWe should now "fix" Win32 >> and pthrea= >> ds to not have GetActivation initialize on-demand=2C just leave >> Init to ini= >> tialize always. This should shave a few more cycles from >> PushEFrame.
>= >> =3B >=3B
>=3B >=3B
>=3B >=3B - Jay
>> = >> >> --_57af40c5-3867-4a47-915e-00f808c2e343_-- > From hosking at cs.purdue.edu Thu Apr 30 19:35:23 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 1 May 2009 03:35:23 +1000 Subject: [M3devel] Fwd: Output from "cron" command References: <200904301321.n3UDL5s4029847@niagara.cs.purdue.edu> Message-ID: Something is still broken with builds on SOLgnu: Begin forwarded message: > From: Tony Hosking > Date: 30 April 2009 23:21:05 GMT+10:00 > To: hosking at cs.purdue.edu > Subject: Output from "cron" command > > Your "cron" job on niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/cron.sh > > produced the following output: > > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-04-30-10-30-04 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSUSER= > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara release-build" > > creating log file /tmp/build-cm3-20090430-063006-xlaG7T/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.04.30 06:30:06 -- checkout in progress. > [start checkout 2009.04.30 06:30:09] > cd /tmp/build-cm3-20090430-063006-xlaG7T/build > cvs return value: 0 > [end checkout 2009.04.30 06:49:48] > CHECKOUT_RETURN = 0 > -- > 2009.04.30 06:49:51 -- compile in progress. > [start compile 2009.04.30 06:49:51] > compile return value: 0 > [end compile 2009.04.30 08:10:52] > COMPILE_RETURN = 1 > *** COMPILE FAILED > removing build tree /tmp/build-cm3-20090430-063006-xlaG7T ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-04-30-12-12-43 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSUSER= > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" > > creating log file /tmp/build-cm3-20090430-081245-KRaGZ0/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.04.30 08:12:45 -- checkout in progress. > [start checkout 2009.04.30 08:12:47] > cd /tmp/build-cm3-20090430-081245-KRaGZ0/build > cvs return value: 0 > [end checkout 2009.04.30 08:32:38] > CHECKOUT_RETURN = 0 > -- > 2009.04.30 08:32:41 -- compile in progress. > [start compile 2009.04.30 08:32:41] > compile return value: 0 > [end compile 2009.04.30 09:19:11] > COMPILE_RETURN = 0 > 2009.04.30 09:19:15 -- tests in progress. > [start run-tests 2009.04.30 09:19:15] > cd /tmp/build-cm3-20090430-081245-KRaGZ0/build > [end run-tests 2009.04.30 09:19:15] > TESTS_RETURN = 0 > 2009.04.30 09:19:15 -- checkout, compile and test run done. > > --- > > removing build tree /tmp/build-cm3-20090430-081245-KRaGZ0 ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > done. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Apr 1 00:03:50 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 01 Apr 2009 00:03:50 +0200 Subject: [M3devel] m3 CVS? In-Reply-To: <47E57322-28FD-4C9E-B1FE-12761C6F32AB@cs.purdue.edu> References: <20090325135234.GA16351@topoi.pooq.com> <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> <20090325144505.GA16526@topoi.pooq.com> <20090325225421.GB17118@topoi.pooq.com> <20090330131918.GA6921@topoi.pooq.com> <20090331133910.flci659jockgo04c@mail.elegosoft.com> <20090331135610.GA9539@topoi.pooq.com> <20090331161908.3pferzf9c08oso40@mail.elegosoft.com> <20090331144252.GA9624@topoi.pooq.com> <20090331173542.60xixsbl4w4kcsgs@mail.elegosoft.com> <47E57322-28FD-4C9E-B1FE-12761C6F32AB@cs.purdue.edu> Message-ID: <20090401000350.9ulc6eobpk44coo0@mail.elegosoft.com> Quoting Tony Hosking : > Both PM3 and CM3 forked from SRC M3. Yes, the releases both built on the SRC source, but as far as I know there was never one repository where the history was combined. Olaf > On 1 Apr 2009, at 02:35, Olaf Wagner wrote: > >> Quoting hendrik at topoi.pooq.com: >> >>> Speaking of ancient history -- Are cm3 and pm3 both in one CVS so that >>> they share history? Or are they in separate CVS's? >> >> CM3 and PM3 are two separate repositories. SRC never used CVS for M3 >> version control (don't exactly know how they did managed the sources). >> PM3 was created by Michel Dagenais as an open source continuation of >> SRC M3, while CM3 started as a commercial product and was later open >> sourced. >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Wed Apr 1 00:38:59 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 31 Mar 2009 18:38:59 -0400 Subject: [M3devel] m3 CVS? In-Reply-To: <20090401000350.9ulc6eobpk44coo0@mail.elegosoft.com> References: <20090325225421.GB17118@topoi.pooq.com> <20090330131918.GA6921@topoi.pooq.com> <20090331133910.flci659jockgo04c@mail.elegosoft.com> <20090331135610.GA9539@topoi.pooq.com> <20090331161908.3pferzf9c08oso40@mail.elegosoft.com> <20090331144252.GA9624@topoi.pooq.com> <20090331173542.60xixsbl4w4kcsgs@mail.elegosoft.com> <47E57322-28FD-4C9E-B1FE-12761C6F32AB@cs.purdue.edu> <20090401000350.9ulc6eobpk44coo0@mail.elegosoft.com> Message-ID: <20090331223859.GC10145@topoi.pooq.com> On Wed, Apr 01, 2009 at 12:03:50AM +0200, Olaf Wagner wrote: > Quoting Tony Hosking : > > >Both PM3 and CM3 forked from SRC M3. > > Yes, the releases both built on the SRC source, but as far as I know > there was never one repository where the history was combined. > > Olaf I suspect combining them would be more work than it's worth. And only feasible if the SRC source both forked from is still in existence. But tempting. -- hendrik From jay.krell at cornell.edu Wed Apr 1 00:41:42 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 31 Mar 2009 22:41:42 +0000 Subject: [M3devel] m3 CVS? In-Reply-To: <20090331161908.3pferzf9c08oso40@mail.elegosoft.com> References: <20090325083158.hkinn8yjkksocw4c@mail.elegosoft.com> <20090325135234.GA16351@topoi.pooq.com> <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> <20090325144505.GA16526@topoi.pooq.com> <20090325225421.GB17118@topoi.pooq.com> <20090330131918.GA6921@topoi.pooq.com> <20090331133910.flci659jockgo04c@mail.elegosoft.com> <20090331135610.GA9539@topoi.pooq.com> <20090331161908.3pferzf9c08oso40@mail.elegosoft.com> Message-ID: Also, presumably you can copy the entire CVS repository with little CPU use and then do the monotone work locally. I doubt it is all that large, can tell you later.. (ssh in and du /usr/cvs) - Jay > Date: Tue, 31 Mar 2009 16:19:08 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > CC: manderson at elego.de > Subject: Re: [M3devel] m3 CVS? > > Quoting hendrik at topoi.pooq.com: > > > On Tue, Mar 31, 2009 at 01:39:10PM +0200, Olaf Wagner wrote: > >> Quoting hendrik at topoi.pooq.com: > >> > >> >Is CVS back up yet? Completely? I've been delaying trying the > >> >monotone conversion because it would be nice to have only one set > >> >of problems to look into. > >> > >> CVS is up and no history should be lost, but tinderbox is still not > >> working and several archives are missing. Michael is working on it > >> (but he's got some other tasks, too). > > > > So the current source is available, but not the tools to investigate > > their status on-line. And the other archives? What are they? Are they > > more source code? Should they be subject to revision control too? Are > > they ancient prehistory that should be grafted into the revision tree > > except that it may not be technically feasible? > > Mostly all the old installation archives and snapshots are still missing. > I'm not sure what's the status of the re-installation of tinderbox. > > > Ah. I have too many questions. > > > > By the way, rumours are that monotone's cvs pull command is quite > > demanding on the cvs server, but that sync operation isn't bad at all > > after that. Getting really old versions of files requires CVS to chain > > back through a lot of reverse differences. And I don't know if it > > caches any of that in case it is asked to cough up another really old > > version. > > > > If there are any scheduling considerations I'd like to hear them. I > > don't know if I'll flatten your system, but if I do there are probably > > better and worse times to do it. (I may saturate ny DSL link first, but > > you never know until you try it.) > > > > By the way, what's the total size of Modula 3's CVS archive? > > I've got no access from here (can only check later tonight); please > ask Michael Anderson directly for administrative topics. > > Olaf > > PS: I don't think you can bring the server down a one external CVS > client; the syncing will just take a long time. Unless lots of parallel > requests are started... > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 1 00:43:41 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 31 Mar 2009 22:43:41 +0000 Subject: [M3devel] m3 CVS? In-Reply-To: <20090331223859.GC10145@topoi.pooq.com> References: <20090325225421.GB17118@topoi.pooq.com> <20090330131918.GA6921@topoi.pooq.com> <20090331133910.flci659jockgo04c@mail.elegosoft.com> <20090331135610.GA9539@topoi.pooq.com> <20090331161908.3pferzf9c08oso40@mail.elegosoft.com> <20090331144252.GA9624@topoi.pooq.com> <20090331173542.60xixsbl4w4kcsgs@mail.elegosoft.com> <47E57322-28FD-4C9E-B1FE-12761C6F32AB@cs.purdue.edu> <20090401000350.9ulc6eobpk44coo0@mail.elegosoft.com> <20090331223859.GC10145@topoi.pooq.com> Message-ID: > And only feasible if the SRC source both forked from is still in existence. The SRC 3.6 release is certainly available, not sure if that is what they forked from. I do wonder: - Does PM3 have anything we should salvage? Unknown. - Does ezm3? - Is CM3 the one true Modula-3? I guess not. Or at least the "best" by far and the only one worth working on? I think so. - Jay > Date: Tue, 31 Mar 2009 18:38:59 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3 CVS? > > On Wed, Apr 01, 2009 at 12:03:50AM +0200, Olaf Wagner wrote: > > Quoting Tony Hosking : > > > > >Both PM3 and CM3 forked from SRC M3. > > > > Yes, the releases both built on the SRC source, but as far as I know > > there was never one repository where the history was combined. > > > > Olaf > > I suspect combining them would be more work than it's worth. And only > feasible if the SRC source both forked from is still in existence. > > But tempting. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 1 00:38:35 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 31 Mar 2009 22:38:35 +0000 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: <49D2807D.7010100@bellsouth.net> References: <200903311842.n2VIg6LS046075@camembert.async.caltech.edu> <49D2807D.7010100@bellsouth.net> Message-ID: http://modula3.elegosoft.com/cm3/uploaded-archives ? I can make another later this week. All you need is a working cm3 on any system. >From there you can build the whole system, targeting any system. As long as that cm3 understands LONGINT and your target system. And it is easier, but not necessary, if you have Python. :) - Jay > Date: Tue, 31 Mar 2009 15:43:41 -0500 > From: martinbishop at bellsouth.net > To: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Help finding CM3 compiler for Linux? > > Not sure if this helps, but on my linux system: > > Critical Mass Modula-3 version d5.7.0 > last updated: 2008-03-16 > compiled: 2008-08-14 00:56:14 > configuration: /usr/local/cm3/bin/cm3.cfg > > Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 > i686 GNU/Linux > > > I don't have the cm3 tarball, but I do have the sources in cm3/ still. > > Mika Nystrom wrote: > > Hello everyone, > > > > This is, for me, a most unfortunate time for the CM3 servers to > > have crashed. I'm teaching a class using Modula-3, and we need a > > compiler... here's the uname of the system I'm trying to use: > > > > Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Linux > > > > The most recent archives I have for Linux are: > > > > cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz > > > > And they don't seem to work on this system: I can compile a program > > but when I try to run it, it says "Segmentation fault". Can anyone > > help? (My understanding is that I need 5.5.1 or later...) > > > > Mika > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Apr 1 00:46:59 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 31 Mar 2009 15:46:59 -0700 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: Your message of "Tue, 31 Mar 2009 22:38:35 -0000." Message-ID: <200903312246.n2VMkxml055400@camembert.async.caltech.edu> Aaaah it works now.. or was I looking in the wrong place earlier? (I was getting only broken links.) Thanks to everyone who offered to help! Jay writes: >--_806446ae-8d10-4d74-8eea-51aa365e9204_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > http://modula3.elegosoft.com/cm3/uploaded-archives > >? > >=20 > >I can make another later this week. > >=20 > >All you need is a working cm3 on any system. > >>From there you can build the whole system=2C targeting any system. > >As long as that cm3 understands LONGINT and your target system. > >And it is easier=2C but not necessary=2C if you have Python. :) > >=20 > > - Jay > >=20 >> Date: Tue=2C 31 Mar 2009 15:43:41 -0500 >> From: martinbishop at bellsouth.net >> To: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >>=20 >> Not sure if this helps=2C but on my linux system: >>=20 >> Critical Mass Modula-3 version d5.7.0 >> last updated: 2008-03-16 >> compiled: 2008-08-14 00:56:14 >> configuration: /usr/local/cm3/bin/cm3.cfg >>=20 >> Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 >> i686 GNU/Linux >>=20 >>=20 >> I don't have the cm3 tarball=2C but I do have the sources in cm3/ still. >>=20 >> Mika Nystrom wrote: >> > Hello everyone=2C >> >=20 >> > This is=2C for me=2C a most unfortunate time for the CM3 servers to >> > have crashed. I'm teaching a class using Modula-3=2C and we need a >> > compiler... here's the uname of the system I'm trying to use: >> >=20 >> > Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Lin= >ux >> >=20 >> > The most recent archives I have for Linux are: >> >=20 >> > cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=20 >> >=20 >> > And they don't seem to work on this system: I can compile a program >> > but when I try to run it=2C it says "Segmentation fault". Can anyone >> > help? (My understanding is that I need 5.5.1 or later...) >> >=20 >> > Mika >> >=20 >>=20 > >--_806446ae-8d10-4d74-8eea-51aa365e9204_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > > =3Bet=3D_blank>http://modula3.elegosoft.com/cm3/uploaded= >-archives
>?
> =3B
>I can make another later this week.
> =3B
>All you need is a working cm3 on any system.
>>From there you can build the whole system=2C targeting any system.
>As long as that cm3 understands LONGINT and your target system.
>And it is easier=2C but not necessary=2C if you have Python. :)
> =3B
> =3B- Jay

 =3B
>=3B Date: Tue=2C 31 Mar 2009 15:43:41 -= >0500
>=3B From: martinbishop at bellsouth.net
>=3B To: mika at async.ca= >ltech.edu
>=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3dev= >el] Help finding CM3 compiler for Linux?
>=3B
>=3B Not sure if t= >his helps=2C but on my linux system:
>=3B
>=3B Critical Mass Mod= >ula-3 version d5.7.0
>=3B last updated: 2008-03-16
>=3B compiled:= > 2008-08-14 00:56:14
>=3B configuration: /usr/local/cm3/bin/cm3.cfg>>=3B
>=3B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24= >:39 UTC 2009
>=3B i686 GNU/Linux
>=3B
>=3B
>=3B I don= >'t have the cm3 tarball=2C but I do have the sources in cm3/ still.
>= >=3B
>=3B Mika Nystrom wrote:
>=3B >=3B Hello everyone=2C
&g= >t=3B >=3B
>=3B >=3B This is=2C for me=2C a most unfortunate time = >for the CM3 servers to
>=3B >=3B have crashed. I'm teaching a class = >using Modula-3=2C and we need a
>=3B >=3B compiler... here's the una= >me of the system I'm trying to use:
>=3B >=3B
>=3B >=3B Linu= >x lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Linux
&g= >t=3B >=3B
>=3B >=3B The most recent archives I have for Linux are= >:
>=3B >=3B
>=3B >=3B cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3= >-src-all-5.4.0.tgz
>=3B >=3B
>=3B >=3B And they don't seem = >to work on this system: I can compile a program
>=3B >=3B but when I= > try to run it=2C it says "Segmentation fault". Can anyone
>=3B >=3B= > help? (My understanding is that I need 5.5.1 or later...)
>=3B >=3B= >
>=3B >=3B Mika
>=3B >=3B
>=3B
>= > >--_806446ae-8d10-4d74-8eea-51aa365e9204_-- From hendrik at topoi.pooq.com Wed Apr 1 01:05:07 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 31 Mar 2009 19:05:07 -0400 Subject: [M3devel] m3 CVS? In-Reply-To: References: <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> <20090325144505.GA16526@topoi.pooq.com> <20090325225421.GB17118@topoi.pooq.com> <20090330131918.GA6921@topoi.pooq.com> <20090331133910.flci659jockgo04c@mail.elegosoft.com> <20090331135610.GA9539@topoi.pooq.com> <20090331161908.3pferzf9c08oso40@mail.elegosoft.com> Message-ID: <20090331230507.GA10261@topoi.pooq.com> On Tue, Mar 31, 2009 at 10:41:42PM +0000, Jay wrote: > > Also, presumably you can copy the entire CVS repository with little CPU use and then do the monotone work locally. I doubt it is all that large, can tell you later.. (ssh in and du /usr/cvs) That might be the way to go. My LAN is a hundred times faster than my connexion with the outside world. Not mention putting it on localhost or getting monotone to look at the cvs files directly (whichever it turns out to like). -- hendrik From hendrik at topoi.pooq.com Wed Apr 1 01:08:28 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 31 Mar 2009 19:08:28 -0400 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: <200903312259.n2VMxIQk055916@camembert.async.caltech.edu> References: <20090331214921.GA10145@topoi.pooq.com> <200903312259.n2VMxIQk055916@camembert.async.caltech.edu> Message-ID: <20090331230828.GB10261@topoi.pooq.com> On Tue, Mar 31, 2009 at 03:59:18PM -0700, Mika Nystrom wrote: > Yes you could try sending it to me somehow? Sorry.. I had an anon > ftp site but it seems to have succumbed to some sort of bit rot. > (If it's too big a hassle for you to send in an attachment or via > the web, let me know and I'll configure something...) > > You could also try uploading it to "rapidshare.com"? > > Any help is appreciated! > > Mika For the time being, there's a link to a copy of cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-04-08-14-00-05.tgz near the bottonm of the web page http://hendrik.pooq.com/ -- hendrik From hosking at cs.purdue.edu Wed Apr 1 03:15:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 1 Apr 2009 12:15:29 +1100 Subject: [M3devel] m3 CVS? In-Reply-To: References: <20090325225421.GB17118@topoi.pooq.com> <20090330131918.GA6921@topoi.pooq.com> <20090331133910.flci659jockgo04c@mail.elegosoft.com> <20090331135610.GA9539@topoi.pooq.com> <20090331161908.3pferzf9c08oso40@mail.elegosoft.com> <20090331144252.GA9624@topoi.pooq.com> <20090331173542.60xixsbl4w4kcsgs@mail.elegosoft.com> <47E57322-28FD-4C9E-B1FE-12761C6F32AB@cs.purdue.edu> <20090401000350.9ulc6eobpk44coo0@mail.elegosoft.com> <20090331223859.GC10145@topoi.pooq.com> Message-ID: <51447406-6C71-4CC2-AEAB-EFFFAA139555@cs.purdue.edu> CM3 has evolved significantly beyond PM3. I switched over because PM3 was getting a little crusty. 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 1 Apr 2009, at 09:43, Jay wrote: > > And only feasible if the SRC source both forked from is still in > existence. > > The SRC 3.6 release is certainly available, not sure if that is what > they forked from. > > I do wonder: > - Does PM3 have anything we should salvage? Unknown. > - Does ezm3? > - Is CM3 the one true Modula-3? I guess not. > Or at least the "best" by far and the only one worth working > on? I think so. > > - Jay > > > > Date: Tue, 31 Mar 2009 18:38:59 -0400 > > From: hendrik at topoi.pooq.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] m3 CVS? > > > > On Wed, Apr 01, 2009 at 12:03:50AM +0200, Olaf Wagner wrote: > > > Quoting Tony Hosking : > > > > > > >Both PM3 and CM3 forked from SRC M3. > > > > > > Yes, the releases both built on the SRC source, but as far as I > know > > > there was never one repository where the history was combined. > > > > > > Olaf > > > > I suspect combining them would be more work than it's worth. And > only > > feasible if the SRC source both forked from is still in existence. > > > > But tempting. > > > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Apr 1 07:59:18 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 31 Mar 2009 22:59:18 -0700 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: Your message of "Wed, 01 Apr 2009 04:31:27 -0000." Message-ID: <200904010559.n315xIBx071256@camembert.async.caltech.edu> Is there any documentation for this format beyond what you just wrote? Where? terpsichore-14: cm3 --- building in ../LINUXLIBC6 --- new source -> compiling Main.m3 "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common", line 169: quake runtime error: undefined variable: ROOT --procedure-- -line- -file--- GetM3Back 169 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common _IsM3BackFlagSupported 181 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common IsM3BackFlagSupported 193 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common GetM3BackFlag 197 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common m3_backend 62 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common program -- 6 /afs/.ugcs.caltech.edu/user/mika/test/LINUXLIBC6/m3make.args Fatal Error: procedure "m3_backend" defined in "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3.cfg" failed. Jay writes: >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >These archives do have a different format=2C yes. > >But it isn't a bad format. > >cminstall is pretty worthless imho. > >Extract=2C rename=2C set PATH and LD_LIBRARY_PATH. > >=20 > > - Jay > >=20 >> To: jay.krell at cornell.edu >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux?=20 >> Date: Tue=2C 31 Mar 2009 15:56:11 -0700 >> From: mika at async.caltech.edu >>=20 >> No=2C I'm sorry... >>=20 >> the archives do not have the usual format. I'm expecting to unpack >> and run "cminstall" and then unpack the big source tar on top and=20 >> build that. But there's no cminstall in the archive on this page. >> This is "the normal procedure" for installing CM3=2C no? It's what >> the instructions say to do=2C as well... >>=20 >> And the link from the "Download" page is broken (to -d5.5.0.tgz). >>=20 >> Mika >>=20 >> Jay writes: >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> > http://modula3.elegosoft.com/cm3/uploaded-archives >> > >> >? >> > >> >=3D20 >> > >> >I can make another later this week. >> > >> >=3D20 >> > >> >All you need is a working cm3 on any system. >> > >> >>From there you can build the whole system=3D2C targeting any system. >> > >> >As long as that cm3 understands LONGINT and your target system. >> > >> >And it is easier=3D2C but not necessary=3D2C if you have Python. :) >> > >> >=3D20 >> > >> > - Jay >> > >> >=3D20 >> >> Date: Tue=3D2C 31 Mar 2009 15:43:41 -0500 >> >> From: martinbishop at bellsouth.net >> >> To: mika at async.caltech.edu >> >> CC: m3devel at elegosoft.com >> >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >> >>=3D20 >> >> Not sure if this helps=3D2C but on my linux system: >> >>=3D20 >> >> Critical Mass Modula-3 version d5.7.0 >> >> last updated: 2008-03-16 >> >> compiled: 2008-08-14 00:56:14 >> >> configuration: /usr/local/cm3/bin/cm3.cfg >> >>=3D20 >> >> Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 >> >> i686 GNU/Linux >> >>=3D20 >> >>=3D20 >> >> I don't have the cm3 tarball=3D2C but I do have the sources in cm3/ st= >ill. >> >>=3D20 >> >> Mika Nystrom wrote: >> >> > Hello everyone=3D2C >> >> >=3D20 >> >> > This is=3D2C for me=3D2C a most unfortunate time for the CM3 servers= > to >> >> > have crashed. I'm teaching a class using Modula-3=3D2C and we need a >> >> > compiler... here's the uname of the system I'm trying to use: >> >> >=3D20 >> >> > Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/= >Lin=3D >> >ux >> >> >=3D20 >> >> > The most recent archives I have for Linux are: >> >> >=3D20 >> >> > cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D20 >> >> >=3D20 >> >> > And they don't seem to work on this system: I can compile a program >> >> > but when I try to run it=3D2C it says "Segmentation fault". Can anyo= >ne >> >> > help? (My understanding is that I need 5.5.1 or later...) >> >> >=3D20 >> >> > Mika >> >> >=3D20 >> >>=3D20 >> > >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ >> >Content-Type: text/html=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> > >> > >> > >> > >> > =3D3Bs" targ=3D >> >et=3D3D_blank>http://modula3.elegosoft.com/cm3/u= >ploaded=3D >> >-archives
>> >?
>> > =3D3B
>> >I can make another later this week.
>> > =3D3B
>> >All you need is a working cm3 on any system.
>> >>From there you can build the whole system=3D2C targeting any system.> >> >As long as that cm3 understands LONGINT and your target system.
>> >And it is easier=3D2C but not necessary=3D2C if you have Python. :)
>> > =3D3B
>> > =3D3B- Jay

 =3D3B
>=3D3B Date: Tue=3D2C 31 Mar 2009= > 15:43:41 -=3D >> >0500
>=3D3B From: martinbishop at bellsouth.net
>=3D3B To: mika at a= >sync.ca=3D >> >ltech.edu
>=3D3B CC: m3devel at elegosoft.com
>=3D3B Subject: Re:= > [M3dev=3D >> >el] Help finding CM3 compiler for Linux?
>=3D3B
>=3D3B Not su= >re if t=3D >> >his helps=3D2C but on my linux system:
>=3D3B
>=3D3B Critical= > Mass Mod=3D >> >ula-3 version d5.7.0
>=3D3B last updated: 2008-03-16
>=3D3B co= >mpiled:=3D >> > 2008-08-14 00:56:14
>=3D3B configuration: /usr/local/cm3/bin/cm3.c= >fg> >>>=3D3B
>=3D3B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 2= >9 19:24=3D >> >:39 UTC 2009
>=3D3B i686 GNU/Linux
>=3D3B
>=3D3B
>= >=3D3B I don=3D >> >'t have the cm3 tarball=3D2C but I do have the sources in cm3/ still.>>=3D >> >=3D3B
>=3D3B Mika Nystrom wrote:
>=3D3B >=3D3B Hello everyo= >ne=3D2C
&g=3D >> >t=3D3B >=3D3B
>=3D3B >=3D3B This is=3D2C for me=3D2C a most un= >fortunate time =3D >> >for the CM3 servers to
>=3D3B >=3D3B have crashed. I'm teaching a= > class =3D >> >using Modula-3=3D2C and we need a
>=3D3B >=3D3B compiler... here'= >s the una=3D >> >me of the system I'm trying to use:
>=3D3B >=3D3B
>=3D3B &g= >t=3D3B Linu=3D >> >x lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Linux>&g=3D >> >t=3D3B >=3D3B
>=3D3B >=3D3B The most recent archives I have fo= >r Linux are=3D >> >:
>=3D3B >=3D3B
>=3D3B >=3D3B cm3-min-POSIX-LINUXLIBC6-5.= >4.0.tgz cm3=3D >> >-src-all-5.4.0.tgz
>=3D3B >=3D3B
>=3D3B >=3D3B And they = >don't seem =3D >> >to work on this system: I can compile a program
>=3D3B >=3D3B but= > when I=3D >> > try to run it=3D2C it says "Segmentation fault". Can anyone
>=3D3B= > >=3D3B=3D >> > help? (My understanding is that I need 5.5.1 or later...)
>=3D3B &= >gt=3D3B=3D >> >
>=3D3B >=3D3B Mika
>=3D3B >=3D3B
>=3D3B
> >> >=3D >> > >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_-- > >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >These archives do have a different format=2C yes.
>But it isn't a bad format.
>cminstall is pretty worthless imho.
>Extract=2C rename=2C set PATH and LD_LIBRARY_PATH.
> =3B
> =3B- Jay

 =3B
>=3B To: jay.krell at cornell.edu
>=3B= > Subject: Re: [M3devel] Help finding CM3 compiler for Linux?
>=3B Dat= >e: Tue=2C 31 Mar 2009 15:56:11 -0700
>=3B From: mika at async.caltech.edu= >
>=3B
>=3B No=2C I'm sorry...
>=3B
>=3B the archives = >do not have the usual format. I'm expecting to unpack
>=3B and run "cm= >install" and then unpack the big source tar on top and
>=3B build tha= >t. But there's no cminstall in the archive on this page.
>=3B This is = >"the normal procedure" for installing CM3=2C no? It's what
>=3B the in= >structions say to do=2C as well...
>=3B
>=3B And the link from t= >he "Download" page is broken (to -d5.5.0.tgz).
>=3B
>=3B Mika>>=3B
>=3B Jay writes:
>=3B >=3B--_806446ae-8d10-4d74-8eea-5= >1aa365e9204_
>=3B >=3BContent-Type: text/plain=3B charset=3D"iso-885= >9-1"
>=3B >=3BContent-Transfer-Encoding: quoted-printable
>=3B = >>=3B
>=3B >=3B
>=3B >=3B http://modula3.elegosoft.com/cm3/u= >ploaded-archives
>=3B >=3B
>=3B >=3B?
>=3B >=3B
>= >=3B >=3B=3D20
>=3B >=3B
>=3B >=3BI can make another later t= >his week.
>=3B >=3B
>=3B >=3B=3D20
>=3B >=3B
>=3B= > >=3BAll you need is a working cm3 on any system.
>=3B >=3B
>= >=3B >=3B>=3BFrom there you can build the whole system=3D2C targeting an= >y system.
>=3B >=3B
>=3B >=3BAs long as that cm3 understands = >LONGINT and your target system.
>=3B >=3B
>=3B >=3BAnd it is = >easier=3D2C but not necessary=3D2C if you have Python. :)
>=3B >=3B<= >BR>>=3B >=3B=3D20
>=3B >=3B
>=3B >=3B - Jay
>=3B >= >=3B
>=3B >=3B=3D20
>=3B >=3B>=3B Date: Tue=3D2C 31 Mar 2009= > 15:43:41 -0500
>=3B >=3B>=3B From: martinbishop at bellsouth.net
= >>=3B >=3B>=3B To: mika at async.caltech.edu
>=3B >=3B>=3B CC: m= >3devel at elegosoft.com
>=3B >=3B>=3B Subject: Re: [M3devel] Help fin= >ding CM3 compiler for Linux?
>=3B >=3B>=3B=3D20
>=3B >=3B&g= >t=3B Not sure if this helps=3D2C but on my linux system:
>=3B >=3B&g= >t=3B=3D20
>=3B >=3B>=3B Critical Mass Modula-3 version d5.7.0
&= >gt=3B >=3B>=3B last updated: 2008-03-16
>=3B >=3B>=3B compiled= >: 2008-08-14 00:56:14
>=3B >=3B>=3B configuration: /usr/local/cm3/= >bin/cm3.cfg
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B Linux thinkp= >ad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009
>=3B >=3B&g= >t=3B i686 GNU/Linux
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B=3D20= >
>=3B >=3B>=3B I don't have the cm3 tarball=3D2C but I do have the= > sources in cm3/ still.
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B = >Mika Nystrom wrote:
>=3B >=3B>=3B >=3B Hello everyone=3D2C
&g= >t=3B >=3B>=3B >=3B=3D20
>=3B >=3B>=3B >=3B This is=3D2C fo= >r me=3D2C a most unfortunate time for the CM3 servers to
>=3B >=3B&g= >t=3B >=3B have crashed. I'm teaching a class using Modula-3=3D2C and we n= >eed a
>=3B >=3B>=3B >=3B compiler... here's the uname of the sys= >tem I'm trying to use:
>=3B >=3B>=3B >=3B=3D20
>=3B >=3B&= >gt=3B >=3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i68= >6 GNU/Lin=3D
>=3B >=3Bux
>=3B >=3B>=3B >=3B=3D20
>= >=3B >=3B>=3B >=3B The most recent archives I have for Linux are:
&= >gt=3B >=3B>=3B >=3B=3D20
>=3B >=3B>=3B >=3B cm3-min-POSIX-= >LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D20
>=3B >=3B>=3B >= >=3B=3D20
>=3B >=3B>=3B >=3B And they don't seem to work on this = >system: I can compile a program
>=3B >=3B>=3B >=3B but when I tr= >y to run it=3D2C it says "Segmentation fault". Can anyone
>=3B >=3B&= >gt=3B >=3B help? (My understanding is that I need 5.5.1 or later...)
&= >gt=3B >=3B>=3B >=3B=3D20
>=3B >=3B>=3B >=3B Mika
>=3B= > >=3B>=3B >=3B=3D20
>=3B >=3B>=3B=3D20
>=3B >=3B
&= >gt=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>=3B >=3BConten= >t-Type: text/html=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfe= >r-Encoding: quoted-printable
>=3B >=3B
>=3B >=3B<=3Bhtml>= >=3B
>=3B >=3B<=3Bhead>=3B
>=3B >=3B<=3Bstyle>=3B
&= >gt=3B >=3B.hmmessage P
>=3B >=3B{
>=3B >=3Bmargin:0px=3D3B<= >BR>>=3B >=3Bpadding:0px
>=3B >=3B}
>=3B >=3Bbody.hmmessag= >e
>=3B >=3B{
>=3B >=3Bfont-size: 10pt=3D3B
>=3B >=3Bfo= >nt-family:Verdana
>=3B >=3B}
>=3B >=3B<=3B/style>=3B
&= >gt=3B >=3B<=3B/head>=3B
>=3B >=3B<=3Bbody class=3D3D'hmmessa= >ge'>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BA href=3D3D"http://modula3.= >elegosoft.com/cm3/uploaded-archives" targ=3D
>=3B >=3Bet=3D3D_blank&= >gt=3B<=3BFONT color=3D3D#0068cf>=3Bhttp://modula3.elegosoft.com/cm3/upl= >oaded=3D
>=3B >=3B-archives<=3B/FONT>=3B<=3B/A>=3B<=3BBR&g= >t=3B
>=3B >=3B?<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3B= >BR>=3B
>=3B >=3BI can make another later this week.<=3BBR>=3B<= >BR>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BAll you need= > is a working cm3 on any system.<=3BBR>=3B
>=3B >=3B>=3BFrom t= >here you can build the whole system=3D2C targeting any system.<=3BBR>= >=3B
>=3B >=3BAs long as that cm3 understands LONGINT and your target= > system.<=3BBR>=3B
>=3B >=3BAnd it is easier=3D2C but not necess= >ary=3D2C if you have Python. :)<=3BBR>=3B
>=3B >=3B&=3Bnbsp= >=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B- Jay<=3BBR>=3B<= >=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3B&=3Bgt=3D3B Date: Tue=3D2C 31 M= >ar 2009 15:43:41 -=3D
>=3B >=3B0500<=3BBR>=3B&=3Bgt=3D3B From= >: martinbishop at bellsouth.net<=3BBR>=3B&=3Bgt=3D3B To: mika at async.ca= >=3D
>=3B >=3Bltech.edu<=3BBR>=3B&=3Bgt=3D3B CC: m3devel at elego= >soft.com<=3BBR>=3B&=3Bgt=3D3B Subject: Re: [M3dev=3D
>=3B >= >=3Bel] Help finding CM3 compiler for Linux?<=3BBR>=3B&=3Bgt=3D3B <= >=3BBR>=3B&=3Bgt=3D3B Not sure if t=3D
>=3B >=3Bhis helps=3D2C b= >ut on my linux system:<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt= >=3D3B Critical Mass Mod=3D
>=3B >=3Bula-3 version d5.7.0<=3BBR>= >=3B&=3Bgt=3D3B last updated: 2008-03-16<=3BBR>=3B&=3Bgt=3D3B comp= >iled:=3D
>=3B >=3B 2008-08-14 00:56:14<=3BBR>=3B&=3Bgt=3D3B c= >onfiguration: /usr/local/cm3/bin/cm3.cfg<=3BBR=3D
>=3B >=3B>=3B&= >amp=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Linux thinkpad 2.6.27-11-generic= > #1 SMP Thu Jan 29 19:24=3D
>=3B >=3B:39 UTC 2009<=3BBR>=3B&= >=3Bgt=3D3B i686 GNU/Linux<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3B= >gt=3D3B <=3BBR>=3B&=3Bgt=3D3B I don=3D
>=3B >=3B't have the c= >m3 tarball=3D2C but I do have the sources in cm3/ still.<=3BBR>=3B&= >=3Bgt=3D
>=3B >=3B=3D3B <=3BBR>=3B&=3Bgt=3D3B Mika Nystrom wr= >ote:<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B Hello everyone=3D2C<=3BBR= >>=3B&=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B <=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B This is=3D2C for me=3D2C a most unfortunate time = >=3D
>=3B >=3Bfor the CM3 servers to<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B have crashed. I'm teaching a class =3D
>=3B >=3Busing Mod= >ula-3=3D2C and we need a<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B compile= >r... here's the una=3D
>=3B >=3Bme of the system I'm trying to use:&= >lt=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B &am= >p=3Bgt=3D3B Linu=3D
>=3B >=3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10= >:53:03 PST 2008 i686 GNU/Linux<=3BBR>=3B&=3Bg=3D
>=3B >=3Bt= >=3D3B &=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B The most r= >ecent archives I have for Linux are=3D
>=3B >=3B:<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B cm3-m= >in-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D
>=3B >=3B-src-all-5.4.0.tgz <= =3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B And they don't seem =3D
>=3B >=3Bto work on this system: = >I can compile a program<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B but when= > I=3D
>=3B >=3B try to run it=3D2C it says "Segmentation fault". Can= > anyone<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D
>=3B >=3B help= >? (My understanding is that I need 5.5.1 or later...)<=3BBR>=3B&=3Bg= >t=3D3B &=3Bgt=3D3B=3D
>=3B >=3B <=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B Mika<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B <=3BBR>=3B&a= >mp=3Bgt=3D3B <=3BBR>=3B<=3B/body>=3B
>=3B >=3B<=3B/html>= >=3B=3D
>=3B >=3B
>=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e= >9204_--
>= > >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_-- From jay.krell at cornell.edu Wed Apr 1 08:13:00 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Apr 2009 06:13:00 +0000 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: <200904010559.n315xIBx071256@camembert.async.caltech.edu> References: Your message of "Wed, 01 Apr 2009 04:31:27 -0000." <200904010559.n315xIBx071256@camembert.async.caltech.edu> Message-ID: Maybe not. Hm. That is bug. There is use with a cvs tree, and use without. I must have broken use without. Try this: export CM3_ROOT=root of cm3 cvs (for me this is /dev2/cm3, for you, maybe $HOME/cm3?) rm $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6 # *Common and *common in one command rm $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/*ommon cp root of cm3 cvs/m3-sys/cminstall/src/config/cm3.cfg $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin The .cfg will delegate out to the cvs tree. I don't like having two copies of files..having to keep them in sync.. Though the archives are meant to work standalone, without CVS. But I don't test that so much oops sorry. That /might/ not be the right file, but it is close. - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Help finding CM3 compiler for Linux? > Date: Tue, 31 Mar 2009 22:59:18 -0700 > From: mika at async.caltech.edu > > > Is there any documentation for this format beyond what you just > wrote? Where? > > terpsichore-14: cm3 > --- building in ../LINUXLIBC6 --- > > new source -> compiling Main.m3 > "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common", line 169: quake runtime error: undefined variable: ROOT > > --procedure-- -line- -file--- > GetM3Back 169 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common > _IsM3BackFlagSupported 181 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common > IsM3BackFlagSupported 193 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common > GetM3BackFlag 197 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common > m3_backend 62 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common > program -- > 6 /afs/.ugcs.caltech.edu/user/mika/test/LINUXLIBC6/m3make.args > > > Fatal Error: procedure "m3_backend" defined in "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3.cfg" failed. > > Jay writes: > >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >These archives do have a different format=2C yes. > > > >But it isn't a bad format. > > > >cminstall is pretty worthless imho. > > > >Extract=2C rename=2C set PATH and LD_LIBRARY_PATH. > > > >=20 > > > > - Jay > > > >=20 > >> To: jay.krell at cornell.edu > >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux?=20 > >> Date: Tue=2C 31 Mar 2009 15:56:11 -0700 > >> From: mika at async.caltech.edu > >>=20 > >> No=2C I'm sorry... > >>=20 > >> the archives do not have the usual format. I'm expecting to unpack > >> and run "cminstall" and then unpack the big source tar on top and=20 > >> build that. But there's no cminstall in the archive on this page. > >> This is "the normal procedure" for installing CM3=2C no? It's what > >> the instructions say to do=2C as well... > >>=20 > >> And the link from the "Download" page is broken (to -d5.5.0.tgz). > >>=20 > >> Mika > >>=20 > >> Jay writes: > >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ > >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> > http://modula3.elegosoft.com/cm3/uploaded-archives > >> > > >> >? > >> > > >> >=3D20 > >> > > >> >I can make another later this week. > >> > > >> >=3D20 > >> > > >> >All you need is a working cm3 on any system. > >> > > >> >>From there you can build the whole system=3D2C targeting any system. > >> > > >> >As long as that cm3 understands LONGINT and your target system. > >> > > >> >And it is easier=3D2C but not necessary=3D2C if you have Python. :) > >> > > >> >=3D20 > >> > > >> > - Jay > >> > > >> >=3D20 > >> >> Date: Tue=3D2C 31 Mar 2009 15:43:41 -0500 > >> >> From: martinbishop at bellsouth.net > >> >> To: mika at async.caltech.edu > >> >> CC: m3devel at elegosoft.com > >> >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? > >> >>=3D20 > >> >> Not sure if this helps=3D2C but on my linux system: > >> >>=3D20 > >> >> Critical Mass Modula-3 version d5.7.0 > >> >> last updated: 2008-03-16 > >> >> compiled: 2008-08-14 00:56:14 > >> >> configuration: /usr/local/cm3/bin/cm3.cfg > >> >>=3D20 > >> >> Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 > >> >> i686 GNU/Linux > >> >>=3D20 > >> >>=3D20 > >> >> I don't have the cm3 tarball=3D2C but I do have the sources in cm3/ st= > >ill. > >> >>=3D20 > >> >> Mika Nystrom wrote: > >> >> > Hello everyone=3D2C > >> >> >=3D20 > >> >> > This is=3D2C for me=3D2C a most unfortunate time for the CM3 servers= > > to > >> >> > have crashed. I'm teaching a class using Modula-3=3D2C and we need a > >> >> > compiler... here's the uname of the system I'm trying to use: > >> >> >=3D20 > >> >> > Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/= > >Lin=3D > >> >ux > >> >> >=3D20 > >> >> > The most recent archives I have for Linux are: > >> >> >=3D20 > >> >> > cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D20 > >> >> >=3D20 > >> >> > And they don't seem to work on this system: I can compile a program > >> >> > but when I try to run it=3D2C it says "Segmentation fault". Can anyo= > >ne > >> >> > help? (My understanding is that I need 5.5.1 or later...) > >> >> >=3D20 > >> >> > Mika > >> >> >=3D20 > >> >>=3D20 > >> > > >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ > >> >Content-Type: text/html=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> > > >> > > >> > > >> > > >> > =3D3B >s" targ=3D > >> >et=3D3D_blank>http://modula3.elegosoft.com/cm3/u= > >ploaded=3D > >> >-archives
> >> >?
> >> > =3D3B
> >> >I can make another later this week.
> >> > =3D3B
> >> >All you need is a working cm3 on any system.
> >> >>From there you can build the whole system=3D2C targeting any system. >> > >> >As long as that cm3 understands LONGINT and your target system.
> >> >And it is easier=3D2C but not necessary=3D2C if you have Python. :)
> >> > =3D3B
> >> > =3D3B- Jay

 =3D3B
>=3D3B Date: Tue=3D2C 31 Mar 2009= > > 15:43:41 -=3D > >> >0500
>=3D3B From: martinbishop at bellsouth.net
>=3D3B To: mika at a= > >sync.ca=3D > >> >ltech.edu
>=3D3B CC: m3devel at elegosoft.com
>=3D3B Subject: Re:= > > [M3dev=3D > >> >el] Help finding CM3 compiler for Linux?
>=3D3B
>=3D3B Not su= > >re if t=3D > >> >his helps=3D2C but on my linux system:
>=3D3B
>=3D3B Critical= > > Mass Mod=3D > >> >ula-3 version d5.7.0
>=3D3B last updated: 2008-03-16
>=3D3B co= > >mpiled:=3D > >> > 2008-08-14 00:56:14
>=3D3B configuration: /usr/local/cm3/bin/cm3.c= > >fg >> >>>=3D3B
>=3D3B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 2= > >9 19:24=3D > >> >:39 UTC 2009
>=3D3B i686 GNU/Linux
>=3D3B
>=3D3B
>= > >=3D3B I don=3D > >> >'t have the cm3 tarball=3D2C but I do have the sources in cm3/ still. >>>=3D > >> >=3D3B
>=3D3B Mika Nystrom wrote:
>=3D3B >=3D3B Hello everyo= > >ne=3D2C
&g=3D > >> >t=3D3B >=3D3B
>=3D3B >=3D3B This is=3D2C for me=3D2C a most un= > >fortunate time =3D > >> >for the CM3 servers to
>=3D3B >=3D3B have crashed. I'm teaching a= > > class =3D > >> >using Modula-3=3D2C and we need a
>=3D3B >=3D3B compiler... here'= > >s the una=3D > >> >me of the system I'm trying to use:
>=3D3B >=3D3B
>=3D3B &g= > >t=3D3B Linu=3D > >> >x lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Linux >>&g=3D > >> >t=3D3B >=3D3B
>=3D3B >=3D3B The most recent archives I have fo= > >r Linux are=3D > >> >:
>=3D3B >=3D3B
>=3D3B >=3D3B cm3-min-POSIX-LINUXLIBC6-5.= > >4.0.tgz cm3=3D > >> >-src-all-5.4.0.tgz
>=3D3B >=3D3B
>=3D3B >=3D3B And they = > >don't seem =3D > >> >to work on this system: I can compile a program
>=3D3B >=3D3B but= > > when I=3D > >> > try to run it=3D2C it says "Segmentation fault". Can anyone
>=3D3B= > > >=3D3B=3D > >> > help? (My understanding is that I need 5.5.1 or later...)
>=3D3B &= > >gt=3D3B=3D > >> >
>=3D3B >=3D3B Mika
>=3D3B >=3D3B
>=3D3B
>> > >> >=3D > >> > > >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_-- > > > >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >These archives do have a different format=2C yes.
> >But it isn't a bad format.
> >cminstall is pretty worthless imho.
> >Extract=2C rename=2C set PATH and LD_LIBRARY_PATH.
> > =3B
> > =3B- Jay

 =3B
>=3B To: jay.krell at cornell.edu
>=3B= > > Subject: Re: [M3devel] Help finding CM3 compiler for Linux?
>=3B Dat= > >e: Tue=2C 31 Mar 2009 15:56:11 -0700
>=3B From: mika at async.caltech.edu= > >
>=3B
>=3B No=2C I'm sorry...
>=3B
>=3B the archives = > >do not have the usual format. I'm expecting to unpack
>=3B and run "cm= > >install" and then unpack the big source tar on top and
>=3B build tha= > >t. But there's no cminstall in the archive on this page.
>=3B This is = > >"the normal procedure" for installing CM3=2C no? It's what
>=3B the in= > >structions say to do=2C as well...
>=3B
>=3B And the link from t= > >he "Download" page is broken (to -d5.5.0.tgz).
>=3B
>=3B Mika >>>=3B
>=3B Jay writes:
>=3B >=3B--_806446ae-8d10-4d74-8eea-5= > >1aa365e9204_
>=3B >=3BContent-Type: text/plain=3B charset=3D"iso-885= > >9-1"
>=3B >=3BContent-Transfer-Encoding: quoted-printable
>=3B = > >>=3B
>=3B >=3B
>=3B >=3B http://modula3.elegosoft.com/cm3/u= > >ploaded-archives
>=3B >=3B
>=3B >=3B?
>=3B >=3B
>= > >=3B >=3B=3D20
>=3B >=3B
>=3B >=3BI can make another later t= > >his week.
>=3B >=3B
>=3B >=3B=3D20
>=3B >=3B
>=3B= > > >=3BAll you need is a working cm3 on any system.
>=3B >=3B
>= > >=3B >=3B>=3BFrom there you can build the whole system=3D2C targeting an= > >y system.
>=3B >=3B
>=3B >=3BAs long as that cm3 understands = > >LONGINT and your target system.
>=3B >=3B
>=3B >=3BAnd it is = > >easier=3D2C but not necessary=3D2C if you have Python. :)
>=3B >=3B<= > >BR>>=3B >=3B=3D20
>=3B >=3B
>=3B >=3B - Jay
>=3B >= > >=3B
>=3B >=3B=3D20
>=3B >=3B>=3B Date: Tue=3D2C 31 Mar 2009= > > 15:43:41 -0500
>=3B >=3B>=3B From: martinbishop at bellsouth.net
= > >>=3B >=3B>=3B To: mika at async.caltech.edu
>=3B >=3B>=3B CC: m= > >3devel at elegosoft.com
>=3B >=3B>=3B Subject: Re: [M3devel] Help fin= > >ding CM3 compiler for Linux?
>=3B >=3B>=3B=3D20
>=3B >=3B&g= > >t=3B Not sure if this helps=3D2C but on my linux system:
>=3B >=3B&g= > >t=3B=3D20
>=3B >=3B>=3B Critical Mass Modula-3 version d5.7.0
&= > >gt=3B >=3B>=3B last updated: 2008-03-16
>=3B >=3B>=3B compiled= > >: 2008-08-14 00:56:14
>=3B >=3B>=3B configuration: /usr/local/cm3/= > >bin/cm3.cfg
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B Linux thinkp= > >ad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009
>=3B >=3B&g= > >t=3B i686 GNU/Linux
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B=3D20= > >
>=3B >=3B>=3B I don't have the cm3 tarball=3D2C but I do have the= > > sources in cm3/ still.
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B = > >Mika Nystrom wrote:
>=3B >=3B>=3B >=3B Hello everyone=3D2C
&g= > >t=3B >=3B>=3B >=3B=3D20
>=3B >=3B>=3B >=3B This is=3D2C fo= > >r me=3D2C a most unfortunate time for the CM3 servers to
>=3B >=3B&g= > >t=3B >=3B have crashed. I'm teaching a class using Modula-3=3D2C and we n= > >eed a
>=3B >=3B>=3B >=3B compiler... here's the uname of the sys= > >tem I'm trying to use:
>=3B >=3B>=3B >=3B=3D20
>=3B >=3B&= > >gt=3B >=3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i68= > >6 GNU/Lin=3D
>=3B >=3Bux
>=3B >=3B>=3B >=3B=3D20
>= > >=3B >=3B>=3B >=3B The most recent archives I have for Linux are:
&= > >gt=3B >=3B>=3B >=3B=3D20
>=3B >=3B>=3B >=3B cm3-min-POSIX-= > >LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D20
>=3B >=3B>=3B >= > >=3B=3D20
>=3B >=3B>=3B >=3B And they don't seem to work on this = > >system: I can compile a program
>=3B >=3B>=3B >=3B but when I tr= > >y to run it=3D2C it says "Segmentation fault". Can anyone
>=3B >=3B&= > >gt=3B >=3B help? (My understanding is that I need 5.5.1 or later...)
&= > >gt=3B >=3B>=3B >=3B=3D20
>=3B >=3B>=3B >=3B Mika
>=3B= > > >=3B>=3B >=3B=3D20
>=3B >=3B>=3B=3D20
>=3B >=3B
&= > >gt=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>=3B >=3BConten= > >t-Type: text/html=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfe= > >r-Encoding: quoted-printable
>=3B >=3B
>=3B >=3B<=3Bhtml>= > >=3B
>=3B >=3B<=3Bhead>=3B
>=3B >=3B<=3Bstyle>=3B
&= > >gt=3B >=3B.hmmessage P
>=3B >=3B{
>=3B >=3Bmargin:0px=3D3B<= > >BR>>=3B >=3Bpadding:0px
>=3B >=3B}
>=3B >=3Bbody.hmmessag= > >e
>=3B >=3B{
>=3B >=3Bfont-size: 10pt=3D3B
>=3B >=3Bfo= > >nt-family:Verdana
>=3B >=3B}
>=3B >=3B<=3B/style>=3B
&= > >gt=3B >=3B<=3B/head>=3B
>=3B >=3B<=3Bbody class=3D3D'hmmessa= > >ge'>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BA href=3D3D"http://modula3.= > >elegosoft.com/cm3/uploaded-archives" targ=3D
>=3B >=3Bet=3D3D_blank&= > >gt=3B<=3BFONT color=3D3D#0068cf>=3Bhttp://modula3.elegosoft.com/cm3/upl= > >oaded=3D
>=3B >=3B-archives<=3B/FONT>=3B<=3B/A>=3B<=3BBR&g= > >t=3B
>=3B >=3B?<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3B= > >BR>=3B
>=3B >=3BI can make another later this week.<=3BBR>=3B<= > >BR>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BAll you need= > > is a working cm3 on any system.<=3BBR>=3B
>=3B >=3B>=3BFrom t= > >here you can build the whole system=3D2C targeting any system.<=3BBR>= > >=3B
>=3B >=3BAs long as that cm3 understands LONGINT and your target= > > system.<=3BBR>=3B
>=3B >=3BAnd it is easier=3D2C but not necess= > >ary=3D2C if you have Python. :)<=3BBR>=3B
>=3B >=3B&=3Bnbsp= > >=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B- Jay<=3BBR>=3B<= > >=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3B&=3Bgt=3D3B Date: Tue=3D2C 31 M= > >ar 2009 15:43:41 -=3D
>=3B >=3B0500<=3BBR>=3B&=3Bgt=3D3B From= > >: martinbishop at bellsouth.net<=3BBR>=3B&=3Bgt=3D3B To: mika at async.ca= > >=3D
>=3B >=3Bltech.edu<=3BBR>=3B&=3Bgt=3D3B CC: m3devel at elego= > >soft.com<=3BBR>=3B&=3Bgt=3D3B Subject: Re: [M3dev=3D
>=3B >= > >=3Bel] Help finding CM3 compiler for Linux?<=3BBR>=3B&=3Bgt=3D3B <= > >=3BBR>=3B&=3Bgt=3D3B Not sure if t=3D
>=3B >=3Bhis helps=3D2C b= > >ut on my linux system:<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt= > >=3D3B Critical Mass Mod=3D
>=3B >=3Bula-3 version d5.7.0<=3BBR>= > >=3B&=3Bgt=3D3B last updated: 2008-03-16<=3BBR>=3B&=3Bgt=3D3B comp= > >iled:=3D
>=3B >=3B 2008-08-14 00:56:14<=3BBR>=3B&=3Bgt=3D3B c= > >onfiguration: /usr/local/cm3/bin/cm3.cfg<=3BBR=3D
>=3B >=3B>=3B&= > >amp=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Linux thinkpad 2.6.27-11-generic= > > #1 SMP Thu Jan 29 19:24=3D
>=3B >=3B:39 UTC 2009<=3BBR>=3B&= > >=3Bgt=3D3B i686 GNU/Linux<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3B= > >gt=3D3B <=3BBR>=3B&=3Bgt=3D3B I don=3D
>=3B >=3B't have the c= > >m3 tarball=3D2C but I do have the sources in cm3/ still.<=3BBR>=3B&= > >=3Bgt=3D
>=3B >=3B=3D3B <=3BBR>=3B&=3Bgt=3D3B Mika Nystrom wr= > >ote:<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B Hello everyone=3D2C<=3BBR= > >>=3B&=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B <=3BBR>=3B&= > >=3Bgt=3D3B &=3Bgt=3D3B This is=3D2C for me=3D2C a most unfortunate time = > >=3D
>=3B >=3Bfor the CM3 servers to<=3BBR>=3B&=3Bgt=3D3B &= > >=3Bgt=3D3B have crashed. I'm teaching a class =3D
>=3B >=3Busing Mod= > >ula-3=3D2C and we need a<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B compile= > >r... here's the una=3D
>=3B >=3Bme of the system I'm trying to use:&= > >lt=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B &am= > >p=3Bgt=3D3B Linu=3D
>=3B >=3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10= > >:53:03 PST 2008 i686 GNU/Linux<=3BBR>=3B&=3Bg=3D
>=3B >=3Bt= > >=3D3B &=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B The most r= > >ecent archives I have for Linux are=3D
>=3B >=3B:<=3BBR>=3B&= > >=3Bgt=3D3B &=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B cm3-m= > >in-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D
>=3B >=3B-src-all-5.4.0.tgz <= > =3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B &= > >=3Bgt=3D3B And they don't seem =3D
>=3B >=3Bto work on this system: = > >I can compile a program<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B but when= > > I=3D
>=3B >=3B try to run it=3D2C it says "Segmentation fault". Can= > > anyone<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D
>=3B >=3B help= > >? (My understanding is that I need 5.5.1 or later...)<=3BBR>=3B&=3Bg= > >t=3D3B &=3Bgt=3D3B=3D
>=3B >=3B <=3BBR>=3B&=3Bgt=3D3B &= > >=3Bgt=3D3B Mika<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B <=3BBR>=3B&a= > >mp=3Bgt=3D3B <=3BBR>=3B<=3B/body>=3B
>=3B >=3B<=3B/html>= > >=3B=3D
>=3B >=3B
>=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e= > >9204_--
> >= > > > >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Apr 1 08:27:22 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 31 Mar 2009 23:27:22 -0700 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: Your message of "Wed, 01 Apr 2009 06:13:00 -0000." Message-ID: <200904010627.n316RM55072294@camembert.async.caltech.edu> Hmm, I'm not sure what you mean? "root of cm3 cvs"? I have lots of Modula-3 installations on my own machines, but I'm just trying to get a system installed for student use on the student systems (which are different)... A working binary dist for Linux is exactly what I'm looking for and this is what you seem to have directed me to, but I don't have a CVS repository... I don't have "m3-sys/cminstall/" etc. Do I need to unpack both the min and std before doing these things? What I'm *used to* is that I unpack the binary distribution, then unpack the sources (or CVS if you like) on top of that, and then compile everything. Which works about 1 time in 3. I think Modula-3 is almost impossible to install if you don't know exactly what to do! (I'm sure I can figure this out with some work.. but is it really meant to be hard to do? I guess it keeps the riff-raff off the M3 mailing lists!) Mika Jay writes: >--_55339e45-8c85-4ab6-9440-0d2131bbad69_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Maybe not. > >Hm. That is bug. There is use with a cvs tree=2C and use without. > >I must have broken use without. > >=20 > >Try this: > >export CM3_ROOT=3Droot of cm3 cvs (for me this is /dev2/cm3=2C > >for you=2C maybe $HOME/cm3?) > >rm $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6 > ># *Common and *common in one command >rm $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/*ommon >cp root of cm3 cvs/m3-sys/cminstall/src/config/cm3.cfg $HOME/cm3/cm3-min-LI= >NUXLIBC6-d5.7.0/bin > >=20 > >The .cfg will delegate out to the cvs tree. > >I don't like having two copies of files..having to keep them in sync.. > > Though the archives are meant to work standalone=2C without CVS. > > But I don't test that so much oops sorry. > >That /might/ not be the right file=2C but it is close. > >=20 > > - Jay > >=20 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux?=20 >> Date: Tue=2C 31 Mar 2009 22:59:18 -0700 >> From: mika at async.caltech.edu >>=20 >>=20 >> Is there any documentation for this format beyond what you just >> wrote? Where? >>=20 >> terpsichore-14: cm3 >> --- building in ../LINUXLIBC6 --- >>=20 >> new source -> compiling Main.m3 >> "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common"=2C= > line 169: quake runtime error: undefined variable: ROOT >>=20 >> --procedure-- -line- -file--- >> GetM3Back 169 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3c= >fg.common >> _IsM3BackFlagSupported 181 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5= >.7.0/bin/Unix.common >> IsM3BackFlagSupported 193 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.= >7.0/bin/Unix.common >> GetM3BackFlag 197 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/= >Unix.common >> m3_backend 62 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix= >.common >> program -- >> 6 /afs/.ugcs.caltech.edu/user/mika/test/LINUXLIBC6/m3make.args >>=20 >>=20 >> Fatal Error: procedure "m3_backend" defined in "/afs/.ugcs/user/mika/cm3/= >cm3-min-LINUXLIBC6-d5.7.0/bin/cm3.cfg" failed. >>=20 >> Jay writes: >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> >These archives do have a different format=3D2C yes. >> > >> >But it isn't a bad format. >> > >> >cminstall is pretty worthless imho. >> > >> >Extract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH. >> > >> >=3D20 >> > >> > - Jay >> > >> >=3D20 >> >> To: jay.krell at cornell.edu >> >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux?=3D20 >> >> Date: Tue=3D2C 31 Mar 2009 15:56:11 -0700 >> >> From: mika at async.caltech.edu >> >>=3D20 >> >> No=3D2C I'm sorry... >> >>=3D20 >> >> the archives do not have the usual format. I'm expecting to unpack >> >> and run "cminstall" and then unpack the big source tar on top and=3D20 >> >> build that. But there's no cminstall in the archive on this page. >> >> This is "the normal procedure" for installing CM3=3D2C no? It's what >> >> the instructions say to do=3D2C as well... >> >>=3D20 >> >> And the link from the "Download" page is broken (to -d5.5.0.tgz). >> >>=3D20 >> >> Mika >> >>=3D20 >> >> Jay writes: >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ >> >> >Content-Type: text/plain=3D3B charset=3D3D"iso-8859-1" >> >> >Content-Transfer-Encoding: quoted-printable >> >> > >> >> > >> >> > http://modula3.elegosoft.com/cm3/uploaded-archives >> >> > >> >> >? >> >> > >> >> >=3D3D20 >> >> > >> >> >I can make another later this week. >> >> > >> >> >=3D3D20 >> >> > >> >> >All you need is a working cm3 on any system. >> >> > >> >> >>From there you can build the whole system=3D3D2C targeting any syste= >m. >> >> > >> >> >As long as that cm3 understands LONGINT and your target system. >> >> > >> >> >And it is easier=3D3D2C but not necessary=3D3D2C if you have Python. = >:) >> >> > >> >> >=3D3D20 >> >> > >> >> > - Jay >> >> > >> >> >=3D3D20 >> >> >> Date: Tue=3D3D2C 31 Mar 2009 15:43:41 -0500 >> >> >> From: martinbishop at bellsouth.net >> >> >> To: mika at async.caltech.edu >> >> >> CC: m3devel at elegosoft.com >> >> >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >> >> >>=3D3D20 >> >> >> Not sure if this helps=3D3D2C but on my linux system: >> >> >>=3D3D20 >> >> >> Critical Mass Modula-3 version d5.7.0 >> >> >> last updated: 2008-03-16 >> >> >> compiled: 2008-08-14 00:56:14 >> >> >> configuration: /usr/local/cm3/bin/cm3.cfg >> >> >>=3D3D20 >> >> >> Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 200= >9 >> >> >> i686 GNU/Linux >> >> >>=3D3D20 >> >> >>=3D3D20 >> >> >> I don't have the cm3 tarball=3D3D2C but I do have the sources in cm= >3/ st=3D >> >ill. >> >> >>=3D3D20 >> >> >> Mika Nystrom wrote: >> >> >> > Hello everyone=3D3D2C >> >> >> >=3D3D20 >> >> >> > This is=3D3D2C for me=3D3D2C a most unfortunate time for the CM3 = >servers=3D >> > to >> >> >> > have crashed. I'm teaching a class using Modula-3=3D3D2C and we n= >eed a >> >> >> > compiler... here's the uname of the system I'm trying to use: >> >> >> >=3D3D20 >> >> >> > Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 G= >NU/=3D >> >Lin=3D3D >> >> >ux >> >> >> >=3D3D20 >> >> >> > The most recent archives I have for Linux are: >> >> >> >=3D3D20 >> >> >> > cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D3D20 >> >> >> >=3D3D20 >> >> >> > And they don't seem to work on this system: I can compile a progr= >am >> >> >> > but when I try to run it=3D3D2C it says "Segmentation fault". Can= > anyo=3D >> >ne >> >> >> > help? (My understanding is that I need 5.5.1 or later...) >> >> >> >=3D3D20 >> >> >> > Mika >> >> >> >=3D3D20 >> >> >>=3D3D20 >> >> > >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ >> >> >Content-Type: text/html=3D3B charset=3D3D"iso-8859-1" >> >> >Content-Transfer-Encoding: quoted-printable >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > =3D3D3Barchive=3D >> >s" targ=3D3D >> >> >et=3D3D3D_blank>http://modula3.elegosoft.co= >m/cm3/u=3D >> >ploaded=3D3D >> >> >-archives
>> >> >?
>> >> > =3D3D3B
>> >> >I can make another later this week.
>> >> > =3D3D3B
>> >> >All you need is a working cm3 on any system.
>> >> >>From there you can build the whole system=3D3D2C targeting any syste= >m.> >> >> >> >As long as that cm3 understands LONGINT and your target system.
>> >> >And it is easier=3D3D2C but not necessary=3D3D2C if you have Python. = >:)
>> >> > =3D3D3B
>> >> > =3D3D3B- Jay

 =3D3D3B
>=3D3D3B Date: Tue=3D3D2C = >31 Mar 2009=3D >> > 15:43:41 -=3D3D >> >> >0500
>=3D3D3B From: martinbishop at bellsouth.net
>=3D3D3B To:= > mika at a=3D >> >sync.ca=3D3D >> >> >ltech.edu
>=3D3D3B CC: m3devel at elegosoft.com
>=3D3D3B Subje= >ct: Re:=3D >> > [M3dev=3D3D >> >> >el] Help finding CM3 compiler for Linux?
>=3D3D3B
>=3D3D3B= > Not su=3D >> >re if t=3D3D >> >> >his helps=3D3D2C but on my linux system:
>=3D3D3B
>=3D3D3B= > Critical=3D >> > Mass Mod=3D3D >> >> >ula-3 version d5.7.0
>=3D3D3B last updated: 2008-03-16
>=3D= >3D3B co=3D >> >mpiled:=3D3D >> >> > 2008-08-14 00:56:14
>=3D3D3B configuration: /usr/local/cm3/bin/= >cm3.c=3D >> >fg> >> >>>=3D3D3B
>=3D3D3B Linux thinkpad 2.6.27-11-generic #1 SMP Th= >u Jan 2=3D >> >9 19:24=3D3D >> >> >:39 UTC 2009
>=3D3D3B i686 GNU/Linux
>=3D3D3B
>=3D3D3= >B
>=3D >> >=3D3D3B I don=3D3D >> >> >'t have the cm3 tarball=3D3D2C but I do have the sources in cm3/ stil= >l.> >>>=3D3D >> >> >=3D3D3B
>=3D3D3B Mika Nystrom wrote:
>=3D3D3B >=3D3D3B H= >ello everyo=3D >> >ne=3D3D2C
&g=3D3D >> >> >t=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B This is=3D3D2C for me= >=3D3D2C a most un=3D >> >fortunate time =3D3D >> >> >for the CM3 servers to
>=3D3D3B >=3D3D3B have crashed. I'm tea= >ching a=3D >> > class =3D3D >> >> >using Modula-3=3D3D2C and we need a
>=3D3D3B >=3D3D3B compiler= >... here'=3D >> >s the una=3D3D >> >> >me of the system I'm trying to use:
>=3D3D3B >=3D3D3B
>= >=3D3D3B &g=3D >> >t=3D3D3B Linu=3D3D >> >> >x lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Linux= >> >>&g=3D3D >> >> >t=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B The most recent archive= >s I have fo=3D >> >r Linux are=3D3D >> >> >:
>=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B cm3-min-POSIX-LI= >NUXLIBC6-5.=3D >> >4.0.tgz cm3=3D3D >> >> >-src-all-5.4.0.tgz
>=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3= >B And they =3D >> >don't seem =3D3D >> >> >to work on this system: I can compile a program
>=3D3D3B >=3D3= >D3B but=3D >> > when I=3D3D >> >> > try to run it=3D3D2C it says "Segmentation fault". Can anyone
>= >=3D3D3B=3D >> > >=3D3D3B=3D3D >> >> > help? (My understanding is that I need 5.5.1 or later...)
>=3D3= >D3B &=3D >> >gt=3D3D3B=3D3D >> >> >
>=3D3D3B >=3D3D3B Mika
>=3D3D3B >=3D3D3B
>=3D3D= >3B
> >> >> >> >=3D3D >> >> > >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_-- >> > >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ >> >Content-Type: text/html=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> > >> > >> > >> > >> >These archives do have a different format=3D2C yes.
>> >But it isn't a bad format.
>> >cminstall is pretty worthless imho.
>> >Extract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.
>> > =3D3B
>> > =3D3B- Jay

 =3D3B
>=3D3B To: jay.krell at cornell.edu<= >BR>>=3D3B=3D >> > Subject: Re: [M3devel] Help finding CM3 compiler for Linux?
>=3D3= >B Dat=3D >> >e: Tue=3D2C 31 Mar 2009 15:56:11 -0700
>=3D3B From: mika at async.calt= >ech.edu=3D >> >
>=3D3B
>=3D3B No=3D2C I'm sorry...
>=3D3B
>=3D3B = >the archives =3D >> >do not have the usual format. I'm expecting to unpack
>=3D3B and ru= >n "cm=3D >> >install" and then unpack the big source tar on top and
>=3D3B buil= >d tha=3D >> >t. But there's no cminstall in the archive on this page.
>=3D3B Thi= >s is =3D >> >"the normal procedure" for installing CM3=3D2C no? It's what
>=3D3B= > the in=3D >> >structions say to do=3D2C as well...
>=3D3B
>=3D3B And the li= >nk from t=3D >> >he "Download" page is broken (to -d5.5.0.tgz).
>=3D3B
>=3D3B = >Mika> >>>=3D3B
>=3D3B Jay writes:
>=3D3B >=3D3B--_806446ae-8d10-= >4d74-8eea-5=3D >> >1aa365e9204_
>=3D3B >=3D3BContent-Type: text/plain=3D3B charset= >=3D3D"iso-885=3D >> >9-1"
>=3D3B >=3D3BContent-Transfer-Encoding: quoted-printable
= >>=3D3B =3D >> >>=3D3B
>=3D3B >=3D3B
>=3D3B >=3D3B http://modula3.elegos= >oft.com/cm3/u=3D >> >ploaded-archives
>=3D3B >=3D3B
>=3D3B >=3D3B?
>=3D3B = >>=3D3B
>=3D >> >=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B
>=3D3B >=3D3BI can mak= >e another later t=3D >> >his week.
>=3D3B >=3D3B
>=3D3B >=3D3B=3D3D20
>=3D3B &= >gt=3D3B
>=3D3B=3D >> > >=3D3BAll you need is a working cm3 on any system.
>=3D3B >=3D= >3B
>=3D >> >=3D3B >=3D3B>=3D3BFrom there you can build the whole system=3D3D2C t= >argeting an=3D >> >y system.
>=3D3B >=3D3B
>=3D3B >=3D3BAs long as that cm3 u= >nderstands =3D >> >LONGINT and your target system.
>=3D3B >=3D3B
>=3D3B >=3D3= >BAnd it is =3D >> >easier=3D3D2C but not necessary=3D3D2C if you have Python. :)
>=3D3= >B >=3D3B<=3D >> >BR>>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B
>=3D3B >=3D3B - = >Jay
>=3D3B >=3D >> >=3D3B
>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B Date: Tue= >=3D3D2C 31 Mar 2009=3D >> > 15:43:41 -0500
>=3D3B >=3D3B>=3D3B From: martinbishop at bellsout= >h.net
=3D >> >>=3D3B >=3D3B>=3D3B To: mika at async.caltech.edu
>=3D3B >=3D3= >B>=3D3B CC: m=3D >> >3devel at elegosoft.com
>=3D3B >=3D3B>=3D3B Subject: Re: [M3devel]= > Help fin=3D >> >ding CM3 compiler for Linux?
>=3D3B >=3D3B>=3D3B=3D3D20
>= >=3D3B >=3D3B&g=3D >> >t=3D3B Not sure if this helps=3D3D2C but on my linux system:
>=3D3B= > >=3D3B&g=3D >> >t=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B Critical Mass Modula-3 versio= >n d5.7.0
&=3D >> >gt=3D3B >=3D3B>=3D3B last updated: 2008-03-16
>=3D3B >=3D3B&g= >t=3D3B compiled=3D >> >: 2008-08-14 00:56:14
>=3D3B >=3D3B>=3D3B configuration: /usr/l= >ocal/cm3/=3D >> >bin/cm3.cfg
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B >=3D3B>= >=3D3B Linux thinkp=3D >> >ad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009
>=3D3B >= >=3D3B&g=3D >> >t=3D3B i686 GNU/Linux
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B &g= >t=3D3B>=3D3B=3D3D20=3D >> >
>=3D3B >=3D3B>=3D3B I don't have the cm3 tarball=3D3D2C but I = >do have the=3D >> > sources in cm3/ still.
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B = >>=3D3B>=3D3B =3D >> >Mika Nystrom wrote:
>=3D3B >=3D3B>=3D3B >=3D3B Hello everyone= >=3D3D2C
&g=3D >> >t=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B >= >=3D3B This is=3D3D2C fo=3D >> >r me=3D3D2C a most unfortunate time for the CM3 servers to
>=3D3B &= >gt=3D3B&g=3D >> >t=3D3B >=3D3B have crashed. I'm teaching a class using Modula-3=3D3D2C= > and we n=3D >> >eed a
>=3D3B >=3D3B>=3D3B >=3D3B compiler... here's the uname= > of the sys=3D >> >tem I'm trying to use:
>=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
&= >gt=3D3B >=3D3B&=3D >> >gt=3D3B >=3D3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2= >008 i68=3D >> >6 GNU/Lin=3D3D
>=3D3B >=3D3Bux
>=3D3B >=3D3B>=3D3B >= >=3D3B=3D3D20
>=3D >> >=3D3B >=3D3B>=3D3B >=3D3B The most recent archives I have for Linu= >x are:
&=3D >> >gt=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B &g= >t=3D3B cm3-min-POSIX-=3D >> >LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D3D20
>=3D3B >=3D3B&g= >t=3D3B >=3D >> >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B >=3D3B And they don't seem t= >o work on this =3D >> >system: I can compile a program
>=3D3B >=3D3B>=3D3B >=3D3B bu= >t when I tr=3D >> >y to run it=3D3D2C it says "Segmentation fault". Can anyone
>=3D3B = >>=3D3B&=3D >> >gt=3D3B >=3D3B help? (My understanding is that I need 5.5.1 or later..= >.)
&=3D >> >gt=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B &g= >t=3D3B Mika
>=3D3B=3D >> > >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B=3D3D20>>=3D3B >=3D3B
&=3D >> >gt=3D3B >=3D3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>=3D3B >= >=3D3BConten=3D >> >t-Type: text/html=3D3B charset=3D3D"iso-8859-1"
>=3D3B >=3D3BCont= >ent-Transfe=3D >> >r-Encoding: quoted-printable
>=3D3B >=3D3B
>=3D3B >=3D3B&l= >t=3D3Bhtml>=3D >> >=3D3B
>=3D3B >=3D3B<=3D3Bhead>=3D3B
>=3D3B >=3D3B<= >=3D3Bstyle>=3D3B
&=3D >> >gt=3D3B >=3D3B.hmmessage P
>=3D3B >=3D3B{
>=3D3B >=3D3Bm= >argin:0px=3D3D3B<=3D >> >BR>>=3D3B >=3D3Bpadding:0px
>=3D3B >=3D3B}
>=3D3B >=3D= >3Bbody.hmmessag=3D >> >e
>=3D3B >=3D3B{
>=3D3B >=3D3Bfont-size: 10pt=3D3D3B
&g= >t=3D3B >=3D3Bfo=3D >> >nt-family:Verdana
>=3D3B >=3D3B}
>=3D3B >=3D3B<=3D3B/sty= >le>=3D3B
&=3D >> >gt=3D3B >=3D3B<=3D3B/head>=3D3B
>=3D3B >=3D3B<=3D3Bbody c= >lass=3D3D3D'hmmessa=3D >> >ge'>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BA href=3D3D3= >D"http://modula3.=3D >> >elegosoft.com/cm3/uploaded-archives" targ=3D3D
>=3D3B >=3D3Bet=3D= >3D3D_blank&=3D >> >gt=3D3B<=3D3BFONT color=3D3D3D#0068cf>=3D3Bhttp://modula3.elegosoft.= >com/cm3/upl=3D >> >oaded=3D3D
>=3D3B >=3D3B-archives<=3D3B/FONT>=3D3B<=3D3B/A&= >gt=3D3B<=3D3BBR&g=3D >> >t=3D3B
>=3D3B >=3D3B?<=3D3BBR>=3D3B
>=3D3B >=3D3B&= >=3D3Bnbsp=3D3D3B<=3D3B=3D >> >BR>=3D3B
>=3D3B >=3D3BI can make another later this week.<=3D= >3BBR>=3D3B<=3D >> >BR>>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
>=3D3B &= >gt=3D3BAll you need=3D >> > is a working cm3 on any system.<=3D3BBR>=3D3B
>=3D3B >=3D3B&= >gt=3D3BFrom t=3D >> >here you can build the whole system=3D3D2C targeting any system.<=3D3B= >BR>=3D >> >=3D3B
>=3D3B >=3D3BAs long as that cm3 understands LONGINT and yo= >ur target=3D >> > system.<=3D3BBR>=3D3B
>=3D3B >=3D3BAnd it is easier=3D3D2C b= >ut not necess=3D >> >ary=3D3D2C if you have Python. :)<=3D3BBR>=3D3B
>=3D3B >=3D3B= >&=3D3Bnbsp=3D >> >=3D3D3B<=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B- Jay&= >lt=3D3BBR>=3D3B<=3D >> >=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B = >Date: Tue=3D3D2C 31 M=3D >> >ar 2009 15:43:41 -=3D3D
>=3D3B >=3D3B0500<=3D3BBR>=3D3B&= >=3D3Bgt=3D3D3B From=3D >> >: martinbishop at bellsouth.net<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B To: mik= >a at async.ca=3D >> >=3D3D
>=3D3B >=3D3Bltech.edu<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B = >CC: m3devel at elego=3D >> >soft.com<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Subject: Re: [M3dev=3D3D>>=3D3B >=3D >> >=3D3Bel] Help finding CM3 compiler for Linux?<=3D3BBR>=3D3B&=3D3B= >gt=3D3D3B <=3D >> >=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Not sure if t=3D3D
>=3D3B >=3D3= >Bhis helps=3D3D2C b=3D >> >ut on my linux system:<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B <=3D3BBR>= >=3D3B&=3D3Bgt=3D >> >=3D3D3B Critical Mass Mod=3D3D
>=3D3B >=3D3Bula-3 version d5.7.0&= >lt=3D3BBR>=3D >> >=3D3B&=3D3Bgt=3D3D3B last updated: 2008-03-16<=3D3BBR>=3D3B&= >=3D3Bgt=3D3D3B comp=3D >> >iled:=3D3D
>=3D3B >=3D3B 2008-08-14 00:56:14<=3D3BBR>=3D3B&am= >p=3D3Bgt=3D3D3B c=3D >> >onfiguration: /usr/local/cm3/bin/cm3.cfg<=3D3BBR=3D3D
>=3D3B >= >=3D3B>=3D3B&=3D >> >amp=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Linux thinkpad 2.= >6.27-11-generic=3D >> > #1 SMP Thu Jan 29 19:24=3D3D
>=3D3B >=3D3B:39 UTC 2009<=3D3BBR= >>=3D3B&=3D >> >=3D3Bgt=3D3D3B i686 GNU/Linux<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B <=3D= >3BBR>=3D3B&=3D3B=3D >> >gt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B I don=3D3D
>=3D3B &g= >t=3D3B't have the c=3D >> >m3 tarball=3D3D2C but I do have the sources in cm3/ still.<=3D3BBR>= >=3D3B&=3D >> >=3D3Bgt=3D3D
>=3D3B >=3D3B=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt= >=3D3D3B Mika Nystrom wr=3D >> >ote:<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B Hello everyo= >ne=3D3D2C<=3D3BBR=3D >> >>=3D3B&=3D3Bg=3D3D
>=3D3B >=3D3Bt=3D3D3B &=3D3Bgt=3D3D3B = ><=3D3BBR>=3D3B&=3D >> >=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B This is=3D3D2C for me=3D3D2C a most un= >fortunate time =3D >> >=3D3D
>=3D3B >=3D3Bfor the CM3 servers to<=3D3BBR>=3D3B&= >=3D3Bgt=3D3D3B &=3D >> >=3D3Bgt=3D3D3B have crashed. I'm teaching a class =3D3D
>=3D3B >= >=3D3Busing Mod=3D >> >ula-3=3D3D2C and we need a<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3B= >gt=3D3D3B compile=3D >> >r... here's the una=3D3D
>=3D3B >=3D3Bme of the system I'm trying= > to use:&=3D >> >lt=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3= >B&=3D3Bgt=3D3D3B &am=3D >> >p=3D3Bgt=3D3D3B Linu=3D3D
>=3D3B >=3D3Bx lara 2.6.24ugcs1 #4 SMP = >Mon Feb 11 10=3D >> >:53:03 PST 2008 i686 GNU/Linux<=3D3BBR>=3D3B&=3D3Bg=3D3D
>= >=3D3B >=3D3Bt=3D >> >=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3= >Bgt=3D3D3B The most r=3D >> >ecent archives I have for Linux are=3D3D
>=3D3B >=3D3B:<=3D3BBR= >>=3D3B&=3D >> >=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &= >amp=3D3Bgt=3D3D3B cm3-m=3D >> >in-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D3D
>=3D3B >=3D3B-src-all-5.4.= >0.tgz <=3D >> =3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&a= >mp=3D3Bgt=3D3D3B &=3D >> >=3D3Bgt=3D3D3B And they don't seem =3D3D
>=3D3B >=3D3Bto work on = >this system: =3D >> >I can compile a program<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt= >=3D3D3B but when=3D >> > I=3D3D
>=3D3B >=3D3B try to run it=3D3D2C it says "Segmentation = >fault". Can=3D >> > anyone<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B=3D3D
&= >gt=3D3B >=3D3B help=3D >> >? (My understanding is that I need 5.5.1 or later...)<=3D3BBR>=3D3B&= >amp=3D3Bg=3D >> >t=3D3D3B &=3D3Bgt=3D3D3B=3D3D
>=3D3B >=3D3B <=3D3BBR>=3D3B= >&=3D3Bgt=3D3D3B &=3D >> >=3D3Bgt=3D3D3B Mika<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D= >3B <=3D3BBR>=3D3B&a=3D >> >mp=3D3Bgt=3D3D3B <=3D3BBR>=3D3B<=3D3B/body>=3D3B
>=3D3B >= >=3D3B<=3D3B/html>=3D >> >=3D3B=3D3D
>=3D3B >=3D3B
>=3D3B >=3D3B--_806446ae-8d10-4d7= >4-8eea-51aa365e=3D >> >9204_--
>> >=3D >> > >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_-- > >--_55339e45-8c85-4ab6-9440-0d2131bbad69_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Maybe not.
>Hm. That is bug. There is use with a cvs tree=2C and use without.
>I must have broken use without.
> =3B
>Try this:
>export CM3_ROOT=3Droot of cm3 cvs (for me this is /dev2/cm3=2C
>for you=2C maybe $HOME/cm3?)
>rm =3B$HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6
># *Common and *common in one command
rm =3B$HOME/cm3/cm3-min-LINUXLI= >BC6-d5.7.0/bin/*ommon
cp root of cm3 cvs/m3-sys/cminstall/src/config/cm3= >.cfg $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin
> =3B
>The .cfg will delegate out to the cvs tree.
>I don't like having two copies of files..having to keep them in sync..
> =3BThough the archives are meant to work standalone=2C without CVS.> > =3B But I don't test that so much oops sorry.
>That /might/ not be the right file=2C but it is close.
> =3B
> =3B- Jay

 =3B
>=3B To: jay.krell at cornell.edu
>=3B= > CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] Help finding CM= >3 compiler for Linux?
>=3B Date: Tue=2C 31 Mar 2009 22:59:18 -0700>>=3B From: mika at async.caltech.edu
>=3B
>=3B
>=3B Is the= >re any documentation for this format beyond what you just
>=3B wrote? = >Where?
>=3B
>=3B terpsichore-14: cm3
>=3B --- building in .= >./LINUXLIBC6 ---
>=3B
>=3B new source ->=3B compiling Main.m3<= >BR>>=3B "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.co= >mmon"=2C line 169: quake runtime error: undefined variable: ROOT
>=3B = >
>=3B --procedure-- -line- -file---
>=3B GetM3Back 169 /afs/.ugcs= >/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common
>=3B _IsM3B= >ackFlagSupported 181 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin= >/Unix.common
>=3B IsM3BackFlagSupported 193 /afs/.ugcs/user/mika/cm3/c= >m3-min-LINUXLIBC6-d5.7.0/bin/Unix.common
>=3B GetM3BackFlag 197 /afs/.= >ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common
>=3B m3_b= >ackend 62 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.commo= >n
>=3B program -- <=3Bbuiltin>=3B
>=3B 6 /afs/.ugcs.caltech.e= >du/user/mika/test/LINUXLIBC6/m3make.args
>=3B
>=3B
>=3B Fa= >tal Error: procedure "m3_backend" defined in "/afs/.ugcs/user/mika/cm3/cm3-= >min-LINUXLIBC6-d5.7.0/bin/cm3.cfg" failed.
>=3B
>=3B Jay writes:= >
>=3B >=3B--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_
>=3B >=3BC= >ontent-Type: text/plain=3B charset=3D"iso-8859-1"
>=3B >=3BContent-T= >ransfer-Encoding: quoted-printable
>=3B >=3B
>=3B >=3B
>= >=3B >=3BThese archives do have a different format=3D2C yes.
>=3B >= >=3B
>=3B >=3BBut it isn't a bad format.
>=3B >=3B
>=3B &= >gt=3Bcminstall is pretty worthless imho.
>=3B >=3B
>=3B >=3BE= >xtract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.
>=3B >=3B
&= >gt=3B >=3B=3D20
>=3B >=3B
>=3B >=3B - Jay
>=3B >=3B<= >BR>>=3B >=3B=3D20
>=3B >=3B>=3B To: jay.krell at cornell.edu
&= >gt=3B >=3B>=3B Subject: Re: [M3devel] Help finding CM3 compiler for Lin= >ux?=3D20
>=3B >=3B>=3B Date: Tue=3D2C 31 Mar 2009 15:56:11 -0700R>>=3B >=3B>=3B From: mika at async.caltech.edu
>=3B >=3B>=3B= >=3D20
>=3B >=3B>=3B No=3D2C I'm sorry...
>=3B >=3B>=3B=3D= >20
>=3B >=3B>=3B the archives do not have the usual format. I'm ex= >pecting to unpack
>=3B >=3B>=3B and run "cminstall" and then unpac= >k the big source tar on top and=3D20
>=3B >=3B>=3B build that. But= > there's no cminstall in the archive on this page.
>=3B >=3B>=3B T= >his is "the normal procedure" for installing CM3=3D2C no? It's what
>= >=3B >=3B>=3B the instructions say to do=3D2C as well...
>=3B >= >=3B>=3B=3D20
>=3B >=3B>=3B And the link from the "Download" page= > is broken (to -d5.5.0.tgz).
>=3B >=3B>=3B=3D20
>=3B >=3B&g= >t=3B Mika
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B Jay writes:>>=3B >=3B>=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>= >=3B >=3B>=3B >=3BContent-Type: text/plain=3D3B charset=3D3D"iso-8859-= >1"
>=3B >=3B>=3B >=3BContent-Transfer-Encoding: quoted-printable= >
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B
>=3B >= >=3B>=3B >=3B http://modula3.elegosoft.com/cm3/uploaded-archives
>= >=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B?
>=3B >=3B>= >=3B >=3B
>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >= >=3B
>=3B >=3B>=3B >=3BI can make another later this week.
>= >=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B=3D3D20
>=3B >= >=3B>=3B >=3B
>=3B >=3B>=3B >=3BAll you need is a working cm3= > on any system.
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B= >>=3BFrom there you can build the whole system=3D3D2C targeting any system= >.
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3BAs long as tha= >t cm3 understands LONGINT and your target system.
>=3B >=3B>=3B &g= >t=3B
>=3B >=3B>=3B >=3BAnd it is easier=3D3D2C but not necessary= >=3D3D2C if you have Python. :)
>=3B >=3B>=3B >=3B
>=3B >= >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B
>=3B >=3B>= >=3B >=3B - Jay
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >= >=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Date: Tue=3D3D2C 31 Mar 2009= > 15:43:41 -0500
>=3B >=3B>=3B >=3B>=3B From: martinbishop at bell= >south.net
>=3B >=3B>=3B >=3B>=3B To: mika at async.caltech.edu>>=3B >=3B>=3B >=3B>=3B CC: m3devel at elegosoft.com
>=3B >= >=3B>=3B >=3B>=3B Subject: Re: [M3devel] Help finding CM3 compiler for= > Linux?
>=3B >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B &= >gt=3B>=3B Not sure if this helps=3D3D2C but on my linux system:
>=3B= > >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Criti= >cal Mass Modula-3 version d5.7.0
>=3B >=3B>=3B >=3B>=3B last u= >pdated: 2008-03-16
>=3B >=3B>=3B >=3B>=3B compiled: 2008-08-14= > 00:56:14
>=3B >=3B>=3B >=3B>=3B configuration: /usr/local/cm3= >/bin/cm3.cfg
>=3B >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>= >=3B >=3B>=3B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:3= >9 UTC 2009
>=3B >=3B>=3B >=3B>=3B i686 GNU/Linux
>=3B >= >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B=3D3D20>>=3B >=3B>=3B >=3B>=3B I don't have the cm3 tarball=3D3D2C but I= > do have the sources in cm3/ st=3D
>=3B >=3Bill.
>=3B >=3B>= >=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Mika Nystrom wr= >ote:
>=3B >=3B>=3B >=3B>=3B >=3B Hello everyone=3D3D2C
&g= >t=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B&= >gt=3B >=3B This is=3D3D2C for me=3D3D2C a most unfortunate time for the C= >M3 servers=3D
>=3B >=3B to
>=3B >=3B>=3B >=3B>=3B >= >=3B have crashed. I'm teaching a class using Modula-3=3D3D2C and we need a<= >BR>>=3B >=3B>=3B >=3B>=3B >=3B compiler... here's the uname of = >the system I'm trying to use:
>=3B >=3B>=3B >=3B>=3B >=3B=3D= >3D20
>=3B >=3B>=3B >=3B>=3B >=3B Linux lara 2.6.24ugcs1 #4 S= >MP Mon Feb 11 10:53:03 PST 2008 i686 GNU/=3D
>=3B >=3BLin=3D3D
&g= >t=3B >=3B>=3B >=3Bux
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D2= >0
>=3B >=3B>=3B >=3B>=3B >=3B The most recent archives I hav= >e for Linux are:
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>= >=3B >=3B>=3B >=3B>=3B >=3B cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3= >-src-all-5.4.0.tgz=3D3D20
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20= >
>=3B >=3B>=3B >=3B>=3B >=3B And they don't seem to work on = >this system: I can compile a program
>=3B >=3B>=3B >=3B>=3B &g= >t=3B but when I try to run it=3D3D2C it says "Segmentation fault". Can anyo= >=3D
>=3B >=3Bne
>=3B >=3B>=3B >=3B>=3B >=3B help? (My= > understanding is that I need 5.5.1 or later...)
>=3B >=3B>=3B >= >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B >=3B Mika
= >>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >= >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >= >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>=3B >=3B>=3B >=3BCo= >ntent-Type: text/html=3D3B charset=3D3D"iso-8859-1"
>=3B >=3B>=3B = >>=3BContent-Transfer-Encoding: quoted-printable
>=3B >=3B>=3B &g= >t=3B
>=3B >=3B>=3B >=3B<=3Bhtml>=3B
>=3B >=3B>=3B &= >gt=3B<=3Bhead>=3B
>=3B >=3B>=3B >=3B<=3Bstyle>=3B
>= >=3B >=3B>=3B >=3B.hmmessage P
>=3B >=3B>=3B >=3B{
>= >=3B >=3B>=3B >=3Bmargin:0px=3D3D3B
>=3B >=3B>=3B >=3Bpaddi= >ng:0px
>=3B >=3B>=3B >=3B}
>=3B >=3B>=3B >=3Bbody.hmm= >essage
>=3B >=3B>=3B >=3B{
>=3B >=3B>=3B >=3Bfont-siz= e: 10pt=3D3D3B
>=3B >=3B>=3B >=3Bfont-family:Verdana
>=3B &= >gt=3B>=3B >=3B}
>=3B >=3B>=3B >=3B<=3B/style>=3B
>= >=3B >=3B>=3B >=3B<=3B/head>=3B
>=3B >=3B>=3B >=3B<= >=3Bbody class=3D3D3D'hmmessage'>=3B
>=3B >=3B>=3B >=3B&=3Bn= >bsp=3D3D3B<=3BA href=3D3D3D"http://modula3.elegosoft.com/cm3/uploaded-arc= >hive=3D
>=3B >=3Bs" targ=3D3D
>=3B >=3B>=3B >=3Bet=3D3D3D= >_blank>=3B<=3BFONT color=3D3D3D#0068cf>=3Bhttp://modula3.elegosoft.co= >m/cm3/u=3D
>=3B >=3Bploaded=3D3D
>=3B >=3B>=3B >=3B-archi= >ves<=3B/FONT>=3B<=3B/A>=3B<=3BBR>=3B
>=3B >=3B>=3B >= >=3B?<=3BBR>=3B
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR&= >gt=3B
>=3B >=3B>=3B >=3BI can make another later this week.<= >=3BBR>=3B
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3BR>>=3B >=3B>=3B >=3BAll you need is a working cm3 on any system.<= >=3BBR>=3B
>=3B >=3B>=3B >=3B>=3BFrom there you can build the= > whole system=3D3D2C targeting any system.<=3BBR=3D
>=3B >=3B>= >=3B
>=3B >=3B>=3B >=3BAs long as that cm3 understands LONGINT an= >d your target system.<=3BBR>=3B
>=3B >=3B>=3B >=3BAnd it is = >easier=3D3D2C but not necessary=3D3D2C if you have Python. :)<=3BBR>=3B= >
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B
>=3B &g= >t=3B>=3B >=3B&=3Bnbsp=3D3D3B- Jay<=3BBR>=3B<=3BBR>=3B&=3B= >nbsp=3D3D3B<=3BBR>=3B&=3Bgt=3D3D3B Date: Tue=3D3D2C 31 Mar 2009=3DR>>=3B >=3B 15:43:41 -=3D3D
>=3B >=3B>=3B >=3B0500<=3BBR&g= >t=3B&=3Bgt=3D3D3B From: martinbishop at bellsouth.net<=3BBR>=3B&=3Bg= >t=3D3D3B To: mika at a=3D
>=3B >=3Bsync.ca=3D3D
>=3B >=3B>=3B = >>=3Bltech.edu<=3BBR>=3B&=3Bgt=3D3D3B CC: m3devel at elegosoft.com<= >=3BBR>=3B&=3Bgt=3D3D3B Subject: Re:=3D
>=3B >=3B [M3dev=3D3D>>=3B >=3B>=3B >=3Bel] Help finding CM3 compiler for Linux?<=3BBR= >>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B Not su=3D
>=3B &= >gt=3Bre if t=3D3D
>=3B >=3B>=3B >=3Bhis helps=3D3D2C but on my l= >inux system:<=3BBR>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B C= >ritical=3D
>=3B >=3B Mass Mod=3D3D
>=3B >=3B>=3B >=3Bula-= >3 version d5.7.0<=3BBR>=3B&=3Bgt=3D3D3B last updated: 2008-03-16<= >=3BBR>=3B&=3Bgt=3D3D3B co=3D
>=3B >=3Bmpiled:=3D3D
>=3B &g= >t=3B>=3B >=3B 2008-08-14 00:56:14<=3BBR>=3B&=3Bgt=3D3D3B configu= >ration: /usr/local/cm3/bin/cm3.c=3D
>=3B >=3Bfg<=3BBR=3D3D
>= >=3B >=3B>=3B >=3B>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3= >B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 2=3D
>=3B >=3B9 19= >:24=3D3D
>=3B >=3B>=3B >=3B:39 UTC 2009<=3BBR>=3B&=3Bgt= >=3D3D3B i686 GNU/Linux<=3BBR>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bg= >t=3D3D3B <=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3D3B I don=3D3D
&= >gt=3B >=3B>=3B >=3B't have the cm3 tarball=3D3D2C but I do have the s= >ources in cm3/ still.<=3BBR=3D
>=3B >=3B>=3B&=3Bgt=3D3D
&g= >t=3B >=3B>=3B >=3B=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B Mika Nystrom= > wrote:<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B Hello everyo=3D
&= >gt=3B >=3Bne=3D3D2C<=3BBR>=3B&=3Bg=3D3D
>=3B >=3B>=3B >= >=3Bt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3= >B This is=3D3D2C for me=3D3D2C a most un=3D
>=3B >=3Bfortunate time = >=3D3D
>=3B >=3B>=3B >=3Bfor the CM3 servers to<=3BBR>=3B&= >=3Bgt=3D3D3B &=3Bgt=3D3D3B have crashed. I'm teaching a=3D
>=3B >= >=3B class =3D3D
>=3B >=3B>=3B >=3Busing Modula-3=3D3D2C and we n= >eed a<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B compiler... here'=3DR>>=3B >=3Bs the una=3D3D
>=3B >=3B>=3B >=3Bme of the system= > I'm trying to use:<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B <=3BBR= >>=3B&=3Bgt=3D3D3B &=3Bg=3D
>=3B >=3Bt=3D3D3B Linu=3D3D
&g= >t=3B >=3B>=3B >=3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2= >008 i686 GNU/Linux<=3BBR=3D
>=3B >=3B>=3B&=3Bg=3D3D
>=3B= > >=3B>=3B >=3Bt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3= >B &=3Bgt=3D3D3B The most recent archives I have fo=3D
>=3B >=3Br = >Linux are=3D3D
>=3B >=3B>=3B >=3B:<=3BBR>=3B&=3Bgt=3D3D3B= > &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B cm3-min-P= OSIX-LINUXLIBC6-5.=3D
>=3B >=3B4.0.tgz cm3=3D3D
>=3B >=3B>= >=3B >=3B-src-all-5.4.0.tgz <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3= >B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B And they =3D
>=3B &g= >t=3Bdon't seem =3D3D
>=3B >=3B>=3B >=3Bto work on this system: I= > can compile a program<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B but= >=3D
>=3B >=3B when I=3D3D
>=3B >=3B>=3B >=3B try to run i= >t=3D3D2C it says "Segmentation fault". Can anyone<=3BBR>=3B&=3Bgt=3D= >3D3B=3D
>=3B >=3B &=3Bgt=3D3D3B=3D3D
>=3B >=3B>=3B >= >=3B help? (My understanding is that I need 5.5.1 or later...)<=3BBR>=3B= >&=3Bgt=3D3D3B &=3B=3D
>=3B >=3Bgt=3D3D3B=3D3D
>=3B >=3B= >>=3B >=3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B Mika<=3BBR&= >gt=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B <= >=3BBR>=3B<=3B/body=3D
>=3B >=3B>=3B
>=3B >=3B>=3B >= >=3B<=3B/html>=3B=3D3D
>=3B >=3B>=3B >=3B
>=3B >=3B>= >=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_--
>=3B >=3B
&g= >t=3B >=3B--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_
>=3B >=3BContent= >-Type: text/html=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer= >-Encoding: quoted-printable
>=3B >=3B
>=3B >=3B<=3Bhtml>= >=3B
>=3B >=3B<=3Bhead>=3B
>=3B >=3B<=3Bstyle>=3B
&= >gt=3B >=3B.hmmessage P
>=3B >=3B{
>=3B >=3Bmargin:0px=3D3B<= >BR>>=3B >=3Bpadding:0px
>=3B >=3B}
>=3B >=3Bbody.hmmessag= >e
>=3B >=3B{
>=3B >=3Bfont-size: 10pt=3D3B
>=3B >=3Bfo= >nt-family:Verdana
>=3B >=3B}
>=3B >=3B<=3B/style>=3B
&= >gt=3B >=3B<=3B/head>=3B
>=3B >=3B<=3Bbody class=3D3D'hmmessa= >ge'>=3B
>=3B >=3BThese archives do have a different format=3D2C ye= >s.<=3BBR>=3B
>=3B >=3BBut it isn't a bad format.<=3BBR>=3BR>>=3B >=3Bcminstall is pretty worthless imho.<=3BBR>=3B
>=3B = >>=3BExtract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.<=3BBR>=3B<= >BR>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp= >=3D3B- Jay<=3BBR>=3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3B&=3B= >gt=3D3B To: jay.krell at cornell.edu<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B = >>=3B Subject: Re: [M3devel] Help finding CM3 compiler for Linux? <=3BBR= >>=3B&=3Bgt=3D3B Dat=3D
>=3B >=3Be: Tue=3D2C 31 Mar 2009 15:56:1= >1 -0700<=3BBR>=3B&=3Bgt=3D3B From: mika at async.caltech.edu=3D
>= >=3B >=3B<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B No=3D2C= > I'm sorry...<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B the = >archives =3D
>=3B >=3Bdo not have the usual format. I'm expecting to= > unpack<=3BBR>=3B&=3Bgt=3D3B and run "cm=3D
>=3B >=3Binstall"= > and then unpack the big source tar on top and <=3BBR>=3B&=3Bgt=3D3B= > build tha=3D
>=3B >=3Bt. But there's no cminstall in the archive on= > this page.<=3BBR>=3B&=3Bgt=3D3B This is =3D
>=3B >=3B"the no= >rmal procedure" for installing CM3=3D2C no? It's what<=3BBR>=3B&=3Bg= >t=3D3B the in=3D
>=3B >=3Bstructions say to do=3D2C as well...<=3B= >BR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B And the link from t=3D<= >BR>>=3B >=3Bhe "Download" page is broken (to -d5.5.0.tgz).<=3BBR>= >=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Mika<=3BBR=3D
>=3B &g= >t=3B>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Jay writes:<=3BBR&g= >t=3B&=3Bgt=3D3B &=3Bgt=3D3B--_806446ae-8d10-4d74-8eea-5=3D
>=3B = >>=3B1aa365e9204_<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BContent-Type: = >text/plain=3D3B charset=3D3D"iso-885=3D
>=3B >=3B9-1"<=3BBR>=3B&= >amp=3Bgt=3D3B &=3Bgt=3D3BContent-Transfer-Encoding: quoted-printable<= >=3BBR>=3B&=3Bgt=3D3B =3D
>=3B >=3B&=3Bgt=3D3B<=3BBR>=3B&= >amp=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B htt= >p://modula3.elegosoft.com/cm3/u=3D
>=3B >=3Bploaded-archives<=3BBR= >>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3B?<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D= >
>=3B >=3B=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &a= >mp=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BI can make another l= >ater t=3D
>=3B >=3Bhis week.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >=3B &= >amp=3Bgt=3D3BAll you need is a working cm3 on any system.<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &= >amp=3Bgt=3D3B&=3Bgt=3D3BFrom there you can build the whole system=3D3D2C= > targeting an=3D
>=3B >=3By system.<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAs long as that cm3 un= >derstands =3D
>=3B >=3BLONGINT and your target system.<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAnd= > it is =3D
>=3B >=3Beasier=3D3D2C but not necessary=3D3D2C if you ha= >ve Python. :)<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3B=3D
>=3B= > >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt= >=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B - Jay<=3B= >BR>=3B&=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B= >&=3Bgt=3D3B Date: Tue=3D3D2C 31 Mar 2009=3D
>=3B >=3B 15:43:41 -0= >500<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B From: martinbi= >shop at bellsouth.net<=3BBR>=3B=3D
>=3B >=3B&=3Bgt=3D3B &=3Bg= >t=3D3B&=3Bgt=3D3B To: mika at async.caltech.edu<=3BBR>=3B&=3Bgt=3D3B= > &=3Bgt=3D3B&=3Bgt=3D3B CC: m=3D
>=3B >=3B3devel at elegosoft.com= ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B Subject: Re: [M3d= >evel] Help fin=3D
>=3B >=3Bding CM3 compiler for Linux?<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bg= >t=3D3B &=3Bgt=3D3B&=3Bg=3D
>=3B >=3Bt=3D3B Not sure if this he= >lps=3D3D2C but on my linux system:<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3B&=3Bg=3D
>=3B >=3Bt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &am= >p=3Bgt=3D3B&=3Bgt=3D3B Critical Mass Modula-3 version d5.7.0<=3BBR>= >=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B last upd= >ated: 2008-03-16<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B c= >ompiled=3D
>=3B >=3B: 2008-08-14 00:56:14<=3BBR>=3B&=3Bgt=3D3= >B &=3Bgt=3D3B&=3Bgt=3D3B configuration: /usr/local/cm3/=3D
>=3B = >>=3Bbin/cm3.cfg<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B= >=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B Linux thin= >kp=3D
>=3B >=3Bad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2= >009<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bg=3D
>=3B >=3Bt= >=3D3B i686 GNU/Linux<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D= >3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20= >=3D
>=3B >=3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D= >3B I don't have the cm3 tarball=3D3D2C but I do have the=3D
>=3B >= >=3B sources in cm3/ still.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B = >=3D
>=3B >=3BMika Nystrom wrote:<=3BBR>=3B&=3Bgt=3D3B &=3B= >gt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B Hello everyone=3D3D2C<=3BBR>=3B&am= >p=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B= >=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt= >=3D3B This is=3D3D2C fo=3D
>=3B >=3Br me=3D3D2C a most unfortunate t= >ime for the CM3 servers to<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B have crashed. I'm teaching a = >class using Modula-3=3D3D2C and we n=3D
>=3B >=3Beed a<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B compiler... here= >'s the uname of the sys=3D
>=3B >=3Btem I'm trying to use:<=3BBR&g= >t=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3B= >BR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3B=3D
>=3B >=3Bgt=3D3B &am= >p=3Bgt=3D3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i68= >=3D
>=3B >=3B6 GNU/Lin=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3Bux<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3= >B=3D3D20<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &=3Bgt=3D3B&= >=3Bgt=3D3B &=3Bgt=3D3B The most recent archives I have for Linux are:<= >=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B = >&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt= >=3D3B &=3Bgt=3D3B cm3-min-POSIX-=3D
>=3B >=3BLINUXLIBC6-5.4.0.tgz= > cm3-src-all-5.4.0.tgz=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&am= >p=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B=3D3D20<=3BBR>=3B&=3Bg= >t=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B And they don't seem to w= >ork on this =3D
>=3B >=3Bsystem: I can compile a program<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B but when I tr= >=3D
>=3B >=3By to run it=3D3D2C it says "Segmentation fault". Can an= >yone<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3B=3D
>=3B >=3Bg= >t=3D3B &=3Bgt=3D3B help? (My understanding is that I need 5.5.1 or later= >...)<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bg= >t=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Bgt=3D3B &=3Bgt=3D3B Mika<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >= >=3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3B= >gt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &am= >p=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B-= >-_806446ae-8d10-4d74-8eea-51aa365e9204_<=3BBR>=3B&=3Bgt=3D3B &=3B= >gt=3D3BConten=3D
>=3B >=3Bt-Type: text/html=3D3B charset=3D3D"iso-88= >59-1"<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BContent-Transfe=3D
>= >=3B >=3Br-Encoding: quoted-printable<=3BBR>=3B&=3Bgt=3D3B &=3Bg= >t=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3Bhtml&=3Bg= >t=3D
>=3B >=3B=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Blt=3D3Bhead&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Blt=3D3Bstyle&=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D= >3B &=3Bgt=3D3B.hmmessage P<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B{&l= >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bmargin:0px=3D3D3B<=3B=3D
>= >=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bpadding:0px<=3BBR>=3B&am= >p=3Bgt=3D3B &=3Bgt=3D3B}<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bbody.= >hmmessag=3D
>=3B >=3Be<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B{&l= >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfont-size: 10pt=3D3D3B<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3Bfo=3D
>=3B >=3Bnt-family:Verdana<= >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B}<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B&=3Blt=3D3B/style&=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>= >=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3B/head&=3Bgt=3D3B<=3BBR&g= >t=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3Bbody class=3D3D3D'hmmessa=3D= >
>=3B >=3Bge'&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BA href=3D3D3D"http://modula3.=3D<= >BR>>=3B >=3Belegosoft.com/cm3/uploaded-archives" targ=3D3D<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3Bet=3D3D3D_blank&=3B=3D
>=3B >=3Bg= >t=3D3B&=3Blt=3D3BFONT color=3D3D3D#0068cf&=3Bgt=3D3Bhttp://modula3.el= >egosoft.com/cm3/upl=3D
>=3B >=3Boaded=3D3D<=3BBR>=3B&=3Bgt=3D= >3B &=3Bgt=3D3B-archives&=3Blt=3D3B/FONT&=3Bgt=3D3B&=3Blt=3D3B/A= >&=3Bgt=3D3B&=3Blt=3D3BBR&=3Bg=3D
>=3B >=3Bt=3D3B<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3B?&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3B=3D= >
>=3B >=3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3= >BI can make another later this week.&=3Blt=3D3BBR&=3Bgt=3D3B<=3B=3D= >
>=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp= >=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3BAll you need=3D
>=3B >=3B is a working cm3 on any system.&= >=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Bgt=3D3BFrom t=3D
>=3B >=3Bhere you can build the whole system=3D3= >D2C targeting any system.&=3Blt=3D3BBR&=3Bgt=3D
>=3B >=3B=3D3B= ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAs long as that cm3 understands = >LONGINT and your target=3D
>=3B >=3B system.&=3Blt=3D3BBR&=3Bg= >t=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAnd it is easier=3D3D2C bu= >t not necess=3D
>=3B >=3Bary=3D3D2C if you have Python. :)&=3Blt= >=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp= >=3D3Bnbsp=3D
>=3B >=3B=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR&= >gt=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B- Jay&=3Blt= >=3D3BBR&=3Bgt=3D3B&=3Blt=3D
>=3B >=3B=3D3BBR&=3Bgt=3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3= >B Date: Tue=3D3D2C 31 M=3D
>=3B >=3Bar 2009 15:43:41 -=3D3D<=3BBR&= >gt=3B&=3Bgt=3D3B &=3Bgt=3D3B0500&=3Blt=3D3BBR&=3Bgt=3D3B&=3B= >amp=3D3Bgt=3D3D3B From=3D
>=3B >=3B: martinbishop at bellsouth.net&= >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B To: mika at async.ca=3D
= >>=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bltech.edu&= >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B CC: m3devel at elego=3D
= >>=3B >=3Bsoft.com&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B= > Subject: Re: [M3dev=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D
>= >=3B >=3B=3D3Bel] Help finding CM3 compiler for Linux?&=3Blt=3D3BBR&= >=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D
>=3B >=3B=3D3BBR&= >=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B Not sure if t=3D3D<=3BBR>=3B&=3Bg= >t=3D3B &=3Bgt=3D3Bhis helps=3D3D2C b=3D
>=3B >=3But on my linux s= >ystem:&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3B= >BR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D
>=3B >=3B=3D3D3B Critical Mass = >Mod=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bula-3 version d5.7.0&= >=3Blt=3D3BBR&=3Bgt=3D
>=3B >=3B=3D3B&=3Bamp=3D3Bgt=3D3D3B last= > updated: 2008-03-16&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B = >comp=3D
>=3B >=3Biled:=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3B 2008-08-14 00:56:14&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3= >B c=3D
>=3B >=3Bonfiguration: /usr/local/cm3/bin/cm3.cfg&=3Blt=3D= >3BBR=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B&=3B= >=3D
>=3B >=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3B= >amp=3D3Bgt=3D3D3B Linux thinkpad 2.6.27-11-generic=3D
>=3B >=3B #1 S= >MP Thu Jan 29 19:24=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B:39 UTC = >2009&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3= >D3B i686 GNU/Linux&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &a= >mp=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3B=3D
>=3B >=3Bgt=3D3D3B &a= >mp=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B I don=3D3D<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3B't have the c=3D
>=3B >=3Bm3 tarball= >=3D3D2C but I do have the sources in cm3/ still.&=3Blt=3D3BBR&=3Bgt= >=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D<=3BBR>=3B&=3Bgt=3D3B= > &=3Bgt=3D3B=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D= >3B Mika Nystrom wr=3D
>=3B >=3Bote:&=3Blt=3D3BBR&=3Bgt=3D3B&am= >p=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B Hello everyone=3D3D2C&=3B= >lt=3D3BBR=3D
>=3B >=3B&=3Bgt=3D3B&=3Bamp=3D3Bg=3D3D<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3Bt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt= >=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D3B &=3Bam= >p=3D3Bgt=3D3D3B This is=3D3D2C for me=3D3D2C a most unfortunate time =3D>>=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfor the CM3 s= >ervers to&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp= >=3D
>=3B >=3B=3D3Bgt=3D3D3B have crashed. I'm teaching a class =3D3D= ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Busing Mod=3D
>=3B >=3Bula= >-3=3D3D2C and we need a&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D= >3B &=3Bamp=3D3Bgt=3D3D3B compile=3D
>=3B >=3Br... here's the una= >=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bme of the system I'm trying= > to use:&=3B=3D
>=3B >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt= >=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp= >=3D3Bgt=3D3D3B &=3Bam=3D
>=3B >=3Bp=3D3Bgt=3D3D3B Linu=3D3D<=3B= >BR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 1= >0=3D
>=3B >=3B:53:03 PST 2008 i686 GNU/Linux&=3Blt=3D3BBR&=3Bg= >t=3D3B&=3Bamp=3D3Bg=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bt=3D<= >BR>>=3B >=3B=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt= >=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B The most r=3D
>= >=3B >=3Becent archives I have for Linux are=3D3D<=3BBR>=3B&=3Bgt= >=3D3B &=3Bgt=3D3B:&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B = >>=3B=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3= >B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B cm3-m=3D
>=3B >= >=3Bin-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D3D<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B-src-all-5.4.0.tgz &=3Blt=3D
>=3B =3D3BBR&=3Bgt=3D3B&a= >mp=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt= >=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D3B = >And they don't seem =3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bto work= > on this system: =3D
>=3B >=3BI can compile a program&=3Blt=3D3BB= >R&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B but when= >=3D
>=3B >=3B I=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B try = >to run it=3D3D2C it says "Segmentation fault". Can=3D
>=3B >=3B anyo= >ne&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt= >=3D3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B help=3D
>=3B &= >gt=3B? (My understanding is that I need 5.5.1 or later...)&=3Blt=3D3BBR&= >amp=3Bgt=3D3B&=3Bamp=3D3Bg=3D
>=3B >=3Bt=3D3D3B &=3Bamp=3D3Bgt= >=3D3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B &=3Blt=3D3BBR&am= >p=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D
>=3B >=3B=3D3Bgt= >=3D3D3B Mika&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Ba= >mp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Ba=3D
>=3B >=3B= >mp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Blt=3D3B/body&=3Bgt= >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3B/html&=3Bg= >t=3D
>=3B >=3B=3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >lt=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B--_806446ae-8d10-4d74-8eea-51aa36= >5e=3D
>=3B >=3B9204_--<=3BBR>=3B<=3B/body>=3B
>=3B >= >=3B<=3B/html>=3B=3D
>=3B >=3B
>=3B >=3B--_777fdc4e-3c29-4= >0b4-a3dd-e6243f796cee_--
>= > >--_55339e45-8c85-4ab6-9440-0d2131bbad69_-- From mika at async.caltech.edu Wed Apr 1 08:53:38 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 31 Mar 2009 23:53:38 -0700 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: Your message of "Wed, 01 Apr 2009 06:13:00 -0000." Message-ID: <200904010653.n316rcZs073236@camembert.async.caltech.edu> To be honest, I'm not so sure what's intended. I either get this: "/home/mika/cm3/cm3-std-LINUXLIBC6-d5.7.0/bin/cm3.cfg", line 125: quake runtime error: unable to find a configuration file for (/home/mika/cm3/cm3-std-LINUXLIBC6-d5.7.0/bin/.., /afs/.ugcs/user/mika/cm3/cm3-std-LINUXLIBC6-d5.7.0, LINUXLIBC6) or, if I put back the LINUXLIBC6 file you had me delete: "/home/mika/cm3/cm3-std-LINUXLIBC6-d5.7.0/bin/cm3.cfg", line 128: quake runtime error: /home/mika/cm3/cm3-std-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6, line 61: syntax error: missing: <*EOF*> (found: ) which refers to the following (which looks like cminstall stuff to me): INITIAL_REACTOR_EDITOR = BEGIN_CONFIG "What should be the default text editor for new Reactor users?" <--- this line 10 "EDITOR" 0 "emacsclient" 0 "emacs" 0 "vi" 0 "textedit" 0 "xedit" 6 "/usr/local/emacs/bin" "emacsclient" 6 "/usr/local/bin" "emacsclient" 6 "/usr/local/emacs/bin" "emacs" 6 "/usr/local/bin" "emacs" 6 "/usr/bin" "vi" 6 "/usr/local/X11R5/bin" "xedit" 6 "/usr/openwin/bin" "textedit" Jay writes: >--_55339e45-8c85-4ab6-9440-0d2131bbad69_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Maybe not. > >Hm. That is bug. There is use with a cvs tree=2C and use without. > >I must have broken use without. > >=20 > >Try this: > >export CM3_ROOT=3Droot of cm3 cvs (for me this is /dev2/cm3=2C > >for you=2C maybe $HOME/cm3?) > >rm $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6 > ># *Common and *common in one command >rm $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/*ommon >cp root of cm3 cvs/m3-sys/cminstall/src/config/cm3.cfg $HOME/cm3/cm3-min-LI= >NUXLIBC6-d5.7.0/bin > >=20 > >The .cfg will delegate out to the cvs tree. > >I don't like having two copies of files..having to keep them in sync.. > > Though the archives are meant to work standalone=2C without CVS. > > But I don't test that so much oops sorry. > >That /might/ not be the right file=2C but it is close. > >=20 > > - Jay > >=20 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux?=20 >> Date: Tue=2C 31 Mar 2009 22:59:18 -0700 >> From: mika at async.caltech.edu >>=20 >>=20 >> Is there any documentation for this format beyond what you just >> wrote? Where? >>=20 >> terpsichore-14: cm3 >> --- building in ../LINUXLIBC6 --- >>=20 >> new source -> compiling Main.m3 >> "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common"=2C= > line 169: quake runtime error: undefined variable: ROOT >>=20 >> --procedure-- -line- -file--- >> GetM3Back 169 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3c= >fg.common >> _IsM3BackFlagSupported 181 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5= >.7.0/bin/Unix.common >> IsM3BackFlagSupported 193 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.= >7.0/bin/Unix.common >> GetM3BackFlag 197 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/= >Unix.common >> m3_backend 62 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix= >.common >> program -- >> 6 /afs/.ugcs.caltech.edu/user/mika/test/LINUXLIBC6/m3make.args >>=20 >>=20 >> Fatal Error: procedure "m3_backend" defined in "/afs/.ugcs/user/mika/cm3/= >cm3-min-LINUXLIBC6-d5.7.0/bin/cm3.cfg" failed. >>=20 >> Jay writes: >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> >These archives do have a different format=3D2C yes. >> > >> >But it isn't a bad format. >> > >> >cminstall is pretty worthless imho. >> > >> >Extract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH. >> > >> >=3D20 >> > >> > - Jay >> > >> >=3D20 >> >> To: jay.krell at cornell.edu >> >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux?=3D20 >> >> Date: Tue=3D2C 31 Mar 2009 15:56:11 -0700 >> >> From: mika at async.caltech.edu >> >>=3D20 >> >> No=3D2C I'm sorry... >> >>=3D20 >> >> the archives do not have the usual format. I'm expecting to unpack >> >> and run "cminstall" and then unpack the big source tar on top and=3D20 >> >> build that. But there's no cminstall in the archive on this page. >> >> This is "the normal procedure" for installing CM3=3D2C no? It's what >> >> the instructions say to do=3D2C as well... >> >>=3D20 >> >> And the link from the "Download" page is broken (to -d5.5.0.tgz). >> >>=3D20 >> >> Mika >> >>=3D20 >> >> Jay writes: >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ >> >> >Content-Type: text/plain=3D3B charset=3D3D"iso-8859-1" >> >> >Content-Transfer-Encoding: quoted-printable >> >> > >> >> > >> >> > http://modula3.elegosoft.com/cm3/uploaded-archives >> >> > >> >> >? >> >> > >> >> >=3D3D20 >> >> > >> >> >I can make another later this week. >> >> > >> >> >=3D3D20 >> >> > >> >> >All you need is a working cm3 on any system. >> >> > >> >> >>From there you can build the whole system=3D3D2C targeting any syste= >m. >> >> > >> >> >As long as that cm3 understands LONGINT and your target system. >> >> > >> >> >And it is easier=3D3D2C but not necessary=3D3D2C if you have Python. = >:) >> >> > >> >> >=3D3D20 >> >> > >> >> > - Jay >> >> > >> >> >=3D3D20 >> >> >> Date: Tue=3D3D2C 31 Mar 2009 15:43:41 -0500 >> >> >> From: martinbishop at bellsouth.net >> >> >> To: mika at async.caltech.edu >> >> >> CC: m3devel at elegosoft.com >> >> >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >> >> >>=3D3D20 >> >> >> Not sure if this helps=3D3D2C but on my linux system: >> >> >>=3D3D20 >> >> >> Critical Mass Modula-3 version d5.7.0 >> >> >> last updated: 2008-03-16 >> >> >> compiled: 2008-08-14 00:56:14 >> >> >> configuration: /usr/local/cm3/bin/cm3.cfg >> >> >>=3D3D20 >> >> >> Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 200= >9 >> >> >> i686 GNU/Linux >> >> >>=3D3D20 >> >> >>=3D3D20 >> >> >> I don't have the cm3 tarball=3D3D2C but I do have the sources in cm= >3/ st=3D >> >ill. >> >> >>=3D3D20 >> >> >> Mika Nystrom wrote: >> >> >> > Hello everyone=3D3D2C >> >> >> >=3D3D20 >> >> >> > This is=3D3D2C for me=3D3D2C a most unfortunate time for the CM3 = >servers=3D >> > to >> >> >> > have crashed. I'm teaching a class using Modula-3=3D3D2C and we n= >eed a >> >> >> > compiler... here's the uname of the system I'm trying to use: >> >> >> >=3D3D20 >> >> >> > Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 G= >NU/=3D >> >Lin=3D3D >> >> >ux >> >> >> >=3D3D20 >> >> >> > The most recent archives I have for Linux are: >> >> >> >=3D3D20 >> >> >> > cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D3D20 >> >> >> >=3D3D20 >> >> >> > And they don't seem to work on this system: I can compile a progr= >am >> >> >> > but when I try to run it=3D3D2C it says "Segmentation fault". Can= > anyo=3D >> >ne >> >> >> > help? (My understanding is that I need 5.5.1 or later...) >> >> >> >=3D3D20 >> >> >> > Mika >> >> >> >=3D3D20 >> >> >>=3D3D20 >> >> > >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ >> >> >Content-Type: text/html=3D3B charset=3D3D"iso-8859-1" >> >> >Content-Transfer-Encoding: quoted-printable >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > =3D3D3Barchive=3D >> >s" targ=3D3D >> >> >et=3D3D3D_blank>http://modula3.elegosoft.co= >m/cm3/u=3D >> >ploaded=3D3D >> >> >-archives
>> >> >?
>> >> > =3D3D3B
>> >> >I can make another later this week.
>> >> > =3D3D3B
>> >> >All you need is a working cm3 on any system.
>> >> >>From there you can build the whole system=3D3D2C targeting any syste= >m.> >> >> >> >As long as that cm3 understands LONGINT and your target system.
>> >> >And it is easier=3D3D2C but not necessary=3D3D2C if you have Python. = >:)
>> >> > =3D3D3B
>> >> > =3D3D3B- Jay

 =3D3D3B
>=3D3D3B Date: Tue=3D3D2C = >31 Mar 2009=3D >> > 15:43:41 -=3D3D >> >> >0500
>=3D3D3B From: martinbishop at bellsouth.net
>=3D3D3B To:= > mika at a=3D >> >sync.ca=3D3D >> >> >ltech.edu
>=3D3D3B CC: m3devel at elegosoft.com
>=3D3D3B Subje= >ct: Re:=3D >> > [M3dev=3D3D >> >> >el] Help finding CM3 compiler for Linux?
>=3D3D3B
>=3D3D3B= > Not su=3D >> >re if t=3D3D >> >> >his helps=3D3D2C but on my linux system:
>=3D3D3B
>=3D3D3B= > Critical=3D >> > Mass Mod=3D3D >> >> >ula-3 version d5.7.0
>=3D3D3B last updated: 2008-03-16
>=3D= >3D3B co=3D >> >mpiled:=3D3D >> >> > 2008-08-14 00:56:14
>=3D3D3B configuration: /usr/local/cm3/bin/= >cm3.c=3D >> >fg> >> >>>=3D3D3B
>=3D3D3B Linux thinkpad 2.6.27-11-generic #1 SMP Th= >u Jan 2=3D >> >9 19:24=3D3D >> >> >:39 UTC 2009
>=3D3D3B i686 GNU/Linux
>=3D3D3B
>=3D3D3= >B
>=3D >> >=3D3D3B I don=3D3D >> >> >'t have the cm3 tarball=3D3D2C but I do have the sources in cm3/ stil= >l.> >>>=3D3D >> >> >=3D3D3B
>=3D3D3B Mika Nystrom wrote:
>=3D3D3B >=3D3D3B H= >ello everyo=3D >> >ne=3D3D2C
&g=3D3D >> >> >t=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B This is=3D3D2C for me= >=3D3D2C a most un=3D >> >fortunate time =3D3D >> >> >for the CM3 servers to
>=3D3D3B >=3D3D3B have crashed. I'm tea= >ching a=3D >> > class =3D3D >> >> >using Modula-3=3D3D2C and we need a
>=3D3D3B >=3D3D3B compiler= >... here'=3D >> >s the una=3D3D >> >> >me of the system I'm trying to use:
>=3D3D3B >=3D3D3B
>= >=3D3D3B &g=3D >> >t=3D3D3B Linu=3D3D >> >> >x lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Linux= >> >>&g=3D3D >> >> >t=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B The most recent archive= >s I have fo=3D >> >r Linux are=3D3D >> >> >:
>=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B cm3-min-POSIX-LI= >NUXLIBC6-5.=3D >> >4.0.tgz cm3=3D3D >> >> >-src-all-5.4.0.tgz
>=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3= >B And they =3D >> >don't seem =3D3D >> >> >to work on this system: I can compile a program
>=3D3D3B >=3D3= >D3B but=3D >> > when I=3D3D >> >> > try to run it=3D3D2C it says "Segmentation fault". Can anyone
>= >=3D3D3B=3D >> > >=3D3D3B=3D3D >> >> > help? (My understanding is that I need 5.5.1 or later...)
>=3D3= >D3B &=3D >> >gt=3D3D3B=3D3D >> >> >
>=3D3D3B >=3D3D3B Mika
>=3D3D3B >=3D3D3B
>=3D3D= >3B
> >> >> >> >=3D3D >> >> > >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_-- >> > >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ >> >Content-Type: text/html=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> > >> > >> > >> > >> >These archives do have a different format=3D2C yes.
>> >But it isn't a bad format.
>> >cminstall is pretty worthless imho.
>> >Extract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.
>> > =3D3B
>> > =3D3B- Jay

 =3D3B
>=3D3B To: jay.krell at cornell.edu<= >BR>>=3D3B=3D >> > Subject: Re: [M3devel] Help finding CM3 compiler for Linux?
>=3D3= >B Dat=3D >> >e: Tue=3D2C 31 Mar 2009 15:56:11 -0700
>=3D3B From: mika at async.calt= >ech.edu=3D >> >
>=3D3B
>=3D3B No=3D2C I'm sorry...
>=3D3B
>=3D3B = >the archives =3D >> >do not have the usual format. I'm expecting to unpack
>=3D3B and ru= >n "cm=3D >> >install" and then unpack the big source tar on top and
>=3D3B buil= >d tha=3D >> >t. But there's no cminstall in the archive on this page.
>=3D3B Thi= >s is =3D >> >"the normal procedure" for installing CM3=3D2C no? It's what
>=3D3B= > the in=3D >> >structions say to do=3D2C as well...
>=3D3B
>=3D3B And the li= >nk from t=3D >> >he "Download" page is broken (to -d5.5.0.tgz).
>=3D3B
>=3D3B = >Mika> >>>=3D3B
>=3D3B Jay writes:
>=3D3B >=3D3B--_806446ae-8d10-= >4d74-8eea-5=3D >> >1aa365e9204_
>=3D3B >=3D3BContent-Type: text/plain=3D3B charset= >=3D3D"iso-885=3D >> >9-1"
>=3D3B >=3D3BContent-Transfer-Encoding: quoted-printable
= >>=3D3B =3D >> >>=3D3B
>=3D3B >=3D3B
>=3D3B >=3D3B http://modula3.elegos= >oft.com/cm3/u=3D >> >ploaded-archives
>=3D3B >=3D3B
>=3D3B >=3D3B?
>=3D3B = >>=3D3B
>=3D >> >=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B
>=3D3B >=3D3BI can mak= >e another later t=3D >> >his week.
>=3D3B >=3D3B
>=3D3B >=3D3B=3D3D20
>=3D3B &= >gt=3D3B
>=3D3B=3D >> > >=3D3BAll you need is a working cm3 on any system.
>=3D3B >=3D= >3B
>=3D >> >=3D3B >=3D3B>=3D3BFrom there you can build the whole system=3D3D2C t= >argeting an=3D >> >y system.
>=3D3B >=3D3B
>=3D3B >=3D3BAs long as that cm3 u= >nderstands =3D >> >LONGINT and your target system.
>=3D3B >=3D3B
>=3D3B >=3D3= >BAnd it is =3D >> >easier=3D3D2C but not necessary=3D3D2C if you have Python. :)
>=3D3= >B >=3D3B<=3D >> >BR>>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B
>=3D3B >=3D3B - = >Jay
>=3D3B >=3D >> >=3D3B
>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B Date: Tue= >=3D3D2C 31 Mar 2009=3D >> > 15:43:41 -0500
>=3D3B >=3D3B>=3D3B From: martinbishop at bellsout= >h.net
=3D >> >>=3D3B >=3D3B>=3D3B To: mika at async.caltech.edu
>=3D3B >=3D3= >B>=3D3B CC: m=3D >> >3devel at elegosoft.com
>=3D3B >=3D3B>=3D3B Subject: Re: [M3devel]= > Help fin=3D >> >ding CM3 compiler for Linux?
>=3D3B >=3D3B>=3D3B=3D3D20
>= >=3D3B >=3D3B&g=3D >> >t=3D3B Not sure if this helps=3D3D2C but on my linux system:
>=3D3B= > >=3D3B&g=3D >> >t=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B Critical Mass Modula-3 versio= >n d5.7.0
&=3D >> >gt=3D3B >=3D3B>=3D3B last updated: 2008-03-16
>=3D3B >=3D3B&g= >t=3D3B compiled=3D >> >: 2008-08-14 00:56:14
>=3D3B >=3D3B>=3D3B configuration: /usr/l= >ocal/cm3/=3D >> >bin/cm3.cfg
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B >=3D3B>= >=3D3B Linux thinkp=3D >> >ad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009
>=3D3B >= >=3D3B&g=3D >> >t=3D3B i686 GNU/Linux
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B &g= >t=3D3B>=3D3B=3D3D20=3D >> >
>=3D3B >=3D3B>=3D3B I don't have the cm3 tarball=3D3D2C but I = >do have the=3D >> > sources in cm3/ still.
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B = >>=3D3B>=3D3B =3D >> >Mika Nystrom wrote:
>=3D3B >=3D3B>=3D3B >=3D3B Hello everyone= >=3D3D2C
&g=3D >> >t=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B >= >=3D3B This is=3D3D2C fo=3D >> >r me=3D3D2C a most unfortunate time for the CM3 servers to
>=3D3B &= >gt=3D3B&g=3D >> >t=3D3B >=3D3B have crashed. I'm teaching a class using Modula-3=3D3D2C= > and we n=3D >> >eed a
>=3D3B >=3D3B>=3D3B >=3D3B compiler... here's the uname= > of the sys=3D >> >tem I'm trying to use:
>=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
&= >gt=3D3B >=3D3B&=3D >> >gt=3D3B >=3D3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2= >008 i68=3D >> >6 GNU/Lin=3D3D
>=3D3B >=3D3Bux
>=3D3B >=3D3B>=3D3B >= >=3D3B=3D3D20
>=3D >> >=3D3B >=3D3B>=3D3B >=3D3B The most recent archives I have for Linu= >x are:
&=3D >> >gt=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B &g= >t=3D3B cm3-min-POSIX-=3D >> >LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D3D20
>=3D3B >=3D3B&g= >t=3D3B >=3D >> >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B >=3D3B And they don't seem t= >o work on this =3D >> >system: I can compile a program
>=3D3B >=3D3B>=3D3B >=3D3B bu= >t when I tr=3D >> >y to run it=3D3D2C it says "Segmentation fault". Can anyone
>=3D3B = >>=3D3B&=3D >> >gt=3D3B >=3D3B help? (My understanding is that I need 5.5.1 or later..= >.)
&=3D >> >gt=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B &g= >t=3D3B Mika
>=3D3B=3D >> > >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B=3D3D20>>=3D3B >=3D3B
&=3D >> >gt=3D3B >=3D3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>=3D3B >= >=3D3BConten=3D >> >t-Type: text/html=3D3B charset=3D3D"iso-8859-1"
>=3D3B >=3D3BCont= >ent-Transfe=3D >> >r-Encoding: quoted-printable
>=3D3B >=3D3B
>=3D3B >=3D3B&l= >t=3D3Bhtml>=3D >> >=3D3B
>=3D3B >=3D3B<=3D3Bhead>=3D3B
>=3D3B >=3D3B<= >=3D3Bstyle>=3D3B
&=3D >> >gt=3D3B >=3D3B.hmmessage P
>=3D3B >=3D3B{
>=3D3B >=3D3Bm= >argin:0px=3D3D3B<=3D >> >BR>>=3D3B >=3D3Bpadding:0px
>=3D3B >=3D3B}
>=3D3B >=3D= >3Bbody.hmmessag=3D >> >e
>=3D3B >=3D3B{
>=3D3B >=3D3Bfont-size: 10pt=3D3D3B
&g= >t=3D3B >=3D3Bfo=3D >> >nt-family:Verdana
>=3D3B >=3D3B}
>=3D3B >=3D3B<=3D3B/sty= >le>=3D3B
&=3D >> >gt=3D3B >=3D3B<=3D3B/head>=3D3B
>=3D3B >=3D3B<=3D3Bbody c= >lass=3D3D3D'hmmessa=3D >> >ge'>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BA href=3D3D3= >D"http://modula3.=3D >> >elegosoft.com/cm3/uploaded-archives" targ=3D3D
>=3D3B >=3D3Bet=3D= >3D3D_blank&=3D >> >gt=3D3B<=3D3BFONT color=3D3D3D#0068cf>=3D3Bhttp://modula3.elegosoft.= >com/cm3/upl=3D >> >oaded=3D3D
>=3D3B >=3D3B-archives<=3D3B/FONT>=3D3B<=3D3B/A&= >gt=3D3B<=3D3BBR&g=3D >> >t=3D3B
>=3D3B >=3D3B?<=3D3BBR>=3D3B
>=3D3B >=3D3B&= >=3D3Bnbsp=3D3D3B<=3D3B=3D >> >BR>=3D3B
>=3D3B >=3D3BI can make another later this week.<=3D= >3BBR>=3D3B<=3D >> >BR>>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
>=3D3B &= >gt=3D3BAll you need=3D >> > is a working cm3 on any system.<=3D3BBR>=3D3B
>=3D3B >=3D3B&= >gt=3D3BFrom t=3D >> >here you can build the whole system=3D3D2C targeting any system.<=3D3B= >BR>=3D >> >=3D3B
>=3D3B >=3D3BAs long as that cm3 understands LONGINT and yo= >ur target=3D >> > system.<=3D3BBR>=3D3B
>=3D3B >=3D3BAnd it is easier=3D3D2C b= >ut not necess=3D >> >ary=3D3D2C if you have Python. :)<=3D3BBR>=3D3B
>=3D3B >=3D3B= >&=3D3Bnbsp=3D >> >=3D3D3B<=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B- Jay&= >lt=3D3BBR>=3D3B<=3D >> >=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B = >Date: Tue=3D3D2C 31 M=3D >> >ar 2009 15:43:41 -=3D3D
>=3D3B >=3D3B0500<=3D3BBR>=3D3B&= >=3D3Bgt=3D3D3B From=3D >> >: martinbishop at bellsouth.net<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B To: mik= >a at async.ca=3D >> >=3D3D
>=3D3B >=3D3Bltech.edu<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B = >CC: m3devel at elego=3D >> >soft.com<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Subject: Re: [M3dev=3D3D>>=3D3B >=3D >> >=3D3Bel] Help finding CM3 compiler for Linux?<=3D3BBR>=3D3B&=3D3B= >gt=3D3D3B <=3D >> >=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Not sure if t=3D3D
>=3D3B >=3D3= >Bhis helps=3D3D2C b=3D >> >ut on my linux system:<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B <=3D3BBR>= >=3D3B&=3D3Bgt=3D >> >=3D3D3B Critical Mass Mod=3D3D
>=3D3B >=3D3Bula-3 version d5.7.0&= >lt=3D3BBR>=3D >> >=3D3B&=3D3Bgt=3D3D3B last updated: 2008-03-16<=3D3BBR>=3D3B&= >=3D3Bgt=3D3D3B comp=3D >> >iled:=3D3D
>=3D3B >=3D3B 2008-08-14 00:56:14<=3D3BBR>=3D3B&am= >p=3D3Bgt=3D3D3B c=3D >> >onfiguration: /usr/local/cm3/bin/cm3.cfg<=3D3BBR=3D3D
>=3D3B >= >=3D3B>=3D3B&=3D >> >amp=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Linux thinkpad 2.= >6.27-11-generic=3D >> > #1 SMP Thu Jan 29 19:24=3D3D
>=3D3B >=3D3B:39 UTC 2009<=3D3BBR= >>=3D3B&=3D >> >=3D3Bgt=3D3D3B i686 GNU/Linux<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B <=3D= >3BBR>=3D3B&=3D3B=3D >> >gt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B I don=3D3D
>=3D3B &g= >t=3D3B't have the c=3D >> >m3 tarball=3D3D2C but I do have the sources in cm3/ still.<=3D3BBR>= >=3D3B&=3D >> >=3D3Bgt=3D3D
>=3D3B >=3D3B=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt= >=3D3D3B Mika Nystrom wr=3D >> >ote:<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B Hello everyo= >ne=3D3D2C<=3D3BBR=3D >> >>=3D3B&=3D3Bg=3D3D
>=3D3B >=3D3Bt=3D3D3B &=3D3Bgt=3D3D3B = ><=3D3BBR>=3D3B&=3D >> >=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B This is=3D3D2C for me=3D3D2C a most un= >fortunate time =3D >> >=3D3D
>=3D3B >=3D3Bfor the CM3 servers to<=3D3BBR>=3D3B&= >=3D3Bgt=3D3D3B &=3D >> >=3D3Bgt=3D3D3B have crashed. I'm teaching a class =3D3D
>=3D3B >= >=3D3Busing Mod=3D >> >ula-3=3D3D2C and we need a<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3B= >gt=3D3D3B compile=3D >> >r... here's the una=3D3D
>=3D3B >=3D3Bme of the system I'm trying= > to use:&=3D >> >lt=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3= >B&=3D3Bgt=3D3D3B &am=3D >> >p=3D3Bgt=3D3D3B Linu=3D3D
>=3D3B >=3D3Bx lara 2.6.24ugcs1 #4 SMP = >Mon Feb 11 10=3D >> >:53:03 PST 2008 i686 GNU/Linux<=3D3BBR>=3D3B&=3D3Bg=3D3D
>= >=3D3B >=3D3Bt=3D >> >=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3= >Bgt=3D3D3B The most r=3D >> >ecent archives I have for Linux are=3D3D
>=3D3B >=3D3B:<=3D3BBR= >>=3D3B&=3D >> >=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &= >amp=3D3Bgt=3D3D3B cm3-m=3D >> >in-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D3D
>=3D3B >=3D3B-src-all-5.4.= >0.tgz <=3D >> =3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&a= >mp=3D3Bgt=3D3D3B &=3D >> >=3D3Bgt=3D3D3B And they don't seem =3D3D
>=3D3B >=3D3Bto work on = >this system: =3D >> >I can compile a program<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt= >=3D3D3B but when=3D >> > I=3D3D
>=3D3B >=3D3B try to run it=3D3D2C it says "Segmentation = >fault". Can=3D >> > anyone<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B=3D3D
&= >gt=3D3B >=3D3B help=3D >> >? (My understanding is that I need 5.5.1 or later...)<=3D3BBR>=3D3B&= >amp=3D3Bg=3D >> >t=3D3D3B &=3D3Bgt=3D3D3B=3D3D
>=3D3B >=3D3B <=3D3BBR>=3D3B= >&=3D3Bgt=3D3D3B &=3D >> >=3D3Bgt=3D3D3B Mika<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D= >3B <=3D3BBR>=3D3B&a=3D >> >mp=3D3Bgt=3D3D3B <=3D3BBR>=3D3B<=3D3B/body>=3D3B
>=3D3B >= >=3D3B<=3D3B/html>=3D >> >=3D3B=3D3D
>=3D3B >=3D3B
>=3D3B >=3D3B--_806446ae-8d10-4d7= >4-8eea-51aa365e=3D >> >9204_--
>> >=3D >> > >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_-- > >--_55339e45-8c85-4ab6-9440-0d2131bbad69_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Maybe not.
>Hm. That is bug. There is use with a cvs tree=2C and use without.
>I must have broken use without.
> =3B
>Try this:
>export CM3_ROOT=3Droot of cm3 cvs (for me this is /dev2/cm3=2C
>for you=2C maybe $HOME/cm3?)
>rm =3B$HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6
># *Common and *common in one command
rm =3B$HOME/cm3/cm3-min-LINUXLI= >BC6-d5.7.0/bin/*ommon
cp root of cm3 cvs/m3-sys/cminstall/src/config/cm3= >.cfg $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin
> =3B
>The .cfg will delegate out to the cvs tree.
>I don't like having two copies of files..having to keep them in sync..
> =3BThough the archives are meant to work standalone=2C without CVS.> > =3B But I don't test that so much oops sorry.
>That /might/ not be the right file=2C but it is close.
> =3B
> =3B- Jay

 =3B
>=3B To: jay.krell at cornell.edu
>=3B= > CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] Help finding CM= >3 compiler for Linux?
>=3B Date: Tue=2C 31 Mar 2009 22:59:18 -0700>>=3B From: mika at async.caltech.edu
>=3B
>=3B
>=3B Is the= >re any documentation for this format beyond what you just
>=3B wrote? = >Where?
>=3B
>=3B terpsichore-14: cm3
>=3B --- building in .= >./LINUXLIBC6 ---
>=3B
>=3B new source ->=3B compiling Main.m3<= >BR>>=3B "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.co= >mmon"=2C line 169: quake runtime error: undefined variable: ROOT
>=3B = >
>=3B --procedure-- -line- -file---
>=3B GetM3Back 169 /afs/.ugcs= >/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common
>=3B _IsM3B= >ackFlagSupported 181 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin= >/Unix.common
>=3B IsM3BackFlagSupported 193 /afs/.ugcs/user/mika/cm3/c= >m3-min-LINUXLIBC6-d5.7.0/bin/Unix.common
>=3B GetM3BackFlag 197 /afs/.= >ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common
>=3B m3_b= >ackend 62 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.commo= >n
>=3B program -- <=3Bbuiltin>=3B
>=3B 6 /afs/.ugcs.caltech.e= >du/user/mika/test/LINUXLIBC6/m3make.args
>=3B
>=3B
>=3B Fa= >tal Error: procedure "m3_backend" defined in "/afs/.ugcs/user/mika/cm3/cm3-= >min-LINUXLIBC6-d5.7.0/bin/cm3.cfg" failed.
>=3B
>=3B Jay writes:= >
>=3B >=3B--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_
>=3B >=3BC= >ontent-Type: text/plain=3B charset=3D"iso-8859-1"
>=3B >=3BContent-T= >ransfer-Encoding: quoted-printable
>=3B >=3B
>=3B >=3B
>= >=3B >=3BThese archives do have a different format=3D2C yes.
>=3B >= >=3B
>=3B >=3BBut it isn't a bad format.
>=3B >=3B
>=3B &= >gt=3Bcminstall is pretty worthless imho.
>=3B >=3B
>=3B >=3BE= >xtract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.
>=3B >=3B
&= >gt=3B >=3B=3D20
>=3B >=3B
>=3B >=3B - Jay
>=3B >=3B<= >BR>>=3B >=3B=3D20
>=3B >=3B>=3B To: jay.krell at cornell.edu
&= >gt=3B >=3B>=3B Subject: Re: [M3devel] Help finding CM3 compiler for Lin= >ux?=3D20
>=3B >=3B>=3B Date: Tue=3D2C 31 Mar 2009 15:56:11 -0700R>>=3B >=3B>=3B From: mika at async.caltech.edu
>=3B >=3B>=3B= >=3D20
>=3B >=3B>=3B No=3D2C I'm sorry...
>=3B >=3B>=3B=3D= >20
>=3B >=3B>=3B the archives do not have the usual format. I'm ex= >pecting to unpack
>=3B >=3B>=3B and run "cminstall" and then unpac= >k the big source tar on top and=3D20
>=3B >=3B>=3B build that. But= > there's no cminstall in the archive on this page.
>=3B >=3B>=3B T= >his is "the normal procedure" for installing CM3=3D2C no? It's what
>= >=3B >=3B>=3B the instructions say to do=3D2C as well...
>=3B >= >=3B>=3B=3D20
>=3B >=3B>=3B And the link from the "Download" page= > is broken (to -d5.5.0.tgz).
>=3B >=3B>=3B=3D20
>=3B >=3B&g= >t=3B Mika
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B Jay writes:>>=3B >=3B>=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>= >=3B >=3B>=3B >=3BContent-Type: text/plain=3D3B charset=3D3D"iso-8859-= >1"
>=3B >=3B>=3B >=3BContent-Transfer-Encoding: quoted-printable= >
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B
>=3B >= >=3B>=3B >=3B http://modula3.elegosoft.com/cm3/uploaded-archives
>= >=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B?
>=3B >=3B>= >=3B >=3B
>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >= >=3B
>=3B >=3B>=3B >=3BI can make another later this week.
>= >=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B=3D3D20
>=3B >= >=3B>=3B >=3B
>=3B >=3B>=3B >=3BAll you need is a working cm3= > on any system.
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B= >>=3BFrom there you can build the whole system=3D3D2C targeting any system= >.
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3BAs long as tha= >t cm3 understands LONGINT and your target system.
>=3B >=3B>=3B &g= >t=3B
>=3B >=3B>=3B >=3BAnd it is easier=3D3D2C but not necessary= >=3D3D2C if you have Python. :)
>=3B >=3B>=3B >=3B
>=3B >= >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B
>=3B >=3B>= >=3B >=3B - Jay
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >= >=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Date: Tue=3D3D2C 31 Mar 2009= > 15:43:41 -0500
>=3B >=3B>=3B >=3B>=3B From: martinbishop at bell= >south.net
>=3B >=3B>=3B >=3B>=3B To: mika at async.caltech.edu>>=3B >=3B>=3B >=3B>=3B CC: m3devel at elegosoft.com
>=3B >= >=3B>=3B >=3B>=3B Subject: Re: [M3devel] Help finding CM3 compiler for= > Linux?
>=3B >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B &= >gt=3B>=3B Not sure if this helps=3D3D2C but on my linux system:
>=3B= > >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Criti= >cal Mass Modula-3 version d5.7.0
>=3B >=3B>=3B >=3B>=3B last u= >pdated: 2008-03-16
>=3B >=3B>=3B >=3B>=3B compiled: 2008-08-14= > 00:56:14
>=3B >=3B>=3B >=3B>=3B configuration: /usr/local/cm3= >/bin/cm3.cfg
>=3B >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>= >=3B >=3B>=3B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:3= >9 UTC 2009
>=3B >=3B>=3B >=3B>=3B i686 GNU/Linux
>=3B >= >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B=3D3D20>>=3B >=3B>=3B >=3B>=3B I don't have the cm3 tarball=3D3D2C but I= > do have the sources in cm3/ st=3D
>=3B >=3Bill.
>=3B >=3B>= >=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Mika Nystrom wr= >ote:
>=3B >=3B>=3B >=3B>=3B >=3B Hello everyone=3D3D2C
&g= >t=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B&= >gt=3B >=3B This is=3D3D2C for me=3D3D2C a most unfortunate time for the C= >M3 servers=3D
>=3B >=3B to
>=3B >=3B>=3B >=3B>=3B >= >=3B have crashed. I'm teaching a class using Modula-3=3D3D2C and we need a<= >BR>>=3B >=3B>=3B >=3B>=3B >=3B compiler... here's the uname of = >the system I'm trying to use:
>=3B >=3B>=3B >=3B>=3B >=3B=3D= >3D20
>=3B >=3B>=3B >=3B>=3B >=3B Linux lara 2.6.24ugcs1 #4 S= >MP Mon Feb 11 10:53:03 PST 2008 i686 GNU/=3D
>=3B >=3BLin=3D3D
&g= >t=3B >=3B>=3B >=3Bux
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D2= >0
>=3B >=3B>=3B >=3B>=3B >=3B The most recent archives I hav= >e for Linux are:
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>= >=3B >=3B>=3B >=3B>=3B >=3B cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3= >-src-all-5.4.0.tgz=3D3D20
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20= >
>=3B >=3B>=3B >=3B>=3B >=3B And they don't seem to work on = >this system: I can compile a program
>=3B >=3B>=3B >=3B>=3B &g= >t=3B but when I try to run it=3D3D2C it says "Segmentation fault". Can anyo= >=3D
>=3B >=3Bne
>=3B >=3B>=3B >=3B>=3B >=3B help? (My= > understanding is that I need 5.5.1 or later...)
>=3B >=3B>=3B >= >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B >=3B Mika
= >>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >= >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >= >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>=3B >=3B>=3B >=3BCo= >ntent-Type: text/html=3D3B charset=3D3D"iso-8859-1"
>=3B >=3B>=3B = >>=3BContent-Transfer-Encoding: quoted-printable
>=3B >=3B>=3B &g= >t=3B
>=3B >=3B>=3B >=3B<=3Bhtml>=3B
>=3B >=3B>=3B &= >gt=3B<=3Bhead>=3B
>=3B >=3B>=3B >=3B<=3Bstyle>=3B
>= >=3B >=3B>=3B >=3B.hmmessage P
>=3B >=3B>=3B >=3B{
>= >=3B >=3B>=3B >=3Bmargin:0px=3D3D3B
>=3B >=3B>=3B >=3Bpaddi= >ng:0px
>=3B >=3B>=3B >=3B}
>=3B >=3B>=3B >=3Bbody.hmm= >essage
>=3B >=3B>=3B >=3B{
>=3B >=3B>=3B >=3Bfont-siz= e: 10pt=3D3D3B
>=3B >=3B>=3B >=3Bfont-family:Verdana
>=3B &= >gt=3B>=3B >=3B}
>=3B >=3B>=3B >=3B<=3B/style>=3B
>= >=3B >=3B>=3B >=3B<=3B/head>=3B
>=3B >=3B>=3B >=3B<= >=3Bbody class=3D3D3D'hmmessage'>=3B
>=3B >=3B>=3B >=3B&=3Bn= >bsp=3D3D3B<=3BA href=3D3D3D"http://modula3.elegosoft.com/cm3/uploaded-arc= >hive=3D
>=3B >=3Bs" targ=3D3D
>=3B >=3B>=3B >=3Bet=3D3D3D= >_blank>=3B<=3BFONT color=3D3D3D#0068cf>=3Bhttp://modula3.elegosoft.co= >m/cm3/u=3D
>=3B >=3Bploaded=3D3D
>=3B >=3B>=3B >=3B-archi= >ves<=3B/FONT>=3B<=3B/A>=3B<=3BBR>=3B
>=3B >=3B>=3B >= >=3B?<=3BBR>=3B
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR&= >gt=3B
>=3B >=3B>=3B >=3BI can make another later this week.<= >=3BBR>=3B
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3BR>>=3B >=3B>=3B >=3BAll you need is a working cm3 on any system.<= >=3BBR>=3B
>=3B >=3B>=3B >=3B>=3BFrom there you can build the= > whole system=3D3D2C targeting any system.<=3BBR=3D
>=3B >=3B>= >=3B
>=3B >=3B>=3B >=3BAs long as that cm3 understands LONGINT an= >d your target system.<=3BBR>=3B
>=3B >=3B>=3B >=3BAnd it is = >easier=3D3D2C but not necessary=3D3D2C if you have Python. :)<=3BBR>=3B= >
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B
>=3B &g= >t=3B>=3B >=3B&=3Bnbsp=3D3D3B- Jay<=3BBR>=3B<=3BBR>=3B&=3B= >nbsp=3D3D3B<=3BBR>=3B&=3Bgt=3D3D3B Date: Tue=3D3D2C 31 Mar 2009=3DR>>=3B >=3B 15:43:41 -=3D3D
>=3B >=3B>=3B >=3B0500<=3BBR&g= >t=3B&=3Bgt=3D3D3B From: martinbishop at bellsouth.net<=3BBR>=3B&=3Bg= >t=3D3D3B To: mika at a=3D
>=3B >=3Bsync.ca=3D3D
>=3B >=3B>=3B = >>=3Bltech.edu<=3BBR>=3B&=3Bgt=3D3D3B CC: m3devel at elegosoft.com<= >=3BBR>=3B&=3Bgt=3D3D3B Subject: Re:=3D
>=3B >=3B [M3dev=3D3D>>=3B >=3B>=3B >=3Bel] Help finding CM3 compiler for Linux?<=3BBR= >>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B Not su=3D
>=3B &= >gt=3Bre if t=3D3D
>=3B >=3B>=3B >=3Bhis helps=3D3D2C but on my l= >inux system:<=3BBR>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B C= >ritical=3D
>=3B >=3B Mass Mod=3D3D
>=3B >=3B>=3B >=3Bula-= >3 version d5.7.0<=3BBR>=3B&=3Bgt=3D3D3B last updated: 2008-03-16<= >=3BBR>=3B&=3Bgt=3D3D3B co=3D
>=3B >=3Bmpiled:=3D3D
>=3B &g= >t=3B>=3B >=3B 2008-08-14 00:56:14<=3BBR>=3B&=3Bgt=3D3D3B configu= >ration: /usr/local/cm3/bin/cm3.c=3D
>=3B >=3Bfg<=3BBR=3D3D
>= >=3B >=3B>=3B >=3B>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3= >B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 2=3D
>=3B >=3B9 19= >:24=3D3D
>=3B >=3B>=3B >=3B:39 UTC 2009<=3BBR>=3B&=3Bgt= >=3D3D3B i686 GNU/Linux<=3BBR>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bg= >t=3D3D3B <=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3D3B I don=3D3D
&= >gt=3B >=3B>=3B >=3B't have the cm3 tarball=3D3D2C but I do have the s= >ources in cm3/ still.<=3BBR=3D
>=3B >=3B>=3B&=3Bgt=3D3D
&g= >t=3B >=3B>=3B >=3B=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B Mika Nystrom= > wrote:<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B Hello everyo=3D
&= >gt=3B >=3Bne=3D3D2C<=3BBR>=3B&=3Bg=3D3D
>=3B >=3B>=3B >= >=3Bt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3= >B This is=3D3D2C for me=3D3D2C a most un=3D
>=3B >=3Bfortunate time = >=3D3D
>=3B >=3B>=3B >=3Bfor the CM3 servers to<=3BBR>=3B&= >=3Bgt=3D3D3B &=3Bgt=3D3D3B have crashed. I'm teaching a=3D
>=3B >= >=3B class =3D3D
>=3B >=3B>=3B >=3Busing Modula-3=3D3D2C and we n= >eed a<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B compiler... here'=3DR>>=3B >=3Bs the una=3D3D
>=3B >=3B>=3B >=3Bme of the system= > I'm trying to use:<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B <=3BBR= >>=3B&=3Bgt=3D3D3B &=3Bg=3D
>=3B >=3Bt=3D3D3B Linu=3D3D
&g= >t=3B >=3B>=3B >=3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2= >008 i686 GNU/Linux<=3BBR=3D
>=3B >=3B>=3B&=3Bg=3D3D
>=3B= > >=3B>=3B >=3Bt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3= >B &=3Bgt=3D3D3B The most recent archives I have fo=3D
>=3B >=3Br = >Linux are=3D3D
>=3B >=3B>=3B >=3B:<=3BBR>=3B&=3Bgt=3D3D3B= > &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B cm3-min-P= OSIX-LINUXLIBC6-5.=3D
>=3B >=3B4.0.tgz cm3=3D3D
>=3B >=3B>= >=3B >=3B-src-all-5.4.0.tgz <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3= >B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B And they =3D
>=3B &g= >t=3Bdon't seem =3D3D
>=3B >=3B>=3B >=3Bto work on this system: I= > can compile a program<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B but= >=3D
>=3B >=3B when I=3D3D
>=3B >=3B>=3B >=3B try to run i= >t=3D3D2C it says "Segmentation fault". Can anyone<=3BBR>=3B&=3Bgt=3D= >3D3B=3D
>=3B >=3B &=3Bgt=3D3D3B=3D3D
>=3B >=3B>=3B >= >=3B help? (My understanding is that I need 5.5.1 or later...)<=3BBR>=3B= >&=3Bgt=3D3D3B &=3B=3D
>=3B >=3Bgt=3D3D3B=3D3D
>=3B >=3B= >>=3B >=3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B Mika<=3BBR&= >gt=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B <= >=3BBR>=3B<=3B/body=3D
>=3B >=3B>=3B
>=3B >=3B>=3B >= >=3B<=3B/html>=3B=3D3D
>=3B >=3B>=3B >=3B
>=3B >=3B>= >=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_--
>=3B >=3B
&g= >t=3B >=3B--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_
>=3B >=3BContent= >-Type: text/html=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer= >-Encoding: quoted-printable
>=3B >=3B
>=3B >=3B<=3Bhtml>= >=3B
>=3B >=3B<=3Bhead>=3B
>=3B >=3B<=3Bstyle>=3B
&= >gt=3B >=3B.hmmessage P
>=3B >=3B{
>=3B >=3Bmargin:0px=3D3B<= >BR>>=3B >=3Bpadding:0px
>=3B >=3B}
>=3B >=3Bbody.hmmessag= >e
>=3B >=3B{
>=3B >=3Bfont-size: 10pt=3D3B
>=3B >=3Bfo= >nt-family:Verdana
>=3B >=3B}
>=3B >=3B<=3B/style>=3B
&= >gt=3B >=3B<=3B/head>=3B
>=3B >=3B<=3Bbody class=3D3D'hmmessa= >ge'>=3B
>=3B >=3BThese archives do have a different format=3D2C ye= >s.<=3BBR>=3B
>=3B >=3BBut it isn't a bad format.<=3BBR>=3BR>>=3B >=3Bcminstall is pretty worthless imho.<=3BBR>=3B
>=3B = >>=3BExtract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.<=3BBR>=3B<= >BR>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp= >=3D3B- Jay<=3BBR>=3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3B&=3B= >gt=3D3B To: jay.krell at cornell.edu<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B = >>=3B Subject: Re: [M3devel] Help finding CM3 compiler for Linux? <=3BBR= >>=3B&=3Bgt=3D3B Dat=3D
>=3B >=3Be: Tue=3D2C 31 Mar 2009 15:56:1= >1 -0700<=3BBR>=3B&=3Bgt=3D3B From: mika at async.caltech.edu=3D
>= >=3B >=3B<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B No=3D2C= > I'm sorry...<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B the = >archives =3D
>=3B >=3Bdo not have the usual format. I'm expecting to= > unpack<=3BBR>=3B&=3Bgt=3D3B and run "cm=3D
>=3B >=3Binstall"= > and then unpack the big source tar on top and <=3BBR>=3B&=3Bgt=3D3B= > build tha=3D
>=3B >=3Bt. But there's no cminstall in the archive on= > this page.<=3BBR>=3B&=3Bgt=3D3B This is =3D
>=3B >=3B"the no= >rmal procedure" for installing CM3=3D2C no? It's what<=3BBR>=3B&=3Bg= >t=3D3B the in=3D
>=3B >=3Bstructions say to do=3D2C as well...<=3B= >BR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B And the link from t=3D<= >BR>>=3B >=3Bhe "Download" page is broken (to -d5.5.0.tgz).<=3BBR>= >=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Mika<=3BBR=3D
>=3B &g= >t=3B>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Jay writes:<=3BBR&g= >t=3B&=3Bgt=3D3B &=3Bgt=3D3B--_806446ae-8d10-4d74-8eea-5=3D
>=3B = >>=3B1aa365e9204_<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BContent-Type: = >text/plain=3D3B charset=3D3D"iso-885=3D
>=3B >=3B9-1"<=3BBR>=3B&= >amp=3Bgt=3D3B &=3Bgt=3D3BContent-Transfer-Encoding: quoted-printable<= >=3BBR>=3B&=3Bgt=3D3B =3D
>=3B >=3B&=3Bgt=3D3B<=3BBR>=3B&= >amp=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B htt= >p://modula3.elegosoft.com/cm3/u=3D
>=3B >=3Bploaded-archives<=3BBR= >>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3B?<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D= >
>=3B >=3B=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &a= >mp=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BI can make another l= >ater t=3D
>=3B >=3Bhis week.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >=3B &= >amp=3Bgt=3D3BAll you need is a working cm3 on any system.<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &= >amp=3Bgt=3D3B&=3Bgt=3D3BFrom there you can build the whole system=3D3D2C= > targeting an=3D
>=3B >=3By system.<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAs long as that cm3 un= >derstands =3D
>=3B >=3BLONGINT and your target system.<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAnd= > it is =3D
>=3B >=3Beasier=3D3D2C but not necessary=3D3D2C if you ha= >ve Python. :)<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3B=3D
>=3B= > >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt= >=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B - Jay<=3B= >BR>=3B&=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B= >&=3Bgt=3D3B Date: Tue=3D3D2C 31 Mar 2009=3D
>=3B >=3B 15:43:41 -0= >500<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B From: martinbi= >shop at bellsouth.net<=3BBR>=3B=3D
>=3B >=3B&=3Bgt=3D3B &=3Bg= >t=3D3B&=3Bgt=3D3B To: mika at async.caltech.edu<=3BBR>=3B&=3Bgt=3D3B= > &=3Bgt=3D3B&=3Bgt=3D3B CC: m=3D
>=3B >=3B3devel at elegosoft.com= ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B Subject: Re: [M3d= >evel] Help fin=3D
>=3B >=3Bding CM3 compiler for Linux?<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bg= >t=3D3B &=3Bgt=3D3B&=3Bg=3D
>=3B >=3Bt=3D3B Not sure if this he= >lps=3D3D2C but on my linux system:<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3B&=3Bg=3D
>=3B >=3Bt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &am= >p=3Bgt=3D3B&=3Bgt=3D3B Critical Mass Modula-3 version d5.7.0<=3BBR>= >=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B last upd= >ated: 2008-03-16<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B c= >ompiled=3D
>=3B >=3B: 2008-08-14 00:56:14<=3BBR>=3B&=3Bgt=3D3= >B &=3Bgt=3D3B&=3Bgt=3D3B configuration: /usr/local/cm3/=3D
>=3B = >>=3Bbin/cm3.cfg<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B= >=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B Linux thin= >kp=3D
>=3B >=3Bad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2= >009<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bg=3D
>=3B >=3Bt= >=3D3B i686 GNU/Linux<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D= >3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20= >=3D
>=3B >=3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D= >3B I don't have the cm3 tarball=3D3D2C but I do have the=3D
>=3B >= >=3B sources in cm3/ still.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B = >=3D
>=3B >=3BMika Nystrom wrote:<=3BBR>=3B&=3Bgt=3D3B &=3B= >gt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B Hello everyone=3D3D2C<=3BBR>=3B&am= >p=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B= >=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt= >=3D3B This is=3D3D2C fo=3D
>=3B >=3Br me=3D3D2C a most unfortunate t= >ime for the CM3 servers to<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B have crashed. I'm teaching a = >class using Modula-3=3D3D2C and we n=3D
>=3B >=3Beed a<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B compiler... here= >'s the uname of the sys=3D
>=3B >=3Btem I'm trying to use:<=3BBR&g= >t=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3B= >BR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3B=3D
>=3B >=3Bgt=3D3B &am= >p=3Bgt=3D3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i68= >=3D
>=3B >=3B6 GNU/Lin=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3Bux<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3= >B=3D3D20<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &=3Bgt=3D3B&= >=3Bgt=3D3B &=3Bgt=3D3B The most recent archives I have for Linux are:<= >=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B = >&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt= >=3D3B &=3Bgt=3D3B cm3-min-POSIX-=3D
>=3B >=3BLINUXLIBC6-5.4.0.tgz= > cm3-src-all-5.4.0.tgz=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&am= >p=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B=3D3D20<=3BBR>=3B&=3Bg= >t=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B And they don't seem to w= >ork on this =3D
>=3B >=3Bsystem: I can compile a program<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B but when I tr= >=3D
>=3B >=3By to run it=3D3D2C it says "Segmentation fault". Can an= >yone<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3B=3D
>=3B >=3Bg= >t=3D3B &=3Bgt=3D3B help? (My understanding is that I need 5.5.1 or later= >...)<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bg= >t=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Bgt=3D3B &=3Bgt=3D3B Mika<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >= >=3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3B= >gt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &am= >p=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B-= >-_806446ae-8d10-4d74-8eea-51aa365e9204_<=3BBR>=3B&=3Bgt=3D3B &=3B= >gt=3D3BConten=3D
>=3B >=3Bt-Type: text/html=3D3B charset=3D3D"iso-88= >59-1"<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BContent-Transfe=3D
>= >=3B >=3Br-Encoding: quoted-printable<=3BBR>=3B&=3Bgt=3D3B &=3Bg= >t=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3Bhtml&=3Bg= >t=3D
>=3B >=3B=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Blt=3D3Bhead&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Blt=3D3Bstyle&=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D= >3B &=3Bgt=3D3B.hmmessage P<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B{&l= >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bmargin:0px=3D3D3B<=3B=3D
>= >=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bpadding:0px<=3BBR>=3B&am= >p=3Bgt=3D3B &=3Bgt=3D3B}<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bbody.= >hmmessag=3D
>=3B >=3Be<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B{&l= >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfont-size: 10pt=3D3D3B<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3Bfo=3D
>=3B >=3Bnt-family:Verdana<= >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B}<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B&=3Blt=3D3B/style&=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>= >=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3B/head&=3Bgt=3D3B<=3BBR&g= >t=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3Bbody class=3D3D3D'hmmessa=3D= >
>=3B >=3Bge'&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BA href=3D3D3D"http://modula3.=3D<= >BR>>=3B >=3Belegosoft.com/cm3/uploaded-archives" targ=3D3D<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3Bet=3D3D3D_blank&=3B=3D
>=3B >=3Bg= >t=3D3B&=3Blt=3D3BFONT color=3D3D3D#0068cf&=3Bgt=3D3Bhttp://modula3.el= >egosoft.com/cm3/upl=3D
>=3B >=3Boaded=3D3D<=3BBR>=3B&=3Bgt=3D= >3B &=3Bgt=3D3B-archives&=3Blt=3D3B/FONT&=3Bgt=3D3B&=3Blt=3D3B/A= >&=3Bgt=3D3B&=3Blt=3D3BBR&=3Bg=3D
>=3B >=3Bt=3D3B<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3B?&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3B=3D= >
>=3B >=3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3= >BI can make another later this week.&=3Blt=3D3BBR&=3Bgt=3D3B<=3B=3D= >
>=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp= >=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3BAll you need=3D
>=3B >=3B is a working cm3 on any system.&= >=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Bgt=3D3BFrom t=3D
>=3B >=3Bhere you can build the whole system=3D3= >D2C targeting any system.&=3Blt=3D3BBR&=3Bgt=3D
>=3B >=3B=3D3B= ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAs long as that cm3 understands = >LONGINT and your target=3D
>=3B >=3B system.&=3Blt=3D3BBR&=3Bg= >t=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAnd it is easier=3D3D2C bu= >t not necess=3D
>=3B >=3Bary=3D3D2C if you have Python. :)&=3Blt= >=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp= >=3D3Bnbsp=3D
>=3B >=3B=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR&= >gt=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B- Jay&=3Blt= >=3D3BBR&=3Bgt=3D3B&=3Blt=3D
>=3B >=3B=3D3BBR&=3Bgt=3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3= >B Date: Tue=3D3D2C 31 M=3D
>=3B >=3Bar 2009 15:43:41 -=3D3D<=3BBR&= >gt=3B&=3Bgt=3D3B &=3Bgt=3D3B0500&=3Blt=3D3BBR&=3Bgt=3D3B&=3B= >amp=3D3Bgt=3D3D3B From=3D
>=3B >=3B: martinbishop at bellsouth.net&= >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B To: mika at async.ca=3D
= >>=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bltech.edu&= >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B CC: m3devel at elego=3D
= >>=3B >=3Bsoft.com&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B= > Subject: Re: [M3dev=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D
>= >=3B >=3B=3D3Bel] Help finding CM3 compiler for Linux?&=3Blt=3D3BBR&= >=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D
>=3B >=3B=3D3BBR&= >=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B Not sure if t=3D3D<=3BBR>=3B&=3Bg= >t=3D3B &=3Bgt=3D3Bhis helps=3D3D2C b=3D
>=3B >=3But on my linux s= >ystem:&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3B= >BR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D
>=3B >=3B=3D3D3B Critical Mass = >Mod=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bula-3 version d5.7.0&= >=3Blt=3D3BBR&=3Bgt=3D
>=3B >=3B=3D3B&=3Bamp=3D3Bgt=3D3D3B last= > updated: 2008-03-16&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B = >comp=3D
>=3B >=3Biled:=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3B 2008-08-14 00:56:14&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3= >B c=3D
>=3B >=3Bonfiguration: /usr/local/cm3/bin/cm3.cfg&=3Blt=3D= >3BBR=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B&=3B= >=3D
>=3B >=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3B= >amp=3D3Bgt=3D3D3B Linux thinkpad 2.6.27-11-generic=3D
>=3B >=3B #1 S= >MP Thu Jan 29 19:24=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B:39 UTC = >2009&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3= >D3B i686 GNU/Linux&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &a= >mp=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3B=3D
>=3B >=3Bgt=3D3D3B &a= >mp=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B I don=3D3D<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3B't have the c=3D
>=3B >=3Bm3 tarball= >=3D3D2C but I do have the sources in cm3/ still.&=3Blt=3D3BBR&=3Bgt= >=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D<=3BBR>=3B&=3Bgt=3D3B= > &=3Bgt=3D3B=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D= >3B Mika Nystrom wr=3D
>=3B >=3Bote:&=3Blt=3D3BBR&=3Bgt=3D3B&am= >p=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B Hello everyone=3D3D2C&=3B= >lt=3D3BBR=3D
>=3B >=3B&=3Bgt=3D3B&=3Bamp=3D3Bg=3D3D<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3Bt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt= >=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D3B &=3Bam= >p=3D3Bgt=3D3D3B This is=3D3D2C for me=3D3D2C a most unfortunate time =3D>>=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfor the CM3 s= >ervers to&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp= >=3D
>=3B >=3B=3D3Bgt=3D3D3B have crashed. I'm teaching a class =3D3D= ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Busing Mod=3D
>=3B >=3Bula= >-3=3D3D2C and we need a&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D= >3B &=3Bamp=3D3Bgt=3D3D3B compile=3D
>=3B >=3Br... here's the una= >=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bme of the system I'm trying= > to use:&=3B=3D
>=3B >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt= >=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp= >=3D3Bgt=3D3D3B &=3Bam=3D
>=3B >=3Bp=3D3Bgt=3D3D3B Linu=3D3D<=3B= >BR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 1= >0=3D
>=3B >=3B:53:03 PST 2008 i686 GNU/Linux&=3Blt=3D3BBR&=3Bg= >t=3D3B&=3Bamp=3D3Bg=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bt=3D<= >BR>>=3B >=3B=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt= >=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B The most r=3D
>= >=3B >=3Becent archives I have for Linux are=3D3D<=3BBR>=3B&=3Bgt= >=3D3B &=3Bgt=3D3B:&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B = >>=3B=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3= >B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B cm3-m=3D
>=3B >= >=3Bin-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D3D<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B-src-all-5.4.0.tgz &=3Blt=3D
>=3B =3D3BBR&=3Bgt=3D3B&a= >mp=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt= >=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D3B = >And they don't seem =3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bto work= > on this system: =3D
>=3B >=3BI can compile a program&=3Blt=3D3BB= >R&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B but when= >=3D
>=3B >=3B I=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B try = >to run it=3D3D2C it says "Segmentation fault". Can=3D
>=3B >=3B anyo= >ne&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt= >=3D3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B help=3D
>=3B &= >gt=3B? (My understanding is that I need 5.5.1 or later...)&=3Blt=3D3BBR&= >amp=3Bgt=3D3B&=3Bamp=3D3Bg=3D
>=3B >=3Bt=3D3D3B &=3Bamp=3D3Bgt= >=3D3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B &=3Blt=3D3BBR&am= >p=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D
>=3B >=3B=3D3Bgt= >=3D3D3B Mika&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Ba= >mp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Ba=3D
>=3B >=3B= >mp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Blt=3D3B/body&=3Bgt= >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3B/html&=3Bg= >t=3D
>=3B >=3B=3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >lt=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B--_806446ae-8d10-4d74-8eea-51aa36= >5e=3D
>=3B >=3B9204_--<=3BBR>=3B<=3B/body>=3B
>=3B >= >=3B<=3B/html>=3B=3D
>=3B >=3B
>=3B >=3B--_777fdc4e-3c29-4= >0b4-a3dd-e6243f796cee_--
>= > >--_55339e45-8c85-4ab6-9440-0d2131bbad69_-- From jay.krell at cornell.edu Wed Apr 1 08:56:45 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Apr 2009 06:56:45 +0000 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: <200904010627.n316RM55072294@camembert.async.caltech.edu> References: Your message of "Wed, 01 Apr 2009 06:13:00 -0000." <200904010627.n316RM55072294@camembert.async.caltech.edu> Message-ID: Sorry it is meant to be a little easier. I'll see about putting an "install" or "readme" file in. "root of cm3 cvs" is the root of a cvs checkout, not a "repository". But it isn't meant to be required...it is just the way I always work.. Similar to your "extracting the source tarball", though that isn't supposed to be necessary either. Here is another avenue..roundabout, but.. You had a kind of working install from 5.4 and running its cminstall. cm3 ran but produced crashing binaries. Take the cm3.cfg file from it and put it at. $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3.cfg That might work. I'll test this out more later and maybe make an updated archive. "this" being "not having any source tree", just the extracted archive + set $PATH and $LD_LIBRARY_PATH. It should be a small fix, if it isn't fixed already, and easy to patch up existing extracted archives -- you might just try a current cm3cfg.common from the source tree, but..the "shoe" is kind of on my "foot" at this point. - Jay > To: jay.krell at cornell.edu > Date: Tue, 31 Mar 2009 23:27:22 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Help finding CM3 compiler for Linux? > > Hmm, I'm not sure what you mean? "root of cm3 cvs"? > > I have lots of Modula-3 installations on my own machines, but I'm > just trying to get a system installed for student use on the student > systems (which are different)... A working binary dist for Linux > is exactly what I'm looking for and this is what you seem to have > directed me to, but I don't have a CVS repository... > > I don't have "m3-sys/cminstall/" etc. Do I need to unpack both > the min and std before doing these things? > > What I'm *used to* is that I unpack the binary distribution, then > unpack the sources (or CVS if you like) on top of that, and > then compile everything. Which works about 1 time in 3. > > I think Modula-3 is almost impossible to install if you don't know > exactly what to do! (I'm sure I can figure this out with some > work.. but is it really meant to be hard to do? I guess it keeps > the riff-raff off the M3 mailing lists!) > > Mika > > Jay writes: > >--_55339e45-8c85-4ab6-9440-0d2131bbad69_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Maybe not. > > > >Hm. That is bug. There is use with a cvs tree=2C and use without. > > > >I must have broken use without. > > > >=20 > > > >Try this: > > > >export CM3_ROOT=3Droot of cm3 cvs (for me this is /dev2/cm3=2C > > > >for you=2C maybe $HOME/cm3?) > > > >rm $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6 > > > ># *Common and *common in one command > >rm $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/*ommon > >cp root of cm3 cvs/m3-sys/cminstall/src/config/cm3.cfg $HOME/cm3/cm3-min-LI= > >NUXLIBC6-d5.7.0/bin > > > >=20 > > > >The .cfg will delegate out to the cvs tree. > > > >I don't like having two copies of files..having to keep them in sync.. > > > > Though the archives are meant to work standalone=2C without CVS. > > > > But I don't test that so much oops sorry. > > > >That /might/ not be the right file=2C but it is close. > > > >=20 > > > > - Jay > > > >=20 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux?=20 > >> Date: Tue=2C 31 Mar 2009 22:59:18 -0700 > >> From: mika at async.caltech.edu > >>=20 > >>=20 > >> Is there any documentation for this format beyond what you just > >> wrote? Where? > >>=20 > >> terpsichore-14: cm3 > >> --- building in ../LINUXLIBC6 --- > >>=20 > >> new source -> compiling Main.m3 > >> "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common"=2C= > > line 169: quake runtime error: undefined variable: ROOT > >>=20 > >> --procedure-- -line- -file--- > >> GetM3Back 169 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3c= > >fg.common > >> _IsM3BackFlagSupported 181 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5= > >.7.0/bin/Unix.common > >> IsM3BackFlagSupported 193 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.= > >7.0/bin/Unix.common > >> GetM3BackFlag 197 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/= > >Unix.common > >> m3_backend 62 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix= > >.common > >> program -- > >> 6 /afs/.ugcs.caltech.edu/user/mika/test/LINUXLIBC6/m3make.args > >>=20 > >>=20 > >> Fatal Error: procedure "m3_backend" defined in "/afs/.ugcs/user/mika/cm3/= > >cm3-min-LINUXLIBC6-d5.7.0/bin/cm3.cfg" failed. > >>=20 > >> Jay writes: > >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ > >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> >These archives do have a different format=3D2C yes. > >> > > >> >But it isn't a bad format. > >> > > >> >cminstall is pretty worthless imho. > >> > > >> >Extract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH. > >> > > >> >=3D20 > >> > > >> > - Jay > >> > > >> >=3D20 > >> >> To: jay.krell at cornell.edu > >> >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux?=3D20 > >> >> Date: Tue=3D2C 31 Mar 2009 15:56:11 -0700 > >> >> From: mika at async.caltech.edu > >> >>=3D20 > >> >> No=3D2C I'm sorry... > >> >>=3D20 > >> >> the archives do not have the usual format. I'm expecting to unpack > >> >> and run "cminstall" and then unpack the big source tar on top and=3D20 > >> >> build that. But there's no cminstall in the archive on this page. > >> >> This is "the normal procedure" for installing CM3=3D2C no? It's what > >> >> the instructions say to do=3D2C as well... > >> >>=3D20 > >> >> And the link from the "Download" page is broken (to -d5.5.0.tgz). > >> >>=3D20 > >> >> Mika > >> >>=3D20 > >> >> Jay writes: > >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ > >> >> >Content-Type: text/plain=3D3B charset=3D3D"iso-8859-1" > >> >> >Content-Transfer-Encoding: quoted-printable > >> >> > > >> >> > > >> >> > http://modula3.elegosoft.com/cm3/uploaded-archives > >> >> > > >> >> >? > >> >> > > >> >> >=3D3D20 > >> >> > > >> >> >I can make another later this week. > >> >> > > >> >> >=3D3D20 > >> >> > > >> >> >All you need is a working cm3 on any system. > >> >> > > >> >> >>From there you can build the whole system=3D3D2C targeting any syste= > >m. > >> >> > > >> >> >As long as that cm3 understands LONGINT and your target system. > >> >> > > >> >> >And it is easier=3D3D2C but not necessary=3D3D2C if you have Python. = > >:) > >> >> > > >> >> >=3D3D20 > >> >> > > >> >> > - Jay > >> >> > > >> >> >=3D3D20 > >> >> >> Date: Tue=3D3D2C 31 Mar 2009 15:43:41 -0500 > >> >> >> From: martinbishop at bellsouth.net > >> >> >> To: mika at async.caltech.edu > >> >> >> CC: m3devel at elegosoft.com > >> >> >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? > >> >> >>=3D3D20 > >> >> >> Not sure if this helps=3D3D2C but on my linux system: > >> >> >>=3D3D20 > >> >> >> Critical Mass Modula-3 version d5.7.0 > >> >> >> last updated: 2008-03-16 > >> >> >> compiled: 2008-08-14 00:56:14 > >> >> >> configuration: /usr/local/cm3/bin/cm3.cfg > >> >> >>=3D3D20 > >> >> >> Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 200= > >9 > >> >> >> i686 GNU/Linux > >> >> >>=3D3D20 > >> >> >>=3D3D20 > >> >> >> I don't have the cm3 tarball=3D3D2C but I do have the sources in cm= > >3/ st=3D > >> >ill. > >> >> >>=3D3D20 > >> >> >> Mika Nystrom wrote: > >> >> >> > Hello everyone=3D3D2C > >> >> >> >=3D3D20 > >> >> >> > This is=3D3D2C for me=3D3D2C a most unfortunate time for the CM3 = > >servers=3D > >> > to > >> >> >> > have crashed. I'm teaching a class using Modula-3=3D3D2C and we n= > >eed a > >> >> >> > compiler... here's the uname of the system I'm trying to use: > >> >> >> >=3D3D20 > >> >> >> > Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 G= > >NU/=3D > >> >Lin=3D3D > >> >> >ux > >> >> >> >=3D3D20 > >> >> >> > The most recent archives I have for Linux are: > >> >> >> >=3D3D20 > >> >> >> > cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D3D20 > >> >> >> >=3D3D20 > >> >> >> > And they don't seem to work on this system: I can compile a progr= > >am > >> >> >> > but when I try to run it=3D3D2C it says "Segmentation fault". Can= > > anyo=3D > >> >ne > >> >> >> > help? (My understanding is that I need 5.5.1 or later...) > >> >> >> >=3D3D20 > >> >> >> > Mika > >> >> >> >=3D3D20 > >> >> >>=3D3D20 > >> >> > > >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ > >> >> >Content-Type: text/html=3D3B charset=3D3D"iso-8859-1" > >> >> >Content-Transfer-Encoding: quoted-printable > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > =3D3D3B >archive=3D > >> >s" targ=3D3D > >> >> >et=3D3D3D_blank>http://modula3.elegosoft.co= > >m/cm3/u=3D > >> >ploaded=3D3D > >> >> >-archives
> >> >> >?
> >> >> > =3D3D3B
> >> >> >I can make another later this week.
> >> >> > =3D3D3B
> >> >> >All you need is a working cm3 on any system.
> >> >> >>From there you can build the whole system=3D3D2C targeting any syste= > >m. >> >> > >> >> >As long as that cm3 understands LONGINT and your target system.
> >> >> >And it is easier=3D3D2C but not necessary=3D3D2C if you have Python. = > >:)
> >> >> > =3D3D3B
> >> >> > =3D3D3B- Jay

 =3D3D3B
>=3D3D3B Date: Tue=3D3D2C = > >31 Mar 2009=3D > >> > 15:43:41 -=3D3D > >> >> >0500
>=3D3D3B From: martinbishop at bellsouth.net
>=3D3D3B To:= > > mika at a=3D > >> >sync.ca=3D3D > >> >> >ltech.edu
>=3D3D3B CC: m3devel at elegosoft.com
>=3D3D3B Subje= > >ct: Re:=3D > >> > [M3dev=3D3D > >> >> >el] Help finding CM3 compiler for Linux?
>=3D3D3B
>=3D3D3B= > > Not su=3D > >> >re if t=3D3D > >> >> >his helps=3D3D2C but on my linux system:
>=3D3D3B
>=3D3D3B= > > Critical=3D > >> > Mass Mod=3D3D > >> >> >ula-3 version d5.7.0
>=3D3D3B last updated: 2008-03-16
>=3D= > >3D3B co=3D > >> >mpiled:=3D3D > >> >> > 2008-08-14 00:56:14
>=3D3D3B configuration: /usr/local/cm3/bin/= > >cm3.c=3D > >> >fg >> >> >>>=3D3D3B
>=3D3D3B Linux thinkpad 2.6.27-11-generic #1 SMP Th= > >u Jan 2=3D > >> >9 19:24=3D3D > >> >> >:39 UTC 2009
>=3D3D3B i686 GNU/Linux
>=3D3D3B
>=3D3D3= > >B
>=3D > >> >=3D3D3B I don=3D3D > >> >> >'t have the cm3 tarball=3D3D2C but I do have the sources in cm3/ stil= > >l. >> >>>=3D3D > >> >> >=3D3D3B
>=3D3D3B Mika Nystrom wrote:
>=3D3D3B >=3D3D3B H= > >ello everyo=3D > >> >ne=3D3D2C
&g=3D3D > >> >> >t=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B This is=3D3D2C for me= > >=3D3D2C a most un=3D > >> >fortunate time =3D3D > >> >> >for the CM3 servers to
>=3D3D3B >=3D3D3B have crashed. I'm tea= > >ching a=3D > >> > class =3D3D > >> >> >using Modula-3=3D3D2C and we need a
>=3D3D3B >=3D3D3B compiler= > >... here'=3D > >> >s the una=3D3D > >> >> >me of the system I'm trying to use:
>=3D3D3B >=3D3D3B
>= > >=3D3D3B &g=3D > >> >t=3D3D3B Linu=3D3D > >> >> >x lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Linux= > > >> >>&g=3D3D > >> >> >t=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B The most recent archive= > >s I have fo=3D > >> >r Linux are=3D3D > >> >> >:
>=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B cm3-min-POSIX-LI= > >NUXLIBC6-5.=3D > >> >4.0.tgz cm3=3D3D > >> >> >-src-all-5.4.0.tgz
>=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3= > >B And they =3D > >> >don't seem =3D3D > >> >> >to work on this system: I can compile a program
>=3D3D3B >=3D3= > >D3B but=3D > >> > when I=3D3D > >> >> > try to run it=3D3D2C it says "Segmentation fault". Can anyone
>= > >=3D3D3B=3D > >> > >=3D3D3B=3D3D > >> >> > help? (My understanding is that I need 5.5.1 or later...)
>=3D3= > >D3B &=3D > >> >gt=3D3D3B=3D3D > >> >> >
>=3D3D3B >=3D3D3B Mika
>=3D3D3B >=3D3D3B
>=3D3D= > >3B
>> >> > >> >> >=3D3D > >> >> > > >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_-- > >> > > >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ > >> >Content-Type: text/html=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> > > >> > > >> > > >> > > >> >These archives do have a different format=3D2C yes.
> >> >But it isn't a bad format.
> >> >cminstall is pretty worthless imho.
> >> >Extract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.
> >> > =3D3B
> >> > =3D3B- Jay

 =3D3B
>=3D3B To: jay.krell at cornell.edu<= > >BR>>=3D3B=3D > >> > Subject: Re: [M3devel] Help finding CM3 compiler for Linux?
>=3D3= > >B Dat=3D > >> >e: Tue=3D2C 31 Mar 2009 15:56:11 -0700
>=3D3B From: mika at async.calt= > >ech.edu=3D > >> >
>=3D3B
>=3D3B No=3D2C I'm sorry...
>=3D3B
>=3D3B = > >the archives =3D > >> >do not have the usual format. I'm expecting to unpack
>=3D3B and ru= > >n "cm=3D > >> >install" and then unpack the big source tar on top and
>=3D3B buil= > >d tha=3D > >> >t. But there's no cminstall in the archive on this page.
>=3D3B Thi= > >s is =3D > >> >"the normal procedure" for installing CM3=3D2C no? It's what
>=3D3B= > > the in=3D > >> >structions say to do=3D2C as well...
>=3D3B
>=3D3B And the li= > >nk from t=3D > >> >he "Download" page is broken (to -d5.5.0.tgz).
>=3D3B
>=3D3B = > >Mika >> >>>=3D3B
>=3D3B Jay writes:
>=3D3B >=3D3B--_806446ae-8d10-= > >4d74-8eea-5=3D > >> >1aa365e9204_
>=3D3B >=3D3BContent-Type: text/plain=3D3B charset= > >=3D3D"iso-885=3D > >> >9-1"
>=3D3B >=3D3BContent-Transfer-Encoding: quoted-printable
= > >>=3D3B =3D > >> >>=3D3B
>=3D3B >=3D3B
>=3D3B >=3D3B http://modula3.elegos= > >oft.com/cm3/u=3D > >> >ploaded-archives
>=3D3B >=3D3B
>=3D3B >=3D3B?
>=3D3B = > >>=3D3B
>=3D > >> >=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B
>=3D3B >=3D3BI can mak= > >e another later t=3D > >> >his week.
>=3D3B >=3D3B
>=3D3B >=3D3B=3D3D20
>=3D3B &= > >gt=3D3B
>=3D3B=3D > >> > >=3D3BAll you need is a working cm3 on any system.
>=3D3B >=3D= > >3B
>=3D > >> >=3D3B >=3D3B>=3D3BFrom there you can build the whole system=3D3D2C t= > >argeting an=3D > >> >y system.
>=3D3B >=3D3B
>=3D3B >=3D3BAs long as that cm3 u= > >nderstands =3D > >> >LONGINT and your target system.
>=3D3B >=3D3B
>=3D3B >=3D3= > >BAnd it is =3D > >> >easier=3D3D2C but not necessary=3D3D2C if you have Python. :)
>=3D3= > >B >=3D3B<=3D > >> >BR>>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B
>=3D3B >=3D3B - = > >Jay
>=3D3B >=3D > >> >=3D3B
>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B Date: Tue= > >=3D3D2C 31 Mar 2009=3D > >> > 15:43:41 -0500
>=3D3B >=3D3B>=3D3B From: martinbishop at bellsout= > >h.net
=3D > >> >>=3D3B >=3D3B>=3D3B To: mika at async.caltech.edu
>=3D3B >=3D3= > >B>=3D3B CC: m=3D > >> >3devel at elegosoft.com
>=3D3B >=3D3B>=3D3B Subject: Re: [M3devel]= > > Help fin=3D > >> >ding CM3 compiler for Linux?
>=3D3B >=3D3B>=3D3B=3D3D20
>= > >=3D3B >=3D3B&g=3D > >> >t=3D3B Not sure if this helps=3D3D2C but on my linux system:
>=3D3B= > > >=3D3B&g=3D > >> >t=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B Critical Mass Modula-3 versio= > >n d5.7.0
&=3D > >> >gt=3D3B >=3D3B>=3D3B last updated: 2008-03-16
>=3D3B >=3D3B&g= > >t=3D3B compiled=3D > >> >: 2008-08-14 00:56:14
>=3D3B >=3D3B>=3D3B configuration: /usr/l= > >ocal/cm3/=3D > >> >bin/cm3.cfg
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B >=3D3B>= > >=3D3B Linux thinkp=3D > >> >ad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009
>=3D3B >= > >=3D3B&g=3D > >> >t=3D3B i686 GNU/Linux
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B &g= > >t=3D3B>=3D3B=3D3D20=3D > >> >
>=3D3B >=3D3B>=3D3B I don't have the cm3 tarball=3D3D2C but I = > >do have the=3D > >> > sources in cm3/ still.
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B = > >>=3D3B>=3D3B =3D > >> >Mika Nystrom wrote:
>=3D3B >=3D3B>=3D3B >=3D3B Hello everyone= > >=3D3D2C
&g=3D > >> >t=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B >= > >=3D3B This is=3D3D2C fo=3D > >> >r me=3D3D2C a most unfortunate time for the CM3 servers to
>=3D3B &= > >gt=3D3B&g=3D > >> >t=3D3B >=3D3B have crashed. I'm teaching a class using Modula-3=3D3D2C= > > and we n=3D > >> >eed a
>=3D3B >=3D3B>=3D3B >=3D3B compiler... here's the uname= > > of the sys=3D > >> >tem I'm trying to use:
>=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
&= > >gt=3D3B >=3D3B&=3D > >> >gt=3D3B >=3D3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2= > >008 i68=3D > >> >6 GNU/Lin=3D3D
>=3D3B >=3D3Bux
>=3D3B >=3D3B>=3D3B >= > >=3D3B=3D3D20
>=3D > >> >=3D3B >=3D3B>=3D3B >=3D3B The most recent archives I have for Linu= > >x are:
&=3D > >> >gt=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B &g= > >t=3D3B cm3-min-POSIX-=3D > >> >LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D3D20
>=3D3B >=3D3B&g= > >t=3D3B >=3D > >> >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B >=3D3B And they don't seem t= > >o work on this =3D > >> >system: I can compile a program
>=3D3B >=3D3B>=3D3B >=3D3B bu= > >t when I tr=3D > >> >y to run it=3D3D2C it says "Segmentation fault". Can anyone
>=3D3B = > >>=3D3B&=3D > >> >gt=3D3B >=3D3B help? (My understanding is that I need 5.5.1 or later..= > >.)
&=3D > >> >gt=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B &g= > >t=3D3B Mika
>=3D3B=3D > >> > >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B=3D3D20 >>>=3D3B >=3D3B
&=3D > >> >gt=3D3B >=3D3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>=3D3B >= > >=3D3BConten=3D > >> >t-Type: text/html=3D3B charset=3D3D"iso-8859-1"
>=3D3B >=3D3BCont= > >ent-Transfe=3D > >> >r-Encoding: quoted-printable
>=3D3B >=3D3B
>=3D3B >=3D3B&l= > >t=3D3Bhtml>=3D > >> >=3D3B
>=3D3B >=3D3B<=3D3Bhead>=3D3B
>=3D3B >=3D3B<= > >=3D3Bstyle>=3D3B
&=3D > >> >gt=3D3B >=3D3B.hmmessage P
>=3D3B >=3D3B{
>=3D3B >=3D3Bm= > >argin:0px=3D3D3B<=3D > >> >BR>>=3D3B >=3D3Bpadding:0px
>=3D3B >=3D3B}
>=3D3B >=3D= > >3Bbody.hmmessag=3D > >> >e
>=3D3B >=3D3B{
>=3D3B >=3D3Bfont-size: 10pt=3D3D3B
&g= > >t=3D3B >=3D3Bfo=3D > >> >nt-family:Verdana
>=3D3B >=3D3B}
>=3D3B >=3D3B<=3D3B/sty= > >le>=3D3B
&=3D > >> >gt=3D3B >=3D3B<=3D3B/head>=3D3B
>=3D3B >=3D3B<=3D3Bbody c= > >lass=3D3D3D'hmmessa=3D > >> >ge'>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BA href=3D3D3= > >D"http://modula3.=3D > >> >elegosoft.com/cm3/uploaded-archives" targ=3D3D
>=3D3B >=3D3Bet=3D= > >3D3D_blank&=3D > >> >gt=3D3B<=3D3BFONT color=3D3D3D#0068cf>=3D3Bhttp://modula3.elegosoft.= > >com/cm3/upl=3D > >> >oaded=3D3D
>=3D3B >=3D3B-archives<=3D3B/FONT>=3D3B<=3D3B/A&= > >gt=3D3B<=3D3BBR&g=3D > >> >t=3D3B
>=3D3B >=3D3B?<=3D3BBR>=3D3B
>=3D3B >=3D3B&= > >=3D3Bnbsp=3D3D3B<=3D3B=3D > >> >BR>=3D3B
>=3D3B >=3D3BI can make another later this week.<=3D= > >3BBR>=3D3B<=3D > >> >BR>>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
>=3D3B &= > >gt=3D3BAll you need=3D > >> > is a working cm3 on any system.<=3D3BBR>=3D3B
>=3D3B >=3D3B&= > >gt=3D3BFrom t=3D > >> >here you can build the whole system=3D3D2C targeting any system.<=3D3B= > >BR>=3D > >> >=3D3B
>=3D3B >=3D3BAs long as that cm3 understands LONGINT and yo= > >ur target=3D > >> > system.<=3D3BBR>=3D3B
>=3D3B >=3D3BAnd it is easier=3D3D2C b= > >ut not necess=3D > >> >ary=3D3D2C if you have Python. :)<=3D3BBR>=3D3B
>=3D3B >=3D3B= > >&=3D3Bnbsp=3D > >> >=3D3D3B<=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B- Jay&= > >lt=3D3BBR>=3D3B<=3D > >> >=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B = > >Date: Tue=3D3D2C 31 M=3D > >> >ar 2009 15:43:41 -=3D3D
>=3D3B >=3D3B0500<=3D3BBR>=3D3B&= > >=3D3Bgt=3D3D3B From=3D > >> >: martinbishop at bellsouth.net<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B To: mik= > >a at async.ca=3D > >> >=3D3D
>=3D3B >=3D3Bltech.edu<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B = > >CC: m3devel at elego=3D > >> >soft.com<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Subject: Re: [M3dev=3D3D >>>=3D3B >=3D > >> >=3D3Bel] Help finding CM3 compiler for Linux?<=3D3BBR>=3D3B&=3D3B= > >gt=3D3D3B <=3D > >> >=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Not sure if t=3D3D
>=3D3B >=3D3= > >Bhis helps=3D3D2C b=3D > >> >ut on my linux system:<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B <=3D3BBR>= > >=3D3B&=3D3Bgt=3D > >> >=3D3D3B Critical Mass Mod=3D3D
>=3D3B >=3D3Bula-3 version d5.7.0&= > >lt=3D3BBR>=3D > >> >=3D3B&=3D3Bgt=3D3D3B last updated: 2008-03-16<=3D3BBR>=3D3B&= > >=3D3Bgt=3D3D3B comp=3D > >> >iled:=3D3D
>=3D3B >=3D3B 2008-08-14 00:56:14<=3D3BBR>=3D3B&am= > >p=3D3Bgt=3D3D3B c=3D > >> >onfiguration: /usr/local/cm3/bin/cm3.cfg<=3D3BBR=3D3D
>=3D3B >= > >=3D3B>=3D3B&=3D > >> >amp=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Linux thinkpad 2.= > >6.27-11-generic=3D > >> > #1 SMP Thu Jan 29 19:24=3D3D
>=3D3B >=3D3B:39 UTC 2009<=3D3BBR= > >>=3D3B&=3D > >> >=3D3Bgt=3D3D3B i686 GNU/Linux<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B <=3D= > >3BBR>=3D3B&=3D3B=3D > >> >gt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B I don=3D3D
>=3D3B &g= > >t=3D3B't have the c=3D > >> >m3 tarball=3D3D2C but I do have the sources in cm3/ still.<=3D3BBR>= > >=3D3B&=3D > >> >=3D3Bgt=3D3D
>=3D3B >=3D3B=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt= > >=3D3D3B Mika Nystrom wr=3D > >> >ote:<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B Hello everyo= > >ne=3D3D2C<=3D3BBR=3D > >> >>=3D3B&=3D3Bg=3D3D
>=3D3B >=3D3Bt=3D3D3B &=3D3Bgt=3D3D3B = > ><=3D3BBR>=3D3B&=3D > >> >=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B This is=3D3D2C for me=3D3D2C a most un= > >fortunate time =3D > >> >=3D3D
>=3D3B >=3D3Bfor the CM3 servers to<=3D3BBR>=3D3B&= > >=3D3Bgt=3D3D3B &=3D > >> >=3D3Bgt=3D3D3B have crashed. I'm teaching a class =3D3D
>=3D3B >= > >=3D3Busing Mod=3D > >> >ula-3=3D3D2C and we need a<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3B= > >gt=3D3D3B compile=3D > >> >r... here's the una=3D3D
>=3D3B >=3D3Bme of the system I'm trying= > > to use:&=3D > >> >lt=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3= > >B&=3D3Bgt=3D3D3B &am=3D > >> >p=3D3Bgt=3D3D3B Linu=3D3D
>=3D3B >=3D3Bx lara 2.6.24ugcs1 #4 SMP = > >Mon Feb 11 10=3D > >> >:53:03 PST 2008 i686 GNU/Linux<=3D3BBR>=3D3B&=3D3Bg=3D3D
>= > >=3D3B >=3D3Bt=3D > >> >=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3= > >Bgt=3D3D3B The most r=3D > >> >ecent archives I have for Linux are=3D3D
>=3D3B >=3D3B:<=3D3BBR= > >>=3D3B&=3D > >> >=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &= > >amp=3D3Bgt=3D3D3B cm3-m=3D > >> >in-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D3D
>=3D3B >=3D3B-src-all-5.4.= > >0.tgz <=3D > >> =3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&a= > >mp=3D3Bgt=3D3D3B &=3D > >> >=3D3Bgt=3D3D3B And they don't seem =3D3D
>=3D3B >=3D3Bto work on = > >this system: =3D > >> >I can compile a program<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt= > >=3D3D3B but when=3D > >> > I=3D3D
>=3D3B >=3D3B try to run it=3D3D2C it says "Segmentation = > >fault". Can=3D > >> > anyone<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B=3D3D
&= > >gt=3D3B >=3D3B help=3D > >> >? (My understanding is that I need 5.5.1 or later...)<=3D3BBR>=3D3B&= > >amp=3D3Bg=3D > >> >t=3D3D3B &=3D3Bgt=3D3D3B=3D3D
>=3D3B >=3D3B <=3D3BBR>=3D3B= > >&=3D3Bgt=3D3D3B &=3D > >> >=3D3Bgt=3D3D3B Mika<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D= > >3B <=3D3BBR>=3D3B&a=3D > >> >mp=3D3Bgt=3D3D3B <=3D3BBR>=3D3B<=3D3B/body>=3D3B
>=3D3B >= > >=3D3B<=3D3B/html>=3D > >> >=3D3B=3D3D
>=3D3B >=3D3B
>=3D3B >=3D3B--_806446ae-8d10-4d7= > >4-8eea-51aa365e=3D > >> >9204_--
> >> >=3D > >> > > >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_-- > > > >--_55339e45-8c85-4ab6-9440-0d2131bbad69_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >Maybe not.
> >Hm. That is bug. There is use with a cvs tree=2C and use without.
> >I must have broken use without.
> > =3B
> >Try this:
> >export CM3_ROOT=3Droot of cm3 cvs (for me this is /dev2/cm3=2C
> >for you=2C maybe $HOME/cm3?)
> >rm =3B$HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6
> ># *Common and *common in one command
rm =3B$HOME/cm3/cm3-min-LINUXLI= > >BC6-d5.7.0/bin/*ommon
cp root of cm3 cvs/m3-sys/cminstall/src/config/cm3= > >.cfg $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin
> > =3B
> >The .cfg will delegate out to the cvs tree.
> >I don't like having two copies of files..having to keep them in sync..
> > =3BThough the archives are meant to work standalone=2C without CVS. >> > > =3B But I don't test that so much oops sorry.
> >That /might/ not be the right file=2C but it is close.
> > =3B
> > =3B- Jay

 =3B
>=3B To: jay.krell at cornell.edu
>=3B= > > CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] Help finding CM= > >3 compiler for Linux?
>=3B Date: Tue=2C 31 Mar 2009 22:59:18 -0700 >>>=3B From: mika at async.caltech.edu
>=3B
>=3B
>=3B Is the= > >re any documentation for this format beyond what you just
>=3B wrote? = > >Where?
>=3B
>=3B terpsichore-14: cm3
>=3B --- building in .= > >./LINUXLIBC6 ---
>=3B
>=3B new source ->=3B compiling Main.m3<= > >BR>>=3B "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.co= > >mmon"=2C line 169: quake runtime error: undefined variable: ROOT
>=3B = > >
>=3B --procedure-- -line- -file---
>=3B GetM3Back 169 /afs/.ugcs= > >/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common
>=3B _IsM3B= > >ackFlagSupported 181 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin= > >/Unix.common
>=3B IsM3BackFlagSupported 193 /afs/.ugcs/user/mika/cm3/c= > >m3-min-LINUXLIBC6-d5.7.0/bin/Unix.common
>=3B GetM3BackFlag 197 /afs/.= > >ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common
>=3B m3_b= > >ackend 62 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.commo= > >n
>=3B program -- <=3Bbuiltin>=3B
>=3B 6 /afs/.ugcs.caltech.e= > >du/user/mika/test/LINUXLIBC6/m3make.args
>=3B
>=3B
>=3B Fa= > >tal Error: procedure "m3_backend" defined in "/afs/.ugcs/user/mika/cm3/cm3-= > >min-LINUXLIBC6-d5.7.0/bin/cm3.cfg" failed.
>=3B
>=3B Jay writes:= > >
>=3B >=3B--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_
>=3B >=3BC= > >ontent-Type: text/plain=3B charset=3D"iso-8859-1"
>=3B >=3BContent-T= > >ransfer-Encoding: quoted-printable
>=3B >=3B
>=3B >=3B
>= > >=3B >=3BThese archives do have a different format=3D2C yes.
>=3B >= > >=3B
>=3B >=3BBut it isn't a bad format.
>=3B >=3B
>=3B &= > >gt=3Bcminstall is pretty worthless imho.
>=3B >=3B
>=3B >=3BE= > >xtract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.
>=3B >=3B
&= > >gt=3B >=3B=3D20
>=3B >=3B
>=3B >=3B - Jay
>=3B >=3B<= > >BR>>=3B >=3B=3D20
>=3B >=3B>=3B To: jay.krell at cornell.edu
&= > >gt=3B >=3B>=3B Subject: Re: [M3devel] Help finding CM3 compiler for Lin= > >ux?=3D20
>=3B >=3B>=3B Date: Tue=3D2C 31 Mar 2009 15:56:11 -0700 >R>>=3B >=3B>=3B From: mika at async.caltech.edu
>=3B >=3B>=3B= > >=3D20
>=3B >=3B>=3B No=3D2C I'm sorry...
>=3B >=3B>=3B=3D= > >20
>=3B >=3B>=3B the archives do not have the usual format. I'm ex= > >pecting to unpack
>=3B >=3B>=3B and run "cminstall" and then unpac= > >k the big source tar on top and=3D20
>=3B >=3B>=3B build that. But= > > there's no cminstall in the archive on this page.
>=3B >=3B>=3B T= > >his is "the normal procedure" for installing CM3=3D2C no? It's what
>= > >=3B >=3B>=3B the instructions say to do=3D2C as well...
>=3B >= > >=3B>=3B=3D20
>=3B >=3B>=3B And the link from the "Download" page= > > is broken (to -d5.5.0.tgz).
>=3B >=3B>=3B=3D20
>=3B >=3B&g= > >t=3B Mika
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B Jay writes: >>>=3B >=3B>=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>= > >=3B >=3B>=3B >=3BContent-Type: text/plain=3D3B charset=3D3D"iso-8859-= > >1"
>=3B >=3B>=3B >=3BContent-Transfer-Encoding: quoted-printable= > >
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B
>=3B >= > >=3B>=3B >=3B http://modula3.elegosoft.com/cm3/uploaded-archives
>= > >=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B?
>=3B >=3B>= > >=3B >=3B
>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >= > >=3B
>=3B >=3B>=3B >=3BI can make another later this week.
>= > >=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B=3D3D20
>=3B >= > >=3B>=3B >=3B
>=3B >=3B>=3B >=3BAll you need is a working cm3= > > on any system.
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B= > >>=3BFrom there you can build the whole system=3D3D2C targeting any system= > >.
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3BAs long as tha= > >t cm3 understands LONGINT and your target system.
>=3B >=3B>=3B &g= > >t=3B
>=3B >=3B>=3B >=3BAnd it is easier=3D3D2C but not necessary= > >=3D3D2C if you have Python. :)
>=3B >=3B>=3B >=3B
>=3B >= > >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B
>=3B >=3B>= > >=3B >=3B - Jay
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >= > >=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Date: Tue=3D3D2C 31 Mar 2009= > > 15:43:41 -0500
>=3B >=3B>=3B >=3B>=3B From: martinbishop at bell= > >south.net
>=3B >=3B>=3B >=3B>=3B To: mika at async.caltech.edu >>>=3B >=3B>=3B >=3B>=3B CC: m3devel at elegosoft.com
>=3B >= > >=3B>=3B >=3B>=3B Subject: Re: [M3devel] Help finding CM3 compiler for= > > Linux?
>=3B >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B &= > >gt=3B>=3B Not sure if this helps=3D3D2C but on my linux system:
>=3B= > > >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Criti= > >cal Mass Modula-3 version d5.7.0
>=3B >=3B>=3B >=3B>=3B last u= > >pdated: 2008-03-16
>=3B >=3B>=3B >=3B>=3B compiled: 2008-08-14= > > 00:56:14
>=3B >=3B>=3B >=3B>=3B configuration: /usr/local/cm3= > >/bin/cm3.cfg
>=3B >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>= > >=3B >=3B>=3B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:3= > >9 UTC 2009
>=3B >=3B>=3B >=3B>=3B i686 GNU/Linux
>=3B >= > >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B=3D3D20 >>>=3B >=3B>=3B >=3B>=3B I don't have the cm3 tarball=3D3D2C but I= > > do have the sources in cm3/ st=3D
>=3B >=3Bill.
>=3B >=3B>= > >=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Mika Nystrom wr= > >ote:
>=3B >=3B>=3B >=3B>=3B >=3B Hello everyone=3D3D2C
&g= > >t=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B&= > >gt=3B >=3B This is=3D3D2C for me=3D3D2C a most unfortunate time for the C= > >M3 servers=3D
>=3B >=3B to
>=3B >=3B>=3B >=3B>=3B >= > >=3B have crashed. I'm teaching a class using Modula-3=3D3D2C and we need a<= > >BR>>=3B >=3B>=3B >=3B>=3B >=3B compiler... here's the uname of = > >the system I'm trying to use:
>=3B >=3B>=3B >=3B>=3B >=3B=3D= > >3D20
>=3B >=3B>=3B >=3B>=3B >=3B Linux lara 2.6.24ugcs1 #4 S= > >MP Mon Feb 11 10:53:03 PST 2008 i686 GNU/=3D
>=3B >=3BLin=3D3D
&g= > >t=3B >=3B>=3B >=3Bux
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D2= > >0
>=3B >=3B>=3B >=3B>=3B >=3B The most recent archives I hav= > >e for Linux are:
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>= > >=3B >=3B>=3B >=3B>=3B >=3B cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3= > >-src-all-5.4.0.tgz=3D3D20
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20= > >
>=3B >=3B>=3B >=3B>=3B >=3B And they don't seem to work on = > >this system: I can compile a program
>=3B >=3B>=3B >=3B>=3B &g= > >t=3B but when I try to run it=3D3D2C it says "Segmentation fault". Can anyo= > >=3D
>=3B >=3Bne
>=3B >=3B>=3B >=3B>=3B >=3B help? (My= > > understanding is that I need 5.5.1 or later...)
>=3B >=3B>=3B >= > >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B >=3B Mika
= > >>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >= > >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >= > >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>=3B >=3B>=3B >=3BCo= > >ntent-Type: text/html=3D3B charset=3D3D"iso-8859-1"
>=3B >=3B>=3B = > >>=3BContent-Transfer-Encoding: quoted-printable
>=3B >=3B>=3B &g= > >t=3B
>=3B >=3B>=3B >=3B<=3Bhtml>=3B
>=3B >=3B>=3B &= > >gt=3B<=3Bhead>=3B
>=3B >=3B>=3B >=3B<=3Bstyle>=3B
>= > >=3B >=3B>=3B >=3B.hmmessage P
>=3B >=3B>=3B >=3B{
>= > >=3B >=3B>=3B >=3Bmargin:0px=3D3D3B
>=3B >=3B>=3B >=3Bpaddi= > >ng:0px
>=3B >=3B>=3B >=3B}
>=3B >=3B>=3B >=3Bbody.hmm= > >essage
>=3B >=3B>=3B >=3B{
>=3B >=3B>=3B >=3Bfont-siz= > e: 10pt=3D3D3B
>=3B >=3B>=3B >=3Bfont-family:Verdana
>=3B &= > >gt=3B>=3B >=3B}
>=3B >=3B>=3B >=3B<=3B/style>=3B
>= > >=3B >=3B>=3B >=3B<=3B/head>=3B
>=3B >=3B>=3B >=3B<= > >=3Bbody class=3D3D3D'hmmessage'>=3B
>=3B >=3B>=3B >=3B&=3Bn= > >bsp=3D3D3B<=3BA href=3D3D3D"http://modula3.elegosoft.com/cm3/uploaded-arc= > >hive=3D
>=3B >=3Bs" targ=3D3D
>=3B >=3B>=3B >=3Bet=3D3D3D= > >_blank>=3B<=3BFONT color=3D3D3D#0068cf>=3Bhttp://modula3.elegosoft.co= > >m/cm3/u=3D
>=3B >=3Bploaded=3D3D
>=3B >=3B>=3B >=3B-archi= > >ves<=3B/FONT>=3B<=3B/A>=3B<=3BBR>=3B
>=3B >=3B>=3B >= > >=3B?<=3BBR>=3B
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR&= > >gt=3B
>=3B >=3B>=3B >=3BI can make another later this week.<= > >=3BBR>=3B
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B >R>>=3B >=3B>=3B >=3BAll you need is a working cm3 on any system.<= > >=3BBR>=3B
>=3B >=3B>=3B >=3B>=3BFrom there you can build the= > > whole system=3D3D2C targeting any system.<=3BBR=3D
>=3B >=3B>= > >=3B
>=3B >=3B>=3B >=3BAs long as that cm3 understands LONGINT an= > >d your target system.<=3BBR>=3B
>=3B >=3B>=3B >=3BAnd it is = > >easier=3D3D2C but not necessary=3D3D2C if you have Python. :)<=3BBR>=3B= > >
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B
>=3B &g= > >t=3B>=3B >=3B&=3Bnbsp=3D3D3B- Jay<=3BBR>=3B<=3BBR>=3B&=3B= > >nbsp=3D3D3B<=3BBR>=3B&=3Bgt=3D3D3B Date: Tue=3D3D2C 31 Mar 2009=3D >R>>=3B >=3B 15:43:41 -=3D3D
>=3B >=3B>=3B >=3B0500<=3BBR&g= > >t=3B&=3Bgt=3D3D3B From: martinbishop at bellsouth.net<=3BBR>=3B&=3Bg= > >t=3D3D3B To: mika at a=3D
>=3B >=3Bsync.ca=3D3D
>=3B >=3B>=3B = > >>=3Bltech.edu<=3BBR>=3B&=3Bgt=3D3D3B CC: m3devel at elegosoft.com<= > >=3BBR>=3B&=3Bgt=3D3D3B Subject: Re:=3D
>=3B >=3B [M3dev=3D3D >>>=3B >=3B>=3B >=3Bel] Help finding CM3 compiler for Linux?<=3BBR= > >>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B Not su=3D
>=3B &= > >gt=3Bre if t=3D3D
>=3B >=3B>=3B >=3Bhis helps=3D3D2C but on my l= > >inux system:<=3BBR>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B C= > >ritical=3D
>=3B >=3B Mass Mod=3D3D
>=3B >=3B>=3B >=3Bula-= > >3 version d5.7.0<=3BBR>=3B&=3Bgt=3D3D3B last updated: 2008-03-16<= > >=3BBR>=3B&=3Bgt=3D3D3B co=3D
>=3B >=3Bmpiled:=3D3D
>=3B &g= > >t=3B>=3B >=3B 2008-08-14 00:56:14<=3BBR>=3B&=3Bgt=3D3D3B configu= > >ration: /usr/local/cm3/bin/cm3.c=3D
>=3B >=3Bfg<=3BBR=3D3D
>= > >=3B >=3B>=3B >=3B>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3= > >B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 2=3D
>=3B >=3B9 19= > >:24=3D3D
>=3B >=3B>=3B >=3B:39 UTC 2009<=3BBR>=3B&=3Bgt= > >=3D3D3B i686 GNU/Linux<=3BBR>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bg= > >t=3D3D3B <=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3D3B I don=3D3D
&= > >gt=3B >=3B>=3B >=3B't have the cm3 tarball=3D3D2C but I do have the s= > >ources in cm3/ still.<=3BBR=3D
>=3B >=3B>=3B&=3Bgt=3D3D
&g= > >t=3B >=3B>=3B >=3B=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B Mika Nystrom= > > wrote:<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B Hello everyo=3D
&= > >gt=3B >=3Bne=3D3D2C<=3BBR>=3B&=3Bg=3D3D
>=3B >=3B>=3B >= > >=3Bt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3= > >B This is=3D3D2C for me=3D3D2C a most un=3D
>=3B >=3Bfortunate time = > >=3D3D
>=3B >=3B>=3B >=3Bfor the CM3 servers to<=3BBR>=3B&= > >=3Bgt=3D3D3B &=3Bgt=3D3D3B have crashed. I'm teaching a=3D
>=3B >= > >=3B class =3D3D
>=3B >=3B>=3B >=3Busing Modula-3=3D3D2C and we n= > >eed a<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B compiler... here'=3D >R>>=3B >=3Bs the una=3D3D
>=3B >=3B>=3B >=3Bme of the system= > > I'm trying to use:<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B <=3BBR= > >>=3B&=3Bgt=3D3D3B &=3Bg=3D
>=3B >=3Bt=3D3D3B Linu=3D3D
&g= > >t=3B >=3B>=3B >=3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2= > >008 i686 GNU/Linux<=3BBR=3D
>=3B >=3B>=3B&=3Bg=3D3D
>=3B= > > >=3B>=3B >=3Bt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3= > >B &=3Bgt=3D3D3B The most recent archives I have fo=3D
>=3B >=3Br = > >Linux are=3D3D
>=3B >=3B>=3B >=3B:<=3BBR>=3B&=3Bgt=3D3D3B= > > &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B cm3-min-P= > OSIX-LINUXLIBC6-5.=3D
>=3B >=3B4.0.tgz cm3=3D3D
>=3B >=3B>= > >=3B >=3B-src-all-5.4.0.tgz <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3= > >B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B And they =3D
>=3B &g= > >t=3Bdon't seem =3D3D
>=3B >=3B>=3B >=3Bto work on this system: I= > > can compile a program<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B but= > >=3D
>=3B >=3B when I=3D3D
>=3B >=3B>=3B >=3B try to run i= > >t=3D3D2C it says "Segmentation fault". Can anyone<=3BBR>=3B&=3Bgt=3D= > >3D3B=3D
>=3B >=3B &=3Bgt=3D3D3B=3D3D
>=3B >=3B>=3B >= > >=3B help? (My understanding is that I need 5.5.1 or later...)<=3BBR>=3B= > >&=3Bgt=3D3D3B &=3B=3D
>=3B >=3Bgt=3D3D3B=3D3D
>=3B >=3B= > >>=3B >=3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B Mika<=3BBR&= > >gt=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B <= > >=3BBR>=3B<=3B/body=3D
>=3B >=3B>=3B
>=3B >=3B>=3B >= > >=3B<=3B/html>=3B=3D3D
>=3B >=3B>=3B >=3B
>=3B >=3B>= > >=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_--
>=3B >=3B
&g= > >t=3B >=3B--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_
>=3B >=3BContent= > >-Type: text/html=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer= > >-Encoding: quoted-printable
>=3B >=3B
>=3B >=3B<=3Bhtml>= > >=3B
>=3B >=3B<=3Bhead>=3B
>=3B >=3B<=3Bstyle>=3B
&= > >gt=3B >=3B.hmmessage P
>=3B >=3B{
>=3B >=3Bmargin:0px=3D3B<= > >BR>>=3B >=3Bpadding:0px
>=3B >=3B}
>=3B >=3Bbody.hmmessag= > >e
>=3B >=3B{
>=3B >=3Bfont-size: 10pt=3D3B
>=3B >=3Bfo= > >nt-family:Verdana
>=3B >=3B}
>=3B >=3B<=3B/style>=3B
&= > >gt=3B >=3B<=3B/head>=3B
>=3B >=3B<=3Bbody class=3D3D'hmmessa= > >ge'>=3B
>=3B >=3BThese archives do have a different format=3D2C ye= > >s.<=3BBR>=3B
>=3B >=3BBut it isn't a bad format.<=3BBR>=3B >R>>=3B >=3Bcminstall is pretty worthless imho.<=3BBR>=3B
>=3B = > >>=3BExtract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.<=3BBR>=3B<= > >BR>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp= > >=3D3B- Jay<=3BBR>=3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3B&=3B= > >gt=3D3B To: jay.krell at cornell.edu<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B = > >>=3B Subject: Re: [M3devel] Help finding CM3 compiler for Linux? <=3BBR= > >>=3B&=3Bgt=3D3B Dat=3D
>=3B >=3Be: Tue=3D2C 31 Mar 2009 15:56:1= > >1 -0700<=3BBR>=3B&=3Bgt=3D3B From: mika at async.caltech.edu=3D
>= > >=3B >=3B<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B No=3D2C= > > I'm sorry...<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B the = > >archives =3D
>=3B >=3Bdo not have the usual format. I'm expecting to= > > unpack<=3BBR>=3B&=3Bgt=3D3B and run "cm=3D
>=3B >=3Binstall"= > > and then unpack the big source tar on top and <=3BBR>=3B&=3Bgt=3D3B= > > build tha=3D
>=3B >=3Bt. But there's no cminstall in the archive on= > > this page.<=3BBR>=3B&=3Bgt=3D3B This is =3D
>=3B >=3B"the no= > >rmal procedure" for installing CM3=3D2C no? It's what<=3BBR>=3B&=3Bg= > >t=3D3B the in=3D
>=3B >=3Bstructions say to do=3D2C as well...<=3B= > >BR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B And the link from t=3D<= > >BR>>=3B >=3Bhe "Download" page is broken (to -d5.5.0.tgz).<=3BBR>= > >=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Mika<=3BBR=3D
>=3B &g= > >t=3B>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Jay writes:<=3BBR&g= > >t=3B&=3Bgt=3D3B &=3Bgt=3D3B--_806446ae-8d10-4d74-8eea-5=3D
>=3B = > >>=3B1aa365e9204_<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BContent-Type: = > >text/plain=3D3B charset=3D3D"iso-885=3D
>=3B >=3B9-1"<=3BBR>=3B&= > >amp=3Bgt=3D3B &=3Bgt=3D3BContent-Transfer-Encoding: quoted-printable<= > >=3BBR>=3B&=3Bgt=3D3B =3D
>=3B >=3B&=3Bgt=3D3B<=3BBR>=3B&= > >amp=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B htt= > >p://modula3.elegosoft.com/cm3/u=3D
>=3B >=3Bploaded-archives<=3BBR= > >>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= > >=3D3B?<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D= > >
>=3B >=3B=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &a= > >mp=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BI can make another l= > >ater t=3D
>=3B >=3Bhis week.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= > >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&= > >=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >=3B &= > >amp=3Bgt=3D3BAll you need is a working cm3 on any system.<=3BBR>=3B&= > >=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &= > >amp=3Bgt=3D3B&=3Bgt=3D3BFrom there you can build the whole system=3D3D2C= > > targeting an=3D
>=3B >=3By system.<=3BBR>=3B&=3Bgt=3D3B &= > >=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAs long as that cm3 un= > >derstands =3D
>=3B >=3BLONGINT and your target system.<=3BBR>=3B= > >&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAnd= > > it is =3D
>=3B >=3Beasier=3D3D2C but not necessary=3D3D2C if you ha= > >ve Python. :)<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3B=3D
>=3B= > > >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt= > >=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B - Jay<=3B= > >BR>=3B&=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B<=3BBR>=3B&= > >=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B= > >&=3Bgt=3D3B Date: Tue=3D3D2C 31 Mar 2009=3D
>=3B >=3B 15:43:41 -0= > >500<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B From: martinbi= > >shop at bellsouth.net<=3BBR>=3B=3D
>=3B >=3B&=3Bgt=3D3B &=3Bg= > >t=3D3B&=3Bgt=3D3B To: mika at async.caltech.edu<=3BBR>=3B&=3Bgt=3D3B= > > &=3Bgt=3D3B&=3Bgt=3D3B CC: m=3D
>=3B >=3B3devel at elegosoft.com= > ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B Subject: Re: [M3d= > >evel] Help fin=3D
>=3B >=3Bding CM3 compiler for Linux?<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bg= > >t=3D3B &=3Bgt=3D3B&=3Bg=3D
>=3B >=3Bt=3D3B Not sure if this he= > >lps=3D3D2C but on my linux system:<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= > >3B&=3Bg=3D
>=3B >=3Bt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &am= > >p=3Bgt=3D3B&=3Bgt=3D3B Critical Mass Modula-3 version d5.7.0<=3BBR>= > >=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B last upd= > >ated: 2008-03-16<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B c= > >ompiled=3D
>=3B >=3B: 2008-08-14 00:56:14<=3BBR>=3B&=3Bgt=3D3= > >B &=3Bgt=3D3B&=3Bgt=3D3B configuration: /usr/local/cm3/=3D
>=3B = > >>=3Bbin/cm3.cfg<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B= > >=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B Linux thin= > >kp=3D
>=3B >=3Bad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2= > >009<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bg=3D
>=3B >=3Bt= > >=3D3B i686 GNU/Linux<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D= > >3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20= > >=3D
>=3B >=3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D= > >3B I don't have the cm3 tarball=3D3D2C but I do have the=3D
>=3B >= > >=3B sources in cm3/ still.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B = > >=3D
>=3B >=3BMika Nystrom wrote:<=3BBR>=3B&=3Bgt=3D3B &=3B= > >gt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B Hello everyone=3D3D2C<=3BBR>=3B&am= > >p=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B= > >=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt= > >=3D3B This is=3D3D2C fo=3D
>=3B >=3Br me=3D3D2C a most unfortunate t= > >ime for the CM3 servers to<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B have crashed. I'm teaching a = > >class using Modula-3=3D3D2C and we n=3D
>=3B >=3Beed a<=3BBR>=3B= > >&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B compiler... here= > >'s the uname of the sys=3D
>=3B >=3Btem I'm trying to use:<=3BBR&g= > >t=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3B= > >BR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3B=3D
>=3B >=3Bgt=3D3B &am= > >p=3Bgt=3D3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i68= > >=3D
>=3B >=3B6 GNU/Lin=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= > >3Bux<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3= > >B=3D3D20<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &=3Bgt=3D3B&= > >=3Bgt=3D3B &=3Bgt=3D3B The most recent archives I have for Linux are:<= > >=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B = > >&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt= > >=3D3B &=3Bgt=3D3B cm3-min-POSIX-=3D
>=3B >=3BLINUXLIBC6-5.4.0.tgz= > > cm3-src-all-5.4.0.tgz=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&am= > >p=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B=3D3D20<=3BBR>=3B&=3Bg= > >t=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B And they don't seem to w= > >ork on this =3D
>=3B >=3Bsystem: I can compile a program<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B but when I tr= > >=3D
>=3B >=3By to run it=3D3D2C it says "Segmentation fault". Can an= > >yone<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3B=3D
>=3B >=3Bg= > >t=3D3B &=3Bgt=3D3B help? (My understanding is that I need 5.5.1 or later= > >...)<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bg= > >t=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Bgt=3D3B &=3Bgt=3D3B Mika<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >= > >=3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3B= > >gt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &am= > >p=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B-= > >-_806446ae-8d10-4d74-8eea-51aa365e9204_<=3BBR>=3B&=3Bgt=3D3B &=3B= > >gt=3D3BConten=3D
>=3B >=3Bt-Type: text/html=3D3B charset=3D3D"iso-88= > >59-1"<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BContent-Transfe=3D
>= > >=3B >=3Br-Encoding: quoted-printable<=3BBR>=3B&=3Bgt=3D3B &=3Bg= > >t=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3Bhtml&=3Bg= > >t=3D
>=3B >=3B=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Blt=3D3Bhead&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Blt=3D3Bstyle&=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D= > >3B &=3Bgt=3D3B.hmmessage P<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B{&l= > >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bmargin:0px=3D3D3B<=3B=3D
>= > >=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bpadding:0px<=3BBR>=3B&am= > >p=3Bgt=3D3B &=3Bgt=3D3B}<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bbody.= > >hmmessag=3D
>=3B >=3Be<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B{&l= > >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfont-size: 10pt=3D3D3B<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3Bfo=3D
>=3B >=3Bnt-family:Verdana<= > >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B}<=3BBR>=3B&=3Bgt=3D3B &= > >=3Bgt=3D3B&=3Blt=3D3B/style&=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>= > >=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3B/head&=3Bgt=3D3B<=3BBR&g= > >t=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3Bbody class=3D3D3D'hmmessa=3D= > >
>=3B >=3Bge'&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= > >3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BA href=3D3D3D"http://modula3.=3D<= > >BR>>=3B >=3Belegosoft.com/cm3/uploaded-archives" targ=3D3D<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3Bet=3D3D3D_blank&=3B=3D
>=3B >=3Bg= > >t=3D3B&=3Blt=3D3BFONT color=3D3D3D#0068cf&=3Bgt=3D3Bhttp://modula3.el= > >egosoft.com/cm3/upl=3D
>=3B >=3Boaded=3D3D<=3BBR>=3B&=3Bgt=3D= > >3B &=3Bgt=3D3B-archives&=3Blt=3D3B/FONT&=3Bgt=3D3B&=3Blt=3D3B/A= > >&=3Bgt=3D3B&=3Blt=3D3BBR&=3Bg=3D
>=3B >=3Bt=3D3B<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3B?&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3B=3D= > >
>=3B >=3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3= > >BI can make another later this week.&=3Blt=3D3BBR&=3Bgt=3D3B<=3B=3D= > >
>=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp= > >=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= > >=3D3BAll you need=3D
>=3B >=3B is a working cm3 on any system.&= > >=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Bgt=3D3BFrom t=3D
>=3B >=3Bhere you can build the whole system=3D3= > >D2C targeting any system.&=3Blt=3D3BBR&=3Bgt=3D
>=3B >=3B=3D3B= > ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAs long as that cm3 understands = > >LONGINT and your target=3D
>=3B >=3B system.&=3Blt=3D3BBR&=3Bg= > >t=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAnd it is easier=3D3D2C bu= > >t not necess=3D
>=3B >=3Bary=3D3D2C if you have Python. :)&=3Blt= > >=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp= > >=3D3Bnbsp=3D
>=3B >=3B=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR&= > >gt=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B- Jay&=3Blt= > >=3D3BBR&=3Bgt=3D3B&=3Blt=3D
>=3B >=3B=3D3BBR&=3Bgt=3D3B&= > >=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3= > >B Date: Tue=3D3D2C 31 M=3D
>=3B >=3Bar 2009 15:43:41 -=3D3D<=3BBR&= > >gt=3B&=3Bgt=3D3B &=3Bgt=3D3B0500&=3Blt=3D3BBR&=3Bgt=3D3B&=3B= > >amp=3D3Bgt=3D3D3B From=3D
>=3B >=3B: martinbishop at bellsouth.net&= > >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B To: mika at async.ca=3D
= > >>=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bltech.edu&= > >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B CC: m3devel at elego=3D
= > >>=3B >=3Bsoft.com&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B= > > Subject: Re: [M3dev=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D
>= > >=3B >=3B=3D3Bel] Help finding CM3 compiler for Linux?&=3Blt=3D3BBR&= > >=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D
>=3B >=3B=3D3BBR&= > >=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B Not sure if t=3D3D<=3BBR>=3B&=3Bg= > >t=3D3B &=3Bgt=3D3Bhis helps=3D3D2C b=3D
>=3B >=3But on my linux s= > >ystem:&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3B= > >BR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D
>=3B >=3B=3D3D3B Critical Mass = > >Mod=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bula-3 version d5.7.0&= > >=3Blt=3D3BBR&=3Bgt=3D
>=3B >=3B=3D3B&=3Bamp=3D3Bgt=3D3D3B last= > > updated: 2008-03-16&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B = > >comp=3D
>=3B >=3Biled:=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= > >3B 2008-08-14 00:56:14&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3= > >B c=3D
>=3B >=3Bonfiguration: /usr/local/cm3/bin/cm3.cfg&=3Blt=3D= > >3BBR=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B&=3B= > >=3D
>=3B >=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3B= > >amp=3D3Bgt=3D3D3B Linux thinkpad 2.6.27-11-generic=3D
>=3B >=3B #1 S= > >MP Thu Jan 29 19:24=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B:39 UTC = > >2009&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3= > >D3B i686 GNU/Linux&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &a= > >mp=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3B=3D
>=3B >=3Bgt=3D3D3B &a= > >mp=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B I don=3D3D<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3B't have the c=3D
>=3B >=3Bm3 tarball= > >=3D3D2C but I do have the sources in cm3/ still.&=3Blt=3D3BBR&=3Bgt= > >=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D<=3BBR>=3B&=3Bgt=3D3B= > > &=3Bgt=3D3B=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D= > >3B Mika Nystrom wr=3D
>=3B >=3Bote:&=3Blt=3D3BBR&=3Bgt=3D3B&am= > >p=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B Hello everyone=3D3D2C&=3B= > >lt=3D3BBR=3D
>=3B >=3B&=3Bgt=3D3B&=3Bamp=3D3Bg=3D3D<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3Bt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt= > >=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D3B &=3Bam= > >p=3D3Bgt=3D3D3B This is=3D3D2C for me=3D3D2C a most unfortunate time =3D >>>=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfor the CM3 s= > >ervers to&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp= > >=3D
>=3B >=3B=3D3Bgt=3D3D3B have crashed. I'm teaching a class =3D3D= > ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Busing Mod=3D
>=3B >=3Bula= > >-3=3D3D2C and we need a&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D= > >3B &=3Bamp=3D3Bgt=3D3D3B compile=3D
>=3B >=3Br... here's the una= > >=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bme of the system I'm trying= > > to use:&=3B=3D
>=3B >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt= > >=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp= > >=3D3Bgt=3D3D3B &=3Bam=3D
>=3B >=3Bp=3D3Bgt=3D3D3B Linu=3D3D<=3B= > >BR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 1= > >0=3D
>=3B >=3B:53:03 PST 2008 i686 GNU/Linux&=3Blt=3D3BBR&=3Bg= > >t=3D3B&=3Bamp=3D3Bg=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bt=3D<= > >BR>>=3B >=3B=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt= > >=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B The most r=3D
>= > >=3B >=3Becent archives I have for Linux are=3D3D<=3BBR>=3B&=3Bgt= > >=3D3B &=3Bgt=3D3B:&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B = > >>=3B=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3= > >B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B cm3-m=3D
>=3B >= > >=3Bin-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D3D<=3BBR>=3B&=3Bgt=3D3B &= > >=3Bgt=3D3B-src-all-5.4.0.tgz &=3Blt=3D
>=3B =3D3BBR&=3Bgt=3D3B&a= > >mp=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt= > >=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D3B = > >And they don't seem =3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bto work= > > on this system: =3D
>=3B >=3BI can compile a program&=3Blt=3D3BB= > >R&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B but when= > >=3D
>=3B >=3B I=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B try = > >to run it=3D3D2C it says "Segmentation fault". Can=3D
>=3B >=3B anyo= > >ne&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt= > >=3D3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B help=3D
>=3B &= > >gt=3B? (My understanding is that I need 5.5.1 or later...)&=3Blt=3D3BBR&= > >amp=3Bgt=3D3B&=3Bamp=3D3Bg=3D
>=3B >=3Bt=3D3D3B &=3Bamp=3D3Bgt= > >=3D3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B &=3Blt=3D3BBR&am= > >p=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D
>=3B >=3B=3D3Bgt= > >=3D3D3B Mika&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Ba= > >mp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Ba=3D
>=3B >=3B= > >mp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Blt=3D3B/body&=3Bgt= > >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3B/html&=3Bg= > >t=3D
>=3B >=3B=3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >lt=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B--_806446ae-8d10-4d74-8eea-51aa36= > >5e=3D
>=3B >=3B9204_--<=3BBR>=3B<=3B/body>=3B
>=3B >= > >=3B<=3B/html>=3B=3D
>=3B >=3B
>=3B >=3B--_777fdc4e-3c29-4= > >0b4-a3dd-e6243f796cee_--
> >= > > > >--_55339e45-8c85-4ab6-9440-0d2131bbad69_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 1 08:58:19 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Apr 2009 06:58:19 +0000 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: <200904010653.n316rcZs073236@camembert.async.caltech.edu> References: Your message of "Wed, 01 Apr 2009 06:13:00 -0000." <200904010653.n316rcZs073236@camembert.async.caltech.edu> Message-ID: For the first part, do you have CM3_ROOT set to the root of your cvs checkout? It should use that to find a current set of config files. For the second part, wrong file, my fault. That is an "unconfigured" file -- one that cminstall hasn't munged. How about m3-sys/cminstall/src/config-no-install/cm3.cfg? - Jay > To: jay.krell at cornell.edu > Date: Tue, 31 Mar 2009 23:53:38 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Help finding CM3 compiler for Linux? > > To be honest, I'm not so sure what's intended. > > I either get this: > > "/home/mika/cm3/cm3-std-LINUXLIBC6-d5.7.0/bin/cm3.cfg", line 125: quake runtime error: unable to find a configuration file for (/home/mika/cm3/cm3-std-LINUXLIBC6-d5.7.0/bin/.., /afs/.ugcs/user/mika/cm3/cm3-std-LINUXLIBC6-d5.7.0, LINUXLIBC6) > > or, if I put back the LINUXLIBC6 file you had me delete: > > "/home/mika/cm3/cm3-std-LINUXLIBC6-d5.7.0/bin/cm3.cfg", line 128: quake runtime error: /home/mika/cm3/cm3-std-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6, line 61: syntax error: missing: <*EOF*> (found: ) > > which refers to the following (which looks like cminstall stuff to me): > > INITIAL_REACTOR_EDITOR = BEGIN_CONFIG > "What should be the default text editor for new Reactor users?" <--- this line > 10 "EDITOR" > 0 "emacsclient" > 0 "emacs" > 0 "vi" > 0 "textedit" > 0 "xedit" > 6 "/usr/local/emacs/bin" "emacsclient" > 6 "/usr/local/bin" "emacsclient" > 6 "/usr/local/emacs/bin" "emacs" > 6 "/usr/local/bin" "emacs" > 6 "/usr/bin" "vi" > 6 "/usr/local/X11R5/bin" "xedit" > 6 "/usr/openwin/bin" "textedit" > > Jay writes: > >--_55339e45-8c85-4ab6-9440-0d2131bbad69_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Maybe not. > > > >Hm. That is bug. There is use with a cvs tree=2C and use without. > > > >I must have broken use without. > > > >=20 > > > >Try this: > > > >export CM3_ROOT=3Droot of cm3 cvs (for me this is /dev2/cm3=2C > > > >for you=2C maybe $HOME/cm3?) > > > >rm $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6 > > > ># *Common and *common in one command > >rm $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/*ommon > >cp root of cm3 cvs/m3-sys/cminstall/src/config/cm3.cfg $HOME/cm3/cm3-min-LI= > >NUXLIBC6-d5.7.0/bin > > > >=20 > > > >The .cfg will delegate out to the cvs tree. > > > >I don't like having two copies of files..having to keep them in sync.. > > > > Though the archives are meant to work standalone=2C without CVS. > > > > But I don't test that so much oops sorry. > > > >That /might/ not be the right file=2C but it is close. > > > >=20 > > > > - Jay > > > >=20 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux?=20 > >> Date: Tue=2C 31 Mar 2009 22:59:18 -0700 > >> From: mika at async.caltech.edu > >>=20 > >>=20 > >> Is there any documentation for this format beyond what you just > >> wrote? Where? > >>=20 > >> terpsichore-14: cm3 > >> --- building in ../LINUXLIBC6 --- > >>=20 > >> new source -> compiling Main.m3 > >> "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common"=2C= > > line 169: quake runtime error: undefined variable: ROOT > >>=20 > >> --procedure-- -line- -file--- > >> GetM3Back 169 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3c= > >fg.common > >> _IsM3BackFlagSupported 181 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5= > >.7.0/bin/Unix.common > >> IsM3BackFlagSupported 193 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.= > >7.0/bin/Unix.common > >> GetM3BackFlag 197 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/= > >Unix.common > >> m3_backend 62 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix= > >.common > >> program -- > >> 6 /afs/.ugcs.caltech.edu/user/mika/test/LINUXLIBC6/m3make.args > >>=20 > >>=20 > >> Fatal Error: procedure "m3_backend" defined in "/afs/.ugcs/user/mika/cm3/= > >cm3-min-LINUXLIBC6-d5.7.0/bin/cm3.cfg" failed. > >>=20 > >> Jay writes: > >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ > >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> >These archives do have a different format=3D2C yes. > >> > > >> >But it isn't a bad format. > >> > > >> >cminstall is pretty worthless imho. > >> > > >> >Extract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH. > >> > > >> >=3D20 > >> > > >> > - Jay > >> > > >> >=3D20 > >> >> To: jay.krell at cornell.edu > >> >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux?=3D20 > >> >> Date: Tue=3D2C 31 Mar 2009 15:56:11 -0700 > >> >> From: mika at async.caltech.edu > >> >>=3D20 > >> >> No=3D2C I'm sorry... > >> >>=3D20 > >> >> the archives do not have the usual format. I'm expecting to unpack > >> >> and run "cminstall" and then unpack the big source tar on top and=3D20 > >> >> build that. But there's no cminstall in the archive on this page. > >> >> This is "the normal procedure" for installing CM3=3D2C no? It's what > >> >> the instructions say to do=3D2C as well... > >> >>=3D20 > >> >> And the link from the "Download" page is broken (to -d5.5.0.tgz). > >> >>=3D20 > >> >> Mika > >> >>=3D20 > >> >> Jay writes: > >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ > >> >> >Content-Type: text/plain=3D3B charset=3D3D"iso-8859-1" > >> >> >Content-Transfer-Encoding: quoted-printable > >> >> > > >> >> > > >> >> > http://modula3.elegosoft.com/cm3/uploaded-archives > >> >> > > >> >> >? > >> >> > > >> >> >=3D3D20 > >> >> > > >> >> >I can make another later this week. > >> >> > > >> >> >=3D3D20 > >> >> > > >> >> >All you need is a working cm3 on any system. > >> >> > > >> >> >>From there you can build the whole system=3D3D2C targeting any syste= > >m. > >> >> > > >> >> >As long as that cm3 understands LONGINT and your target system. > >> >> > > >> >> >And it is easier=3D3D2C but not necessary=3D3D2C if you have Python. = > >:) > >> >> > > >> >> >=3D3D20 > >> >> > > >> >> > - Jay > >> >> > > >> >> >=3D3D20 > >> >> >> Date: Tue=3D3D2C 31 Mar 2009 15:43:41 -0500 > >> >> >> From: martinbishop at bellsouth.net > >> >> >> To: mika at async.caltech.edu > >> >> >> CC: m3devel at elegosoft.com > >> >> >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? > >> >> >>=3D3D20 > >> >> >> Not sure if this helps=3D3D2C but on my linux system: > >> >> >>=3D3D20 > >> >> >> Critical Mass Modula-3 version d5.7.0 > >> >> >> last updated: 2008-03-16 > >> >> >> compiled: 2008-08-14 00:56:14 > >> >> >> configuration: /usr/local/cm3/bin/cm3.cfg > >> >> >>=3D3D20 > >> >> >> Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 200= > >9 > >> >> >> i686 GNU/Linux > >> >> >>=3D3D20 > >> >> >>=3D3D20 > >> >> >> I don't have the cm3 tarball=3D3D2C but I do have the sources in cm= > >3/ st=3D > >> >ill. > >> >> >>=3D3D20 > >> >> >> Mika Nystrom wrote: > >> >> >> > Hello everyone=3D3D2C > >> >> >> >=3D3D20 > >> >> >> > This is=3D3D2C for me=3D3D2C a most unfortunate time for the CM3 = > >servers=3D > >> > to > >> >> >> > have crashed. I'm teaching a class using Modula-3=3D3D2C and we n= > >eed a > >> >> >> > compiler... here's the uname of the system I'm trying to use: > >> >> >> >=3D3D20 > >> >> >> > Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 G= > >NU/=3D > >> >Lin=3D3D > >> >> >ux > >> >> >> >=3D3D20 > >> >> >> > The most recent archives I have for Linux are: > >> >> >> >=3D3D20 > >> >> >> > cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D3D20 > >> >> >> >=3D3D20 > >> >> >> > And they don't seem to work on this system: I can compile a progr= > >am > >> >> >> > but when I try to run it=3D3D2C it says "Segmentation fault". Can= > > anyo=3D > >> >ne > >> >> >> > help? (My understanding is that I need 5.5.1 or later...) > >> >> >> >=3D3D20 > >> >> >> > Mika > >> >> >> >=3D3D20 > >> >> >>=3D3D20 > >> >> > > >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_ > >> >> >Content-Type: text/html=3D3B charset=3D3D"iso-8859-1" > >> >> >Content-Transfer-Encoding: quoted-printable > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > =3D3D3B >archive=3D > >> >s" targ=3D3D > >> >> >et=3D3D3D_blank>http://modula3.elegosoft.co= > >m/cm3/u=3D > >> >ploaded=3D3D > >> >> >-archives
> >> >> >?
> >> >> > =3D3D3B
> >> >> >I can make another later this week.
> >> >> > =3D3D3B
> >> >> >All you need is a working cm3 on any system.
> >> >> >>From there you can build the whole system=3D3D2C targeting any syste= > >m. >> >> > >> >> >As long as that cm3 understands LONGINT and your target system.
> >> >> >And it is easier=3D3D2C but not necessary=3D3D2C if you have Python. = > >:)
> >> >> > =3D3D3B
> >> >> > =3D3D3B- Jay

 =3D3D3B
>=3D3D3B Date: Tue=3D3D2C = > >31 Mar 2009=3D > >> > 15:43:41 -=3D3D > >> >> >0500
>=3D3D3B From: martinbishop at bellsouth.net
>=3D3D3B To:= > > mika at a=3D > >> >sync.ca=3D3D > >> >> >ltech.edu
>=3D3D3B CC: m3devel at elegosoft.com
>=3D3D3B Subje= > >ct: Re:=3D > >> > [M3dev=3D3D > >> >> >el] Help finding CM3 compiler for Linux?
>=3D3D3B
>=3D3D3B= > > Not su=3D > >> >re if t=3D3D > >> >> >his helps=3D3D2C but on my linux system:
>=3D3D3B
>=3D3D3B= > > Critical=3D > >> > Mass Mod=3D3D > >> >> >ula-3 version d5.7.0
>=3D3D3B last updated: 2008-03-16
>=3D= > >3D3B co=3D > >> >mpiled:=3D3D > >> >> > 2008-08-14 00:56:14
>=3D3D3B configuration: /usr/local/cm3/bin/= > >cm3.c=3D > >> >fg >> >> >>>=3D3D3B
>=3D3D3B Linux thinkpad 2.6.27-11-generic #1 SMP Th= > >u Jan 2=3D > >> >9 19:24=3D3D > >> >> >:39 UTC 2009
>=3D3D3B i686 GNU/Linux
>=3D3D3B
>=3D3D3= > >B
>=3D > >> >=3D3D3B I don=3D3D > >> >> >'t have the cm3 tarball=3D3D2C but I do have the sources in cm3/ stil= > >l. >> >>>=3D3D > >> >> >=3D3D3B
>=3D3D3B Mika Nystrom wrote:
>=3D3D3B >=3D3D3B H= > >ello everyo=3D > >> >ne=3D3D2C
&g=3D3D > >> >> >t=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B This is=3D3D2C for me= > >=3D3D2C a most un=3D > >> >fortunate time =3D3D > >> >> >for the CM3 servers to
>=3D3D3B >=3D3D3B have crashed. I'm tea= > >ching a=3D > >> > class =3D3D > >> >> >using Modula-3=3D3D2C and we need a
>=3D3D3B >=3D3D3B compiler= > >... here'=3D > >> >s the una=3D3D > >> >> >me of the system I'm trying to use:
>=3D3D3B >=3D3D3B
>= > >=3D3D3B &g=3D > >> >t=3D3D3B Linu=3D3D > >> >> >x lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Linux= > > >> >>&g=3D3D > >> >> >t=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B The most recent archive= > >s I have fo=3D > >> >r Linux are=3D3D > >> >> >:
>=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3B cm3-min-POSIX-LI= > >NUXLIBC6-5.=3D > >> >4.0.tgz cm3=3D3D > >> >> >-src-all-5.4.0.tgz
>=3D3D3B >=3D3D3B
>=3D3D3B >=3D3D3= > >B And they =3D > >> >don't seem =3D3D > >> >> >to work on this system: I can compile a program
>=3D3D3B >=3D3= > >D3B but=3D > >> > when I=3D3D > >> >> > try to run it=3D3D2C it says "Segmentation fault". Can anyone
>= > >=3D3D3B=3D > >> > >=3D3D3B=3D3D > >> >> > help? (My understanding is that I need 5.5.1 or later...)
>=3D3= > >D3B &=3D > >> >gt=3D3D3B=3D3D > >> >> >
>=3D3D3B >=3D3D3B Mika
>=3D3D3B >=3D3D3B
>=3D3D= > >3B
>> >> > >> >> >=3D3D > >> >> > > >> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_-- > >> > > >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_ > >> >Content-Type: text/html=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> > > >> > > >> > > >> > > >> >These archives do have a different format=3D2C yes.
> >> >But it isn't a bad format.
> >> >cminstall is pretty worthless imho.
> >> >Extract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.
> >> > =3D3B
> >> > =3D3B- Jay

 =3D3B
>=3D3B To: jay.krell at cornell.edu<= > >BR>>=3D3B=3D > >> > Subject: Re: [M3devel] Help finding CM3 compiler for Linux?
>=3D3= > >B Dat=3D > >> >e: Tue=3D2C 31 Mar 2009 15:56:11 -0700
>=3D3B From: mika at async.calt= > >ech.edu=3D > >> >
>=3D3B
>=3D3B No=3D2C I'm sorry...
>=3D3B
>=3D3B = > >the archives =3D > >> >do not have the usual format. I'm expecting to unpack
>=3D3B and ru= > >n "cm=3D > >> >install" and then unpack the big source tar on top and
>=3D3B buil= > >d tha=3D > >> >t. But there's no cminstall in the archive on this page.
>=3D3B Thi= > >s is =3D > >> >"the normal procedure" for installing CM3=3D2C no? It's what
>=3D3B= > > the in=3D > >> >structions say to do=3D2C as well...
>=3D3B
>=3D3B And the li= > >nk from t=3D > >> >he "Download" page is broken (to -d5.5.0.tgz).
>=3D3B
>=3D3B = > >Mika >> >>>=3D3B
>=3D3B Jay writes:
>=3D3B >=3D3B--_806446ae-8d10-= > >4d74-8eea-5=3D > >> >1aa365e9204_
>=3D3B >=3D3BContent-Type: text/plain=3D3B charset= > >=3D3D"iso-885=3D > >> >9-1"
>=3D3B >=3D3BContent-Transfer-Encoding: quoted-printable
= > >>=3D3B =3D > >> >>=3D3B
>=3D3B >=3D3B
>=3D3B >=3D3B http://modula3.elegos= > >oft.com/cm3/u=3D > >> >ploaded-archives
>=3D3B >=3D3B
>=3D3B >=3D3B?
>=3D3B = > >>=3D3B
>=3D > >> >=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B
>=3D3B >=3D3BI can mak= > >e another later t=3D > >> >his week.
>=3D3B >=3D3B
>=3D3B >=3D3B=3D3D20
>=3D3B &= > >gt=3D3B
>=3D3B=3D > >> > >=3D3BAll you need is a working cm3 on any system.
>=3D3B >=3D= > >3B
>=3D > >> >=3D3B >=3D3B>=3D3BFrom there you can build the whole system=3D3D2C t= > >argeting an=3D > >> >y system.
>=3D3B >=3D3B
>=3D3B >=3D3BAs long as that cm3 u= > >nderstands =3D > >> >LONGINT and your target system.
>=3D3B >=3D3B
>=3D3B >=3D3= > >BAnd it is =3D > >> >easier=3D3D2C but not necessary=3D3D2C if you have Python. :)
>=3D3= > >B >=3D3B<=3D > >> >BR>>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B
>=3D3B >=3D3B - = > >Jay
>=3D3B >=3D > >> >=3D3B
>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B Date: Tue= > >=3D3D2C 31 Mar 2009=3D > >> > 15:43:41 -0500
>=3D3B >=3D3B>=3D3B From: martinbishop at bellsout= > >h.net
=3D > >> >>=3D3B >=3D3B>=3D3B To: mika at async.caltech.edu
>=3D3B >=3D3= > >B>=3D3B CC: m=3D > >> >3devel at elegosoft.com
>=3D3B >=3D3B>=3D3B Subject: Re: [M3devel]= > > Help fin=3D > >> >ding CM3 compiler for Linux?
>=3D3B >=3D3B>=3D3B=3D3D20
>= > >=3D3B >=3D3B&g=3D > >> >t=3D3B Not sure if this helps=3D3D2C but on my linux system:
>=3D3B= > > >=3D3B&g=3D > >> >t=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B Critical Mass Modula-3 versio= > >n d5.7.0
&=3D > >> >gt=3D3B >=3D3B>=3D3B last updated: 2008-03-16
>=3D3B >=3D3B&g= > >t=3D3B compiled=3D > >> >: 2008-08-14 00:56:14
>=3D3B >=3D3B>=3D3B configuration: /usr/l= > >ocal/cm3/=3D > >> >bin/cm3.cfg
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B >=3D3B>= > >=3D3B Linux thinkp=3D > >> >ad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009
>=3D3B >= > >=3D3B&g=3D > >> >t=3D3B i686 GNU/Linux
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B &g= > >t=3D3B>=3D3B=3D3D20=3D > >> >
>=3D3B >=3D3B>=3D3B I don't have the cm3 tarball=3D3D2C but I = > >do have the=3D > >> > sources in cm3/ still.
>=3D3B >=3D3B>=3D3B=3D3D20
>=3D3B = > >>=3D3B>=3D3B =3D > >> >Mika Nystrom wrote:
>=3D3B >=3D3B>=3D3B >=3D3B Hello everyone= > >=3D3D2C
&g=3D > >> >t=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B >= > >=3D3B This is=3D3D2C fo=3D > >> >r me=3D3D2C a most unfortunate time for the CM3 servers to
>=3D3B &= > >gt=3D3B&g=3D > >> >t=3D3B >=3D3B have crashed. I'm teaching a class using Modula-3=3D3D2C= > > and we n=3D > >> >eed a
>=3D3B >=3D3B>=3D3B >=3D3B compiler... here's the uname= > > of the sys=3D > >> >tem I'm trying to use:
>=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
&= > >gt=3D3B >=3D3B&=3D > >> >gt=3D3B >=3D3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2= > >008 i68=3D > >> >6 GNU/Lin=3D3D
>=3D3B >=3D3Bux
>=3D3B >=3D3B>=3D3B >= > >=3D3B=3D3D20
>=3D > >> >=3D3B >=3D3B>=3D3B >=3D3B The most recent archives I have for Linu= > >x are:
&=3D > >> >gt=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B &g= > >t=3D3B cm3-min-POSIX-=3D > >> >LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D3D20
>=3D3B >=3D3B&g= > >t=3D3B >=3D > >> >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B >=3D3B And they don't seem t= > >o work on this =3D > >> >system: I can compile a program
>=3D3B >=3D3B>=3D3B >=3D3B bu= > >t when I tr=3D > >> >y to run it=3D3D2C it says "Segmentation fault". Can anyone
>=3D3B = > >>=3D3B&=3D > >> >gt=3D3B >=3D3B help? (My understanding is that I need 5.5.1 or later..= > >.)
&=3D > >> >gt=3D3B >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B &g= > >t=3D3B Mika
>=3D3B=3D > >> > >=3D3B>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B>=3D3B=3D3D20 >>>=3D3B >=3D3B
&=3D > >> >gt=3D3B >=3D3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>=3D3B >= > >=3D3BConten=3D > >> >t-Type: text/html=3D3B charset=3D3D"iso-8859-1"
>=3D3B >=3D3BCont= > >ent-Transfe=3D > >> >r-Encoding: quoted-printable
>=3D3B >=3D3B
>=3D3B >=3D3B&l= > >t=3D3Bhtml>=3D > >> >=3D3B
>=3D3B >=3D3B<=3D3Bhead>=3D3B
>=3D3B >=3D3B<= > >=3D3Bstyle>=3D3B
&=3D > >> >gt=3D3B >=3D3B.hmmessage P
>=3D3B >=3D3B{
>=3D3B >=3D3Bm= > >argin:0px=3D3D3B<=3D > >> >BR>>=3D3B >=3D3Bpadding:0px
>=3D3B >=3D3B}
>=3D3B >=3D= > >3Bbody.hmmessag=3D > >> >e
>=3D3B >=3D3B{
>=3D3B >=3D3Bfont-size: 10pt=3D3D3B
&g= > >t=3D3B >=3D3Bfo=3D > >> >nt-family:Verdana
>=3D3B >=3D3B}
>=3D3B >=3D3B<=3D3B/sty= > >le>=3D3B
&=3D > >> >gt=3D3B >=3D3B<=3D3B/head>=3D3B
>=3D3B >=3D3B<=3D3Bbody c= > >lass=3D3D3D'hmmessa=3D > >> >ge'>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BA href=3D3D3= > >D"http://modula3.=3D > >> >elegosoft.com/cm3/uploaded-archives" targ=3D3D
>=3D3B >=3D3Bet=3D= > >3D3D_blank&=3D > >> >gt=3D3B<=3D3BFONT color=3D3D3D#0068cf>=3D3Bhttp://modula3.elegosoft.= > >com/cm3/upl=3D > >> >oaded=3D3D
>=3D3B >=3D3B-archives<=3D3B/FONT>=3D3B<=3D3B/A&= > >gt=3D3B<=3D3BBR&g=3D > >> >t=3D3B
>=3D3B >=3D3B?<=3D3BBR>=3D3B
>=3D3B >=3D3B&= > >=3D3Bnbsp=3D3D3B<=3D3B=3D > >> >BR>=3D3B
>=3D3B >=3D3BI can make another later this week.<=3D= > >3BBR>=3D3B<=3D > >> >BR>>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
>=3D3B &= > >gt=3D3BAll you need=3D > >> > is a working cm3 on any system.<=3D3BBR>=3D3B
>=3D3B >=3D3B&= > >gt=3D3BFrom t=3D > >> >here you can build the whole system=3D3D2C targeting any system.<=3D3B= > >BR>=3D > >> >=3D3B
>=3D3B >=3D3BAs long as that cm3 understands LONGINT and yo= > >ur target=3D > >> > system.<=3D3BBR>=3D3B
>=3D3B >=3D3BAnd it is easier=3D3D2C b= > >ut not necess=3D > >> >ary=3D3D2C if you have Python. :)<=3D3BBR>=3D3B
>=3D3B >=3D3B= > >&=3D3Bnbsp=3D > >> >=3D3D3B<=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B- Jay&= > >lt=3D3BBR>=3D3B<=3D > >> >=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B = > >Date: Tue=3D3D2C 31 M=3D > >> >ar 2009 15:43:41 -=3D3D
>=3D3B >=3D3B0500<=3D3BBR>=3D3B&= > >=3D3Bgt=3D3D3B From=3D > >> >: martinbishop at bellsouth.net<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B To: mik= > >a at async.ca=3D > >> >=3D3D
>=3D3B >=3D3Bltech.edu<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B = > >CC: m3devel at elego=3D > >> >soft.com<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Subject: Re: [M3dev=3D3D >>>=3D3B >=3D > >> >=3D3Bel] Help finding CM3 compiler for Linux?<=3D3BBR>=3D3B&=3D3B= > >gt=3D3D3B <=3D > >> >=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Not sure if t=3D3D
>=3D3B >=3D3= > >Bhis helps=3D3D2C b=3D > >> >ut on my linux system:<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B <=3D3BBR>= > >=3D3B&=3D3Bgt=3D > >> >=3D3D3B Critical Mass Mod=3D3D
>=3D3B >=3D3Bula-3 version d5.7.0&= > >lt=3D3BBR>=3D > >> >=3D3B&=3D3Bgt=3D3D3B last updated: 2008-03-16<=3D3BBR>=3D3B&= > >=3D3Bgt=3D3D3B comp=3D > >> >iled:=3D3D
>=3D3B >=3D3B 2008-08-14 00:56:14<=3D3BBR>=3D3B&am= > >p=3D3Bgt=3D3D3B c=3D > >> >onfiguration: /usr/local/cm3/bin/cm3.cfg<=3D3BBR=3D3D
>=3D3B >= > >=3D3B>=3D3B&=3D > >> >amp=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B Linux thinkpad 2.= > >6.27-11-generic=3D > >> > #1 SMP Thu Jan 29 19:24=3D3D
>=3D3B >=3D3B:39 UTC 2009<=3D3BBR= > >>=3D3B&=3D > >> >=3D3Bgt=3D3D3B i686 GNU/Linux<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B <=3D= > >3BBR>=3D3B&=3D3B=3D > >> >gt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B I don=3D3D
>=3D3B &g= > >t=3D3B't have the c=3D > >> >m3 tarball=3D3D2C but I do have the sources in cm3/ still.<=3D3BBR>= > >=3D3B&=3D > >> >=3D3Bgt=3D3D
>=3D3B >=3D3B=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt= > >=3D3D3B Mika Nystrom wr=3D > >> >ote:<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B Hello everyo= > >ne=3D3D2C<=3D3BBR=3D > >> >>=3D3B&=3D3Bg=3D3D
>=3D3B >=3D3Bt=3D3D3B &=3D3Bgt=3D3D3B = > ><=3D3BBR>=3D3B&=3D > >> >=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B This is=3D3D2C for me=3D3D2C a most un= > >fortunate time =3D > >> >=3D3D
>=3D3B >=3D3Bfor the CM3 servers to<=3D3BBR>=3D3B&= > >=3D3Bgt=3D3D3B &=3D > >> >=3D3Bgt=3D3D3B have crashed. I'm teaching a class =3D3D
>=3D3B >= > >=3D3Busing Mod=3D > >> >ula-3=3D3D2C and we need a<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3B= > >gt=3D3D3B compile=3D > >> >r... here's the una=3D3D
>=3D3B >=3D3Bme of the system I'm trying= > > to use:&=3D > >> >lt=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3= > >B&=3D3Bgt=3D3D3B &am=3D > >> >p=3D3Bgt=3D3D3B Linu=3D3D
>=3D3B >=3D3Bx lara 2.6.24ugcs1 #4 SMP = > >Mon Feb 11 10=3D > >> >:53:03 PST 2008 i686 GNU/Linux<=3D3BBR>=3D3B&=3D3Bg=3D3D
>= > >=3D3B >=3D3Bt=3D > >> >=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3= > >Bgt=3D3D3B The most r=3D > >> >ecent archives I have for Linux are=3D3D
>=3D3B >=3D3B:<=3D3BBR= > >>=3D3B&=3D > >> >=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &= > >amp=3D3Bgt=3D3D3B cm3-m=3D > >> >in-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D3D
>=3D3B >=3D3B-src-all-5.4.= > >0.tgz <=3D > >> =3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B <=3D3BBR>=3D3B&a= > >mp=3D3Bgt=3D3D3B &=3D > >> >=3D3Bgt=3D3D3B And they don't seem =3D3D
>=3D3B >=3D3Bto work on = > >this system: =3D > >> >I can compile a program<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt= > >=3D3D3B but when=3D > >> > I=3D3D
>=3D3B >=3D3B try to run it=3D3D2C it says "Segmentation = > >fault". Can=3D > >> > anyone<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D3B=3D3D
&= > >gt=3D3B >=3D3B help=3D > >> >? (My understanding is that I need 5.5.1 or later...)<=3D3BBR>=3D3B&= > >amp=3D3Bg=3D > >> >t=3D3D3B &=3D3Bgt=3D3D3B=3D3D
>=3D3B >=3D3B <=3D3BBR>=3D3B= > >&=3D3Bgt=3D3D3B &=3D > >> >=3D3Bgt=3D3D3B Mika<=3D3BBR>=3D3B&=3D3Bgt=3D3D3B &=3D3Bgt=3D3D= > >3B <=3D3BBR>=3D3B&a=3D > >> >mp=3D3Bgt=3D3D3B <=3D3BBR>=3D3B<=3D3B/body>=3D3B
>=3D3B >= > >=3D3B<=3D3B/html>=3D > >> >=3D3B=3D3D
>=3D3B >=3D3B
>=3D3B >=3D3B--_806446ae-8d10-4d7= > >4-8eea-51aa365e=3D > >> >9204_--
> >> >=3D > >> > > >> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_-- > > > >--_55339e45-8c85-4ab6-9440-0d2131bbad69_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >Maybe not.
> >Hm. That is bug. There is use with a cvs tree=2C and use without.
> >I must have broken use without.
> > =3B
> >Try this:
> >export CM3_ROOT=3Droot of cm3 cvs (for me this is /dev2/cm3=2C
> >for you=2C maybe $HOME/cm3?)
> >rm =3B$HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/LINUXLIBC6
> ># *Common and *common in one command
rm =3B$HOME/cm3/cm3-min-LINUXLI= > >BC6-d5.7.0/bin/*ommon
cp root of cm3 cvs/m3-sys/cminstall/src/config/cm3= > >.cfg $HOME/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin
> > =3B
> >The .cfg will delegate out to the cvs tree.
> >I don't like having two copies of files..having to keep them in sync..
> > =3BThough the archives are meant to work standalone=2C without CVS. >> > > =3B But I don't test that so much oops sorry.
> >That /might/ not be the right file=2C but it is close.
> > =3B
> > =3B- Jay

 =3B
>=3B To: jay.krell at cornell.edu
>=3B= > > CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] Help finding CM= > >3 compiler for Linux?
>=3B Date: Tue=2C 31 Mar 2009 22:59:18 -0700 >>>=3B From: mika at async.caltech.edu
>=3B
>=3B
>=3B Is the= > >re any documentation for this format beyond what you just
>=3B wrote? = > >Where?
>=3B
>=3B terpsichore-14: cm3
>=3B --- building in .= > >./LINUXLIBC6 ---
>=3B
>=3B new source ->=3B compiling Main.m3<= > >BR>>=3B "/afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.co= > >mmon"=2C line 169: quake runtime error: undefined variable: ROOT
>=3B = > >
>=3B --procedure-- -line- -file---
>=3B GetM3Back 169 /afs/.ugcs= > >/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/cm3cfg.common
>=3B _IsM3B= > >ackFlagSupported 181 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin= > >/Unix.common
>=3B IsM3BackFlagSupported 193 /afs/.ugcs/user/mika/cm3/c= > >m3-min-LINUXLIBC6-d5.7.0/bin/Unix.common
>=3B GetM3BackFlag 197 /afs/.= > >ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.common
>=3B m3_b= > >ackend 62 /afs/.ugcs/user/mika/cm3/cm3-min-LINUXLIBC6-d5.7.0/bin/Unix.commo= > >n
>=3B program -- <=3Bbuiltin>=3B
>=3B 6 /afs/.ugcs.caltech.e= > >du/user/mika/test/LINUXLIBC6/m3make.args
>=3B
>=3B
>=3B Fa= > >tal Error: procedure "m3_backend" defined in "/afs/.ugcs/user/mika/cm3/cm3-= > >min-LINUXLIBC6-d5.7.0/bin/cm3.cfg" failed.
>=3B
>=3B Jay writes:= > >
>=3B >=3B--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_
>=3B >=3BC= > >ontent-Type: text/plain=3B charset=3D"iso-8859-1"
>=3B >=3BContent-T= > >ransfer-Encoding: quoted-printable
>=3B >=3B
>=3B >=3B
>= > >=3B >=3BThese archives do have a different format=3D2C yes.
>=3B >= > >=3B
>=3B >=3BBut it isn't a bad format.
>=3B >=3B
>=3B &= > >gt=3Bcminstall is pretty worthless imho.
>=3B >=3B
>=3B >=3BE= > >xtract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.
>=3B >=3B
&= > >gt=3B >=3B=3D20
>=3B >=3B
>=3B >=3B - Jay
>=3B >=3B<= > >BR>>=3B >=3B=3D20
>=3B >=3B>=3B To: jay.krell at cornell.edu
&= > >gt=3B >=3B>=3B Subject: Re: [M3devel] Help finding CM3 compiler for Lin= > >ux?=3D20
>=3B >=3B>=3B Date: Tue=3D2C 31 Mar 2009 15:56:11 -0700 >R>>=3B >=3B>=3B From: mika at async.caltech.edu
>=3B >=3B>=3B= > >=3D20
>=3B >=3B>=3B No=3D2C I'm sorry...
>=3B >=3B>=3B=3D= > >20
>=3B >=3B>=3B the archives do not have the usual format. I'm ex= > >pecting to unpack
>=3B >=3B>=3B and run "cminstall" and then unpac= > >k the big source tar on top and=3D20
>=3B >=3B>=3B build that. But= > > there's no cminstall in the archive on this page.
>=3B >=3B>=3B T= > >his is "the normal procedure" for installing CM3=3D2C no? It's what
>= > >=3B >=3B>=3B the instructions say to do=3D2C as well...
>=3B >= > >=3B>=3B=3D20
>=3B >=3B>=3B And the link from the "Download" page= > > is broken (to -d5.5.0.tgz).
>=3B >=3B>=3B=3D20
>=3B >=3B&g= > >t=3B Mika
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B Jay writes: >>>=3B >=3B>=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>= > >=3B >=3B>=3B >=3BContent-Type: text/plain=3D3B charset=3D3D"iso-8859-= > >1"
>=3B >=3B>=3B >=3BContent-Transfer-Encoding: quoted-printable= > >
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B
>=3B >= > >=3B>=3B >=3B http://modula3.elegosoft.com/cm3/uploaded-archives
>= > >=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B?
>=3B >=3B>= > >=3B >=3B
>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >= > >=3B
>=3B >=3B>=3B >=3BI can make another later this week.
>= > >=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B=3D3D20
>=3B >= > >=3B>=3B >=3B
>=3B >=3B>=3B >=3BAll you need is a working cm3= > > on any system.
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B= > >>=3BFrom there you can build the whole system=3D3D2C targeting any system= > >.
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3BAs long as tha= > >t cm3 understands LONGINT and your target system.
>=3B >=3B>=3B &g= > >t=3B
>=3B >=3B>=3B >=3BAnd it is easier=3D3D2C but not necessary= > >=3D3D2C if you have Python. :)
>=3B >=3B>=3B >=3B
>=3B >= > >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B
>=3B >=3B>= > >=3B >=3B - Jay
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >= > >=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Date: Tue=3D3D2C 31 Mar 2009= > > 15:43:41 -0500
>=3B >=3B>=3B >=3B>=3B From: martinbishop at bell= > >south.net
>=3B >=3B>=3B >=3B>=3B To: mika at async.caltech.edu >>>=3B >=3B>=3B >=3B>=3B CC: m3devel at elegosoft.com
>=3B >= > >=3B>=3B >=3B>=3B Subject: Re: [M3devel] Help finding CM3 compiler for= > > Linux?
>=3B >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B &= > >gt=3B>=3B Not sure if this helps=3D3D2C but on my linux system:
>=3B= > > >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Criti= > >cal Mass Modula-3 version d5.7.0
>=3B >=3B>=3B >=3B>=3B last u= > >pdated: 2008-03-16
>=3B >=3B>=3B >=3B>=3B compiled: 2008-08-14= > > 00:56:14
>=3B >=3B>=3B >=3B>=3B configuration: /usr/local/cm3= > >/bin/cm3.cfg
>=3B >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>= > >=3B >=3B>=3B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:3= > >9 UTC 2009
>=3B >=3B>=3B >=3B>=3B i686 GNU/Linux
>=3B >= > >=3B>=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B=3D3D20 >>>=3B >=3B>=3B >=3B>=3B I don't have the cm3 tarball=3D3D2C but I= > > do have the sources in cm3/ st=3D
>=3B >=3Bill.
>=3B >=3B>= > >=3B >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B Mika Nystrom wr= > >ote:
>=3B >=3B>=3B >=3B>=3B >=3B Hello everyone=3D3D2C
&g= > >t=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B&= > >gt=3B >=3B This is=3D3D2C for me=3D3D2C a most unfortunate time for the C= > >M3 servers=3D
>=3B >=3B to
>=3B >=3B>=3B >=3B>=3B >= > >=3B have crashed. I'm teaching a class using Modula-3=3D3D2C and we need a<= > >BR>>=3B >=3B>=3B >=3B>=3B >=3B compiler... here's the uname of = > >the system I'm trying to use:
>=3B >=3B>=3B >=3B>=3B >=3B=3D= > >3D20
>=3B >=3B>=3B >=3B>=3B >=3B Linux lara 2.6.24ugcs1 #4 S= > >MP Mon Feb 11 10:53:03 PST 2008 i686 GNU/=3D
>=3B >=3BLin=3D3D
&g= > >t=3B >=3B>=3B >=3Bux
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D2= > >0
>=3B >=3B>=3B >=3B>=3B >=3B The most recent archives I hav= > >e for Linux are:
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>= > >=3B >=3B>=3B >=3B>=3B >=3B cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3= > >-src-all-5.4.0.tgz=3D3D20
>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20= > >
>=3B >=3B>=3B >=3B>=3B >=3B And they don't seem to work on = > >this system: I can compile a program
>=3B >=3B>=3B >=3B>=3B &g= > >t=3B but when I try to run it=3D3D2C it says "Segmentation fault". Can anyo= > >=3D
>=3B >=3Bne
>=3B >=3B>=3B >=3B>=3B >=3B help? (My= > > understanding is that I need 5.5.1 or later...)
>=3B >=3B>=3B >= > >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >=3B>=3B >=3B Mika
= > >>=3B >=3B>=3B >=3B>=3B >=3B=3D3D20
>=3B >=3B>=3B >= > >=3B>=3B=3D3D20
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >= > >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_
>=3B >=3B>=3B >=3BCo= > >ntent-Type: text/html=3D3B charset=3D3D"iso-8859-1"
>=3B >=3B>=3B = > >>=3BContent-Transfer-Encoding: quoted-printable
>=3B >=3B>=3B &g= > >t=3B
>=3B >=3B>=3B >=3B<=3Bhtml>=3B
>=3B >=3B>=3B &= > >gt=3B<=3Bhead>=3B
>=3B >=3B>=3B >=3B<=3Bstyle>=3B
>= > >=3B >=3B>=3B >=3B.hmmessage P
>=3B >=3B>=3B >=3B{
>= > >=3B >=3B>=3B >=3Bmargin:0px=3D3D3B
>=3B >=3B>=3B >=3Bpaddi= > >ng:0px
>=3B >=3B>=3B >=3B}
>=3B >=3B>=3B >=3Bbody.hmm= > >essage
>=3B >=3B>=3B >=3B{
>=3B >=3B>=3B >=3Bfont-siz= > e: 10pt=3D3D3B
>=3B >=3B>=3B >=3Bfont-family:Verdana
>=3B &= > >gt=3B>=3B >=3B}
>=3B >=3B>=3B >=3B<=3B/style>=3B
>= > >=3B >=3B>=3B >=3B<=3B/head>=3B
>=3B >=3B>=3B >=3B<= > >=3Bbody class=3D3D3D'hmmessage'>=3B
>=3B >=3B>=3B >=3B&=3Bn= > >bsp=3D3D3B<=3BA href=3D3D3D"http://modula3.elegosoft.com/cm3/uploaded-arc= > >hive=3D
>=3B >=3Bs" targ=3D3D
>=3B >=3B>=3B >=3Bet=3D3D3D= > >_blank>=3B<=3BFONT color=3D3D3D#0068cf>=3Bhttp://modula3.elegosoft.co= > >m/cm3/u=3D
>=3B >=3Bploaded=3D3D
>=3B >=3B>=3B >=3B-archi= > >ves<=3B/FONT>=3B<=3B/A>=3B<=3BBR>=3B
>=3B >=3B>=3B >= > >=3B?<=3BBR>=3B
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR&= > >gt=3B
>=3B >=3B>=3B >=3BI can make another later this week.<= > >=3BBR>=3B
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B >R>>=3B >=3B>=3B >=3BAll you need is a working cm3 on any system.<= > >=3BBR>=3B
>=3B >=3B>=3B >=3B>=3BFrom there you can build the= > > whole system=3D3D2C targeting any system.<=3BBR=3D
>=3B >=3B>= > >=3B
>=3B >=3B>=3B >=3BAs long as that cm3 understands LONGINT an= > >d your target system.<=3BBR>=3B
>=3B >=3B>=3B >=3BAnd it is = > >easier=3D3D2C but not necessary=3D3D2C if you have Python. :)<=3BBR>=3B= > >
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B
>=3B &g= > >t=3B>=3B >=3B&=3Bnbsp=3D3D3B- Jay<=3BBR>=3B<=3BBR>=3B&=3B= > >nbsp=3D3D3B<=3BBR>=3B&=3Bgt=3D3D3B Date: Tue=3D3D2C 31 Mar 2009=3D >R>>=3B >=3B 15:43:41 -=3D3D
>=3B >=3B>=3B >=3B0500<=3BBR&g= > >t=3B&=3Bgt=3D3D3B From: martinbishop at bellsouth.net<=3BBR>=3B&=3Bg= > >t=3D3D3B To: mika at a=3D
>=3B >=3Bsync.ca=3D3D
>=3B >=3B>=3B = > >>=3Bltech.edu<=3BBR>=3B&=3Bgt=3D3D3B CC: m3devel at elegosoft.com<= > >=3BBR>=3B&=3Bgt=3D3D3B Subject: Re:=3D
>=3B >=3B [M3dev=3D3D >>>=3B >=3B>=3B >=3Bel] Help finding CM3 compiler for Linux?<=3BBR= > >>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B Not su=3D
>=3B &= > >gt=3Bre if t=3D3D
>=3B >=3B>=3B >=3Bhis helps=3D3D2C but on my l= > >inux system:<=3BBR>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B C= > >ritical=3D
>=3B >=3B Mass Mod=3D3D
>=3B >=3B>=3B >=3Bula-= > >3 version d5.7.0<=3BBR>=3B&=3Bgt=3D3D3B last updated: 2008-03-16<= > >=3BBR>=3B&=3Bgt=3D3D3B co=3D
>=3B >=3Bmpiled:=3D3D
>=3B &g= > >t=3B>=3B >=3B 2008-08-14 00:56:14<=3BBR>=3B&=3Bgt=3D3D3B configu= > >ration: /usr/local/cm3/bin/cm3.c=3D
>=3B >=3Bfg<=3BBR=3D3D
>= > >=3B >=3B>=3B >=3B>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3= > >B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 2=3D
>=3B >=3B9 19= > >:24=3D3D
>=3B >=3B>=3B >=3B:39 UTC 2009<=3BBR>=3B&=3Bgt= > >=3D3D3B i686 GNU/Linux<=3BBR>=3B&=3Bgt=3D3D3B <=3BBR>=3B&=3Bg= > >t=3D3D3B <=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3D3B I don=3D3D
&= > >gt=3B >=3B>=3B >=3B't have the cm3 tarball=3D3D2C but I do have the s= > >ources in cm3/ still.<=3BBR=3D
>=3B >=3B>=3B&=3Bgt=3D3D
&g= > >t=3B >=3B>=3B >=3B=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B Mika Nystrom= > > wrote:<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B Hello everyo=3D
&= > >gt=3B >=3Bne=3D3D2C<=3BBR>=3B&=3Bg=3D3D
>=3B >=3B>=3B >= > >=3Bt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3= > >B This is=3D3D2C for me=3D3D2C a most un=3D
>=3B >=3Bfortunate time = > >=3D3D
>=3B >=3B>=3B >=3Bfor the CM3 servers to<=3BBR>=3B&= > >=3Bgt=3D3D3B &=3Bgt=3D3D3B have crashed. I'm teaching a=3D
>=3B >= > >=3B class =3D3D
>=3B >=3B>=3B >=3Busing Modula-3=3D3D2C and we n= > >eed a<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B compiler... here'=3D >R>>=3B >=3Bs the una=3D3D
>=3B >=3B>=3B >=3Bme of the system= > > I'm trying to use:<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B <=3BBR= > >>=3B&=3Bgt=3D3D3B &=3Bg=3D
>=3B >=3Bt=3D3D3B Linu=3D3D
&g= > >t=3B >=3B>=3B >=3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2= > >008 i686 GNU/Linux<=3BBR=3D
>=3B >=3B>=3B&=3Bg=3D3D
>=3B= > > >=3B>=3B >=3Bt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3= > >B &=3Bgt=3D3D3B The most recent archives I have fo=3D
>=3B >=3Br = > >Linux are=3D3D
>=3B >=3B>=3B >=3B:<=3BBR>=3B&=3Bgt=3D3D3B= > > &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B cm3-min-P= > OSIX-LINUXLIBC6-5.=3D
>=3B >=3B4.0.tgz cm3=3D3D
>=3B >=3B>= > >=3B >=3B-src-all-5.4.0.tgz <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3= > >B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B And they =3D
>=3B &g= > >t=3Bdon't seem =3D3D
>=3B >=3B>=3B >=3Bto work on this system: I= > > can compile a program<=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B but= > >=3D
>=3B >=3B when I=3D3D
>=3B >=3B>=3B >=3B try to run i= > >t=3D3D2C it says "Segmentation fault". Can anyone<=3BBR>=3B&=3Bgt=3D= > >3D3B=3D
>=3B >=3B &=3Bgt=3D3D3B=3D3D
>=3B >=3B>=3B >= > >=3B help? (My understanding is that I need 5.5.1 or later...)<=3BBR>=3B= > >&=3Bgt=3D3D3B &=3B=3D
>=3B >=3Bgt=3D3D3B=3D3D
>=3B >=3B= > >>=3B >=3B <=3BBR>=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B Mika<=3BBR&= > >gt=3B&=3Bgt=3D3D3B &=3Bgt=3D3D3B <=3BBR>=3B&=3Bgt=3D3D3B <= > >=3BBR>=3B<=3B/body=3D
>=3B >=3B>=3B
>=3B >=3B>=3B >= > >=3B<=3B/html>=3B=3D3D
>=3B >=3B>=3B >=3B
>=3B >=3B>= > >=3B >=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_--
>=3B >=3B
&g= > >t=3B >=3B--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_
>=3B >=3BContent= > >-Type: text/html=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer= > >-Encoding: quoted-printable
>=3B >=3B
>=3B >=3B<=3Bhtml>= > >=3B
>=3B >=3B<=3Bhead>=3B
>=3B >=3B<=3Bstyle>=3B
&= > >gt=3B >=3B.hmmessage P
>=3B >=3B{
>=3B >=3Bmargin:0px=3D3B<= > >BR>>=3B >=3Bpadding:0px
>=3B >=3B}
>=3B >=3Bbody.hmmessag= > >e
>=3B >=3B{
>=3B >=3Bfont-size: 10pt=3D3B
>=3B >=3Bfo= > >nt-family:Verdana
>=3B >=3B}
>=3B >=3B<=3B/style>=3B
&= > >gt=3B >=3B<=3B/head>=3B
>=3B >=3B<=3Bbody class=3D3D'hmmessa= > >ge'>=3B
>=3B >=3BThese archives do have a different format=3D2C ye= > >s.<=3BBR>=3B
>=3B >=3BBut it isn't a bad format.<=3BBR>=3B >R>>=3B >=3Bcminstall is pretty worthless imho.<=3BBR>=3B
>=3B = > >>=3BExtract=3D2C rename=3D2C set PATH and LD_LIBRARY_PATH.<=3BBR>=3B<= > >BR>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp= > >=3D3B- Jay<=3BBR>=3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3B&=3B= > >gt=3D3B To: jay.krell at cornell.edu<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B = > >>=3B Subject: Re: [M3devel] Help finding CM3 compiler for Linux? <=3BBR= > >>=3B&=3Bgt=3D3B Dat=3D
>=3B >=3Be: Tue=3D2C 31 Mar 2009 15:56:1= > >1 -0700<=3BBR>=3B&=3Bgt=3D3B From: mika at async.caltech.edu=3D
>= > >=3B >=3B<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B No=3D2C= > > I'm sorry...<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B the = > >archives =3D
>=3B >=3Bdo not have the usual format. I'm expecting to= > > unpack<=3BBR>=3B&=3Bgt=3D3B and run "cm=3D
>=3B >=3Binstall"= > > and then unpack the big source tar on top and <=3BBR>=3B&=3Bgt=3D3B= > > build tha=3D
>=3B >=3Bt. But there's no cminstall in the archive on= > > this page.<=3BBR>=3B&=3Bgt=3D3B This is =3D
>=3B >=3B"the no= > >rmal procedure" for installing CM3=3D2C no? It's what<=3BBR>=3B&=3Bg= > >t=3D3B the in=3D
>=3B >=3Bstructions say to do=3D2C as well...<=3B= > >BR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B And the link from t=3D<= > >BR>>=3B >=3Bhe "Download" page is broken (to -d5.5.0.tgz).<=3BBR>= > >=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Mika<=3BBR=3D
>=3B &g= > >t=3B>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Jay writes:<=3BBR&g= > >t=3B&=3Bgt=3D3B &=3Bgt=3D3B--_806446ae-8d10-4d74-8eea-5=3D
>=3B = > >>=3B1aa365e9204_<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BContent-Type: = > >text/plain=3D3B charset=3D3D"iso-885=3D
>=3B >=3B9-1"<=3BBR>=3B&= > >amp=3Bgt=3D3B &=3Bgt=3D3BContent-Transfer-Encoding: quoted-printable<= > >=3BBR>=3B&=3Bgt=3D3B =3D
>=3B >=3B&=3Bgt=3D3B<=3BBR>=3B&= > >amp=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B htt= > >p://modula3.elegosoft.com/cm3/u=3D
>=3B >=3Bploaded-archives<=3BBR= > >>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= > >=3D3B?<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D= > >
>=3B >=3B=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &a= > >mp=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BI can make another l= > >ater t=3D
>=3B >=3Bhis week.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= > >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&= > >=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >=3B &= > >amp=3Bgt=3D3BAll you need is a working cm3 on any system.<=3BBR>=3B&= > >=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &= > >amp=3Bgt=3D3B&=3Bgt=3D3BFrom there you can build the whole system=3D3D2C= > > targeting an=3D
>=3B >=3By system.<=3BBR>=3B&=3Bgt=3D3B &= > >=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAs long as that cm3 un= > >derstands =3D
>=3B >=3BLONGINT and your target system.<=3BBR>=3B= > >&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAnd= > > it is =3D
>=3B >=3Beasier=3D3D2C but not necessary=3D3D2C if you ha= > >ve Python. :)<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3B=3D
>=3B= > > >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt= > >=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B - Jay<=3B= > >BR>=3B&=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B<=3BBR>=3B&= > >=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B= > >&=3Bgt=3D3B Date: Tue=3D3D2C 31 Mar 2009=3D
>=3B >=3B 15:43:41 -0= > >500<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B From: martinbi= > >shop at bellsouth.net<=3BBR>=3B=3D
>=3B >=3B&=3Bgt=3D3B &=3Bg= > >t=3D3B&=3Bgt=3D3B To: mika at async.caltech.edu<=3BBR>=3B&=3Bgt=3D3B= > > &=3Bgt=3D3B&=3Bgt=3D3B CC: m=3D
>=3B >=3B3devel at elegosoft.com= > ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B Subject: Re: [M3d= > >evel] Help fin=3D
>=3B >=3Bding CM3 compiler for Linux?<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bg= > >t=3D3B &=3Bgt=3D3B&=3Bg=3D
>=3B >=3Bt=3D3B Not sure if this he= > >lps=3D3D2C but on my linux system:<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= > >3B&=3Bg=3D
>=3B >=3Bt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &am= > >p=3Bgt=3D3B&=3Bgt=3D3B Critical Mass Modula-3 version d5.7.0<=3BBR>= > >=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B last upd= > >ated: 2008-03-16<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B c= > >ompiled=3D
>=3B >=3B: 2008-08-14 00:56:14<=3BBR>=3B&=3Bgt=3D3= > >B &=3Bgt=3D3B&=3Bgt=3D3B configuration: /usr/local/cm3/=3D
>=3B = > >>=3Bbin/cm3.cfg<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B= > >=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B Linux thin= > >kp=3D
>=3B >=3Bad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2= > >009<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bg=3D
>=3B >=3Bt= > >=3D3B i686 GNU/Linux<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D= > >3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20= > >=3D
>=3B >=3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D= > >3B I don't have the cm3 tarball=3D3D2C but I do have the=3D
>=3B >= > >=3B sources in cm3/ still.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B = > >=3D
>=3B >=3BMika Nystrom wrote:<=3BBR>=3B&=3Bgt=3D3B &=3B= > >gt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B Hello everyone=3D3D2C<=3BBR>=3B&am= > >p=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B= > >=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt= > >=3D3B This is=3D3D2C fo=3D
>=3B >=3Br me=3D3D2C a most unfortunate t= > >ime for the CM3 servers to<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B have crashed. I'm teaching a = > >class using Modula-3=3D3D2C and we n=3D
>=3B >=3Beed a<=3BBR>=3B= > >&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B compiler... here= > >'s the uname of the sys=3D
>=3B >=3Btem I'm trying to use:<=3BBR&g= > >t=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3B= > >BR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3B=3D
>=3B >=3Bgt=3D3B &am= > >p=3Bgt=3D3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i68= > >=3D
>=3B >=3B6 GNU/Lin=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= > >3Bux<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3= > >B=3D3D20<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &=3Bgt=3D3B&= > >=3Bgt=3D3B &=3Bgt=3D3B The most recent archives I have for Linux are:<= > >=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B = > >&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt= > >=3D3B &=3Bgt=3D3B cm3-min-POSIX-=3D
>=3B >=3BLINUXLIBC6-5.4.0.tgz= > > cm3-src-all-5.4.0.tgz=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&am= > >p=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B=3D3D20<=3BBR>=3B&=3Bg= > >t=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B And they don't seem to w= > >ork on this =3D
>=3B >=3Bsystem: I can compile a program<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B but when I tr= > >=3D
>=3B >=3By to run it=3D3D2C it says "Segmentation fault". Can an= > >yone<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3B=3D
>=3B >=3Bg= > >t=3D3B &=3Bgt=3D3B help? (My understanding is that I need 5.5.1 or later= > >...)<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bg= > >t=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Bgt=3D3B &=3Bgt=3D3B Mika<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >= > >=3B &=3Bgt=3D3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3B= > >gt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &am= > >p=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &=3Bgt=3D3B-= > >-_806446ae-8d10-4d74-8eea-51aa365e9204_<=3BBR>=3B&=3Bgt=3D3B &=3B= > >gt=3D3BConten=3D
>=3B >=3Bt-Type: text/html=3D3B charset=3D3D"iso-88= > >59-1"<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BContent-Transfe=3D
>= > >=3B >=3Br-Encoding: quoted-printable<=3BBR>=3B&=3Bgt=3D3B &=3Bg= > >t=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3Bhtml&=3Bg= > >t=3D
>=3B >=3B=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Blt=3D3Bhead&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Blt=3D3Bstyle&=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D= > >3B &=3Bgt=3D3B.hmmessage P<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B{&l= > >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bmargin:0px=3D3D3B<=3B=3D
>= > >=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bpadding:0px<=3BBR>=3B&am= > >p=3Bgt=3D3B &=3Bgt=3D3B}<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bbody.= > >hmmessag=3D
>=3B >=3Be<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B{&l= > >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfont-size: 10pt=3D3D3B<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3Bfo=3D
>=3B >=3Bnt-family:Verdana<= > >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B}<=3BBR>=3B&=3Bgt=3D3B &= > >=3Bgt=3D3B&=3Blt=3D3B/style&=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>= > >=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3B/head&=3Bgt=3D3B<=3BBR&g= > >t=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3Bbody class=3D3D3D'hmmessa=3D= > >
>=3B >=3Bge'&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= > >3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BA href=3D3D3D"http://modula3.=3D<= > >BR>>=3B >=3Belegosoft.com/cm3/uploaded-archives" targ=3D3D<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3Bet=3D3D3D_blank&=3B=3D
>=3B >=3Bg= > >t=3D3B&=3Blt=3D3BFONT color=3D3D3D#0068cf&=3Bgt=3D3Bhttp://modula3.el= > >egosoft.com/cm3/upl=3D
>=3B >=3Boaded=3D3D<=3BBR>=3B&=3Bgt=3D= > >3B &=3Bgt=3D3B-archives&=3Blt=3D3B/FONT&=3Bgt=3D3B&=3Blt=3D3B/A= > >&=3Bgt=3D3B&=3Blt=3D3BBR&=3Bg=3D
>=3B >=3Bt=3D3B<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3B?&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3B=3D= > >
>=3B >=3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3= > >BI can make another later this week.&=3Blt=3D3BBR&=3Bgt=3D3B<=3B=3D= > >
>=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp= > >=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= > >=3D3BAll you need=3D
>=3B >=3B is a working cm3 on any system.&= > >=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >=3Bgt=3D3BFrom t=3D
>=3B >=3Bhere you can build the whole system=3D3= > >D2C targeting any system.&=3Blt=3D3BBR&=3Bgt=3D
>=3B >=3B=3D3B= > ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAs long as that cm3 understands = > >LONGINT and your target=3D
>=3B >=3B system.&=3Blt=3D3BBR&=3Bg= > >t=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAnd it is easier=3D3D2C bu= > >t not necess=3D
>=3B >=3Bary=3D3D2C if you have Python. :)&=3Blt= > >=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp= > >=3D3Bnbsp=3D
>=3B >=3B=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR&= > >gt=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B- Jay&=3Blt= > >=3D3BBR&=3Bgt=3D3B&=3Blt=3D
>=3B >=3B=3D3BBR&=3Bgt=3D3B&= > >=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3= > >B Date: Tue=3D3D2C 31 M=3D
>=3B >=3Bar 2009 15:43:41 -=3D3D<=3BBR&= > >gt=3B&=3Bgt=3D3B &=3Bgt=3D3B0500&=3Blt=3D3BBR&=3Bgt=3D3B&=3B= > >amp=3D3Bgt=3D3D3B From=3D
>=3B >=3B: martinbishop at bellsouth.net&= > >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B To: mika at async.ca=3D
= > >>=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bltech.edu&= > >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B CC: m3devel at elego=3D
= > >>=3B >=3Bsoft.com&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B= > > Subject: Re: [M3dev=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D
>= > >=3B >=3B=3D3Bel] Help finding CM3 compiler for Linux?&=3Blt=3D3BBR&= > >=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D
>=3B >=3B=3D3BBR&= > >=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B Not sure if t=3D3D<=3BBR>=3B&=3Bg= > >t=3D3B &=3Bgt=3D3Bhis helps=3D3D2C b=3D
>=3B >=3But on my linux s= > >ystem:&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3B= > >BR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D
>=3B >=3B=3D3D3B Critical Mass = > >Mod=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bula-3 version d5.7.0&= > >=3Blt=3D3BBR&=3Bgt=3D
>=3B >=3B=3D3B&=3Bamp=3D3Bgt=3D3D3B last= > > updated: 2008-03-16&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B = > >comp=3D
>=3B >=3Biled:=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= > >3B 2008-08-14 00:56:14&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3= > >B c=3D
>=3B >=3Bonfiguration: /usr/local/cm3/bin/cm3.cfg&=3Blt=3D= > >3BBR=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B&=3B= > >=3D
>=3B >=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3B= > >amp=3D3Bgt=3D3D3B Linux thinkpad 2.6.27-11-generic=3D
>=3B >=3B #1 S= > >MP Thu Jan 29 19:24=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B:39 UTC = > >2009&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3= > >D3B i686 GNU/Linux&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &a= > >mp=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3B=3D
>=3B >=3Bgt=3D3D3B &a= > >mp=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B I don=3D3D<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3B't have the c=3D
>=3B >=3Bm3 tarball= > >=3D3D2C but I do have the sources in cm3/ still.&=3Blt=3D3BBR&=3Bgt= > >=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D<=3BBR>=3B&=3Bgt=3D3B= > > &=3Bgt=3D3B=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D= > >3B Mika Nystrom wr=3D
>=3B >=3Bote:&=3Blt=3D3BBR&=3Bgt=3D3B&am= > >p=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B Hello everyone=3D3D2C&=3B= > >lt=3D3BBR=3D
>=3B >=3B&=3Bgt=3D3B&=3Bamp=3D3Bg=3D3D<=3BBR>= > >=3B&=3Bgt=3D3B &=3Bgt=3D3Bt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt= > >=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D3B &=3Bam= > >p=3D3Bgt=3D3D3B This is=3D3D2C for me=3D3D2C a most unfortunate time =3D >>>=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfor the CM3 s= > >ervers to&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp= > >=3D
>=3B >=3B=3D3Bgt=3D3D3B have crashed. I'm teaching a class =3D3D= > ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Busing Mod=3D
>=3B >=3Bula= > >-3=3D3D2C and we need a&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D= > >3B &=3Bamp=3D3Bgt=3D3D3B compile=3D
>=3B >=3Br... here's the una= > >=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bme of the system I'm trying= > > to use:&=3B=3D
>=3B >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt= > >=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp= > >=3D3Bgt=3D3D3B &=3Bam=3D
>=3B >=3Bp=3D3Bgt=3D3D3B Linu=3D3D<=3B= > >BR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 1= > >0=3D
>=3B >=3B:53:03 PST 2008 i686 GNU/Linux&=3Blt=3D3BBR&=3Bg= > >t=3D3B&=3Bamp=3D3Bg=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bt=3D<= > >BR>>=3B >=3B=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt= > >=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B The most r=3D
>= > >=3B >=3Becent archives I have for Linux are=3D3D<=3BBR>=3B&=3Bgt= > >=3D3B &=3Bgt=3D3B:&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D
>=3B = > >>=3B=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3= > >B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B cm3-m=3D
>=3B >= > >=3Bin-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D3D<=3BBR>=3B&=3Bgt=3D3B &= > >=3Bgt=3D3B-src-all-5.4.0.tgz &=3Blt=3D
>=3B =3D3BBR&=3Bgt=3D3B&a= > >mp=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt= > >=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D3B = > >And they don't seem =3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bto work= > > on this system: =3D
>=3B >=3BI can compile a program&=3Blt=3D3BB= > >R&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt=3D3D3B but when= > >=3D
>=3B >=3B I=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B try = > >to run it=3D3D2C it says "Segmentation fault". Can=3D
>=3B >=3B anyo= > >ne&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D3Bgt= > >=3D3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B help=3D
>=3B &= > >gt=3B? (My understanding is that I need 5.5.1 or later...)&=3Blt=3D3BBR&= > >amp=3Bgt=3D3B&=3Bamp=3D3Bg=3D
>=3B >=3Bt=3D3D3B &=3Bamp=3D3Bgt= > >=3D3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B &=3Blt=3D3BBR&am= > >p=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Bamp=3D
>=3B >=3B=3D3Bgt= > >=3D3D3B Mika&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bgt=3D3D3B &=3Ba= > >mp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Ba=3D
>=3B >=3B= > >mp=3D3Bgt=3D3D3B &=3Blt=3D3BBR&=3Bgt=3D3B&=3Blt=3D3B/body&=3Bgt= > >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3B/html&=3Bg= > >t=3D
>=3B >=3B=3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= > >lt=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B--_806446ae-8d10-4d74-8eea-51aa36= > >5e=3D
>=3B >=3B9204_--<=3BBR>=3B<=3B/body>=3B
>=3B >= > >=3B<=3B/html>=3B=3D
>=3B >=3B
>=3B >=3B--_777fdc4e-3c29-4= > >0b4-a3dd-e6243f796cee_--
> >= > > > >--_55339e45-8c85-4ab6-9440-0d2131bbad69_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Apr 1 09:08:41 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 01 Apr 2009 00:08:41 -0700 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: Your message of "Wed, 01 Apr 2009 06:56:45 -0000." Message-ID: <200904010708.n3178fm8073790@camembert.async.caltech.edu> Crazily enough, this seems to have worked.... just had to add "-lpthread" to the LIBC libraries in the file. Oh and I had to make some libXaw symlinks to get your mentor binary to work---they seem to be on libXaw.so.7 now. (Yes I know new major #s shouldn't work, but it does seem to...) Thanks for tonight :-) Jay writes: >--_6a7b1519-a5fa-4142-b418-a208dc02c427_ ... > >You had a kind of working install from 5.4 and running its cminstall. > > cm3 ran but produced crashing binaries. > >=20 > >Take the cm3.cfg file from it and put it at. > ... From wagner at elegosoft.com Wed Apr 1 11:11:53 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 01 Apr 2009 11:11:53 +0200 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: <200904010559.n315xIBx071256@camembert.async.caltech.edu> References: <200904010559.n315xIBx071256@camembert.async.caltech.edu> Message-ID: <20090401111153.ul0hzu7nokc808sg@mail.elegosoft.com> Quoting Mika Nystrom : > > Is there any documentation for this format beyond what you just > wrote? Where? Well, yes, that's the problem with these kinds of archives: (1) they're not well tested and (2) there's no documentation user's can rely on This doesn't mean that I disapprove or want to criticise the contributors, but an official well-documented release with installation notes etc. has some advantages. Unfortunately, the official releases are really outdated now. I succeeded in building current AMD64_LINUX and FreeBSD4 installations on our servers for d5.7.1 tonight and was able to build archives for FreeBSD binaries and sources, but the tooling failed for AMD64_KINUX due to changed and missing configuration files. I'll need to have a closer look at that, some extensions seem to be needed. Anybody who feels he can do that faster than me is of course encouraged (I'll have little time as usual :-/). It may also turn out to be difficult to produce LINUXLIBC6 binaries, as birch and other Elego servers are now 64 bit machines, and trying to use current CM3 with --32 produced lots of assembler errors about unsupported instructions on this architecture. As the old installation on birch seems to be gone without a chance of being restored, it will probably be easiest to use a real 32 bit system and start from 5.4.0 again. Anybody who wants to help should be able to build the binary archives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh easily and upload them to birch at /var/www/modula3.elegosoft.com/cm3/uploaded-archives My guess is that tinderbox will take some time to run smoothly again, as it was highly customized, and I'm not sure if these customizations survied the crash. Please stay tuned and thanks for all your patience, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 1 11:22:58 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Apr 2009 09:22:58 +0000 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: <20090401111153.ul0hzu7nokc808sg@mail.elegosoft.com> References: <200904010559.n315xIBx071256@camembert.async.caltech.edu> <20090401111153.ul0hzu7nokc808sg@mail.elegosoft.com> Message-ID: Olaf, in the LINUXLIBC6 configuration, try putting --32 on the as/gas invocations. You mentioned --32 on cm3, but I wonder if you meant -m32 on cm3. cm3 -m32 as --32 or check the man pages or help. They aren't consistent, for more reasons than shown here (e.g. MIPS has -mabi64, and I think AIX has something else, and HP-UX gcc supports none of these -- no bi-arch support). > probably be easiest to use a real 32 bit system and start from 5.4.0 > again. Using any current system should be plenty easy too. e.g. the distributions I put up. :) AMD64_LINUX should be a good starting point, but I haven't tried it in a bit. I should be able to build a current LINUXLIBC6 very very soon. I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test a switch to the "new" Unix *.i3 files. I'll be using python/make-dist.py though. I do need to get more packages into it though, e.g. cm3ide and m3gdb. - Jay > Date: Wed, 1 Apr 2009 11:11:53 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > CC: mand at elego.de; m3-support at elego.de > Subject: Re: [M3devel] Help finding CM3 compiler for Linux? > > Quoting Mika Nystrom : > > > > > Is there any documentation for this format beyond what you just > > wrote? Where? > > Well, yes, that's the problem with these kinds of archives: > > (1) they're not well tested and > (2) there's no documentation user's can rely on > > This doesn't mean that I disapprove or want to criticise the contributors, > but an official well-documented release with installation notes etc. > has some advantages. Unfortunately, the official releases are really > outdated now. > > I succeeded in building current AMD64_LINUX and FreeBSD4 installations > on our servers for d5.7.1 tonight and was able to build archives for > FreeBSD binaries and sources, but the tooling failed for AMD64_KINUX > due to changed and missing configuration files. I'll need to have a > closer look at that, some extensions seem to be needed. Anybody who > feels he can do that faster than me is of course encouraged (I'll have > little time as usual :-/). > > It may also turn out to be difficult to produce LINUXLIBC6 binaries, > as birch and other Elego servers are now 64 bit machines, and trying > to use current CM3 with --32 produced lots of assembler errors about > unsupported instructions on this architecture. As the old installation > on birch seems to be gone without a chance of being restored, it will > probably be easiest to use a real 32 bit system and start from 5.4.0 > again. > > Anybody who wants to help should be able to build the binary > archives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh > easily and upload them to birch at > > /var/www/modula3.elegosoft.com/cm3/uploaded-archives > > My guess is that tinderbox will take some time to run smoothly again, > as it was highly customized, and I'm not sure if these customizations > survied the crash. > > Please stay tuned and thanks for all your patience, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Wed Apr 1 12:03:47 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 01 Apr 2009 12:03:47 +0200 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090331145127.GB9624@topoi.pooq.com> References: <20090331145127.GB9624@topoi.pooq.com> Message-ID: <20090401120347.x8cneize8oscg44o@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > The BottonVBT contains an action, which is a procedure rather than a > method. b This makes it awkward to subclass ButtonVBT becaue the action > will still expect its first parameter to be a ButtonVBT instead of > belonging to the subclass, and an explicit downcast of some sort will be > needed to acess the subclass's members. > > The Trestle manual says this was a deliberate decision: > > : The action procedure is a field rather than a method in order to allow > : buttons with different action procedures to share their method suites. > > I, however, find it massively inconvenient because it mans I have to > resort to downcasting or the very kludgey VBT.GetProp to access what > should be just there. I'd rather the action procedure was a method. > > But it should be possible to have the best of both worlds. Have an > action2 (better name wanted here) method that is available for > overriding, and by default calls the procedure in the existing action. > field. That action2 method wounl then be called by Trestle wherever > action is now called. > > Does anyone see problems with this? Sounds fine to me offhand. You should test your extensions with some of the existing larger applications, like mentor and Juno-2, of course. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 1 16:25:13 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Apr 2009 14:25:13 +0000 Subject: [M3devel] new Linux/x86 archives Message-ID: new Linux/x86 archives, the ones are version 5.7.1: http://modula3.elegosoft.com/cm3/uploaded-archives => http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-LINUXLIBC6-d5.7.1.tar.gz http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-LINUXLIBC6-d5.7.1.tar.lzma http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-LINUXLIBC6-d5.7.1.tar.gz http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-LINUXLIBC6-d5.7.1.tar.lzma The last one is still compressing/uploading (lzma compresses very slow, but compresses smallest and uncompressed fast or fastest.) notes: Mika's problem is fixed. (Jan 12: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cminstall/src/config-no-install/cm3cfg.common) Be sure to export PATH=installroot/bin:$PATH and LD_LIBRARY_PATH=installroot/lib or LD_LIBRARY_PATH=installroot/lib:$LD_LIBRARY_PATH Don't have Modula-3 .so files in /tmp/tmpdtNszn/... (objdump -x installroot/bin/mentor | grep PATH to see what I mean) A near future build should: not require setting either environment variable, nor look in /tmp. setting $PATH will be optional for convenience to find cm3, but cm3 won't use it to find cm3cg. Shared libs will be found via rpath=$ORIGIN/../lib. (Consensus that that is a good idea? Seems clear to me. $LD_LIBRARY_PATH should still either override or provide fallback, for uninstalled binaries or binaries installed elsewhere.) - Jay From hendrik at topoi.pooq.com Wed Apr 1 16:59:45 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 1 Apr 2009 10:59:45 -0400 Subject: [M3devel] new Linux/x86 archives In-Reply-To: References: Message-ID: <20090401145945.GA12017@topoi.pooq.com> On Wed, Apr 01, 2009 at 02:25:13PM +0000, Jay wrote: > > A near future build should: > not require setting either environment variable, nor look in /tmp. > setting $PATH will be optional for convenience to find cm3, > but cm3 won't use it to find cm3cg. > Shared libs will be found via rpath=$ORIGIN/../lib. Would this be problematic it $ORIGIN is a symbolic link? -- hendrik From vapier at gentoo.org Wed Apr 1 17:23:55 2009 From: vapier at gentoo.org (Mike Frysinger) Date: Wed, 1 Apr 2009 11:23:55 -0400 Subject: [M3devel] new Linux/x86 archives In-Reply-To: <20090401145945.GA12017@topoi.pooq.com> References: <20090401145945.GA12017@topoi.pooq.com> Message-ID: <200904011123.56014.vapier@gentoo.org> On Wednesday 01 April 2009 10:59:45 hendrik at topoi.pooq.com wrote: > On Wed, Apr 01, 2009 at 02:25:13PM +0000, Jay wrote: > > A near future build should: > > not require setting either environment variable, nor look in /tmp. > > setting $PATH will be optional for convenience to find cm3, > > but cm3 won't use it to find cm3cg. > > Shared libs will be found via rpath=$ORIGIN/../lib. > > Would this be problematic it $ORIGIN is a symbolic link? is that realistic ? you'd have to unpack the archive, move only ./bin/ somewhere, and then symlink it back in. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mika at async.caltech.edu Wed Apr 1 18:59:45 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 01 Apr 2009 09:59:45 -0700 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: Your message of "Wed, 01 Apr 2009 09:22:58 -0000." Message-ID: <200904011659.n31GxkMW094881@camembert.async.caltech.edu> I have to say that once I figured out what I needed to do, using Jay's distributions was easy---easier than I'm used to with CM3. All I had to do was: untar the -std dist (forget the min one). Set PATH and LD_LIBRARY_PATH And then---the mysterious part, which takes more than passing knowledge of how CM3 works---providing a cm3.cfg file, which doesn't seem to be provided at all by Jay's archive. It seems to me it would be quite easy to package this up, maybe even with cminstall? That would be easiest I think, to cminstall the whole dist rather than cminstalling just the -min and then making people build their own compiler, libraries, and demo apps... Mika Jay writes: >--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Olaf=2C in the LINUXLIBC6 configuration=2C try putting --32 on the as/gas i= >nvocations. > >You mentioned --32 on cm3=2C but I wonder if you meant -m32 on cm3. > > cm3 -m32=20 > > as --32=20 > >=20 > >or check the man pages or help. They aren't consistent=2C for more reasons = >than shown here (e.g. MIPS has -mabi64=2C and I think AIX has something els= >e=2C and HP-UX gcc supports none of these -- no bi-arch support). > >=20 > > > probably be easiest to use a real 32 bit system and start from 5.4.0 > > again. > > >Using any current system should be plenty easy too. > >e.g. the distributions I put up. :) > >=20 > >AMD64_LINUX should be a good starting point=2C but I haven't tried it in a = >bit. > >=20 > >I should be able to build a current LINUXLIBC6 very very soon. > >I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test= > a switch to the "new" Unix *.i3 files. > >=20 > >I'll be using python/make-dist.py though. > >I do need to get more packages into it though=2C e.g. cm3ide and m3gdb. > >=20 > > - Jay >=20 >> Date: Wed=2C 1 Apr 2009 11:11:53 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> CC: mand at elego.de=3B m3-support at elego.de >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >>=20 >> Quoting Mika Nystrom : >>=20 >> > >> > Is there any documentation for this format beyond what you just >> > wrote? Where? >>=20 >> Well=2C yes=2C that's the problem with these kinds of archives: >>=20 >> (1) they're not well tested and >> (2) there's no documentation user's can rely on >>=20 >> This doesn't mean that I disapprove or want to criticise the contributors= >=2C >> but an official well-documented release with installation notes etc. >> has some advantages. Unfortunately=2C the official releases are really >> outdated now. >>=20 >> I succeeded in building current AMD64_LINUX and FreeBSD4 installations >> on our servers for d5.7.1 tonight and was able to build archives for >> FreeBSD binaries and sources=2C but the tooling failed for AMD64_KINUX >> due to changed and missing configuration files. I'll need to have a >> closer look at that=2C some extensions seem to be needed. Anybody who >> feels he can do that faster than me is of course encouraged (I'll have >> little time as usual :-/). >>=20 >> It may also turn out to be difficult to produce LINUXLIBC6 binaries=2C >> as birch and other Elego servers are now 64 bit machines=2C and trying >> to use current CM3 with --32 produced lots of assembler errors about >> unsupported instructions on this architecture. As the old installation >> on birch seems to be gone without a chance of being restored=2C it will >> probably be easiest to use a real 32 bit system and start from 5.4.0 >> again. >>=20 >> Anybody who wants to help should be able to build the binary >> archives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh >> easily and upload them to birch at >>=20 >> /var/www/modula3.elegosoft.com/cm3/uploaded-archives >>=20 >> My guess is that tinderbox will take some time to run smoothly again=2C >> as it was highly customized=2C and I'm not sure if these customizations >> survied the crash. >>=20 >> Please stay tuned and thanks for all your patience=2C >>=20 >> Olaf >> --=20 >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 9= >5 >> http://www.elegosoft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berli= >n >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214= >194 >>=20 > >--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Olaf=2C in the LINUXLIBC6 configuration=2C try putting --32 on the as/gas i= >nvocations.
>You mentioned --32 on cm3=2C but I wonder if you meant -m32 on cm3.
> =3Bcm3 -m32
> =3Bas --32
> =3B
>or check the man pages or help. They aren't consistent=2C for more reasons = >than shown here (e.g. MIPS has -mabi64=2C and I think AIX has something els= >e=2C and HP-UX gcc supports none of these -- no bi-arch support).
> =3B
> =3B>=3B probably be easiest to use a real 32 bit system and start fr= >om 5.4.0
 =3B>=3B again.

>Using any current system should be plenty easy too.
>e.g. the distributions I put up. :)
> =3B
>AMD64_LINUX should be a good starting point=2C but I haven't tried it in a = >bit.
> =3B
>I should be able to build a current LINUXLIBC6 very very soon.
>I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test= > a switch to the "new" Unix *.i3 files.
> =3B
>I'll be using python/make-dist.py though.
>I do need to get more packages into it though=2C e.g. cm3ide and m3gdb.
> =3B
> =3B- Jay
 =3B
>=3B Date: Wed=2C 1 Apr 2009 11:11:53 +0200<= >BR>>=3B From: wagner at elegosoft.com
>=3B To: m3devel at elegosoft.com>>=3B CC: mand at elego.de=3B m3-support at elego.de
>=3B Subject: Re: [M3= >devel] Help finding CM3 compiler for Linux?
>=3B
>=3B Quoting Mi= >ka Nystrom <=3Bmika at async.caltech.edu>=3B:
>=3B
>=3B >=3B<= >BR>>=3B >=3B Is there any documentation for this format beyond what you= > just
>=3B >=3B wrote? Where?
>=3B
>=3B Well=2C yes=2C th= >at's the problem with these kinds of archives:
>=3B
>=3B (1) the= >y're not well tested and
>=3B (2) there's no documentation user's can = >rely on
>=3B
>=3B This doesn't mean that I disapprove or want to= > criticise the contributors=2C
>=3B but an official well-documented re= >lease with installation notes etc.
>=3B has some advantages. Unfortuna= >tely=2C the official releases are really
>=3B outdated now.
>=3B = >
>=3B I succeeded in building current AMD64_LINUX and FreeBSD4 install= >ations
>=3B on our servers for d5.7.1 tonight and was able to build ar= >chives for
>=3B FreeBSD binaries and sources=2C but the tooling failed= > for AMD64_KINUX
>=3B due to changed and missing configuration files. = I'll need to have a
>=3B closer look at that=2C some extensions seem t= >o be needed. Anybody who
>=3B feels he can do that faster than me is o= >f course encouraged (I'll have
>=3B little time as usual :-/).
>= >=3B
>=3B It may also turn out to be difficult to produce LINUXLIBC6 b= >inaries=2C
>=3B as birch and other Elego servers are now 64 bit machin= >es=2C and trying
>=3B to use current CM3 with --32 produced lots of as= >sembler errors about
>=3B unsupported instructions on this architectur= >e. As the old installation
>=3B on birch seems to be gone without a ch= >ance of being restored=2C it will
>=3B probably be easiest to use a re= >al 32 bit system and start from 5.4.0
>=3B again.
>=3B
>=3B= > Anybody who wants to help should be able to build the binary
>=3B arc= >hives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh
>=3B easily = >and upload them to birch at
>=3B
>=3B /var/www/modula3.elegosoft= >.com/cm3/uploaded-archives
>=3B
>=3B My guess is that tinderbox = >will take some time to run smoothly again=2C
>=3B as it was highly cus= >tomized=2C and I'm not sure if these customizations
>=3B survied the c= >rash.
>=3B
>=3B Please stay tuned and thanks for all your patien= >ce=2C
>=3B
>=3B Olaf
>=3B --
>=3B Olaf Wagner -- eleg= >o Software Solutions GmbH
>=3B Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C= > 13355 Berlin=2C Germany
>=3B phone: +49 30 23 45 86 96 mobile: +49 17= >7 2345 869 fax: +49 30 23 45 86 95
>=3B http://www.elegosoft.com | Ges= >ch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berlin
>=3B Handelregister: Amts= >gericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>=3B
dy> >= > >--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_-- From rodney.bates at wichita.edu Wed Apr 1 19:24:58 2009 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 01 Apr 2009 12:24:58 -0500 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: <20090331145127.GB9624@topoi.pooq.com> References: <20090331145127.GB9624@topoi.pooq.com> Message-ID: <49D3A36A.1030501@wichita.edu> hendrik at topoi.pooq.com wrote: > The BottonVBT contains an action, which is a procedure rather than a > method. b This makes it awkward to subclass ButtonVBT becaue the action > will still expect its first parameter to be a ButtonVBT instead of > belonging to the subclass, and an explicit downcast of some sort will be > needed to acess the subclass's members. > > The Trestle manual says this was a deliberate decision: > > : The action procedure is a field rather than a method in order to allow > : buttons with different action procedures to share their method suites. I don't understand the original reasoning. If 'action' were a method, you could create different buttons with overrides for 'action' but not override any other method and get exactly the same set of shared methods among the buttons as in the original design. What have I missed? > > I, however, find it massively inconvenient because it mans I have to > resort to downcasting or the very kludgey VBT.GetProp to access what > should be just there. I'd rather the action procedure was a method. > > But it should be possible to have the best of both worlds. Have an > action2 (better name wanted here) method that is available for > overriding, and by default calls the procedure in the existing action. > field. That action2 method wounl then be called by Trestle wherever > action is now called. > > Does anyone see problems with this? > > -- hendrik > Rodney Bates From mika at async.caltech.edu Wed Apr 1 19:33:01 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 01 Apr 2009 10:33:01 -0700 Subject: [M3devel] small design problem in ButtonVBT? In-Reply-To: Your message of "Wed, 01 Apr 2009 12:24:58 CDT." <49D3A36A.1030501@wichita.edu> Message-ID: <200904011733.n31HX1mO096260@camembert.async.caltech.edu> Seems a bit mysterious to me too but I wonder if it's not a way of getting the benefits of multiple inheritance. If you want method m1 from one set of VBTs V and method m2 from another set W, you can't inherit from both. But if the methods are instead procedure fields with the common supertype as the first argument, you can set the fields of X, m1 := V.M1, m2 := W.m2, even though X is a subtype of neither V nor W... You can probably use a design pattern to get something similar without using procedure fields, but that would involve introducing new types. Mika "Rodney M. Bates" writes: >hendrik at topoi.pooq.com wrote: >> The BottonVBT contains an action, which is a procedure rather than a >> method. b This makes it awkward to subclass ButtonVBT becaue the action >> will still expect its first parameter to be a ButtonVBT instead of >> belonging to the subclass, and an explicit downcast of some sort will be >> needed to acess the subclass's members. >> >> The Trestle manual says this was a deliberate decision: >> >> : The action procedure is a field rather than a method in order to allow >> : buttons with different action procedures to share their method suites. > >I don't understand the original reasoning. If 'action' were a method, you >could create different buttons with overrides for 'action' but not override >any other method and get exactly the same set of shared methods among the >buttons as in the original design. What have I missed? > >> >> I, however, find it massively inconvenient because it mans I have to >> resort to downcasting or the very kludgey VBT.GetProp to access what >> should be just there. I'd rather the action procedure was a method. >> >> But it should be possible to have the best of both worlds. Have an >> action2 (better name wanted here) method that is available for >> overriding, and by default calls the procedure in the existing action. >> field. That action2 method wounl then be called by Trestle wherever >> action is now called. >> >> Does anyone see problems with this? >> >> -- hendrik >> > >Rodney Bates From hendrik at topoi.pooq.com Wed Apr 1 22:34:32 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 1 Apr 2009 16:34:32 -0400 Subject: [M3devel] new Linux/x86 archives In-Reply-To: <200904011123.56014.vapier@gentoo.org> References: <20090401145945.GA12017@topoi.pooq.com> <200904011123.56014.vapier@gentoo.org> Message-ID: <20090401203432.GA12427@topoi.pooq.com> On Wed, Apr 01, 2009 at 11:23:55AM -0400, Mike Frysinger wrote: > On Wednesday 01 April 2009 10:59:45 hendrik at topoi.pooq.com wrote: > > On Wed, Apr 01, 2009 at 02:25:13PM +0000, Jay wrote: > > > A near future build should: > > > not require setting either environment variable, nor look in /tmp. > > > setting $PATH will be optional for convenience to find cm3, > > > but cm3 won't use it to find cm3cg. > > > Shared libs will be found via rpath=$ORIGIN/../lib. > > > > Would this be problematic it $ORIGIN is a symbolic link? > > is that realistic ? you'd have to unpack the archive, move only ./bin/ > somewhere, and then symlink it back in. I guess not. > -mike From jay.krell at cornell.edu Wed Apr 1 22:51:22 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Apr 2009 20:51:22 +0000 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: <200904011659.n31GxkMW094881@camembert.async.caltech.edu> References: Your message of "Wed, 01 Apr 2009 09:22:58 -0000." <200904011659.n31GxkMW094881@camembert.async.caltech.edu> Message-ID: Thank you Mika. There is a cm3.cfg file, but it had a small bug. Actually if you look the cm3.cfg file was probably a mere one line that includes LINUXLIBC6. That is probably overly confusing for anyone trying to understand how it works. If you repeat the experiment with the 5.7.1 archives you should find it easier. The not easy cheat is to take cm3cfg.common from current source tree. If you repeat it with a NOT yet existing archive that I have in mind, even easier, however not for all platforms -- i.e. no need to set LD_LIBRARY_PATH, on platforms that support $ORIGIN, but again, not yet. NT386 is already easy this way, since the .dlls are in the bin directory and that is searched; that is NT386-specific. I also need to get m3gdb and cm3ide into it. > It seems to me it would be quite easy to package this up, maybe even > with cminstall? That would be easiest I think, to cminstall the whole I deliberately don't. I find cminstall not very worthwhile. Try the 5.7.1 archive and see what you think? What you are saying I guess is you like the "one level archive" instead of the usual "two level". Agreed. One level can be easily achieved and have cminstall do a copy instead of untargz. But I also find cminstall not all that worthwhile (as I've said..). - Jay ---------------------------------------- > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Help finding CM3 compiler for Linux? > Date: Wed, 1 Apr 2009 09:59:45 -0700 > From: mika at async.caltech.edu > > > I have to say that once I figured out what I needed to do, using > Jay's distributions was easy---easier than I'm used to with CM3. > > All I had to do was: untar the -std dist (forget the min one). > > Set PATH and LD_LIBRARY_PATH > > And then---the mysterious part, which takes more than passing knowledge > of how CM3 works---providing a cm3.cfg file, which doesn't seem to be > provided at all by Jay's archive. > > It seems to me it would be quite easy to package this up, maybe even > with cminstall? That would be easiest I think, to cminstall the whole > dist rather than cminstalling just the -min and then making people build > their own compiler, libraries, and demo apps... > > Mika > > Jay writes: >>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_ >>Content-Type: text/plain; charset="iso-8859-1" >>Content-Transfer-Encoding: quoted-printable >> >> >>Olaf=2C in the LINUXLIBC6 configuration=2C try putting --32 on the as/gas i= >>nvocations. >> >>You mentioned --32 on cm3=2C but I wonder if you meant -m32 on cm3. >> >> cm3 -m32=20 >> >> as --32=20 >> >>=20 >> >>or check the man pages or help. They aren't consistent=2C for more reasons = >>than shown here (e.g. MIPS has -mabi64=2C and I think AIX has something els= >>e=2C and HP-UX gcc supports none of these -- no bi-arch support). >> >>=20 >> >>> probably be easiest to use a real 32 bit system and start from 5.4.0 >>> again. >> >> >>Using any current system should be plenty easy too. >> >>e.g. the distributions I put up. :) >> >>=20 >> >>AMD64_LINUX should be a good starting point=2C but I haven't tried it in a = >>bit. >> >>=20 >> >>I should be able to build a current LINUXLIBC6 very very soon. >> >>I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test= >> a switch to the "new" Unix *.i3 files. >> >>=20 >> >>I'll be using python/make-dist.py though. >> >>I do need to get more packages into it though=2C e.g. cm3ide and m3gdb. >> >>=20 >> >> - Jay >>=20 >>> Date: Wed=2C 1 Apr 2009 11:11:53 +0200 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> CC: mand at elego.de=3B m3-support at elego.de >>> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >>>=20 >>> Quoting Mika Nystrom : >>>=20 >>>> >>>> Is there any documentation for this format beyond what you just >>>> wrote? Where? >>>=20 >>> Well=2C yes=2C that's the problem with these kinds of archives: >>>=20 >>> (1) they're not well tested and >>> (2) there's no documentation user's can rely on >>>=20 >>> This doesn't mean that I disapprove or want to criticise the contributors= >>=2C >>> but an official well-documented release with installation notes etc. >>> has some advantages. Unfortunately=2C the official releases are really >>> outdated now. >>>=20 >>> I succeeded in building current AMD64_LINUX and FreeBSD4 installations >>> on our servers for d5.7.1 tonight and was able to build archives for >>> FreeBSD binaries and sources=2C but the tooling failed for AMD64_KINUX >>> due to changed and missing configuration files. I'll need to have a >>> closer look at that=2C some extensions seem to be needed. Anybody who >>> feels he can do that faster than me is of course encouraged (I'll have >>> little time as usual :-/). >>>=20 >>> It may also turn out to be difficult to produce LINUXLIBC6 binaries=2C >>> as birch and other Elego servers are now 64 bit machines=2C and trying >>> to use current CM3 with --32 produced lots of assembler errors about >>> unsupported instructions on this architecture. As the old installation >>> on birch seems to be gone without a chance of being restored=2C it will >>> probably be easiest to use a real 32 bit system and start from 5.4.0 >>> again. >>>=20 >>> Anybody who wants to help should be able to build the binary >>> archives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh >>> easily and upload them to birch at >>>=20 >>> /var/www/modula3.elegosoft.com/cm3/uploaded-archives >>>=20 >>> My guess is that tinderbox will take some time to run smoothly again=2C >>> as it was highly customized=2C and I'm not sure if these customizations >>> survied the crash. >>>=20 >>> Please stay tuned and thanks for all your patience=2C >>>=20 >>> Olaf >>> --=20 >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 9= >>5 >>> http://www.elegosoft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berli= >>n >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214= >>194 >>>=20 >> >>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_ >>Content-Type: text/html; charset="iso-8859-1" >>Content-Transfer-Encoding: quoted-printable >> >> >> >> >> >> >>Olaf=2C in the LINUXLIBC6 configuration=2C try putting --32 on the as/gas i= >>nvocations. >>You mentioned --32 on cm3=2C but I wonder if you meant -m32 on cm3. >> =3Bcm3 -m32 >> =3Bas --32 >> =3B >>or check the man pages or help. They aren't consistent=2C for more reasons = >>than shown here (e.g. MIPS has -mabi64=2C and I think AIX has something els= >>e=2C and HP-UX gcc supports none of these -- no bi-arch support). >> =3B >> =3B>=3B probably be easiest to use a real 32 bit system and start fr= >>om 5.4.0 =3B>=3B again. >>Using any current system should be plenty easy too. >>e.g. the distributions I put up. :) >> =3B >>AMD64_LINUX should be a good starting point=2C but I haven't tried it in a = >>bit. >> =3B >>I should be able to build a current LINUXLIBC6 very very soon. >>I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test= >> a switch to the "new" Unix *.i3 files. >> =3B >>I'll be using python/make-dist.py though. >>I do need to get more packages into it though=2C e.g. cm3ide and m3gdb. >> =3B >> =3B- Jay =3B >=3B Date: Wed=2C 1 Apr 2009 11:11:53 +0200<= >>BR>>=3B From: wagner at elegosoft.com >=3B To: m3devel at elegosoft.com>>>>=3B CC: mand at elego.de=3B m3-support at elego.de >=3B Subject: Re: [M3= >>devel] Help finding CM3 compiler for Linux? >=3B >=3B Quoting Mi= >>ka Nystrom <=3Bmika at async.caltech.edu>=3B: >=3B >=3B>=3B<= >>BR>>=3B>=3B Is there any documentation for this format beyond what you= >> just >=3B>=3B wrote? Where? >=3B >=3B Well=2C yes=2C th= >>at's the problem with these kinds of archives: >=3B >=3B (1) the= >>y're not well tested and >=3B (2) there's no documentation user's can = >>rely on >=3B >=3B This doesn't mean that I disapprove or want to= >> criticise the contributors=2C >=3B but an official well-documented re= >>lease with installation notes etc. >=3B has some advantages. Unfortuna= >>tely=2C the official releases are really >=3B outdated now. >=3B = >> >=3B I succeeded in building current AMD64_LINUX and FreeBSD4 install= >>ations >=3B on our servers for d5.7.1 tonight and was able to build ar= >>chives for >=3B FreeBSD binaries and sources=2C but the tooling failed= >> for AMD64_KINUX >=3B due to changed and missing configuration files. = > I'll need to have a >=3B closer look at that=2C some extensions seem t= >>o be needed. Anybody who >=3B feels he can do that faster than me is o= >>f course encouraged (I'll have >=3B little time as usual :-/). >= >>=3B >=3B It may also turn out to be difficult to produce LINUXLIBC6 b= >>inaries=2C >=3B as birch and other Elego servers are now 64 bit machin= >>es=2C and trying >=3B to use current CM3 with --32 produced lots of as= >>sembler errors about >=3B unsupported instructions on this architectur= >>e. As the old installation >=3B on birch seems to be gone without a ch= >>ance of being restored=2C it will >=3B probably be easiest to use a re= >>al 32 bit system and start from 5.4.0 >=3B again. >=3B >=3B= >> Anybody who wants to help should be able to build the binary >=3B arc= >>hives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh >=3B easily = >>and upload them to birch at >=3B >=3B /var/www/modula3.elegosoft= >>.com/cm3/uploaded-archives >=3B >=3B My guess is that tinderbox = >>will take some time to run smoothly again=2C >=3B as it was highly cus= >>tomized=2C and I'm not sure if these customizations >=3B survied the c= >>rash. >=3B >=3B Please stay tuned and thanks for all your patien= >>ce=2C >=3B >=3B Olaf >=3B -- >=3B Olaf Wagner -- eleg= >>o Software Solutions GmbH >=3B Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C= >> 13355 Berlin=2C Germany >=3B phone: +49 30 23 45 86 96 mobile: +49 17= >>7 2345 869 fax: +49 30 23 45 86 95 >=3B http://www.elegosoft.com | Ges= >>ch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berlin >=3B Handelregister: Amts= >>gericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >=3B >>dy> >>= >> >>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_-- From jay.krell at cornell.edu Wed Apr 1 22:55:46 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Apr 2009 20:55:46 +0000 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: <200904011659.n31GxkMW094881@camembert.async.caltech.edu> References: Your message of "Wed, 01 Apr 2009 09:22:58 -0000." <200904011659.n31GxkMW094881@camembert.async.caltech.edu> Message-ID: er, actually, the two level shouldn't be too bad, given that cminstall extracts the second level..so I don't know. "Usual two level" as in "usual Modula-3 two level", not usual outside Modula-3. But again, your experience was much worse than intended. There is a cm3.cfg file but it had a small but fatal bug. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Help finding CM3 compiler for Linux? > Date: Wed, 1 Apr 2009 20:51:22 +0000 > > > Thank you Mika. There is a cm3.cfg file, but it had a small bug. > Actually if you look the cm3.cfg file was probably a mere one line that includes LINUXLIBC6. That is probably overly confusing for anyone trying to understand how it works. > > If you repeat the experiment with the 5.7.1 archives you should find it easier. > The not easy cheat is to take cm3cfg.common from current source tree. > > If you repeat it with a NOT yet existing archive that I have in mind, even easier, however not for all platforms -- i.e. no need to set LD_LIBRARY_PATH, on platforms that support $ORIGIN, but again, not yet. NT386 is already easy this way, since the .dlls are in the bin directory and that is searched; that is NT386-specific. > > I also need to get m3gdb and cm3ide into it. > >> It seems to me it would be quite easy to package this up, maybe even >> with cminstall? That would be easiest I think, to cminstall the whole > > I deliberately don't. > I find cminstall not very worthwhile. > Try the 5.7.1 archive and see what you think? > > What you are saying I guess is you like the "one level archive" instead of the usual "two level". Agreed. One level can be easily achieved and have cminstall do a copy instead of untargz. But I also find cminstall not all that worthwhile (as I've said..). > > > - Jay > > ---------------------------------------- >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >> Date: Wed, 1 Apr 2009 09:59:45 -0700 >> From: mika at async.caltech.edu >> >> >> I have to say that once I figured out what I needed to do, using >> Jay's distributions was easy---easier than I'm used to with CM3. >> >> All I had to do was: untar the -std dist (forget the min one). >> >> Set PATH and LD_LIBRARY_PATH >> >> And then---the mysterious part, which takes more than passing knowledge >> of how CM3 works---providing a cm3.cfg file, which doesn't seem to be >> provided at all by Jay's archive. >> >> It seems to me it would be quite easy to package this up, maybe even >> with cminstall? That would be easiest I think, to cminstall the whole >> dist rather than cminstalling just the -min and then making people build >> their own compiler, libraries, and demo apps... >> >> Mika >> >> Jay writes: >>>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_ >>>Content-Type: text/plain; charset="iso-8859-1" >>>Content-Transfer-Encoding: quoted-printable >>> >>> >>>Olaf=2C in the LINUXLIBC6 configuration=2C try putting --32 on the as/gas i= >>>nvocations. >>> >>>You mentioned --32 on cm3=2C but I wonder if you meant -m32 on cm3. >>> >>> cm3 -m32=20 >>> >>> as --32=20 >>> >>>=20 >>> >>>or check the man pages or help. They aren't consistent=2C for more reasons = >>>than shown here (e.g. MIPS has -mabi64=2C and I think AIX has something els= >>>e=2C and HP-UX gcc supports none of these -- no bi-arch support). >>> >>>=20 >>> >>>> probably be easiest to use a real 32 bit system and start from 5.4.0 >>>> again. >>> >>> >>>Using any current system should be plenty easy too. >>> >>>e.g. the distributions I put up. :) >>> >>>=20 >>> >>>AMD64_LINUX should be a good starting point=2C but I haven't tried it in a = >>>bit. >>> >>>=20 >>> >>>I should be able to build a current LINUXLIBC6 very very soon. >>> >>>I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test= >>> a switch to the "new" Unix *.i3 files. >>> >>>=20 >>> >>>I'll be using python/make-dist.py though. >>> >>>I do need to get more packages into it though=2C e.g. cm3ide and m3gdb. >>> >>>=20 >>> >>> - Jay >>>=20 >>>> Date: Wed=2C 1 Apr 2009 11:11:53 +0200 >>>> From: wagner at elegosoft.com >>>> To: m3devel at elegosoft.com >>>> CC: mand at elego.de=3B m3-support at elego.de >>>> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >>>>=20 >>>> Quoting Mika Nystrom : >>>>=20 >>>>> >>>>> Is there any documentation for this format beyond what you just >>>>> wrote? Where? >>>>=20 >>>> Well=2C yes=2C that's the problem with these kinds of archives: >>>>=20 >>>> (1) they're not well tested and >>>> (2) there's no documentation user's can rely on >>>>=20 >>>> This doesn't mean that I disapprove or want to criticise the contributors= >>>=2C >>>> but an official well-documented release with installation notes etc. >>>> has some advantages. Unfortunately=2C the official releases are really >>>> outdated now. >>>>=20 >>>> I succeeded in building current AMD64_LINUX and FreeBSD4 installations >>>> on our servers for d5.7.1 tonight and was able to build archives for >>>> FreeBSD binaries and sources=2C but the tooling failed for AMD64_KINUX >>>> due to changed and missing configuration files. I'll need to have a >>>> closer look at that=2C some extensions seem to be needed. Anybody who >>>> feels he can do that faster than me is of course encouraged (I'll have >>>> little time as usual :-/). >>>>=20 >>>> It may also turn out to be difficult to produce LINUXLIBC6 binaries=2C >>>> as birch and other Elego servers are now 64 bit machines=2C and trying >>>> to use current CM3 with --32 produced lots of assembler errors about >>>> unsupported instructions on this architecture. As the old installation >>>> on birch seems to be gone without a chance of being restored=2C it will >>>> probably be easiest to use a real 32 bit system and start from 5.4.0 >>>> again. >>>>=20 >>>> Anybody who wants to help should be able to build the binary >>>> archives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh >>>> easily and upload them to birch at >>>>=20 >>>> /var/www/modula3.elegosoft.com/cm3/uploaded-archives >>>>=20 >>>> My guess is that tinderbox will take some time to run smoothly again=2C >>>> as it was highly customized=2C and I'm not sure if these customizations >>>> survied the crash. >>>>=20 >>>> Please stay tuned and thanks for all your patience=2C >>>>=20 >>>> Olaf >>>> --=20 >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 9= >>>5 >>>> http://www.elegosoft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berli= >>>n >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214= >>>194 >>>>=20 >>> >>>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_ >>>Content-Type: text/html; charset="iso-8859-1" >>>Content-Transfer-Encoding: quoted-printable >>> >>> >>> >>> > > >>> >>> >>>Olaf=2C in the LINUXLIBC6 configuration=2C try putting --32 on the as/gas i= >>>nvocations. > >>>You mentioned --32 on cm3=2C but I wonder if you meant -m32 on cm3. > >>> =3Bcm3 -m32 > >>> =3Bas --32 > >>> =3B > >>>or check the man pages or help. They aren't consistent=2C for more reasons = >>>than shown here (e.g. MIPS has -mabi64=2C and I think AIX has something els= >>>e=2C and HP-UX gcc supports none of these -- no bi-arch support). > >>> =3B > >>> =3B>=3B probably be easiest to use a real 32 bit system and start fr= >>>om 5.4.0 > =3B>=3B again. > > >>>Using any current system should be plenty easy too. > >>>e.g. the distributions I put up. :) > >>> =3B > >>>AMD64_LINUX should be a good starting point=2C but I haven't tried it in a = >>>bit. > >>> =3B > >>>I should be able to build a current LINUXLIBC6 very very soon. > >>>I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test= >>> a switch to the "new" Unix *.i3 files. > >>> =3B > >>>I'll be using python/make-dist.py though. > >>>I do need to get more packages into it though=2C e.g. cm3ide and m3gdb. > >>> =3B > >>> =3B- Jay > =3B >>=3B Date: Wed=2C 1 Apr 2009 11:11:53 +0200<= >>>BR>>=3B From: wagner at elegosoft.com >>=3B To: m3devel at elegosoft.com>>>>=3B CC: mand at elego.de=3B m3-support at elego.de >>=3B Subject: Re: [M3= >>>devel] Help finding CM3 compiler for Linux? >>=3B >>=3B Quoting Mi= >>>ka Nystrom <=3Bmika at async.caltech.edu>=3B: >>=3B >>=3B>=3B<= >>>BR>>=3B>=3B Is there any documentation for this format beyond what you= >>> just >>=3B>=3B wrote? Where? >>=3B >>=3B Well=2C yes=2C th= >>>at's the problem with these kinds of archives: >>=3B >>=3B (1) the= >>>y're not well tested and >>=3B (2) there's no documentation user's can = >>>rely on >>=3B >>=3B This doesn't mean that I disapprove or want to= >>> criticise the contributors=2C >>=3B but an official well-documented re= >>>lease with installation notes etc. >>=3B has some advantages. Unfortuna= >>>tely=2C the official releases are really >>=3B outdated now. >>=3B = >>> >>=3B I succeeded in building current AMD64_LINUX and FreeBSD4 install= >>>ations >>=3B on our servers for d5.7.1 tonight and was able to build ar= >>>chives for >>=3B FreeBSD binaries and sources=2C but the tooling failed= >>> for AMD64_KINUX >>=3B due to changed and missing configuration files. = >> I'll need to have a >>=3B closer look at that=2C some extensions seem t= >>>o be needed. Anybody who >>=3B feels he can do that faster than me is o= >>>f course encouraged (I'll have >>=3B little time as usual :-/). >>= >>>=3B >>=3B It may also turn out to be difficult to produce LINUXLIBC6 b= >>>inaries=2C >>=3B as birch and other Elego servers are now 64 bit machin= >>>es=2C and trying >>=3B to use current CM3 with --32 produced lots of as= >>>sembler errors about >>=3B unsupported instructions on this architectur= >>>e. As the old installation >>=3B on birch seems to be gone without a ch= >>>ance of being restored=2C it will >>=3B probably be easiest to use a re= >>>al 32 bit system and start from 5.4.0 >>=3B again. >>=3B >>=3B= >>> Anybody who wants to help should be able to build the binary >>=3B arc= >>>hives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh >>=3B easily = >>>and upload them to birch at >>=3B >>=3B /var/www/modula3.elegosoft= >>>.com/cm3/uploaded-archives >>=3B >>=3B My guess is that tinderbox = >>>will take some time to run smoothly again=2C >>=3B as it was highly cus= >>>tomized=2C and I'm not sure if these customizations >>=3B survied the c= >>>rash. >>=3B >>=3B Please stay tuned and thanks for all your patien= >>>ce=2C >>=3B >>=3B Olaf >>=3B -- >>=3B Olaf Wagner -- eleg= >>>o Software Solutions GmbH >>=3B Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C= >>> 13355 Berlin=2C Germany >>=3B phone: +49 30 23 45 86 96 mobile: +49 17= >>>7 2345 869 fax: +49 30 23 45 86 95 >>=3B http://www.elegosoft.com | Ges= >>>ch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berlin >>=3B Handelregister: Amts= >>>gericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>=3B >>>dy> >>>= >>> >>>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_-- From mika at async.caltech.edu Thu Apr 2 00:25:25 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 01 Apr 2009 15:25:25 -0700 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: Your message of "Wed, 01 Apr 2009 20:51:22 -0000." Message-ID: <200904012225.n31MPPDd007216@camembert.async.caltech.edu> Actually I think that the thing that has caused me the most problems in the past is that the -min and the -src-all get out of sync, since the binary bootstrapping dists are often not distributed (for size reasons?) with full source archives from exactly the same date. So when you try to build src-all with the binary bootstrap, something goes wrong. It's the whole... ok I need a binary install (since it's a real compiler), but now I have to bootstrap everything. And then the bootstrap turns out not to be 100% compatible with the compiler sources, libraries, some little detail in m3tk, ... Another way of saying this is "Isn't CM3 way overdue for a 'release'?" Mika Jay writes: > >Thank you Mika. There is a cm3.cfg file, but it had a small bug. > Actually if you look the cm3.cfg file was probably a mere one line that includes LINUXLIBC6. That is probably overly confusing for anyone trying to understand how it works. > >If you repeat the experiment with the 5.7.1 archives you should find it easier. > The not easy cheat is to take cm3cfg.common from current source tree. > >If you repeat it with a NOT yet existing archive that I have in mind, even easier, however not for all platforms -- i.e. no need to set LD_LIBRARY_PATH, on platforms that support $ORIGIN, but again, not yet. >NT386 is already easy this way, since the .dlls are in the bin directory and that is searched; that is NT386-specific. > >I also need to get m3gdb and cm3ide into it. > >> It seems to me it would be quite easy to package this up, maybe even >> with cminstall? That would be easiest I think, to cminstall the whole > >I deliberately don't. >I find cminstall not very worthwhile. >Try the 5.7.1 archive and see what you think? > >What you are saying I guess is you like the "one level archive" instead of the usual "two level". Agreed. One level can be easily achieved and have cminstall do a copy instead of untargz. But I also find cmin >stall not all that worthwhile (as I've said..). > > > - Jay > >---------------------------------------- >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >> Date: Wed, 1 Apr 2009 09:59:45 -0700 >> From: mika at async.caltech.edu >> >> >> I have to say that once I figured out what I needed to do, using >> Jay's distributions was easy---easier than I'm used to with CM3. >> >> All I had to do was: untar the -std dist (forget the min one). >> >> Set PATH and LD_LIBRARY_PATH >> >> And then---the mysterious part, which takes more than passing knowledge >> of how CM3 works---providing a cm3.cfg file, which doesn't seem to be >> provided at all by Jay's archive. >> >> It seems to me it would be quite easy to package this up, maybe even >> with cminstall? That would be easiest I think, to cminstall the whole >> dist rather than cminstalling just the -min and then making people build >> their own compiler, libraries, and demo apps... >> >> Mika >> >> Jay writes: >>>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_ >>>Content-Type: text/plain; charset="iso-8859-1" >>>Content-Transfer-Encoding: quoted-printable >>> >>> >>>Olaf=2C in the LINUXLIBC6 configuration=2C try putting --32 on the as/gas i= >>>nvocations. >>> >>>You mentioned --32 on cm3=2C but I wonder if you meant -m32 on cm3. >>> >>> cm3 -m32=20 >>> >>> as --32=20 >>> >>>=20 >>> >>>or check the man pages or help. They aren't consistent=2C for more reasons = >>>than shown here (e.g. MIPS has -mabi64=2C and I think AIX has something els= >>>e=2C and HP-UX gcc supports none of these -- no bi-arch support). >>> >>>=20 >>> >>>> probably be easiest to use a real 32 bit system and start from 5.4.0 >>>> again. >>> >>> >>>Using any current system should be plenty easy too. >>> >>>e.g. the distributions I put up. :) >>> >>>=20 >>> >>>AMD64_LINUX should be a good starting point=2C but I haven't tried it in a = >>>bit. >>> >>>=20 >>> >>>I should be able to build a current LINUXLIBC6 very very soon. >>> >>>I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test= >>> a switch to the "new" Unix *.i3 files. >>> >>>=20 >>> >>>I'll be using python/make-dist.py though. >>> >>>I do need to get more packages into it though=2C e.g. cm3ide and m3gdb. >>> >>>=20 >>> >>> - Jay >>>=20 >>>> Date: Wed=2C 1 Apr 2009 11:11:53 +0200 >>>> From: wagner at elegosoft.com >>>> To: m3devel at elegosoft.com >>>> CC: mand at elego.de=3B m3-support at elego.de >>>> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >>>>=20 >>>> Quoting Mika Nystrom : >>>>=20 >>>>> >>>>> Is there any documentation for this format beyond what you just >>>>> wrote? Where? >>>>=20 >>>> Well=2C yes=2C that's the problem with these kinds of archives: >>>>=20 >>>> (1) they're not well tested and >>>> (2) there's no documentation user's can rely on >>>>=20 >>>> This doesn't mean that I disapprove or want to criticise the contributors= >>>=2C >>>> but an official well-documented release with installation notes etc. >>>> has some advantages. Unfortunately=2C the official releases are really >>>> outdated now. >>>>=20 >>>> I succeeded in building current AMD64_LINUX and FreeBSD4 installations >>>> on our servers for d5.7.1 tonight and was able to build archives for >>>> FreeBSD binaries and sources=2C but the tooling failed for AMD64_KINUX >>>> due to changed and missing configuration files. I'll need to have a >>>> closer look at that=2C some extensions seem to be needed. Anybody who >>>> feels he can do that faster than me is of course encouraged (I'll have >>>> little time as usual :-/). >>>>=20 >>>> It may also turn out to be difficult to produce LINUXLIBC6 binaries=2C >>>> as birch and other Elego servers are now 64 bit machines=2C and trying >>>> to use current CM3 with --32 produced lots of assembler errors about >>>> unsupported instructions on this architecture. As the old installation >>>> on birch seems to be gone without a chance of being restored=2C it will >>>> probably be easiest to use a real 32 bit system and start from 5.4.0 >>>> again. >>>>=20 >>>> Anybody who wants to help should be able to build the binary >>>> archives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh >>>> easily and upload them to birch at >>>>=20 >>>> /var/www/modula3.elegosoft.com/cm3/uploaded-archives >>>>=20 >>>> My guess is that tinderbox will take some time to run smoothly again=2C >>>> as it was highly customized=2C and I'm not sure if these customizations >>>> survied the crash. >>>>=20 >>>> Please stay tuned and thanks for all your patience=2C >>>>=20 >>>> Olaf >>>> --=20 >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 9= >>>5 >>>> http://www.elegosoft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berli= >>>n >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214= >>>194 >>>>=20 >>> >>>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_ >>>Content-Type: text/html; charset="iso-8859-1" >>>Content-Transfer-Encoding: quoted-printable >>> >>> >>> >>> > > >>> >>> >>>Olaf=2C in the LINUXLIBC6 configuration=2C try putting --32 on the as/gas i= >>>nvocations. > >>>You mentioned --32 on cm3=2C but I wonder if you meant -m32 on cm3. > >>> =3Bcm3 -m32 > >>> =3Bas --32 > >>> =3B > >>>or check the man pages or help. They aren't consistent=2C for more reasons = >>>than shown here (e.g. MIPS has -mabi64=2C and I think AIX has something els= >>>e=2C and HP-UX gcc supports none of these -- no bi-arch support). > >>> =3B > >>> =3B>=3B probably be easiest to use a real 32 bit system and start fr= >>>om 5.4.0 > =3B>=3B again. > > >>>Using any current system should be plenty easy too. > >>>e.g. the distributions I put up. :) > >>> =3B > >>>AMD64_LINUX should be a good starting point=2C but I haven't tried it in a = >>>bit. > >>> =3B > >>>I should be able to build a current LINUXLIBC6 very very soon. > >>>I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test= >>> a switch to the "new" Unix *.i3 files. > >>> =3B > >>>I'll be using python/make-dist.py though. > >>>I do need to get more packages into it though=2C e.g. cm3ide and m3gdb. > >>> =3B > >>> =3B- Jay > =3B >>=3B Date: Wed=2C 1 Apr 2009 11:11:53 +0200<= >>>BR>>=3B From: wagner at elegosoft.com >>=3B To: m3devel at elegosoft.com>>>>=3B CC: mand at elego.de=3B m3-support at elego.de >>=3B Subject: Re: [M3= >>>devel] Help finding CM3 compiler for Linux? >>=3B >>=3B Quoting Mi= >>>ka Nystrom <=3Bmika at async.caltech.edu>=3B: >>=3B >>=3B>=3B<= >>>BR>>=3B>=3B Is there any documentation for this format beyond what you= >>> just >>=3B>=3B wrote? Where? >>=3B >>=3B Well=2C yes=2C th= >>>at's the problem with these kinds of archives: >>=3B >>=3B (1) the= >>>y're not well tested and >>=3B (2) there's no documentation user's can = >>>rely on >>=3B >>=3B This doesn't mean that I disapprove or want to= >>> criticise the contributors=2C >>=3B but an official well-documented re= >>>lease with installation notes etc. >>=3B has some advantages. Unfortuna= >>>tely=2C the official releases are really >>=3B outdated now. >>=3B = >>> >>=3B I succeeded in building current AMD64_LINUX and FreeBSD4 install= >>>ations >>=3B on our servers for d5.7.1 tonight and was able to build ar= >>>chives for >>=3B FreeBSD binaries and sources=2C but the tooling failed= >>> for AMD64_KINUX >>=3B due to changed and missing configuration files. = >> I'll need to have a >>=3B closer look at that=2C some extensions seem t= >>>o be needed. Anybody who >>=3B feels he can do that faster than me is o= >>>f course encouraged (I'll have >>=3B little time as usual :-/). >>= >>>=3B >>=3B It may also turn out to be difficult to produce LINUXLIBC6 b= >>>inaries=2C >>=3B as birch and other Elego servers are now 64 bit machin= >>>es=2C and trying >>=3B to use current CM3 with --32 produced lots of as= >>>sembler errors about >>=3B unsupported instructions on this architectur= >>>e. As the old installation >>=3B on birch seems to be gone without a ch= >>>ance of being restored=2C it will >>=3B probably be easiest to use a re= >>>al 32 bit system and start from 5.4.0 >>=3B again. >>=3B >>=3B= >>> Anybody who wants to help should be able to build the binary >>=3B arc= >>>hives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh >>=3B easily = >>>and upload them to birch at >>=3B >>=3B /var/www/modula3.elegosoft= >>>.com/cm3/uploaded-archives >>=3B >>=3B My guess is that tinderbox = >>>will take some time to run smoothly again=2C >>=3B as it was highly cus= >>>tomized=2C and I'm not sure if these customizations >>=3B survied the c= >>>rash. >>=3B >>=3B Please stay tuned and thanks for all your patien= >>>ce=2C >>=3B >>=3B Olaf >>=3B -- >>=3B Olaf Wagner -- eleg= >>>o Software Solutions GmbH >>=3B Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C= >>> 13355 Berlin=2C Germany >>=3B phone: +49 30 23 45 86 96 mobile: +49 17= >>>7 2345 869 fax: +49 30 23 45 86 95 >>=3B http://www.elegosoft.com | Ges= >>>ch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berlin >>=3B Handelregister: Amts= >>>gericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>=3B >>>dy> >>>= >>> >>>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_-- From rcoleburn at scires.com Thu Apr 2 01:05:16 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 01 Apr 2009 19:05:16 -0400 Subject: [M3devel] new cm3 release (was: Help finding CM3 compiler for Linux?) In-Reply-To: <200904012225.n31MPPDd007216@camembert.async.caltech.edu> References: Your message of "Wed, 01 Apr 2009 20:51:22 -0000." <200904012225.n31MPPDd007216@camembert.async.caltech.edu> Message-ID: <49D3BAD7.1E75.00D7.1@scires.com> I agree about needing a new release. I suppose there is some value in maintaining a MINimal size binary distribution, but I think it would also nice to also provide a FULL distribution with everything pre-built. (Of course, this will eat up more space on elego machines.) I have ready access to Windows XP (32-bit and 64-bit) and Vista platforms. I would be glad to build and supply the distros for these platforms. Suggest we agree upon a plan and a timeframe. a. make a tag or something in CVS that marks what will comprise the official sources for the release b. agree upon distribution format (platform naming conventions, compressed archive format for MIN and FULL variants) c. get a list of who is going to supply distros for which platforms d. establish procedure for how the distros will be uploaded to elego e. set a date for contributors to have the distros uploaded f. have someone put together the web page showing links to all the distros along with updated installation instructions One sticky issue in the past has been target location. If we unpack a distro and put it in a different place in the filesystem tree, we don't want it to break. I know that cminstall attempted to adjust the cm3.cfg file to deal with location differences. Do we need/want to build an installer program or script to deal with this issue, perhaps even adjusting cminstall will suffice? Or, do we give a set of instructions on which file(s) to edit when moving the install location? For Windows, I don't mind building an installer. Perhaps the installer could let you choose whether to install the MIN or the FULL version. Also, I think the Tinderbox has been great, but perhaps it can be improved. I know I would like to see testing for Windows platforms added. I have an XP computer I can pretty much dedicate to this task. The problem is that I tried with Olaf's help to get it working, but there were too many dependencies on unix-type shell/script environment, and trying to force fit into cygwin didn't work well for the native Win32 implementation. Thoughts? Regards, Randy >>> Mika Nystrom 4/1/2009 6:25 PM >>> Actually I think that the thing that has caused me the most problems in the past is that the -min and the -src-all get out of sync, since the binary bootstrapping dists are often not distributed (for size reasons?) with full source archives from exactly the same date. So when you try to build src-all with the binary bootstrap, something goes wrong. It's the whole... ok I need a binary install (since it's a real compiler), but now I have to bootstrap everything. And then the bootstrap turns out not to be 100% compatible with the compiler sources, libraries, some little detail in m3tk, ... Another way of saying this is "Isn't CM3 way overdue for a 'release'?" Mika CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 2 01:28:01 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 1 Apr 2009 23:28:01 +0000 Subject: [M3devel] new cm3 release (was: Help finding CM3 compiler for Linux?) In-Reply-To: <49D3BAD7.1E75.00D7.1@scires.com> References: Your message of "Wed, 01 Apr 2009 20:51:22 -0000." <200904012225.n31MPPDd007216@camembert.async.caltech.edu> <49D3BAD7.1E75.00D7.1@scires.com> Message-ID: "std" is already essentially "full", or meant to be at least. Granted my "std" is missing m3gdb and cm3ide, at least. But it isn't small. "std" isn't new or specific to my releases. It has been in all the "open" cm3 releases, and probably the Critical Mass ones too. I've been meaning to put together "boot" releases that are perhaps smaller than "min", though that isn't perhaps their defining characteristic. They would consist of assembly code for the Modula-3 and uncompiled C code. Very similar to the old Digital SRC releases, and I think the ezm3 releases. The Digital SRC boot format no longer works, because it depended on quake/m3build/m3ship being written in C. A defining characteristic probably of "boot" is that it is safe against API and ABI changes. Another one perhaps though is having to spend the time to build cm3cg. My current "boot" archives build only cm3, but extending them to build m3core and libm3 would be trivial, extending them to build all of "std", not too difficult. I gather one of the nice things PM3 had was they shipped IL instead of assembly. That can be a a lot more portable, or extremely portable. "more portable" -- varying mainly only in wordsize and endian, /maybe/ smaller issues like alignment (almost always the same anyway), page size (not really) "extremely portable" -- factor even those out Though you'd also have to factor out the Time/Date stuff. And if you had user thread support in there, portability gains would be lost. This approach, in fact, can lead to "universal posix" distributions, at the cost of user having to build cm3cg. In fact you could build the Win32 code and have the last-on-the-target stage pick the appropriate files, leading to really "universal" distributions. > One sticky issue in the past has been target location This is not an issue with my config files, hasn't been for a long time. Kind of bothersome..you know..I solved this years ago..to still be discussing it as an issue.. Yeah, I realize my ChangeLog is not readable but... Quake code can query for its own location. At least as of a while ago. Maybe not in much old versions. (I didn't add the feature, I merely discovered it was there.) My cm3.cfg file does that. And then build the rest of the paths from there -- at least for cm3/cm3cg/pkg/lib. The location of cl.exe and link.exe aren't solved by path. For those, I just run "cl" and "link" and depend on $PATH. That's how people often deal with gcc/ld, though I realize there is no unversality here. Some people use full paths to gcc/ld, some rely on $PATH, ditto for cl/link (actually for cl/link, most "people" use an interactive GUI that hides tons of stuff, but there are still "automated builds" that have to do something.) I did some experimentation with building a GUI NT install, using "InnoSetup". It was just a glorified untargz, which does have some value. A little fancier than just distributing a .zip file. I didn't get to the point of (offering to) altering $PATH, ensuring cl.exe/link.exe were available. But this perhaps be adequately handled by one line documentation telling people to run the "shortcut" that Visual C++ installs, that runs an appropriately setup command line (the platform SDK and DDK do the same). I dread the "freeze" state approaching releases. Please hopefully there is a "tag" or "branch" for the release, and I can continue working "my way" (churn too high for near release). - Jay Date: Wed, 1 Apr 2009 19:05:16 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] new cm3 release (was: Help finding CM3 compiler for Linux?) I agree about needing a new release. I suppose there is some value in maintaining a MINimal size binary distribution, but I think it would also nice to also provide a FULL distribution with everything pre-built. (Of course, this will eat up more space on elego machines.) I have ready access to Windows XP (32-bit and 64-bit) and Vista platforms. I would be glad to build and supply the distros for these platforms. Suggest we agree upon a plan and a timeframe. a. make a tag or something in CVS that marks what will comprise the official sources for the release b. agree upon distribution format (platform naming conventions, compressed archive format for MIN and FULL variants) c. get a list of who is going to supply distros for which platforms d. establish procedure for how the distros will be uploaded to elego e. set a date for contributors to have the distros uploaded f. have someone put together the web page showing links to all the distros along with updated installation instructions One sticky issue in the past has been target location. If we unpack a distro and put it in a different place in the filesystem tree, we don't want it to break. I know that cminstall attempted to adjust the cm3.cfg file to deal with location differences. Do we need/want to build an installer program or script to deal with this issue, perhaps even adjusting cminstall will suffice? Or, do we give a set of instructions on which file(s) to edit when moving the install location? For Windows, I don't mind building an installer. Perhaps the installer could let you choose whether to install the MIN or the FULL version. Also, I think the Tinderbox has been great, but perhaps it can be improved. I know I would like to see testing for Windows platforms added. I have an XP computer I can pretty much dedicate to this task. The problem is that I tried with Olaf's help to get it working, but there were too many dependencies on unix-type shell/script environment, and trying to force fit into cygwin didn't work well for the native Win32 implementation. Thoughts? Regards, Randy >>> Mika Nystrom 4/1/2009 6:25 PM >>> Actually I think that the thing that has caused me the most problems in the past is that the -min and the -src-all get out of sync, since the binary bootstrapping dists are often not distributed (for size reasons?) with full source archives from exactly the same date. So when you try to build src-all with the binary bootstrap, something goes wrong. It's the whole... ok I need a binary install (since it's a real compiler), but now I have to bootstrap everything. And then the bootstrap turns out not to be 100% compatible with the compiler sources, libraries, some little detail in m3tk, ... Another way of saying this is "Isn't CM3 way overdue for a 'release'?" Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Thu Apr 2 02:03:47 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 1 Apr 2009 17:03:47 -0700 (PDT) Subject: [M3devel] new cm3 release (was: Help finding CM3 compiler for Linux?) In-Reply-To: <49D3BAD7.1E75.00D7.1@scires.com> Message-ID: <903288.9641.qm@web24714.mail.ird.yahoo.com> Hey what a port of the tinderbox to Obliq, in that way, we could allow the system to test and report hosted on itself and get a hand from the M3 runtime capabilities, network objects and pretty staff (GUIs included, it could allow even to test directly from the Obliq interpreter without recompiling nothing, just using M3 runtime), however depending on M3 runtime I don't know is that is the idea, I think it makes sense since it's supposed to be a M3 system in the platform to be tested and reported. If the test failed there should be a lastok obliq script and runtime that worked so it can be in any case reported on the status web page. With CM3-IDE we could also create a Link from the Initial web page to see the status locally and get or send reported status more easily integrated? Oh, I would like to help but still I haven't checked the latest versions of the complete system, I still want to wait to have all server services running on Elego.de (thanks all there cvs is running) but we can think meanwhile on it. Thanks in advance --- El mi?, 1/4/09, Randy Coleburn escribi?: De: Randy Coleburn Asunto: [M3devel] new cm3 release (was: Help finding CM3 compiler for Linux?) Para: m3devel at elegosoft.com Fecha: mi?rcoles, 1 abril, 2009 6:05 I agree about needing a new release. ? I suppose there is some value in maintaining a MINimal size binary distribution, but I think it would also nice to also provide a FULL distribution with everything pre-built.? (Of course, this will eat up more space on elego machines.) ? I have ready access to Windows XP (32-bit and 64-bit) and Vista platforms.? I would be glad to build and supply the distros for these platforms. ? Suggest we agree upon a plan and a timeframe. a.? make a tag or something in CVS that marks what will comprise the official sources for the release b.? agree upon distribution format (platform naming conventions, compressed archive format for MIN and FULL variants) c.? get a list of who is going to supply distros for which platforms d.? establish procedure for how the distros will be uploaded to elego e.? set a date for contributors to have the distros uploaded f.? have someone put together the web page showing links to all the distros along with updated installation instructions ? One sticky issue in the past has been target location.? If we unpack a distro and put it in a different place in the filesystem tree, we don't want it to break.? I know that cminstall attempted to adjust the cm3.cfg file to deal with location differences.? Do we need/want to build an installer program or script to deal with this issue, perhaps even adjusting cminstall will suffice?? Or, do we give a set of instructions on which file(s) to edit when moving the install location? ? For Windows, I don't mind building an installer.? Perhaps the installer could let you choose whether to install the MIN or the FULL version. ? Also, I think the Tinderbox has been great, but perhaps it can be improved.? I know I would like to see testing for Windows platforms added.? I have an XP computer I can pretty much dedicate to this task.? The problem is that I tried with Olaf's help to get it working, but there were too many dependencies on unix-type shell/script environment, and trying to force fit into cygwin didn't work well for the native Win32 implementation.? Thoughts? ? Regards, Randy >>> Mika Nystrom 4/1/2009 6:25 PM >>> Actually I think that the thing that has caused me the most problems in the past is that the -min and the -src-all get out of sync, since the binary bootstrapping dists are often not distributed (for size reasons?) with full source archives from exactly the same date.? So when you try to build src-all with the binary bootstrap, something goes wrong.? It's the whole... ok I need a binary install (since it's a real compiler), but now I have to bootstrap everything.? And then the bootstrap turns out not to be 100% compatible with the compiler sources, libraries, some little detail in m3tk, ... Another way of saying this is "Isn't CM3 way overdue for a 'release'?" ??? Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Apr 2 08:57:54 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 02 Apr 2009 08:57:54 +0200 Subject: [M3devel] new cm3 release (was: Help finding CM3 compiler for Linux?) In-Reply-To: <49D3BAD7.1E75.00D7.1@scires.com> References: Your message of "Wed, 01 Apr 2009 20:51:22 -0000." <200904012225.n31MPPDd007216@camembert.async.caltech.edu> <49D3BAD7.1E75.00D7.1@scires.com> Message-ID: <20090402085754.wpgiv2sgg800c0c4@mail.elegosoft.com> Quoting Randy Coleburn : > I agree about needing a new release. I suggested a new release twice within the recent two years, but nobody seemed to really support that idea. I never got round to do the work myself. > I suppose there is some value in maintaining a MINimal size binary > distribution, but I think it would also nice to also provide a FULL > distribution with everything pre-built. (Of course, this will eat > up more space on elego machines.) That should be no problem. As for archive size, I think disk sizes and transfer rates have changed much in recent years. We could easily provide full distribution archives in binary form. For those who just want the compiler, I'd suggest something of the size of the core set as defined in the script. > I have ready access to Windows XP (32-bit and 64-bit) and Vista > platforms. I would be glad to build and supply the distros for > these platforms. Great. > Suggest we agree upon a plan and a timeframe. > a. make a tag or something in CVS that marks what will comprise the > official sources for the release I can take over the CVS and pinging work, if everybody agrees. I won't have time to actually build and test all distributions. > b. agree upon distribution format (platform naming conventions, > compressed archive format for MIN and FULL variants) I'd suggest a switch to the complete binary archive format; but we need to automate and document the process. probably Jay has already done most of it, but I haven't tested it. > c. get a list of who is going to supply distros for which platforms Elego can provide FreeBSD 6.X and Linux on AMD64 easily. > d. establish procedure for how the distros will be uploaded to elego We should simply start by collecting release candidates in the uploaded-archives section of the server. We can use a naming scheme to separate these from other archives (cm3-*-*5.7.1-rc[1-9]?). > e. set a date for contributors to have the distros uploaded > f. have someone put together the web page showing links to all the > distros along with updated installation instructions I can do that, too, if you like. > One sticky issue in the past has been target location. If we unpack > a distro and put it in a different place in the filesystem tree, we > don't want it to break. I know that cminstall attempted to adjust > the cm3.cfg file to deal with location differences. Do we need/want > to build an installer program or script to deal with this issue, > perhaps even adjusting cminstall will suffice? Or, do we give a set > of instructions on which file(s) to edit when moving the install > location? I think Jay's archives can be easily relocated. > For Windows, I don't mind building an installer. Perhaps the > installer could let you choose whether to install the MIN or the > FULL version. > > Also, I think the Tinderbox has been great, but perhaps it can be > improved. I know I would like to see testing for Windows platforms > added. I have an XP computer I can pretty much dedicate to this > task. The problem is that I tried with Olaf's help to get it > working, but there were too many dependencies on unix-type > shell/script environment, and trying to force fit into cygwin didn't > work well for the native Win32 implementation. Thoughts? I had working most of it, but then got lost in other work again, and the virtual machine I used was so slow (and tended to crash :-/) We need to start again from where I stopped. > Regards, > Randy > >>>> Mika Nystrom 4/1/2009 6:25 PM >>> > > Actually I think that the thing that has caused me the most problems > in the past is that the -min and the -src-all get out of sync, since > the binary bootstrapping dists are often not distributed (for size > reasons?) with full source archives from exactly the same date. So > when you try to build src-all with the binary bootstrap, something > goes wrong. It's the whole... ok I need a binary install (since > it's a real compiler), but now I have to bootstrap everything. And > then the bootstrap turns out not to be 100% compatible with the > compiler sources, libraries, some little detail in m3tk, ... If you are happy with just overwriting everything existing, it should be no problem to switch to full binary archives. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 3 13:03:56 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 3 Apr 2009 11:03:56 +0000 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: <200904012225.n31MPPDd007216@camembert.async.caltech.edu> References: Your message of "Wed, 01 Apr 2009 20:51:22 -0000." <200904012225.n31MPPDd007216@camembert.async.caltech.edu> Message-ID: "Good oops", I only just noticed that the older releases only had "min binary" and "std src". I thought they had both min and std binary for users to chose from, and I was following suit. (noticed this 'cause I want to try old Solaris/PPC_DARWIN see when the formsedit crash came in; it's still there) - Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Wed, 1 Apr 2009 15:25:25 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Help finding CM3 compiler for Linux? > > > Actually I think that the thing that has caused me the most problems > in the past is that the -min and the -src-all get out of sync, since > the binary bootstrapping dists are often not distributed (for size > reasons?) with full source archives from exactly the same date. So > when you try to build src-all with the binary bootstrap, something > goes wrong. It's the whole... ok I need a binary install (since > it's a real compiler), but now I have to bootstrap everything. And > then the bootstrap turns out not to be 100% compatible with the > compiler sources, libraries, some little detail in m3tk, ... > > Another way of saying this is "Isn't CM3 way overdue for a 'release'?" > > Mika > > Jay writes: >> >>Thank you Mika. There is a cm3.cfg file, but it had a small bug. >> Actually if you look the cm3.cfg file was probably a mere one line that includes LINUXLIBC6. That is probably overly confusing for anyone trying to understand how it works. >> >>If you repeat the experiment with the 5.7.1 archives you should find it easier. >> The not easy cheat is to take cm3cfg.common from current source tree. >> >>If you repeat it with a NOT yet existing archive that I have in mind, even easier, however not for all platforms -- i.e. no need to set LD_LIBRARY_PATH, on platforms that support $ORIGIN, but again, not yet. >>NT386 is already easy this way, since the .dlls are in the bin directory and that is searched; that is NT386-specific. >> >>I also need to get m3gdb and cm3ide into it. >> >>> It seems to me it would be quite easy to package this up, maybe even >>> with cminstall? That would be easiest I think, to cminstall the whole >> >>I deliberately don't. >>I find cminstall not very worthwhile. >>Try the 5.7.1 archive and see what you think? >> >>What you are saying I guess is you like the "one level archive" instead of the usual "two level". Agreed. One level can be easily achieved and have cminstall do a copy instead of untargz. But I also find cmin >>stall not all that worthwhile (as I've said..). >> >> >> - Jay >> >>---------------------------------------- >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >>> Date: Wed, 1 Apr 2009 09:59:45 -0700 >>> From: mika at async.caltech.edu >>> >>> >>> I have to say that once I figured out what I needed to do, using >>> Jay's distributions was easy---easier than I'm used to with CM3. >>> >>> All I had to do was: untar the -std dist (forget the min one). >>> >>> Set PATH and LD_LIBRARY_PATH >>> >>> And then---the mysterious part, which takes more than passing knowledge >>> of how CM3 works---providing a cm3.cfg file, which doesn't seem to be >>> provided at all by Jay's archive. >>> >>> It seems to me it would be quite easy to package this up, maybe even >>> with cminstall? That would be easiest I think, to cminstall the whole >>> dist rather than cminstalling just the -min and then making people build >>> their own compiler, libraries, and demo apps... >>> >>> Mika >>> >>> Jay writes: >>>>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_ >>>>Content-Type: text/plain; charset="iso-8859-1" >>>>Content-Transfer-Encoding: quoted-printable >>>> >>>> >>>>Olaf=2C in the LINUXLIBC6 configuration=2C try putting --32 on the as/gas i= >>>>nvocations. >>>> >>>>You mentioned --32 on cm3=2C but I wonder if you meant -m32 on cm3. >>>> >>>> cm3 -m32=20 >>>> >>>> as --32=20 >>>> >>>>=20 >>>> >>>>or check the man pages or help. They aren't consistent=2C for more reasons = >>>>than shown here (e.g. MIPS has -mabi64=2C and I think AIX has something els= >>>>e=2C and HP-UX gcc supports none of these -- no bi-arch support). >>>> >>>>=20 >>>> >>>>> probably be easiest to use a real 32 bit system and start from 5.4.0 >>>>> again. >>>> >>>> >>>>Using any current system should be plenty easy too. >>>> >>>>e.g. the distributions I put up. :) >>>> >>>>=20 >>>> >>>>AMD64_LINUX should be a good starting point=2C but I haven't tried it in a = >>>>bit. >>>> >>>>=20 >>>> >>>>I should be able to build a current LINUXLIBC6 very very soon. >>>> >>>>I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test= >>>> a switch to the "new" Unix *.i3 files. >>>> >>>>=20 >>>> >>>>I'll be using python/make-dist.py though. >>>> >>>>I do need to get more packages into it though=2C e.g. cm3ide and m3gdb. >>>> >>>>=20 >>>> >>>> - Jay >>>>=20 >>>>> Date: Wed=2C 1 Apr 2009 11:11:53 +0200 >>>>> From: wagner at elegosoft.com >>>>> To: m3devel at elegosoft.com >>>>> CC: mand at elego.de=3B m3-support at elego.de >>>>> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? >>>>>=20 >>>>> Quoting Mika Nystrom : >>>>>=20 >>>>>> >>>>>> Is there any documentation for this format beyond what you just >>>>>> wrote? Where? >>>>>=20 >>>>> Well=2C yes=2C that's the problem with these kinds of archives: >>>>>=20 >>>>> (1) they're not well tested and >>>>> (2) there's no documentation user's can rely on >>>>>=20 >>>>> This doesn't mean that I disapprove or want to criticise the contributors= >>>>=2C >>>>> but an official well-documented release with installation notes etc. >>>>> has some advantages. Unfortunately=2C the official releases are really >>>>> outdated now. >>>>>=20 >>>>> I succeeded in building current AMD64_LINUX and FreeBSD4 installations >>>>> on our servers for d5.7.1 tonight and was able to build archives for >>>>> FreeBSD binaries and sources=2C but the tooling failed for AMD64_KINUX >>>>> due to changed and missing configuration files. I'll need to have a >>>>> closer look at that=2C some extensions seem to be needed. Anybody who >>>>> feels he can do that faster than me is of course encouraged (I'll have >>>>> little time as usual :-/). >>>>>=20 >>>>> It may also turn out to be difficult to produce LINUXLIBC6 binaries=2C >>>>> as birch and other Elego servers are now 64 bit machines=2C and trying >>>>> to use current CM3 with --32 produced lots of assembler errors about >>>>> unsupported instructions on this architecture. As the old installation >>>>> on birch seems to be gone without a chance of being restored=2C it will >>>>> probably be easiest to use a real 32 bit system and start from 5.4.0 >>>>> again. >>>>>=20 >>>>> Anybody who wants to help should be able to build the binary >>>>> archives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh >>>>> easily and upload them to birch at >>>>>=20 >>>>> /var/www/modula3.elegosoft.com/cm3/uploaded-archives >>>>>=20 >>>>> My guess is that tinderbox will take some time to run smoothly again=2C >>>>> as it was highly customized=2C and I'm not sure if these customizations >>>>> survied the crash. >>>>>=20 >>>>> Please stay tuned and thanks for all your patience=2C >>>>>=20 >>>>> Olaf >>>>> --=20 >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 9= >>>>5 >>>>> http://www.elegosoft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berli= >>>>n >>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214= >>>>194 >>>>>=20 >>>> >>>>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_ >>>>Content-Type: text/html; charset="iso-8859-1" >>>>Content-Transfer-Encoding: quoted-printable >>>> >>>> >>>> >>>> >> >> >>>> >>>> >>>>Olaf=2C in the LINUXLIBC6 configuration=2C try putting --32 on the as/gas i= >>>>nvocations. >> >>>>You mentioned --32 on cm3=2C but I wonder if you meant -m32 on cm3. >> >>>> =3Bcm3 -m32 >> >>>> =3Bas --32 >> >>>> =3B >> >>>>or check the man pages or help. They aren't consistent=2C for more reasons = >>>>than shown here (e.g. MIPS has -mabi64=2C and I think AIX has something els= >>>>e=2C and HP-UX gcc supports none of these -- no bi-arch support). >> >>>> =3B >> >>>> =3B>=3B probably be easiest to use a real 32 bit system and start fr= >>>>om 5.4.0 >> =3B>=3B again. >> >> >>>>Using any current system should be plenty easy too. >> >>>>e.g. the distributions I put up. :) >> >>>> =3B >> >>>>AMD64_LINUX should be a good starting point=2C but I haven't tried it in a = >>>>bit. >> >>>> =3B >> >>>>I should be able to build a current LINUXLIBC6 very very soon. >> >>>>I guess I can install FreeBSD 7.1..which I'd been meaning to anyway to test= >>>> a switch to the "new" Unix *.i3 files. >> >>>> =3B >> >>>>I'll be using python/make-dist.py though. >> >>>>I do need to get more packages into it though=2C e.g. cm3ide and m3gdb. >> >>>> =3B >> >>>> =3B- Jay >> =3B >>>=3B Date: Wed=2C 1 Apr 2009 11:11:53 +0200<= >>>>BR>>=3B From: wagner at elegosoft.com >>>=3B To: m3devel at elegosoft.com>>>>=3B CC: mand at elego.de=3B m3-support at elego.de >>>=3B Subject: Re: [M3= >>>>devel] Help finding CM3 compiler for Linux? >>>=3B >>>=3B Quoting Mi= >>>>ka Nystrom <=3Bmika at async.caltech.edu>=3B: >>>=3B >>>=3B>=3B<= >>>>BR>>=3B>=3B Is there any documentation for this format beyond what you= >>>> just >>>=3B>=3B wrote? Where? >>>=3B >>>=3B Well=2C yes=2C th= >>>>at's the problem with these kinds of archives: >>>=3B >>>=3B (1) the= >>>>y're not well tested and >>>=3B (2) there's no documentation user's can = >>>>rely on >>>=3B >>>=3B This doesn't mean that I disapprove or want to= >>>> criticise the contributors=2C >>>=3B but an official well-documented re= >>>>lease with installation notes etc. >>>=3B has some advantages. Unfortuna= >>>>tely=2C the official releases are really >>>=3B outdated now. >>>=3B = >>>> >>>=3B I succeeded in building current AMD64_LINUX and FreeBSD4 install= >>>>ations >>>=3B on our servers for d5.7.1 tonight and was able to build ar= >>>>chives for >>>=3B FreeBSD binaries and sources=2C but the tooling failed= >>>> for AMD64_KINUX >>>=3B due to changed and missing configuration files. = >>> I'll need to have a >>>=3B closer look at that=2C some extensions seem t= >>>>o be needed. Anybody who >>>=3B feels he can do that faster than me is o= >>>>f course encouraged (I'll have >>>=3B little time as usual :-/). >>>= >>>>=3B >>>=3B It may also turn out to be difficult to produce LINUXLIBC6 b= >>>>inaries=2C >>>=3B as birch and other Elego servers are now 64 bit machin= >>>>es=2C and trying >>>=3B to use current CM3 with --32 produced lots of as= >>>>sembler errors about >>>=3B unsupported instructions on this architectur= >>>>e. As the old installation >>>=3B on birch seems to be gone without a ch= >>>>ance of being restored=2C it will >>>=3B probably be easiest to use a re= >>>>al 32 bit system and start from 5.4.0 >>>=3B again. >>>=3B >>>=3B= >>>> Anybody who wants to help should be able to build the binary >>>=3B arc= >>>>hives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh >>>=3B easily = >>>>and upload them to birch at >>>=3B >>>=3B /var/www/modula3.elegosoft= >>>>.com/cm3/uploaded-archives >>>=3B >>>=3B My guess is that tinderbox = >>>>will take some time to run smoothly again=2C >>>=3B as it was highly cus= >>>>tomized=2C and I'm not sure if these customizations >>>=3B survied the c= >>>>rash. >>>=3B >>>=3B Please stay tuned and thanks for all your patien= >>>>ce=2C >>>=3B >>>=3B Olaf >>>=3B -- >>>=3B Olaf Wagner -- eleg= >>>>o Software Solutions GmbH >>>=3B Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C= >>>> 13355 Berlin=2C Germany >>>=3B phone: +49 30 23 45 86 96 mobile: +49 17= >>>>7 2345 869 fax: +49 30 23 45 86 95 >>>=3B http://www.elegosoft.com | Ges= >>>>ch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berlin >>>=3B Handelregister: Amts= >>>>gericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>>=3B >>>>dy> >>>>= >>>> >>>>--_bffd762c-5e48-4bab-ae69-e6ec348c2ed8_-- From jay.krell at cornell.edu Sun Apr 5 14:56:07 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 5 Apr 2009 12:56:07 +0000 Subject: [M3devel] runpath/unshipped vs. shipped binaries Message-ID: Hey..I have a crazy notion that maybe "ship" should first "relink". I've seen this thing..when I watch thw grass grow..I mean autoconf output run.. "how to embed full paths upon install"..."relink"... on some systems.. and I think..geez..what a waste, instead of just copying files, first they get relinked. Now..I find myself wanting something this and it seems maybe only this can provide. Let's limit discusion to Linux for now. These issues are not unique to it. But the area is full of confusing variables enough. When I build a "regular" build, historically, on Linux, binaries have a big bunch of paths run together in them, like: /cm3/pkg/m3core/AMD64_LINUX:/cm3/pkg/libm3/AMD64_LINUX:etc. Maybe maybe each one directory is associated with each one library, though I don't think so. This is called the "run path" and is where dependent shared libraries are sought, among other places. $LD_LIBRARY_PATH is another place but there is some general vague intent that "real" binaries shouldn't depend on that, that it is only for "ad hoc development mode". These full paths are specific to my machine. Other people might have /usr/local/cm3/pkg. Or whatever. Now, today I have made things a bit better. The first path is $ORIGIN/../lib. $ORIGIN is a special syntax for "The directory with the executable". That really is not a sufficient mechanism, but it is a small step forwarder. YOu want relativity from the referencing file, not just the executable. Or something more abstract not dealing with paths at all.. Now, when I make a distribution, I build everything in /tmp/tmprandom. These paths are in the binaries produce. Possibly preceded by $ORIGIN/../lib, but still, I'd rather not "infect" the binaries with these paths. Now, we also run binaries before they are installed -- PklFonts in particular. And user should be expected to be able to run uninstalled binaries. SO long story long... I suggest relink immediately prior to "ship". But this link will omit the bulk of -Wl,-rpath chunks, leaving only the -Wl,-rpath $ORIGIN/../lib. Thoughts? My "research" so far only applies to Linux. Maybe the prepending of $ORIGIN/../lib is enough mitigation. It does bug me though that if you move the binaries around such that ../lib is not correct, and you happen to have the same /tmp/tmprandom/... on your system that I had..very unlikely I realize.. that you will "unintentionally" load the "wrong" file. I'm not super keen on making these changes either..actually digging through and changing all the relevant Modula-3.... Other options include something like the M3_NEED_STANDALONE_LINKS option. Or maybe this is kind of novel/clever/reasonable, always building standalone and shared, standlone named plain "foo", shared/dynamic named "foo.dynamic", and have ship install the dynamic one, built with just -Wl,-rpath,$ORIGIN? This would waste a lot of time and diskspace for rarely used files though. Well, duh, a little less wasteful, when building dynamic, build two versions, both dynamic, one with the one small rpath, one with the usual larger one? This is easier. However if you assume a high build/run/debug to it works/install ratio, this is also wasteful. I come back to the original -- relink upon ship. Again, I'm not super excited to do this work, but it really does seem like the right thing. More generally, if you think about systems that don't support $ORIGIN and you think about some of the Modula-3 distribution formats, relinkin during setup/install of a "distribution" is also a good albeit onerous idea. There's this general theme around "how much of the build occurs on one machine vs. the machine the binaries will run on" and "stopping the build near the end, and finishing it later on another machine". - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 5 14:59:24 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 5 Apr 2009 12:59:24 +0000 Subject: [M3devel] some new archives -- AMD64_LINUX and PPC_DARWIN Message-ID: some new archives I put up PPC_DARWIN and AMD64_LINUX binaries on http://modula3.elegosoft.com/cm3/uploaded-archives. PPC_DARWIN still has the usually crashing formsvbt. I've started building Solaris 5.4 locally to see if it has the bug and then will proceed from there... AMD64_LINUX has paths like /tmp/tmprandom, and $ORIGIN/../lib in it, as mentioned in my other mail. AMD64_LINUX built easily starting with the earlier archives there. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.m.bates at cox.net Mon Apr 6 03:45:15 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Sun, 05 Apr 2009 20:45:15 -0500 Subject: [M3devel] small objects In-Reply-To: References: <200903300333.n2U3XBME062502@camembert.async.caltech.edu> Message-ID: <49D95EAB.8020802@cox.net> I spent quite a bit of time playing with a more general system where there is a set of "tagged" types, with (an implementation-defined subrange of) INTEGER and a reference type both being a subtype of a tagged type. It might have been tolerable, if it weren't for the interaction with object subtypes and opaque types, which quickly gets deep into a deep linguistic tar pit. Tony's approach is much simpler and would serve what I see as the need. It does sacrifice any static checking of what reference type is being tagged, and will also require an extra runtime ISTYPE/TYPECASE. Would INTEGER and REFANY be assignable to TAGGED, or would there also need to be an explicit conversion in that direction too, say VAL(x, TAGGED)? I think I favor the explicit conversion here. It is a bit inconsistent with the usual Modula-3 assignability philosophy, but not requiring the explicit conversion already gets your toes into tar. We would have to have something more like ISTYPE, though, which will tell which type the value belongs to without risking a runtime error, which VAL would do. An intermediate approach might be to have a set of tagged types constructed by, say, TAGGED T, where I is a reference type, but with no subtype relations on them at all, thus still requiring the explicit conversions and checks. I do want to say, I _really_ want this capability somehow. I have an ADT module whose internal data structure, for full generality, needs to have two heap objects (the second because it has nonstatic size) and 11 total words counting the orginal pointer, in the case of values that would fit directly into the "pointer" word. Moreover, these small cases are in the great majority. Besides the 11-to-one increase in actual occupied space, there is extra time for allocation, periodic tracing, and collection, space loss due to heap fragmentation, and time/space tradeoff loss due to reduced locality of reference. So sometimes, it would be a big performance gain if we could do it. Tony Hosking wrote: > It is a much more pervasive hack than I would be comfortable with > since it touches on the compiler (for all the type operations) as well > as the run-time system in ways that are pretty gross. I would much > rather have a new TAGGED builtin. ISTYPE would not work on it since > that only works on references. The only thing you need is a way to > extract the value -- we could overload VAL(x, T) where x can be a > TAGGED and T can be REFANY or INTEGER. > > From carson at taltos.org Mon Apr 6 05:17:02 2009 From: carson at taltos.org (Carson Gaspar) Date: Sun, 05 Apr 2009 20:17:02 -0700 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: References: Message-ID: <49D9742E.6080100@taltos.org> Jay wrote: ... > When I build a "regular" build, historically, on Linux, > binaries have a big bunch of paths run together in them, like: > > > /cm3/pkg/m3core/AMD64_LINUX:/cm3/pkg/libm3/AMD64_LINUX:etc. ... > Now, today I have made things a bit better. > > > The first path is $ORIGIN/../lib. > $ORIGIN is a special syntax for "The directory with the executable". > That really is not a sufficient mechanism, but it is a small step forwarder. > YOu want relativity from the referencing file, not just the executable. > Or something more abstract not dealing with paths at all.. If you're saying that today you produce binaries with an RPATH of: $ORIGIN/../lib:/cm3/pkg/m3core/AMD64_LINUX:... That's just... horrid. Assuming all of your libraries are in ${exe_path}/../lib, you need exactly one RPATH entry: $ORIGIN/../lib Get rid of _all_ the other "-R foo" link arguments, and all will be well. No need to relink if you link properly the first time. -- Carson From jay.krell at cornell.edu Mon Apr 6 06:23:14 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 6 Apr 2009 04:23:14 +0000 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: <49D9742E.6080100@taltos.org> References: <49D9742E.6080100@taltos.org> Message-ID: - The horrid RPATH is not my doing. It has "always" been that way. - The horrid RPATH is needed, for running not installed binaries, a very real scenario, - Jay ---------------------------------------- > Date: Sun, 5 Apr 2009 20:17:02 -0700 > From: carson at taltos.org > To: m3devel at elegosoft.com > Subject: Re: [M3devel] runpath/unshipped vs. shipped binaries > > Jay wrote: > ... >> When I build a "regular" build, historically, on Linux, >> binaries have a big bunch of paths run together in them, like: >> >> >> /cm3/pkg/m3core/AMD64_LINUX:/cm3/pkg/libm3/AMD64_LINUX:etc. > ... >> Now, today I have made things a bit better. >> >> >> The first path is $ORIGIN/../lib. >> $ORIGIN is a special syntax for "The directory with the executable". >> That really is not a sufficient mechanism, but it is a small step forwarder. >> YOu want relativity from the referencing file, not just the executable. >> Or something more abstract not dealing with paths at all.. > > If you're saying that today you produce binaries with an RPATH of: > > $ORIGIN/../lib:/cm3/pkg/m3core/AMD64_LINUX:... > > That's just... horrid. > > Assuming all of your libraries are in ${exe_path}/../lib, you need > exactly one RPATH entry: > > $ORIGIN/../lib > > Get rid of _all_ the other "-R foo" link arguments, and all will be > well. No need to relink if you link properly the first time. > > -- > Carson From hosking at cs.purdue.edu Mon Apr 6 07:08:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 6 Apr 2009 15:08:29 +1000 Subject: [M3devel] small objects In-Reply-To: <49D95E70.6000004@wichita.edu> References: <200903300333.n2U3XBME062502@camembert.async.caltech.edu> <49D95E70.6000004@wichita.edu> Message-ID: <40B7AD71-FBDD-4321-837F-D294DD4A3D45@cs.purdue.edu> I like the notion of having a TAGGED INTEGER type that is a hybrid ordinal/reference. Subtyping rules for references would now be as follows: NULL <: REF T <: REFANY TAGGED INTEGER <: REF T <: REFANY ROOT <: REFANY NULL <: T OBJECT ... END <: T TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: REFANY, not T <: ADDRESS) Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference type. Values of TAGGED INTEGER are non-pointer values similar to the value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and NARROW(x, TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to ISTYPE(x, NULL), NARROW(x, NULL), and TYPECODE(NULL). Because TAGGED INTEGER is an ordinal we can extract the integer value it holds using ORD(x). Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED INTEGER). ***The only problem with this scheme is how to efficiently perform run- time tests for dereferencing NULL, and TAGGED INTEGER?*** So, here is a slightly less elegant alternative that is probably straightforward to implement. Introduce a separate TAGGED hierarchy. NULL <: REF T <: REFANY NULL <: UNTRACED REF T <: ADDRESS TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. ROOT <: REFANY TAGGED ROOT <: TAGGED REFANY NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED REFANY. This way, tagged references only need a run-time test for the tag on dereference (we can throw an "attempt to dereference TAGGED INTEGER" at run time, just like we throw "attempt to dereference NIL" for untagged references). This check can be a straightforward test of the low bit tag. Of course, the weird thing here is now that we don't have a single NULL value for TAGGED references --- we have multiple null values VAL(x, TAGGED INTEGER). Instead of asking "x == NIL" we must ask "ISTYPE(x, TAGGED INTEGER)". Of course, because TAGGED INTEGER is an ordinal, we can also perform the usual ordinal operations like INC(x), DEC(x), wherever x is typed TAGGED INTEGER. On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: > I spent quite a bit of time playing with a more general system where > there is a set of "tagged" types, with (an implementation-defined > subrange of) INTEGER and a reference type both being a subtype of a > tagged type. It might have been tolerable, if it weren't for the > interaction with object subtypes and opaque types, which quickly > gets deep into a deep linguistic tar pit. > > Tony's approach is much simpler and would serve what I see as the > need. It does sacrifice any static checking of what reference type > is being tagged, and will also require an extra runtime ISTYPE/ > TYPECASE. > > Would INTEGER and REFANY be assignable to TAGGED, or would there > also need to be an explicit conversion in that direction too, say > VAL(x, TAGGED)? I think I favor the explicit conversion here. It > is a bit inconsistent with the usual Modula-3 assignability > philosophy, > but not requiring the explicit conversion already gets your toes > into tar. > > We would have to have something more like ISTYPE, though, which will > tell which type the value belongs to without risking a runtime error, > which VAL would do. > > An intermediate approach might be to have a set of tagged types > constructed by, say, TAGGED T, where I is a reference type, but > with no subtype relations on them at all, thus still requiring > the explicit conversions and checks. > > I do want to say, I _really_ want this capability somehow. I have > an ADT module whose internal data structure, for full generality, > needs to have two heap objects (the second because it has nonstatic > size) and 11 total words counting the orginal pointer, in the case of > values that would fit directly into the "pointer" word. Moreover, > these small cases are in the great majority. > > Besides the 11-to-one increase in actual occupied space, there > is extra time for allocation, periodic tracing, and collection, space > loss due to heap fragmentation, and time/space tradeoff loss due to > reduced locality of reference. So sometimes, it would be a big > performance gain if we could do it. > > > Tony Hosking wrote: >> It is a much more pervasive hack than I would be comfortable with >> since it touches on the compiler (for all the type operations) as >> well >> as the run-time system in ways that are pretty gross. I would much >> rather have a new TAGGED builtin. ISTYPE would not work on it since >> that only works on references. The only thing you need is a way to >> extract the value -- we could overload VAL(x, T) where x can be a >> TAGGED and T can be REFANY or INTEGER. >> From jay.krell at cornell.edu Mon Apr 6 07:14:01 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 6 Apr 2009 05:14:01 +0000 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: <49D9742E.6080100@taltos.org> References: <49D9742E.6080100@taltos.org> Message-ID: Here's another point I just discovered...granted, I did say I was only talking about Linux..but on Solaris, I just learned about -s on ldd: ldd -s /cm3/bin/Juno find object=libm3.so.5; required by /home/jay/cm3/bin/../lib/libjuno-compiler.so.5 search path=/usr/local/lib (LD_LIBRARY_PATH) trying path=/usr/local/lib/libm3.so.5 search path=$ORIGIN/../lib:/cm3/pkg/juno-machine/SOLgnu:/cm3/pkg/libm3/SOLgnu:/cm3/pkg/m3core/SO Lgnu (RPATH from file /home/jay/cm3/bin/../lib/libjuno-compiler.so.5) trying path=/home/jay/cm3/pkg/juno-compiler/SOLgnu/../lib/libm3.so.5 trying path=/cm3/pkg/juno-machine/SOLgnu/libm3.so.5 trying path=/cm3/pkg/libm3/SOLgnu/libm3.so.5 find object=libm3core.so.5; required by /home/jay/cm3/bin/../lib/libjuno-compiler.so.5 search path=/usr/local/lib (LD_LIBRARY_PATH) trying path=/usr/local/lib/libm3core.so.5 search path=$ORIGIN/../lib:/cm3/pkg/juno-machine/SOLgnu:/cm3/pkg/libm3/SOLgnu:/cm3/pkg/m3core/SO Lgnu (RPATH from file /home/jay/cm3/bin/../lib/libjuno-compiler.so.5) trying path=/home/jay/cm3/pkg/juno-compiler/SOLgnu/../lib/libm3core.so.5 trying path=/cm3/pkg/juno-machine/SOLgnu/libm3core.so.5 Which shows us that $ORIGIN is not the executable, it is the referencing file. Could be ipmlemented to be "both", have it search both, but I don't think it is. This begs for another large change. Don't ship any /cm3/pkg/foo/platform/libfoo.so. Ship only /cm3/lib/libfoo.so The second is already a symlink to the first anyway. And then add $ORIGIN and $ORIGIN/../lib to RPATH. Heck -- might as well just shove it all into /cm3/bin and just use $ORIGIN, kind of like how NT works..ok, I know that last step wouldn't likely be popular and it isn't important -- keep lib and bin split. One of the qeustions is -- do we believe we have a "useful" "hierarchy", or the world is really kind of flat anyway, embrace it? Given that lib is full of symlinks into pkg, seems like flat is the case and the hierarchy just looks nice, at least for .so file placement (*.i3/*.m3/*.m3x/*.a files would remain asis). I also think there's an issue here that..the ship structure and source structure should perhaps have been kept in parallel. That might allow for relative rpaths to work for uninstalled or installed binaries. Except, the source structure has more hierarchy than the ship structure, always. That is, shipping is a rearrangement of the source structure -- insert "pkg" and flatten. src/m3-libs/m3core => install/pkg/m3core src/m3-foo/bar => install/pkg/bar If instead it went: src/m3-libs/m3core => install/m3-libs/m3core src/m3-foo/bar => install/m3-foo/bar or: src/m3-libs/m3core => install/pkg/m3-libs/m3core src/m3-foo/bar => install/pkg/m3-foo/bar Then relative paths could probably be used in both roots with the same meaning. But they can't. I come back to..I guess..removing all the .so files from the pkg store, or reversing the sense of the symlinks. Or heck, just telling the linker -L /cm3/lib instead of -L/cm3/pkg/foo. That last step might be trivial and helpful. I'll try it, later. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: carson at taltos.org; m3devel at elegosoft.com > Subject: RE: [M3devel] runpath/unshipped vs. shipped binaries > Date: Mon, 6 Apr 2009 04:23:14 +0000 > > > > - The horrid RPATH is not my doing. It has "always" been that way. > > - The horrid RPATH is needed, for running not installed binaries, a very real scenario, > > - Jay > > > > ---------------------------------------- >> Date: Sun, 5 Apr 2009 20:17:02 -0700 >> From: carson at taltos.org >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] runpath/unshipped vs. shipped binaries >> >> Jay wrote: >> ... >>> When I build a "regular" build, historically, on Linux, >>> binaries have a big bunch of paths run together in them, like: >>> >>> >>> /cm3/pkg/m3core/AMD64_LINUX:/cm3/pkg/libm3/AMD64_LINUX:etc. >> ... >>> Now, today I have made things a bit better. >>> >>> >>> The first path is $ORIGIN/../lib. >>> $ORIGIN is a special syntax for "The directory with the executable". >>> That really is not a sufficient mechanism, but it is a small step forwarder. >>> YOu want relativity from the referencing file, not just the executable. >>> Or something more abstract not dealing with paths at all.. >> >> If you're saying that today you produce binaries with an RPATH of: >> >> $ORIGIN/../lib:/cm3/pkg/m3core/AMD64_LINUX:... >> >> That's just... horrid. >> >> Assuming all of your libraries are in ${exe_path}/../lib, you need >> exactly one RPATH entry: >> >> $ORIGIN/../lib >> >> Get rid of _all_ the other "-R foo" link arguments, and all will be >> well. No need to relink if you link properly the first time. >> >> -- >> Carson From carson at taltos.org Mon Apr 6 08:54:00 2009 From: carson at taltos.org (Carson Gaspar) Date: Sun, 05 Apr 2009 23:54:00 -0700 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: References: <49D9742E.6080100@taltos.org> Message-ID: <49D9A708.1050101@taltos.org> Jay wrote: > > - The horrid RPATH is not my doing. It has "always" been that way. > > - The horrid RPATH is needed, for running not installed binaries, a very real scenario, No. It's not needed. Please provide a use case where a crappy polluted RPATH provides any benefit, and be specific. If you need to _temporarily_ run binaries in the build tree, where ${exe_path}/../lib does not contain libraries, set LD_LIBRARY_PATH (which overrides RPATH). Or, better still, fix the build to put things in $foo/bin and $foo/lib before you run them. Hard-coding /tmp/frobnitz/blah/lib in RPATH is _extremely_ bad from many perspectives, including security. Don't do it. No really, don't. -- Carson From carson at taltos.org Mon Apr 6 09:00:27 2009 From: carson at taltos.org (Carson Gaspar) Date: Mon, 06 Apr 2009 00:00:27 -0700 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: References: <49D9742E.6080100@taltos.org> Message-ID: <49D9A88B.4070109@taltos.org> Jay wrote: > Which shows us that $ORIGIN is not the executable, it is the referencing file. > Could be ipmlemented to be "both", have it search both, but I don't think it is. $ORIGIN is the location of the object being linked. That may be the executable, or may be a shared library. So if you have: foo.so bar.so, linked against foo.so baz.exe, linked against bar.so And RPATH for all of them is "$ORIGIN/../lib", when you execute baz.exe, it looks for bar.so in $path_to_baz/../lib/bar.so. It then looks for foo.so in $path_to_bar/../lib/foo.so. Note that this is _different_ from linking baz.exe _explicitly_ against foo.so, instead of _implicitly_ via bar.so. Make sure the RPATH you use when linking objects, whether they be executables or shared objects, is correct. -- Carson From jay.krell at cornell.edu Mon Apr 6 10:08:50 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 6 Apr 2009 08:08:50 +0000 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: <49D9A708.1050101@taltos.org> References: <49D9742E.6080100@taltos.org> <49D9A708.1050101@taltos.org> Message-ID: Well, the big polluted runpath is how Modula-3 has always built things. The only reason for /tmp/tmprandom is because I build up an entire new install from scratch. Otherwise it would be /usr/local/cm3/pkg/... or such. If you look at the distributions Olaf has put out you can see he does similar. I think the Tinderbox builds are the same. This is tied up in the Quake code: M3_SPLIT_LIBNAMES = TRUE % --- split library names and pass -L/-l arguments to the linker if not defined("M3_SHARED_LIB_ARG") M3_SHARED_LIB_ARG = "-Wl,-R" end plus the fact that "install" is very interested in a "package store" and each set of files going in their own directory, and "imported libraries" coming from there, not a flattened /cm3/lib. I'm not sure I like it either, but it has been this way. Running uninstalled binaries seems very reasonable to me, and is also a long standing practise in the cm3 system, but maybe only one instance. I'm trying to find a way to - have a small portable runpath - allow uninstalled binaries to work but I think you might be right that LD_LIBRARY_PATH is how to get the second scenario to work. But that does require LD_LIBRARY_PATH be set within making a distribution. Or maybe just build PklFonts standalone, or ship it and then run it. Standalone is easiest. But this is really tying people's hands it seems, in terms of how much uninstalled binaries work. Maybe there should be an option to install .sos to /usr/lib so LD_LIBRARY_PATH can be left alone? I'm still looking into it all though. Could be that -L/cm3/pkg/foo -lfoo is fine, as long as the -R is dropped. I'll have to check that the full path to libfoo.so isn't recorded, but just the leaf libfoo.so. I guess for .so files we can use rpath like $ORIGIN/../../../lib. Where the ".." are backing up over pkg/package/platform to get back to root. - Jay ---------------------------------------- > Date: Sun, 5 Apr 2009 23:54:00 -0700 > From: carson at taltos.org > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] runpath/unshipped vs. shipped binaries > > Jay wrote: >> >> - The horrid RPATH is not my doing. It has "always" been that way. >> >> - The horrid RPATH is needed, for running not installed binaries, a very real scenario, > > No. It's not needed. Please provide a use case where a crappy polluted > RPATH provides any benefit, and be specific. > > If you need to _temporarily_ run binaries in the build tree, where > ${exe_path}/../lib does not contain libraries, set LD_LIBRARY_PATH > (which overrides RPATH). Or, better still, fix the build to put things > in $foo/bin and $foo/lib before you run them. > > Hard-coding /tmp/frobnitz/blah/lib in RPATH is _extremely_ bad from many > perspectives, including security. Don't do it. No really, don't. > > -- > Carson From carson at taltos.org Mon Apr 6 10:35:42 2009 From: carson at taltos.org (Carson Gaspar) Date: Mon, 06 Apr 2009 01:35:42 -0700 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: References: <49D9742E.6080100@taltos.org> <49D9A708.1050101@taltos.org> Message-ID: <49D9BEDE.1010603@taltos.org> BTW, I'm glad you're working on this, I just want to make sure we end up someplace better ;-) Jay wrote: > Well, the big polluted runpath is how Modula-3 has always built > things. The only reason for /tmp/tmprandom is because I build up an > entire new install from scratch. Otherwise it would be > /usr/local/cm3/pkg/... or such. If you look at the distributions Olaf > has put out you can see he does similar. I think the Tinderbox builds > are the same. The problem with using /tmp is that _any_ user can throw their own .so's in there. Bogus /usr/... paths are still unfortunate, but not a security nightmare like /tmp/... paths are. It may be that re-organizing the build system to behave better is more work than you have time for at the moment, and throwing in a $ORIGIN RPATH isn't a bad thing even if you don't fix the rest. But please don't ship binaries with an RPATH containing /tmp - someone will hurt themselves. -- Carson From jay.krell at cornell.edu Mon Apr 6 10:37:24 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 6 Apr 2009 08:37:24 +0000 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: <49D9A708.1050101@taltos.org> References: <49D9742E.6080100@taltos.org> <49D9A708.1050101@taltos.org> Message-ID: ok, nevermind, thanks Carson, that helped. Like you said: RUNPATH shall be small and portable and just $ORIGIN/../lib. I saw $ORIGIN within pkg and not lib, but now I see it only within lib. Maybe a clean rebuild fixed that, not sure (I had been just deleting all the .a files). If it flips and becomes consistently pkg, I'll try ORIGIN/../../../lib. Too many dot dots seems bad, could be escaping some part of the file system into who-knows-where. I have an idea you could verify your location something like $ORIGIN/../../../pkg/package/platform/.../../../lib. The extra traversal "../../../pkg/package/platform" ensure things are kind of how you expect, though wasteful. Anyway, hopefully not this. Running uninstalled binaries shall require either LD_LIBRARY_PATH or build_standalone(). m3tests uses build_standalone. This is maybe why more stuff is build_standalone -- anything that runs uninstalled when doing buildlobal, the various stub code generators. Systems that don't support $ORIGIN, hopefully that is not many, such as NetBSD, will require LD_LIBRARY_PATH. Another option is to relink on the target and point at /cm3/lib or such, but that requires the notion of relinking on target, which is in limbo. No full path is likely to be baked into any binary, for any system. Darwin is different but achieves similar goals. I changed my configuration files for PPC_DARWIN. I don't have the other architectures available (hm, maybe non-OSX Darwin in a VM, maybe). NT386 is different but achieves similar goals. There all the .exes and .dlls are shipped to the same directory. .exe directories are generally searched for .dlls. A lot of this is still speculative. Solaris seems in good shape, and Darwin, but I have to look into others still. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: carson at taltos.org > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] runpath/unshipped vs. shipped binaries > Date: Mon, 6 Apr 2009 08:08:50 +0000 > > > Well, the big polluted runpath is how Modula-3 has always built things. > The only reason for /tmp/tmprandom is because I build up an entire new install from scratch. Otherwise it would be /usr/local/cm3/pkg/... or such. > If you look at the distributions Olaf has put out you can see he does similar. > I think the Tinderbox builds are the same. > > > This is tied up in the Quake code: > M3_SPLIT_LIBNAMES = TRUE > % --- split library names and pass -L/-l arguments to the linker > if not defined("M3_SHARED_LIB_ARG") > M3_SHARED_LIB_ARG = "-Wl,-R" > end > > plus the fact that "install" is very interested in a "package store" and each set of files going in their own directory, and "imported libraries" coming from there, not a flattened /cm3/lib. > > > I'm not sure I like it either, but it has been this way. > > Running uninstalled binaries seems very reasonable to me, and is also a long standing practise in the cm3 system, but maybe only one instance. > > > I'm trying to find a way to > - have a small portable runpath > - allow uninstalled binaries to work > > but I think you might be right that LD_LIBRARY_PATH is how to get the second scenario to work. But that does require LD_LIBRARY_PATH be set within making a distribution. Or maybe just build PklFonts standalone, or ship it and then run it. Standalone is easiest. > > But this is really tying people's hands it seems, in terms of how much uninstalled binaries work. Maybe there should be an option to install .sos to /usr/lib so LD_LIBRARY_PATH can be left alone? > > > I'm still looking into it all though. > Could be that -L/cm3/pkg/foo -lfoo is fine, as long as the -R is dropped. > I'll have to check that the full path to libfoo.so isn't recorded, but just the leaf libfoo.so. > > I guess for .so files we can use rpath like $ORIGIN/../../../lib. > Where the ".." are backing up over pkg/package/platform to get back to root. > > > > - Jay > > > ---------------------------------------- >> Date: Sun, 5 Apr 2009 23:54:00 -0700 >> From: carson at taltos.org >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] runpath/unshipped vs. shipped binaries >> >> Jay wrote: >>> >>> - The horrid RPATH is not my doing. It has "always" been that way. >>> >>> - The horrid RPATH is needed, for running not installed binaries, a very real scenario, >> >> No. It's not needed. Please provide a use case where a crappy polluted >> RPATH provides any benefit, and be specific. >> >> If you need to _temporarily_ run binaries in the build tree, where >> ${exe_path}/../lib does not contain libraries, set LD_LIBRARY_PATH >> (which overrides RPATH). Or, better still, fix the build to put things >> in $foo/bin and $foo/lib before you run them. >> >> Hard-coding /tmp/frobnitz/blah/lib in RPATH is _extremely_ bad from many >> perspectives, including security. Don't do it. No really, don't. >> >> -- >> Carson From jay.krell at cornell.edu Mon Apr 6 10:43:52 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 6 Apr 2009 08:43:52 +0000 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: <49D9BEDE.1010603@taltos.org> References: <49D9742E.6080100@taltos.org> <49D9A708.1050101@taltos.org> <49D9BEDE.1010603@taltos.org> Message-ID: Good point thanks, /usr/random better than /tmp/random. I'd build as root, so you are safe from non-root, or somesuch. Hopefully it'll become moot. I have made progress inserting $ORIGIN at the front already. I need to double check if that is /cm3/lib or /cm3/pkg/foo/linuxlibc6. Hopefully /cm3/lib. And then see about removing the rest. Solaris is looking good, at least. NetBSD doesn't support $origin. (but hey, my NetBSD machine is booted to FreeBSD currently, where, besides these issues, I want to switch to the new/small/portable Unix/*.i3 files :) ) Ok, Linux/x86 is looking good. Just a tad ugly, you end up with "../lib" for each level in the dependency tree: ldd -v /cm3/bin/Juno: libm3X11R4.so.5 => /home/jay/cm3/bin/../lib/../lib/libm3X11R4.so.5 but that's ok. Pray tell, what's the difference between RPATH and RUNPATH? objdump -f -x /cm3/bin/Juno Dynamic Section: NEEDED libjuno-compiler.so.5 NEEDED libjuno-machine.so.5 NEEDED libm3formsvbt.so.5 NEEDED libm3vbtkit.so.5 NEEDED libm3ui.so.5 NEEDED libm3netobj.so.5 NEEDED libm3.so.5 NEEDED libm3core.so.5 NEEDED libc.so.6 RPATH $ORIGIN/../lib RUNPATH $ORIGIN/../lib - Jay ---------------------------------------- > Date: Mon, 6 Apr 2009 01:35:42 -0700 > From: carson at taltos.org > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] runpath/unshipped vs. shipped binaries > > BTW, I'm glad you're working on this, I just want to make sure we end up > someplace better ;-) > > Jay wrote: >> Well, the big polluted runpath is how Modula-3 has always built >> things. The only reason for /tmp/tmprandom is because I build up an >> entire new install from scratch. Otherwise it would be >> /usr/local/cm3/pkg/... or such. If you look at the distributions Olaf >> has put out you can see he does similar. I think the Tinderbox builds >> are the same. > > The problem with using /tmp is that _any_ user can throw their own .so's > in there. Bogus /usr/... paths are still unfortunate, but not a security > nightmare like /tmp/... paths are. > > It may be that re-organizing the build system to behave better is more > work than you have time for at the moment, and throwing in a $ORIGIN > RPATH isn't a bad thing even if you don't fix the rest. But please don't > ship binaries with an RPATH containing /tmp - someone will hurt themselves. > > -- > Carson From carson at taltos.org Mon Apr 6 10:51:40 2009 From: carson at taltos.org (Carson Gaspar) Date: Mon, 06 Apr 2009 01:51:40 -0700 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: References: <49D9742E.6080100@taltos.org> <49D9A708.1050101@taltos.org> <49D9BEDE.1010603@taltos.org> Message-ID: <49D9C29C.9000404@taltos.org> Jay wrote: > Pray tell, what's the difference between RPATH and RUNPATH? > > objdump -f -x /cm3/bin/Juno > > Dynamic Section: > NEEDED libjuno-compiler.so.5 > NEEDED libjuno-machine.so.5 > NEEDED libm3formsvbt.so.5 > NEEDED libm3vbtkit.so.5 > NEEDED libm3ui.so.5 > NEEDED libm3netobj.so.5 > NEEDED libm3.so.5 > NEEDED libm3core.so.5 > NEEDED libc.so.6 > RPATH $ORIGIN/../lib > RUNPATH $ORIGIN/../lib AFAIK none. At least on Solaris they always point to the same string address. I suspect one is legacy and the other is ELF standard. -- Carson From jay.krell at cornell.edu Mon Apr 6 14:33:15 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 6 Apr 2009 12:33:15 +0000 Subject: [M3devel] some new archives -- AMD64_LINUX, PPC_DARWIN, NT386 Message-ID: NT386 now also. (This part is not difficult..) - Jay ________________________________ > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: some new archives -- AMD64_LINUX and PPC_DARWIN > Date: Sun, 5 Apr 2009 12:59:24 +0000 > > some new archives > > I put up PPC_DARWIN and AMD64_LINUX binaries on http://modula3.elegosoft.com/cm3/uploaded-archives. > > > PPC_DARWIN still has the usually crashing formsvbt. > I've started building Solaris 5.4 locally to see if it has the bug > > and then will proceed from there... > > > > AMD64_LINUX has paths like /tmp/tmprandom, and $ORIGIN/../lib in it, as mentioned > in my other mail. > > > AMD64_LINUX built easily starting with the earlier archives there. > > - Jay From wagner at elegosoft.com Mon Apr 6 14:42:42 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 06 Apr 2009 14:42:42 +0200 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: References: <49D9742E.6080100@taltos.org> <49D9A708.1050101@taltos.org> Message-ID: <20090406144242.almwq5chwgo04kwo@mail.elegosoft.com> Quoting Jay : > Running uninstalled binaries shall require either LD_LIBRARY_PATH > or build_standalone(). m3tests uses build_standalone. This is maybe > why more stuff is build_standalone -- anything that runs uninstalled > when doing buildlobal, the various stub code generators. Please just use build_standalone for all binaries that are needed by the build system itself. That shouldn't be many. Otherwise, I think setting LD_LIBRARY_PATH is acceptable. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Mon Apr 6 16:50:25 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 07:50:25 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Sun, 05 Apr 2009 20:45:15 CDT." <49D95EAB.8020802@cox.net> Message-ID: <200904061450.n36EoPk9085841@camembert.async.caltech.edu> Hi Rodney, I would like this capability too, but I am a bit wary of Tony's idea of changing the Modula-3 language---even in a "minor" way. I've been working for the last week or so on an application using the Modula-3 Toolkit, and I must say I have realized that the Modula-3 type system has a lot more subtleties than I thought. I would not want to make any real changes to it. There's a paper called "The Modula-3 Type System" by Cardelli, Donahue, Kalsow, and Nelson that is worth studying in detail before making any changes whatsoever, I think. Also remember that changes to the type system will affect m3tk and anything that depends on m3tk (which includes two or three stub generators in the main tree and who knows how many dependencies outside of it). I'm still not sure why we can't take the approach of Word.T . Make a RefanyOrInt.T that can safely be: 1. Tested whether it is a small integer or a REFANY 2. If a REFANY, be dereferenced as normal, *or* via RefanyOrInt.ToRefany 3. If a small integer, can be extracted via RefanyOrInt.ToInt 4. Created either as a small integer or a REFANY Any other operations on it (including ISTYPE and TYPECASE, at least when the object is a small integer) would result in a checked runtime error. Note that with the declaration "RefanyOrInt.T = REFANY", the current compiler will as far as I know not accept any operations on RefanyOrInt.T outside of ISTYPE, TYPECASE, and NARROW (explicit or implicit). I wouldn't be surprised if most of what I'm proposing already works (i.e., crashes with a checked runtime error as it should) with the current runtime. Anything that slips through would need to be fixed up with a one-bit check of the LSB of the REFANY for the operations mentioned above. Unfortunately this has to be done for operations on every REFANY, not just the new type. I think that Modula-3 programmers are already aware that using REFANYs involves forcing the runtime to do extra type-checking work, so they already know not to use them if they are looking for maximum performance, so I don't think that burdening operations on REFANY with an extra one-bit check is too onerous. An advantage of my proposal is that the amount of code in the new proposed library is truly diminutive. In fact, I think I posted pretty much that code to the list a few weeks ago. (If you missed it, it's http://www.async.caltech.edu/~mika/interp/ ) Mika "Rodney M. Bates" writes: >I spent quite a bit of time playing with a more general system where >there is a set of "tagged" types, with (an implementation-defined >subrange of) INTEGER and a reference type both being a subtype of a >tagged type. It might have been tolerable, if it weren't for the >interaction with object subtypes and opaque types, which quickly >gets deep into a deep linguistic tar pit. > >Tony's approach is much simpler and would serve what I see as the >need. It does sacrifice any static checking of what reference type >is being tagged, and will also require an extra runtime ISTYPE/TYPECASE. > >Would INTEGER and REFANY be assignable to TAGGED, or would there >also need to be an explicit conversion in that direction too, say >VAL(x, TAGGED)? I think I favor the explicit conversion here. It >is a bit inconsistent with the usual Modula-3 assignability philosophy, >but not requiring the explicit conversion already gets your toes into tar. > >We would have to have something more like ISTYPE, though, which will >tell which type the value belongs to without risking a runtime error, >which VAL would do. > >An intermediate approach might be to have a set of tagged types >constructed by, say, TAGGED T, where I is a reference type, but >with no subtype relations on them at all, thus still requiring >the explicit conversions and checks. > >I do want to say, I _really_ want this capability somehow. I have >an ADT module whose internal data structure, for full generality, >needs to have two heap objects (the second because it has nonstatic >size) and 11 total words counting the orginal pointer, in the case of >values that would fit directly into the "pointer" word. Moreover, >these small cases are in the great majority. > >Besides the 11-to-one increase in actual occupied space, there >is extra time for allocation, periodic tracing, and collection, space >loss due to heap fragmentation, and time/space tradeoff loss due to >reduced locality of reference. So sometimes, it would be a big >performance gain if we could do it. > > >Tony Hosking wrote: > It is a much more pervasive hack than I would be comfortable with >> since it touches on the compiler (for all the type operations) as well >> as the run-time system in ways that are pretty gross. I would much >> rather have a new TAGGED builtin. ISTYPE would not work on it since >> that only works on references. The only thing you need is a way to >> extract the value -- we could overload VAL(x, T) where x can be a >> TAGGED and T can be REFANY or INTEGER. >> >> From mika at async.caltech.edu Mon Apr 6 17:29:29 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 08:29:29 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Mon, 06 Apr 2009 15:08:29 +1000." <40B7AD71-FBDD-4321-837F-D294DD4A3D45@cs.purdue.edu> Message-ID: <200904061529.n36FTTn0086974@camembert.async.caltech.edu> Ah I should read my whole inbox before replying. I take it you would worry that in my proposal (to do this all in a library) the use of REFANY to store an integer could be abused somehow. That the Modula-3 type system (as it exists now) explicitly rules out doing such things, and therefore, a language change is necessary.... Mika Tony Hosking writes: >I like the notion of having a TAGGED INTEGER type that is a hybrid >ordinal/reference. > >Subtyping rules for references would now be as follows: > >NULL <: REF T <: REFANY >TAGGED INTEGER <: REF T <: REFANY > >ROOT <: REFANY >NULL <: T OBJECT ... END <: T >TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: REFANY, not >T <: ADDRESS) > >Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >type. Values of TAGGED INTEGER are non-pointer values similar to the >value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and NARROW(x, >TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to ISTYPE(x, >NULL), NARROW(x, NULL), and TYPECODE(NULL). > >Because TAGGED INTEGER is an ordinal we can extract the integer value >it holds using ORD(x). >Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >INTEGER). > >***The only problem with this scheme is how to efficiently perform run- >time tests for dereferencing NULL, and TAGGED INTEGER?*** > >So, here is a slightly less elegant alternative that is probably >straightforward to implement. Introduce a separate TAGGED hierarchy. > >NULL <: REF T <: REFANY >NULL <: UNTRACED REF T <: ADDRESS >TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY > >Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. > >ROOT <: REFANY >TAGGED ROOT <: TAGGED REFANY >NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY > >Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED >REFANY. > >This way, tagged references only need a run-time test for the tag on >dereference (we can throw an "attempt to dereference TAGGED INTEGER" >at run time, just like we throw "attempt to dereference NIL" for >untagged references). This check can be a straightforward test of the >low bit tag. Of course, the weird thing here is now that we don't >have a single NULL value for TAGGED references --- we have multiple >null values VAL(x, TAGGED INTEGER). Instead of asking "x == NIL" we >must ask "ISTYPE(x, TAGGED INTEGER)". > >Of course, because TAGGED INTEGER is an ordinal, we can also perform >the usual ordinal operations like INC(x), DEC(x), wherever x is typed >TAGGED INTEGER. > > >On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: > >> I spent quite a bit of time playing with a more general system where >> there is a set of "tagged" types, with (an implementation-defined >> subrange of) INTEGER and a reference type both being a subtype of a >> tagged type. It might have been tolerable, if it weren't for the >> interaction with object subtypes and opaque types, which quickly >> gets deep into a deep linguistic tar pit. >> >> Tony's approach is much simpler and would serve what I see as the >> need. It does sacrifice any static checking of what reference type >> is being tagged, and will also require an extra runtime ISTYPE/ >> TYPECASE. >> >> Would INTEGER and REFANY be assignable to TAGGED, or would there >> also need to be an explicit conversion in that direction too, say >> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >> is a bit inconsistent with the usual Modula-3 assignability >> philosophy, >> but not requiring the explicit conversion already gets your toes >> into tar. >> >> We would have to have something more like ISTYPE, though, which will >> tell which type the value belongs to without risking a runtime error, >> which VAL would do. >> >> An intermediate approach might be to have a set of tagged types >> constructed by, say, TAGGED T, where I is a reference type, but >> with no subtype relations on them at all, thus still requiring >> the explicit conversions and checks. >> >> I do want to say, I _really_ want this capability somehow. I have >> an ADT module whose internal data structure, for full generality, >> needs to have two heap objects (the second because it has nonstatic >> size) and 11 total words counting the orginal pointer, in the case of >> values that would fit directly into the "pointer" word. Moreover, >> these small cases are in the great majority. >> >> Besides the 11-to-one increase in actual occupied space, there >> is extra time for allocation, periodic tracing, and collection, space >> loss due to heap fragmentation, and time/space tradeoff loss due to >> reduced locality of reference. So sometimes, it would be a big >> performance gain if we could do it. >> >> >> Tony Hosking wrote: >>> It is a much more pervasive hack than I would be comfortable with >>> since it touches on the compiler (for all the type operations) as >>> well >>> as the run-time system in ways that are pretty gross. I would much >>> rather have a new TAGGED builtin. ISTYPE would not work on it since >>> that only works on references. The only thing you need is a way to >>> extract the value -- we could overload VAL(x, T) where x can be a >>> TAGGED and T can be REFANY or INTEGER. >>> From mika at async.caltech.edu Mon Apr 6 17:32:56 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 08:32:56 -0700 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: Your message of "Mon, 06 Apr 2009 14:42:42 +0200." <20090406144242.almwq5chwgo04kwo@mail.elegosoft.com> Message-ID: <200904061532.n36FWunc087102@camembert.async.caltech.edu> Would this mean that users of CM3 have to set LD_LIBRARY_PATH for things they build themselves but don't ship? I almost never ship binaries because I don't want user "mika" to have write access to the place whither the Modula-3 compiler normally ships. But I use them... from cron and other places. Other users may use them too... Mika Olaf Wagner writes: >Quoting Jay : > >> Running uninstalled binaries shall require either LD_LIBRARY_PATH >> or build_standalone(). m3tests uses build_standalone. This is maybe >> why more stuff is build_standalone -- anything that runs uninstalled >> when doing buildlobal, the various stub code generators. > >Please just use build_standalone for all binaries that are needed >by the build system itself. That shouldn't be many. > >Otherwise, I think setting LD_LIBRARY_PATH is acceptable. > >Olaf >-- >Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb??ude 12, 13355 Berlin, Germany >phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 6 17:51:19 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 06 Apr 2009 17:51:19 +0200 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: <200904061532.n36FWunc087102@camembert.async.caltech.edu> References: <200904061532.n36FWunc087102@camembert.async.caltech.edu> Message-ID: <20090406175119.5nknbzf9dwkcwkks@mail.elegosoft.com> Quoting Mika Nystrom : > > Would this mean that users of CM3 have to set LD_LIBRARY_PATH for > things they build themselves but don't ship? Probably. If the libraries cannot be located by the system in a standard path, it needs help. We could probably come up with a small script which prints the needed settings for a local M3 workspace. > I almost never ship binaries because I don't want user "mika" to > have write access to the place whither the Modula-3 compiler normally > ships. But I use them... from cron and other places. Other users > may use them too... Have you got a better suggestion? This is really not an M3 problem, but a general Unix question. How should dynamic shared object files be found (especially, when they are scattered across an M3 workspace)? If we burn in the local paths, we need to relink the objects before shipping. I also wouldn't like it when some installed program stops to work because the original creator made changes to his home directories... Any ideas? Olaf > Mika > > Olaf Wagner writes: >> Quoting Jay : >> >>> Running uninstalled binaries shall require either LD_LIBRARY_PATH >>> or build_standalone(). m3tests uses build_standalone. This is maybe >>> why more stuff is build_standalone -- anything that runs uninstalled >>> when doing buildlobal, the various stub code generators. >> >> Please just use build_standalone for all binaries that are needed >> by the build system itself. That shouldn't be many. >> >> Otherwise, I think setting LD_LIBRARY_PATH is acceptable. >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb??ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 mika at async.caltech.edu Mon Apr 6 19:12:55 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 10:12:55 -0700 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: Your message of "Mon, 06 Apr 2009 17:51:19 +0200." <20090406175119.5nknbzf9dwkcwkks@mail.elegosoft.com> Message-ID: <200904061712.n36HCtNO089745@camembert.async.caltech.edu> I think what Jay was trying to do sounds right. I think the binary should run without jumping through hoops if it hasn't been shipped. Once shipped it should not be possible to break it by fiddling around in the build directories. This does seem to imply that m3ship does something a bit more than "cp". I think it would be enough if it reordered the defaults, from "link with build tree first, /usr/local/lib second" to "link with /usr/local/lib first, build tree second" (or not at all build tree). Is it bad to have m3ship re-link? Mika Olaf Wagner writes: >Quoting Mika Nystrom : > >> >> Would this mean that users of CM3 have to set LD_LIBRARY_PATH for >> things they build themselves but don't ship? > >Probably. If the libraries cannot be located by the system in a >standard path, it needs help. We could probably come up with a small >script which prints the needed settings for a local M3 workspace. > >> I almost never ship binaries because I don't want user "mika" to >> have write access to the place whither the Modula-3 compiler normally >> ships. But I use them... from cron and other places. Other users >> may use them too... > >Have you got a better suggestion? >This is really not an M3 problem, but a general Unix question. >How should dynamic shared object files be found (especially, when >they are scattered across an M3 workspace)? If we burn in the local >paths, we need to relink the objects before shipping. I also wouldn't >like it when some installed program stops to work because the original >creator made changes to his home directories... > >Any ideas? > >Olaf > >> Mika >> >> Olaf Wagner writes: >>> Quoting Jay : >>> >>>> Running uninstalled binaries shall require either LD_LIBRARY_PATH >>>> or build_standalone(). m3tests uses build_standalone. This is maybe >>>> why more stuff is build_standalone -- anything that runs uninstalled >>>> when doing buildlobal, the various stub code generators. >>> >>> Please just use build_standalone for all binaries that are needed >>> by the build system itself. That shouldn't be many. >>> >>> Otherwise, I think setting LD_LIBRARY_PATH is acceptable. >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb????ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 rodney.m.bates at cox.net Mon Apr 6 21:11:29 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 06 Apr 2009 14:11:29 -0500 Subject: [M3devel] small objects In-Reply-To: <200904061529.n36FTTn0086974@camembert.async.caltech.edu> References: <200904061529.n36FTTn0086974@camembert.async.caltech.edu> Message-ID: <49DA53E1.8020408@cox.net> At first, I just envisioned implementing a small object type entirely inside an UNSAFE module, using unsafe operations to construct/test/separate the values. I think if the GC were to just to ignore words in heap objects that the type system claims are unambiguously pointers but actually have misaligned values, this could be done. But it flies in the face of a fundamental principle of Modula-3, namely that an UNSAFE module, if coded correctly, can prevent all other code from consequences of the unsafety. Unfortunately, this can't be done with the small pointers, because, even if opaque, they are still reference types, and client code can dereference them (including the implicit dereference in accessing a method or field of an object) and do ISTYPE, NARROW, TYPECASE, and assignments that do an implicit NARROW. All these operations could be done outside the implementing module and all could suffer from misaligned values. In fact, misaligned integer "objects" violate another principle that the bit pattern must always be a valid representation of some value of the type. However, this does suggest a different and very simple linguistic solution: Just have a new builtin type, say VERYOPAQUE, that supports no operations other than moving it around, i.e., assignment, bindings, passing as a parameter, etc. Only unsafe code could do anyhing with it, by using LOOPHOLE. The only problem is, would somebody then want one of these in a size other than one word? Mika Nystrom wrote: > Ah I should read my whole inbox before replying. > > I take it you would worry that in my proposal (to do this all in a > library) the use of REFANY to store an integer could be abused > somehow. That the Modula-3 type system (as it exists now) explicitly > rules out doing such things, and therefore, a language change is > necessary.... > > Mika > > Tony Hosking writes: > >> I like the notion of having a TAGGED INTEGER type that is a hybrid >> ordinal/reference. >> >> Subtyping rules for references would now be as follows: >> >> NULL <: REF T <: REFANY >> TAGGED INTEGER <: REF T <: REFANY >> >> ROOT <: REFANY >> NULL <: T OBJECT ... END <: T >> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: REFANY, not >> T <: ADDRESS) >> >> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >> type. Values of TAGGED INTEGER are non-pointer values similar to the >> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and NARROW(x, >> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to ISTYPE(x, >> NULL), NARROW(x, NULL), and TYPECODE(NULL). >> >> Because TAGGED INTEGER is an ordinal we can extract the integer value >> it holds using ORD(x). >> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >> INTEGER). >> >> ***The only problem with this scheme is how to efficiently perform run- >> time tests for dereferencing NULL, and TAGGED INTEGER?*** >> >> So, here is a slightly less elegant alternative that is probably >> straightforward to implement. Introduce a separate TAGGED hierarchy. >> >> NULL <: REF T <: REFANY >> NULL <: UNTRACED REF T <: ADDRESS >> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >> >> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >> >> ROOT <: REFANY >> TAGGED ROOT <: TAGGED REFANY >> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >> >> Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED >> REFANY. >> >> This way, tagged references only need a run-time test for the tag on >> dereference (we can throw an "attempt to dereference TAGGED INTEGER" >> at run time, just like we throw "attempt to dereference NIL" for >> untagged references). This check can be a straightforward test of the >> low bit tag. Of course, the weird thing here is now that we don't >> have a single NULL value for TAGGED references --- we have multiple >> null values VAL(x, TAGGED INTEGER). Instead of asking "x == NIL" we >> must ask "ISTYPE(x, TAGGED INTEGER)". >> >> Of course, because TAGGED INTEGER is an ordinal, we can also perform >> the usual ordinal operations like INC(x), DEC(x), wherever x is typed >> TAGGED INTEGER. >> >> >> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >> >> >>> I spent quite a bit of time playing with a more general system where >>> there is a set of "tagged" types, with (an implementation-defined >>> subrange of) INTEGER and a reference type both being a subtype of a >>> tagged type. It might have been tolerable, if it weren't for the >>> interaction with object subtypes and opaque types, which quickly >>> gets deep into a deep linguistic tar pit. >>> >>> Tony's approach is much simpler and would serve what I see as the >>> need. It does sacrifice any static checking of what reference type >>> is being tagged, and will also require an extra runtime ISTYPE/ >>> TYPECASE. >>> >>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>> also need to be an explicit conversion in that direction too, say >>> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >>> is a bit inconsistent with the usual Modula-3 assignability >>> philosophy, >>> but not requiring the explicit conversion already gets your toes >>> into tar. >>> >>> We would have to have something more like ISTYPE, though, which will >>> tell which type the value belongs to without risking a runtime error, >>> which VAL would do. >>> >>> An intermediate approach might be to have a set of tagged types >>> constructed by, say, TAGGED T, where I is a reference type, but >>> with no subtype relations on them at all, thus still requiring >>> the explicit conversions and checks. >>> >>> I do want to say, I _really_ want this capability somehow. I have >>> an ADT module whose internal data structure, for full generality, >>> needs to have two heap objects (the second because it has nonstatic >>> size) and 11 total words counting the orginal pointer, in the case of >>> values that would fit directly into the "pointer" word. Moreover, >>> these small cases are in the great majority. >>> >>> Besides the 11-to-one increase in actual occupied space, there >>> is extra time for allocation, periodic tracing, and collection, space >>> loss due to heap fragmentation, and time/space tradeoff loss due to >>> reduced locality of reference. So sometimes, it would be a big >>> performance gain if we could do it. >>> >>> >>> Tony Hosking wrote: >>> >>>> It is a much more pervasive hack than I would be comfortable with >>>> since it touches on the compiler (for all the type operations) as >>>> well >>>> as the run-time system in ways that are pretty gross. I would much >>>> rather have a new TAGGED builtin. ISTYPE would not work on it since >>>> that only works on references. The only thing you need is a way to >>>> extract the value -- we could overload VAL(x, T) where x can be a >>>> TAGGED and T can be REFANY or INTEGER. >>>> >>>> > > From mika at async.caltech.edu Mon Apr 6 22:03:03 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 13:03:03 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Mon, 06 Apr 2009 14:11:29 CDT." <49DA53E1.8020408@cox.net> Message-ID: <200904062003.n36K3381094096@camembert.async.caltech.edu> "Rodney M. Bates" writes: >At first, I just envisioned implementing a small object type >entirely inside an UNSAFE module, using unsafe operations >to construct/test/separate the values. I think if the GC were >to just to ignore words in heap objects that the type system >claims are unambiguously pointers but actually have misaligned >values, this could be done. Right that's precisely what the module I posted does. > >But it flies in the face of a fundamental principle of Modula-3, >namely that an UNSAFE module, if coded correctly, can prevent >all other code from consequences of the unsafety. Unfortunately, >this can't be done with the small pointers, because, even if >opaque, they are still reference types, and client code can >dereference them (including the implicit dereference in accessing >a method or field of an object) and do ISTYPE, NARROW, TYPECASE, >and assignments that do an implicit NARROW. All these operations >could be done outside the implementing module and all could >suffer from misaligned values. Well yes that is true. But the client can't dereference REFANY. Modula-3 doesn't permit that. That's an important practical point, because now we're limited to the other things: ISTYPE, NARROW (implicit and explicit), TYPECASE. (There are two more, actually, and they are = and #.) As long as those can be guaranteed to fail you're OK. [ Actually see my P.S. below! ] > >In fact, misaligned integer "objects" violate another principle that >the bit pattern must always be a valid representation of some value >of the type. Yes I think maybe this is what Tony is worried about. But let's just change the definition of REFANY to include anything with the LSB set...? In Modula-3-ese it would be more like the following: "REFANY can hold three types of objects. NIL, REF something or an implementation-defined other set of values that can only be accessed in an UNSAFE module. It is a checked runtime error to pass a 'REFANY of the third kind' to ISTYPE, NARROW, TYPECASE." [ Actually see my P.S. below! ] Then I propose we punt the handling of the new REFANYs to this unsafe module we spoke about above. As far as Modula-3 is concerned, there's just a set of values of (apparently) very little utility that can be represented by REFANY. If you think about it, this is really not so crazy. Any module that uses REFANY today is designed around to the fact that there are plenty of values of REFANY that can be of no interest to that module except for passing along to another module. (REFANY can easily represent a type which a module has no way of accessing *any* declaration of beyond just REFANY.) We're just adding some others, the only difference being that the new values are of no interest to any non-UNSAFE module. (Eh, technically this is already true for any reference type that is declared in an UNSAFE module today so one might argue we have in fact added nothing.) > >However, this does suggest a different and very simple linguistic >solution: Just have a new builtin type, say VERYOPAQUE, that >supports no operations other than moving it around, i.e., >assignment, bindings, passing as a parameter, etc. Only unsafe >code could do anyhing with it, by using LOOPHOLE. The only >problem is, would somebody then want one of these in a size other >than one word? This is nice, and we already have a candidate type, in fact: ADDRESS. But the problem is that the GC doesn't follow this even if the LSB is clear... which we *do* want. Why are you worried about getting it in sizes other than one word? That seems to me to be an application problem. If someone wants an ARRAY OF VERYOPAQUE is that a problem? Mika P.S. Illustration of the above, in today's Modula-3: UNSAFE MODULE Unsafe; (* this module is just declared UNSAFE to conform with the definition above, namely, that T can only be manipulated in an UNSAFE module, which this is! *) TYPE T = BRANDED OBJECT END; BEGIN Safe.P(NEW(T)) END Unsafe. (****************************************) MODULE Safe; PROCEDURE P(r : REFANY) = BEGIN NARROW(r, X); (* checked runtime error for all X *) ISTYPE(r, X); (* returns FALSE for all X except REFANY itself *) TYPECASE r OF X => (* only gets executed for X = REFANY *) END; END P; BEGIN END Safe. Actually is this behavior so bad for tagged integers? Since it is the behavior of existing code... why not keep it? Then you can even store a tagged integer in a RefList.T, say, even if that RefList.T uses NARROW or ISTYPE on the argument (I don't see why it would, but why not...?) > >Mika Nystrom wrote: >> Ah I should read my whole inbox before replying. >> >> I take it you would worry that in my proposal (to do this all in a >> library) the use of REFANY to store an integer could be abused >> somehow. That the Modula-3 type system (as it exists now) explicitly >> rules out doing such things, and therefore, a language change is >> necessary.... >> >> Mika >> >> Tony Hosking writes: >> >>> I like the notion of having a TAGGED INTEGER type that is a hybrid >>> ordinal/reference. >>> >>> Subtyping rules for references would now be as follows: >>> >>> NULL <: REF T <: REFANY >>> TAGGED INTEGER <: REF T <: REFANY >>> >>> ROOT <: REFANY >>> NULL <: T OBJECT ... END <: T >>> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: REFANY, not >>> T <: ADDRESS) >>> >>> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >>> type. Values of TAGGED INTEGER are non-pointer values similar to the >>> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and NARROW(x, >>> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to ISTYPE(x, >>> NULL), NARROW(x, NULL), and TYPECODE(NULL). >>> >>> Because TAGGED INTEGER is an ordinal we can extract the integer value >>> it holds using ORD(x). >>> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >>> INTEGER). >>> >>> ***The only problem with this scheme is how to efficiently perform run- >>> time tests for dereferencing NULL, and TAGGED INTEGER?*** >> >>> So, here is a slightly less elegant alternative that is probably >>> straightforward to implement. Introduce a separate TAGGED hierarchy. >>> >>> NULL <: REF T <: REFANY >>> NULL <: UNTRACED REF T <: ADDRESS >>> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >>> >>> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >>> >>> ROOT <: REFANY >>> TAGGED ROOT <: TAGGED REFANY >>> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >>> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >>> >>> Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED >>> REFANY. >>> >>> This way, tagged references only need a run-time test for the tag on >>> dereference (we can throw an "attempt to dereference TAGGED INTEGER" >>> at run time, just like we throw "attempt to dereference NIL" for >>> untagged references). This check can be a straightforward test of the >>> low bit tag. Of course, the weird thing here is now that we don't >>> have a single NULL value for TAGGED references --- we have multiple >>> null values VAL(x, TAGGED INTEGER). Instead of asking "x == NIL" we >>> must ask "ISTYPE(x, TAGGED INTEGER)". >>> >>> Of course, because TAGGED INTEGER is an ordinal, we can also perform >>> the usual ordinal operations like INC(x), DEC(x), wherever x is typed >>> TAGGED INTEGER. >>> >>> >>> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >>> >>> >>>> I spent quite a bit of time playing with a more general system where >>>> there is a set of "tagged" types, with (an implementation-defined >>>> subrange of) INTEGER and a reference type both being a subtype of a >>>> tagged type. It might have been tolerable, if it weren't for the >>>> interaction with object subtypes and opaque types, which quickly >>>> gets deep into a deep linguistic tar pit. >>>> >>>> Tony's approach is much simpler and would serve what I see as the >>>> need. It does sacrifice any static checking of what reference type >>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>> TYPECASE. >>>> >>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>> also need to be an explicit conversion in that direction too, say >>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >>>> is a bit inconsistent with the usual Modula-3 assignability >>>> philosophy, >>>> but not requiring the explicit conversion already gets your toes >>>> into tar. >>>> >>>> We would have to have something more like ISTYPE, though, which will >>>> tell which type the value belongs to without risking a runtime error, >>>> which VAL would do. >>>> >>>> An intermediate approach might be to have a set of tagged types >>>> constructed by, say, TAGGED T, where I is a reference type, but >>>> with no subtype relations on them at all, thus still requiring >>>> the explicit conversions and checks. >>>> >>>> I do want to say, I _really_ want this capability somehow. I have >>>> an ADT module whose internal data structure, for full generality, >>>> needs to have two heap objects (the second because it has nonstatic >>>> size) and 11 total words counting the orginal pointer, in the case of >>>> values that would fit directly into the "pointer" word. Moreover, >>>> these small cases are in the great majority. >>>> >>>> Besides the 11-to-one increase in actual occupied space, there >>>> is extra time for allocation, periodic tracing, and collection, space >>>> loss due to heap fragmentation, and time/space tradeoff loss due to >>>> reduced locality of reference. So sometimes, it would be a big >>>> performance gain if we could do it. >>>> >>>> >>>> Tony Hosking wrote: >>>> >>>>> It is a much more pervasive hack than I would be comfortable with >>>>> since it touches on the compiler (for all the type operations) as >>>>> well >>>>> as the run-time system in ways that are pretty gross. I would much >>>>> rather have a new TAGGED builtin. ISTYPE would not work on it since >>>>> that only works on references. The only thing you need is a way to >>>>> extract the value -- we could overload VAL(x, T) where x can be a >>>>> TAGGED and T can be REFANY or INTEGER. >>>>> >>>>> >> >> From mika at async.caltech.edu Mon Apr 6 22:17:37 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 13:17:37 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Mon, 06 Apr 2009 13:03:03 PDT." <200904062003.n36K3381094096@camembert.async.caltech.edu> Message-ID: <200904062017.n36KHbcq094473@camembert.async.caltech.edu> Ok I admit I missed something important. TYPECODE. It's easy enough to allocate a special TYPECODE to the tagged integer. One not used by any "real" type of course. It will break pickles and fingerprints. Pickles can be fixed, check the typecode and call a routine in the TaggedInteger interface (by default, user can override it?) to translate to and fro. But what about fingerprints? Again I guess we can just return the fingerprint of a nonexistent type............................. Hummm humm. Ok, how about this... let's declare a completely hidden type ... UNSAFE MODULE TaggedInteger; TYPE T = BRANDED OBJECT x : INTEGER END; BEGIN END TaggedInteger. Now, fix up TYPECODE, ISTYPE, NARROW, TYPECASE so that they all act *precisely* as if TaggedInteger.T were passed to them, when they see a REFANY with the LSB set. fingerprinting the type will give you the fingerprint of TaggedInteger.T. (But you better not rely on that! Only UNSAFE modules can do anything with this information, anyhow, so who cares, but see below.) I don't see how this breaks anything at all once we introduce the 'REFANY of the third kind', which is so small a change to the language's type system that I'm not sure it even qualifies as a change. Pickles are already unsafe, so the fact that the current pickles package would subvert the type system based on what I propose is a non-issue (language wise), it just means a few extra lines of code in the pickles package. The reason for the x : field above is that I propose that this be how the tagged integer be un/pickled, as an instance of an object of the (actual) type TaggedInteger.T. Mika Mika Nystrom writes: >"Rodney M. Bates" writes: >>At first, I just envisioned implementing a small object type >>entirely inside an UNSAFE module, using unsafe operations >>to construct/test/separate the values. I think if the GC were >>to just to ignore words in heap objects that the type system >>claims are unambiguously pointers but actually have misaligned >>values, this could be done. > >Right that's precisely what the module I posted does. > >> >>But it flies in the face of a fundamental principle of Modula-3, >>namely that an UNSAFE module, if coded correctly, can prevent >>all other code from consequences of the unsafety. Unfortunately, >>this can't be done with the small pointers, because, even if >>opaque, they are still reference types, and client code can >>dereference them (including the implicit dereference in accessing >>a method or field of an object) and do ISTYPE, NARROW, TYPECASE, >>and assignments that do an implicit NARROW. All these operations >>could be done outside the implementing module and all could >>suffer from misaligned values. > >Well yes that is true. But the client can't dereference REFANY. >Modula-3 doesn't permit that. That's an important practical point, >because now we're limited to the other things: ISTYPE, NARROW >(implicit and explicit), TYPECASE. (There are two more, actually, >and they are = and #.) As long as those can be guaranteed to fail >you're OK. [ Actually see my P.S. below! ] > >> >>In fact, misaligned integer "objects" violate another principle that >>the bit pattern must always be a valid representation of some value >>of the type. > >Yes I think maybe this is what Tony is worried about. But let's >just change the definition of REFANY to include anything with the >LSB set...? > >In Modula-3-ese it would be more like the following: > >"REFANY can hold three types of objects. NIL, REF something or an >implementation-defined other set of values that can only be accessed >in an UNSAFE module. It is a checked runtime error to pass a 'REFANY >of the third kind' to ISTYPE, NARROW, TYPECASE." [ Actually see my P.S. below! ] > >Then I propose we punt the handling of the new REFANYs to this >unsafe module we spoke about above. As far as Modula-3 is concerned, >there's just a set of values of (apparently) very little utility >that can be represented by REFANY. If you think about it, this is >really not so crazy. Any module that uses REFANY today is designed >around to the fact that there are plenty of values of REFANY that >can be of no interest to that module except for passing along to >another module. (REFANY can easily represent a type which a module >has no way of accessing *any* declaration of beyond just REFANY.) >We're just adding some others, the only difference being that the >new values are of no interest to any non-UNSAFE module. (Eh, >technically this is already true for any reference type that is >declared in an UNSAFE module today so one might argue we have in >fact added nothing.) > >> >>However, this does suggest a different and very simple linguistic >>solution: Just have a new builtin type, say VERYOPAQUE, that >>supports no operations other than moving it around, i.e., >>assignment, bindings, passing as a parameter, etc. Only unsafe >>code could do anyhing with it, by using LOOPHOLE. The only >>problem is, would somebody then want one of these in a size other >>than one word? > >This is nice, and we already have a candidate type, in fact: ADDRESS. >But the problem is that the GC doesn't follow this even if the LSB >is clear... which we *do* want. > >Why are you worried about getting it in sizes other than one word? >That seems to me to be an application problem. If someone wants >an ARRAY OF VERYOPAQUE is that a problem? > > Mika > >P.S. Illustration of the above, in today's Modula-3: > >UNSAFE MODULE Unsafe; > >(* this module is just declared UNSAFE to conform with the definition > above, namely, that T can only be manipulated in an UNSAFE > module, which this is! *) > >TYPE T = BRANDED OBJECT END; > >BEGIN > Safe.P(NEW(T)) >END Unsafe. > >(****************************************) > >MODULE Safe; > >PROCEDURE P(r : REFANY) = > BEGIN > NARROW(r, X); (* checked runtime error for all X *) > > ISTYPE(r, X); (* returns FALSE for all X except REFANY itself *) > > TYPECASE r OF > X => (* only gets executed for X = REFANY *) > END; > END P; > >BEGIN END Safe. > >Actually is this behavior so bad for tagged integers? Since it is >the behavior of existing code... why not keep it? Then you can even >store a tagged integer in a RefList.T, say, even if that RefList.T >uses NARROW or ISTYPE on the argument (I don't see why it would, but >why not...?) > > > >> >>Mika Nystrom wrote: >>> Ah I should read my whole inbox before replying. >>> >>> I take it you would worry that in my proposal (to do this all in a >>> library) the use of REFANY to store an integer could be abused >>> somehow. That the Modula-3 type system (as it exists now) explicitly >>> rules out doing such things, and therefore, a language change is >>> necessary.... >>> >>> Mika >>> >>> Tony Hosking writes: >>> >>>> I like the notion of having a TAGGED INTEGER type that is a hybrid >>>> ordinal/reference. >>>> >>>> Subtyping rules for references would now be as follows: >>>> >>>> NULL <: REF T <: REFANY >>>> TAGGED INTEGER <: REF T <: REFANY >>>> >>>> ROOT <: REFANY >>>> NULL <: T OBJECT ... END <: T >>>> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: REFANY, not >>>> T <: ADDRESS) >>>> >>>> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >>>> type. Values of TAGGED INTEGER are non-pointer values similar to the >>>> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and NARROW(x, >>>> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to ISTYPE(x, >>>> NULL), NARROW(x, NULL), and TYPECODE(NULL). >>>> >>>> Because TAGGED INTEGER is an ordinal we can extract the integer value >>>> it holds using ORD(x). >>>> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >>>> INTEGER). >>>> >>>> ***The only problem with this scheme is how to efficiently perform run- >>>> time tests for dereferencing NULL, and TAGGED INTEGER?*** >>> >>>> So, here is a slightly less elegant alternative that is probably >>>> straightforward to implement. Introduce a separate TAGGED hierarchy. >>>> >>>> NULL <: REF T <: REFANY >>>> NULL <: UNTRACED REF T <: ADDRESS >>>> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >>>> >>>> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >>>> >>>> ROOT <: REFANY >>>> TAGGED ROOT <: TAGGED REFANY >>>> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >>>> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >>>> >>>> Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED >>>> REFANY. >>>> >>>> This way, tagged references only need a run-time test for the tag on >>>> dereference (we can throw an "attempt to dereference TAGGED INTEGER" >>>> at run time, just like we throw "attempt to dereference NIL" for >>>> untagged references). This check can be a straightforward test of the >>>> low bit tag. Of course, the weird thing here is now that we don't >>>> have a single NULL value for TAGGED references --- we have multiple >>>> null values VAL(x, TAGGED INTEGER). Instead of asking "x == NIL" we >>>> must ask "ISTYPE(x, TAGGED INTEGER)". >>>> >>>> Of course, because TAGGED INTEGER is an ordinal, we can also perform >>>> the usual ordinal operations like INC(x), DEC(x), wherever x is typed >>>> TAGGED INTEGER. >>>> >>>> >>>> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >>>> >>>> >>>>> I spent quite a bit of time playing with a more general system where >>>>> there is a set of "tagged" types, with (an implementation-defined >>>>> subrange of) INTEGER and a reference type both being a subtype of a >>>>> tagged type. It might have been tolerable, if it weren't for the >>>>> interaction with object subtypes and opaque types, which quickly >>>>> gets deep into a deep linguistic tar pit. >>>>> >>>>> Tony's approach is much simpler and would serve what I see as the >>>>> need. It does sacrifice any static checking of what reference type >>>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>>> TYPECASE. >>>>> >>>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>>> also need to be an explicit conversion in that direction too, say >>>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >>>>> is a bit inconsistent with the usual Modula-3 assignability >>>>> philosophy, >>>>> but not requiring the explicit conversion already gets your toes >>>>> into tar. >>>>> >>>>> We would have to have something more like ISTYPE, though, which will >>>>> tell which type the value belongs to without risking a runtime error, >>>>> which VAL would do. >>>>> >>>>> An intermediate approach might be to have a set of tagged types >>>>> constructed by, say, TAGGED T, where I is a reference type, but >>>>> with no subtype relations on them at all, thus still requiring >>>>> the explicit conversions and checks. >>>>> >>>>> I do want to say, I _really_ want this capability somehow. I have >>>>> an ADT module whose internal data structure, for full generality, >>>>> needs to have two heap objects (the second because it has nonstatic >>>>> size) and 11 total words counting the orginal pointer, in the case of >>>>> values that would fit directly into the "pointer" word. Moreover, >>>>> these small cases are in the great majority. >>>>> >>>>> Besides the 11-to-one increase in actual occupied space, there >>>>> is extra time for allocation, periodic tracing, and collection, space >>>>> loss due to heap fragmentation, and time/space tradeoff loss due to >>>>> reduced locality of reference. So sometimes, it would be a big >>>>> performance gain if we could do it. >>>>> >>>>> >>>>> Tony Hosking wrote: >>>>> >>>>>> It is a much more pervasive hack than I would be comfortable with >>>>>> since it touches on the compiler (for all the type operations) as >>>>>> well >>>>>> as the run-time system in ways that are pretty gross. I would much >>>>>> rather have a new TAGGED builtin. ISTYPE would not work on it since >>>>>> that only works on references. The only thing you need is a way to >>>>>> extract the value -- we could overload VAL(x, T) where x can be a >>>>>> TAGGED and T can be REFANY or INTEGER. >>>>>> >>>>>> >>> >>> From mika at async.caltech.edu Mon Apr 6 22:31:57 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 13:31:57 -0700 Subject: [M3devel] Implementing the "Singleton pattern" in Modula-3 Message-ID: <200904062031.n36KVvC2094839@camembert.async.caltech.edu> Tony, Jay, you two seem to be most knowledgeable about this. Let's say I wanted to implement the "singleton pattern" in Modula-3. At present there seems to be no way of doing this. What about changing RTAllocator.callback as follows (or adding another callback): VAR callback : PROCEDURE(r : REFANY) : REFANY := NIL; (* If non-NIL, the allocator calls "callback(r)" just before returning a new traced reference "r" and instead returns the result of callback(r). See "RTAllocStats" for an example client. It is a checked runtime error for the typecode of r to differ from the typecode of the return value of callback(r). *) Mika From mika at async.caltech.edu Mon Apr 6 22:39:18 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 13:39:18 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Mon, 06 Apr 2009 13:03:03 PDT." <200904062003.n36K3381094096@camembert.async.caltech.edu> Message-ID: <200904062039.n36KdIsY095003@camembert.async.caltech.edu> And finally, to forestall a possible objection to the scheme I proposed: Yes, it is true that even a non-UNSAFE module can allocate a TaggedInteger.T by calling new := RTAllocator.NewTraced(TYPECODE(r)) where r is a tagged integer. But since it cannot dereference that new value or do anything else with it, I don't think this is a problem. The Pickler (built into the TaggedInteger module, one must assume) would simply have to be on the lookout for values of the "real" TaggedInteger.T versus those that are just numbers with the LSB set, and act accordingly. Since the T declaration is only visible within the UNSAFE module there can never be any question of another module's muddling the two types up. Mika Mika Nystrom writes: >"Rodney M. Bates" writes: >>At first, I just envisioned implementing a small object type >>entirely inside an UNSAFE module, using unsafe operations >>to construct/test/separate the values. I think if the GC were >>to just to ignore words in heap objects that the type system >>claims are unambiguously pointers but actually have misaligned >>values, this could be done. > >Right that's precisely what the module I posted does. > >> >>But it flies in the face of a fundamental principle of Modula-3, >>namely that an UNSAFE module, if coded correctly, can prevent >>all other code from consequences of the unsafety. Unfortunately, >>this can't be done with the small pointers, because, even if >>opaque, they are still reference types, and client code can >>dereference them (including the implicit dereference in accessing >>a method or field of an object) and do ISTYPE, NARROW, TYPECASE, >>and assignments that do an implicit NARROW. All these operations >>could be done outside the implementing module and all could >>suffer from misaligned values. > >Well yes that is true. But the client can't dereference REFANY. >Modula-3 doesn't permit that. That's an important practical point, >because now we're limited to the other things: ISTYPE, NARROW >(implicit and explicit), TYPECASE. (There are two more, actually, >and they are = and #.) As long as those can be guaranteed to fail >you're OK. [ Actually see my P.S. below! ] > >> >>In fact, misaligned integer "objects" violate another principle that >>the bit pattern must always be a valid representation of some value >>of the type. > >Yes I think maybe this is what Tony is worried about. But let's >just change the definition of REFANY to include anything with the >LSB set...? > >In Modula-3-ese it would be more like the following: > >"REFANY can hold three types of objects. NIL, REF something or an >implementation-defined other set of values that can only be accessed >in an UNSAFE module. It is a checked runtime error to pass a 'REFANY >of the third kind' to ISTYPE, NARROW, TYPECASE." [ Actually see my P.S. below! ] > >Then I propose we punt the handling of the new REFANYs to this >unsafe module we spoke about above. As far as Modula-3 is concerned, >there's just a set of values of (apparently) very little utility >that can be represented by REFANY. If you think about it, this is >really not so crazy. Any module that uses REFANY today is designed >around to the fact that there are plenty of values of REFANY that >can be of no interest to that module except for passing along to >another module. (REFANY can easily represent a type which a module >has no way of accessing *any* declaration of beyond just REFANY.) >We're just adding some others, the only difference being that the >new values are of no interest to any non-UNSAFE module. (Eh, >technically this is already true for any reference type that is >declared in an UNSAFE module today so one might argue we have in >fact added nothing.) > >> >>However, this does suggest a different and very simple linguistic >>solution: Just have a new builtin type, say VERYOPAQUE, that >>supports no operations other than moving it around, i.e., >>assignment, bindings, passing as a parameter, etc. Only unsafe >>code could do anyhing with it, by using LOOPHOLE. The only >>problem is, would somebody then want one of these in a size other >>than one word? > >This is nice, and we already have a candidate type, in fact: ADDRESS. >But the problem is that the GC doesn't follow this even if the LSB >is clear... which we *do* want. > >Why are you worried about getting it in sizes other than one word? >That seems to me to be an application problem. If someone wants >an ARRAY OF VERYOPAQUE is that a problem? > > Mika > >P.S. Illustration of the above, in today's Modula-3: > >UNSAFE MODULE Unsafe; > >(* this module is just declared UNSAFE to conform with the definition > above, namely, that T can only be manipulated in an UNSAFE > module, which this is! *) > >TYPE T = BRANDED OBJECT END; > >BEGIN > Safe.P(NEW(T)) >END Unsafe. > >(****************************************) > >MODULE Safe; > >PROCEDURE P(r : REFANY) = > BEGIN > NARROW(r, X); (* checked runtime error for all X *) > > ISTYPE(r, X); (* returns FALSE for all X except REFANY itself *) > > TYPECASE r OF > X => (* only gets executed for X = REFANY *) > END; > END P; > >BEGIN END Safe. > >Actually is this behavior so bad for tagged integers? Since it is >the behavior of existing code... why not keep it? Then you can even >store a tagged integer in a RefList.T, say, even if that RefList.T >uses NARROW or ISTYPE on the argument (I don't see why it would, but >why not...?) > > > >> >>Mika Nystrom wrote: >>> Ah I should read my whole inbox before replying. >>> >>> I take it you would worry that in my proposal (to do this all in a >>> library) the use of REFANY to store an integer could be abused >>> somehow. That the Modula-3 type system (as it exists now) explicitly >>> rules out doing such things, and therefore, a language change is >>> necessary.... >>> >>> Mika >>> >>> Tony Hosking writes: >>> >>>> I like the notion of having a TAGGED INTEGER type that is a hybrid >>>> ordinal/reference. >>>> >>>> Subtyping rules for references would now be as follows: >>>> >>>> NULL <: REF T <: REFANY >>>> TAGGED INTEGER <: REF T <: REFANY >>>> >>>> ROOT <: REFANY >>>> NULL <: T OBJECT ... END <: T >>>> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: REFANY, not >>>> T <: ADDRESS) >>>> >>>> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >>>> type. Values of TAGGED INTEGER are non-pointer values similar to the >>>> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and NARROW(x, >>>> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to ISTYPE(x, >>>> NULL), NARROW(x, NULL), and TYPECODE(NULL). >>>> >>>> Because TAGGED INTEGER is an ordinal we can extract the integer value >>>> it holds using ORD(x). >>>> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >>>> INTEGER). >>>> >>>> ***The only problem with this scheme is how to efficiently perform run- >>>> time tests for dereferencing NULL, and TAGGED INTEGER?*** >>> >>>> So, here is a slightly less elegant alternative that is probably >>>> straightforward to implement. Introduce a separate TAGGED hierarchy. >>>> >>>> NULL <: REF T <: REFANY >>>> NULL <: UNTRACED REF T <: ADDRESS >>>> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >>>> >>>> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >>>> >>>> ROOT <: REFANY >>>> TAGGED ROOT <: TAGGED REFANY >>>> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >>>> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >>>> >>>> Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED >>>> REFANY. >>>> >>>> This way, tagged references only need a run-time test for the tag on >>>> dereference (we can throw an "attempt to dereference TAGGED INTEGER" >>>> at run time, just like we throw "attempt to dereference NIL" for >>>> untagged references). This check can be a straightforward test of the >>>> low bit tag. Of course, the weird thing here is now that we don't >>>> have a single NULL value for TAGGED references --- we have multiple >>>> null values VAL(x, TAGGED INTEGER). Instead of asking "x == NIL" we >>>> must ask "ISTYPE(x, TAGGED INTEGER)". >>>> >>>> Of course, because TAGGED INTEGER is an ordinal, we can also perform >>>> the usual ordinal operations like INC(x), DEC(x), wherever x is typed >>>> TAGGED INTEGER. >>>> >>>> >>>> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >>>> >>>> >>>>> I spent quite a bit of time playing with a more general system where >>>>> there is a set of "tagged" types, with (an implementation-defined >>>>> subrange of) INTEGER and a reference type both being a subtype of a >>>>> tagged type. It might have been tolerable, if it weren't for the >>>>> interaction with object subtypes and opaque types, which quickly >>>>> gets deep into a deep linguistic tar pit. >>>>> >>>>> Tony's approach is much simpler and would serve what I see as the >>>>> need. It does sacrifice any static checking of what reference type >>>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>>> TYPECASE. >>>>> >>>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>>> also need to be an explicit conversion in that direction too, say >>>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >>>>> is a bit inconsistent with the usual Modula-3 assignability >>>>> philosophy, >>>>> but not requiring the explicit conversion already gets your toes >>>>> into tar. >>>>> >>>>> We would have to have something more like ISTYPE, though, which will >>>>> tell which type the value belongs to without risking a runtime error, >>>>> which VAL would do. >>>>> >>>>> An intermediate approach might be to have a set of tagged types >>>>> constructed by, say, TAGGED T, where I is a reference type, but >>>>> with no subtype relations on them at all, thus still requiring >>>>> the explicit conversions and checks. >>>>> >>>>> I do want to say, I _really_ want this capability somehow. I have >>>>> an ADT module whose internal data structure, for full generality, >>>>> needs to have two heap objects (the second because it has nonstatic >>>>> size) and 11 total words counting the orginal pointer, in the case of >>>>> values that would fit directly into the "pointer" word. Moreover, >>>>> these small cases are in the great majority. >>>>> >>>>> Besides the 11-to-one increase in actual occupied space, there >>>>> is extra time for allocation, periodic tracing, and collection, space >>>>> loss due to heap fragmentation, and time/space tradeoff loss due to >>>>> reduced locality of reference. So sometimes, it would be a big >>>>> performance gain if we could do it. >>>>> >>>>> >>>>> Tony Hosking wrote: >>>>> >>>>>> It is a much more pervasive hack than I would be comfortable with >>>>>> since it touches on the compiler (for all the type operations) as >>>>>> well >>>>>> as the run-time system in ways that are pretty gross. I would much >>>>>> rather have a new TAGGED builtin. ISTYPE would not work on it since >>>>>> that only works on references. The only thing you need is a way to >>>>>> extract the value -- we could overload VAL(x, T) where x can be a >>>>>> TAGGED and T can be REFANY or INTEGER. >>>>>> >>>>>> >>> >>> From hosking at cs.purdue.edu Tue Apr 7 02:06:03 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 10:06:03 +1000 Subject: [M3devel] small objects In-Reply-To: <200904061450.n36EoPk9085841@camembert.async.caltech.edu> References: <200904061450.n36EoPk9085841@camembert.async.caltech.edu> Message-ID: <59082335-E94F-48FC-AD7B-6632542B5ED4@cs.purdue.edu> I really don't like your proposal for the reasons you mention. It makes regular REF more expensive than it currently is. What is it about my relatively minor changes to the type system that you object to? I've just about finished changing the compiler front-end (in relatively minor ways) to accomodate the proposal I made yesterday. And it has the advantage of separating REF from TAGGED REF so we keep the standard REF clean. On 7 Apr 2009, at 00:50, Mika Nystrom wrote: > Hi Rodney, > > I would like this capability too, but I am a bit wary of Tony's > idea of changing the Modula-3 language---even in a "minor" way. > I've been working for the last week or so on an application using > the Modula-3 Toolkit, and I must say I have realized that the > Modula-3 type system has a lot more subtleties than I thought. I > would not want to make any real changes to it. There's a paper > called "The Modula-3 Type System" by Cardelli, Donahue, Kalsow, and > Nelson that is worth studying in detail before making any changes > whatsoever, I think. Also remember that changes to the type system > will affect m3tk and anything that depends on m3tk (which includes > two or three stub generators in the main tree and who knows how > many dependencies outside of it). > > I'm still not sure why we can't take the approach of Word.T . > Make a RefanyOrInt.T that can safely be: > > 1. Tested whether it is a small integer or a REFANY > > 2. If a REFANY, be dereferenced as normal, *or* via > RefanyOrInt.ToRefany > > 3. If a small integer, can be extracted via RefanyOrInt.ToInt > > 4. Created either as a small integer or a REFANY > > Any other operations on it (including ISTYPE and TYPECASE, at least > when the object is a small integer) would result in a checked runtime > error. > > Note that with the declaration "RefanyOrInt.T = REFANY", the current > compiler will as far as I know not accept any operations on > RefanyOrInt.T outside of ISTYPE, TYPECASE, and NARROW (explicit or > implicit). > > I wouldn't be surprised if most of what I'm proposing already works > (i.e., crashes with a checked runtime error as it should) with the > current runtime. Anything that slips through would need to be fixed > up with a one-bit check of the LSB of the REFANY for the operations > mentioned above. Unfortunately this has to be done for operations on > every REFANY, not just the new type. > > I think that Modula-3 programmers are already aware that using > REFANYs involves forcing the runtime to do extra type-checking work, > so they already know not to use them if they are looking for maximum > performance, so I don't think that burdening operations on REFANY > with an extra one-bit check is too onerous. > > An advantage of my proposal is that the amount of code in the new > proposed library is truly diminutive. In fact, I think I posted > pretty much that code to the list a few weeks ago. > > (If you missed it, it's > > http://www.async.caltech.edu/~mika/interp/ > > ) > > Mika > > > "Rodney M. Bates" writes: >> I spent quite a bit of time playing with a more general system where >> there is a set of "tagged" types, with (an implementation-defined >> subrange of) INTEGER and a reference type both being a subtype of a >> tagged type. It might have been tolerable, if it weren't for the >> interaction with object subtypes and opaque types, which quickly >> gets deep into a deep linguistic tar pit. >> >> Tony's approach is much simpler and would serve what I see as the >> need. It does sacrifice any static checking of what reference type >> is being tagged, and will also require an extra runtime ISTYPE/ >> TYPECASE. >> >> Would INTEGER and REFANY be assignable to TAGGED, or would there >> also need to be an explicit conversion in that direction too, say >> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >> is a bit inconsistent with the usual Modula-3 assignability >> philosophy, >> but not requiring the explicit conversion already gets your toes >> into tar. >> >> We would have to have something more like ISTYPE, though, which will >> tell which type the value belongs to without risking a runtime error, >> which VAL would do. >> >> An intermediate approach might be to have a set of tagged types >> constructed by, say, TAGGED T, where I is a reference type, but >> with no subtype relations on them at all, thus still requiring >> the explicit conversions and checks. >> >> I do want to say, I _really_ want this capability somehow. I have >> an ADT module whose internal data structure, for full generality, >> needs to have two heap objects (the second because it has nonstatic >> size) and 11 total words counting the orginal pointer, in the case of >> values that would fit directly into the "pointer" word. Moreover, >> these small cases are in the great majority. >> >> Besides the 11-to-one increase in actual occupied space, there >> is extra time for allocation, periodic tracing, and collection, space >> loss due to heap fragmentation, and time/space tradeoff loss due to >> reduced locality of reference. So sometimes, it would be a big >> performance gain if we could do it. >> >> >> Tony Hosking wrote: >> It is a much more pervasive hack than I would be comfortable with >>> since it touches on the compiler (for all the type operations) as >>> well >>> as the run-time system in ways that are pretty gross. I would much >>> rather have a new TAGGED builtin. ISTYPE would not work on it since >>> that only works on references. The only thing you need is a way to >>> extract the value -- we could overload VAL(x, T) where x can be a >>> TAGGED and T can be REFANY or INTEGER. >>> >>> From hosking at cs.purdue.edu Tue Apr 7 02:07:10 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 10:07:10 +1000 Subject: [M3devel] small objects In-Reply-To: <200904061450.n36EoPk9085841@camembert.async.caltech.edu> References: <200904061450.n36EoPk9085841@camembert.async.caltech.edu> Message-ID: PS What you propose has more pervasive impact on the run-time system and performance than my proposal simply because it conflates tagging with existing REFANY. On 7 Apr 2009, at 00:50, Mika Nystrom wrote: > Hi Rodney, > > I would like this capability too, but I am a bit wary of Tony's > idea of changing the Modula-3 language---even in a "minor" way. > I've been working for the last week or so on an application using > the Modula-3 Toolkit, and I must say I have realized that the > Modula-3 type system has a lot more subtleties than I thought. I > would not want to make any real changes to it. There's a paper > called "The Modula-3 Type System" by Cardelli, Donahue, Kalsow, and > Nelson that is worth studying in detail before making any changes > whatsoever, I think. Also remember that changes to the type system > will affect m3tk and anything that depends on m3tk (which includes > two or three stub generators in the main tree and who knows how > many dependencies outside of it). > > I'm still not sure why we can't take the approach of Word.T . > Make a RefanyOrInt.T that can safely be: > > 1. Tested whether it is a small integer or a REFANY > > 2. If a REFANY, be dereferenced as normal, *or* via > RefanyOrInt.ToRefany > > 3. If a small integer, can be extracted via RefanyOrInt.ToInt > > 4. Created either as a small integer or a REFANY > > Any other operations on it (including ISTYPE and TYPECASE, at least > when the object is a small integer) would result in a checked runtime > error. > > Note that with the declaration "RefanyOrInt.T = REFANY", the current > compiler will as far as I know not accept any operations on > RefanyOrInt.T outside of ISTYPE, TYPECASE, and NARROW (explicit or > implicit). > > I wouldn't be surprised if most of what I'm proposing already works > (i.e., crashes with a checked runtime error as it should) with the > current runtime. Anything that slips through would need to be fixed > up with a one-bit check of the LSB of the REFANY for the operations > mentioned above. Unfortunately this has to be done for operations on > every REFANY, not just the new type. > > I think that Modula-3 programmers are already aware that using > REFANYs involves forcing the runtime to do extra type-checking work, > so they already know not to use them if they are looking for maximum > performance, so I don't think that burdening operations on REFANY > with an extra one-bit check is too onerous. > > An advantage of my proposal is that the amount of code in the new > proposed library is truly diminutive. In fact, I think I posted > pretty much that code to the list a few weeks ago. > > (If you missed it, it's > > http://www.async.caltech.edu/~mika/interp/ > > ) > > Mika > > > "Rodney M. Bates" writes: >> I spent quite a bit of time playing with a more general system where >> there is a set of "tagged" types, with (an implementation-defined >> subrange of) INTEGER and a reference type both being a subtype of a >> tagged type. It might have been tolerable, if it weren't for the >> interaction with object subtypes and opaque types, which quickly >> gets deep into a deep linguistic tar pit. >> >> Tony's approach is much simpler and would serve what I see as the >> need. It does sacrifice any static checking of what reference type >> is being tagged, and will also require an extra runtime ISTYPE/ >> TYPECASE. >> >> Would INTEGER and REFANY be assignable to TAGGED, or would there >> also need to be an explicit conversion in that direction too, say >> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >> is a bit inconsistent with the usual Modula-3 assignability >> philosophy, >> but not requiring the explicit conversion already gets your toes >> into tar. >> >> We would have to have something more like ISTYPE, though, which will >> tell which type the value belongs to without risking a runtime error, >> which VAL would do. >> >> An intermediate approach might be to have a set of tagged types >> constructed by, say, TAGGED T, where I is a reference type, but >> with no subtype relations on them at all, thus still requiring >> the explicit conversions and checks. >> >> I do want to say, I _really_ want this capability somehow. I have >> an ADT module whose internal data structure, for full generality, >> needs to have two heap objects (the second because it has nonstatic >> size) and 11 total words counting the orginal pointer, in the case of >> values that would fit directly into the "pointer" word. Moreover, >> these small cases are in the great majority. >> >> Besides the 11-to-one increase in actual occupied space, there >> is extra time for allocation, periodic tracing, and collection, space >> loss due to heap fragmentation, and time/space tradeoff loss due to >> reduced locality of reference. So sometimes, it would be a big >> performance gain if we could do it. >> >> >> Tony Hosking wrote: >> It is a much more pervasive hack than I would be comfortable with >>> since it touches on the compiler (for all the type operations) as >>> well >>> as the run-time system in ways that are pretty gross. I would much >>> rather have a new TAGGED builtin. ISTYPE would not work on it since >>> that only works on references. The only thing you need is a way to >>> extract the value -- we could overload VAL(x, T) where x can be a >>> TAGGED and T can be REFANY or INTEGER. >>> >>> From mika at async.caltech.edu Tue Apr 7 02:42:23 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 17:42:23 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Tue, 07 Apr 2009 10:06:03 +1000." <59082335-E94F-48FC-AD7B-6632542B5ED4@cs.purdue.edu> Message-ID: <200904070042.n370gNK3001242@camembert.async.caltech.edu> You mean this proposal (you had two, I think)? --- NULL <: REF T <: REFANY NULL <: UNTRACED REF T <: ADDRESS TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. ROOT <: REFANY TAGGED ROOT <: TAGGED REFANY NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED REFANY. --- I like it fine, I think... I'm just worried, generally, about changing the type system. Hmmmm... you mean that the TAGGED things would just be a separate hierarchy? So you'd just add TAGGED in front of the REFs for this new hierarchy. But why no NULL? And you're comfortable with doing the conversions automatically? So tx : TAGGED INTEGER := 5; x : INTEGER := tx; would be OK? In that case it's just the m3tk that needs to be modified, and that's just busy work, I think. If it works it's beautiful... Mika Tony Hosking writes: >I really don't like your proposal for the reasons you mention. It >makes regular REF more expensive than it currently is. What is it >about my relatively minor changes to the type system that you object >to? I've just about finished changing the compiler front-end (in >relatively minor ways) to accomodate the proposal I made yesterday. >And it has the advantage of separating REF from TAGGED REF so we keep >the standard REF clean. > >On 7 Apr 2009, at 00:50, Mika Nystrom wrote: > >> Hi Rodney, >> >> I would like this capability too, but I am a bit wary of Tony's >> idea of changing the Modula-3 language---even in a "minor" way. >> I've been working for the last week or so on an application using >> the Modula-3 Toolkit, and I must say I have realized that the > Modula-3 type system has a lot more subtleties than I thought. I >> would not want to make any real changes to it. There's a paper >> called "The Modula-3 Type System" by Cardelli, Donahue, Kalsow, and >> Nelson that is worth studying in detail before making any changes >> whatsoever, I think. Also remember that changes to the type system >> will affect m3tk and anything that depends on m3tk (which includes >> two or three stub generators in the main tree and who knows how >> many dependencies outside of it). >> >> I'm still not sure why we can't take the approach of Word.T . >> Make a RefanyOrInt.T that can safely be: >> >> 1. Tested whether it is a small integer or a REFANY >> >> 2. If a REFANY, be dereferenced as normal, *or* via >> RefanyOrInt.ToRefany >> >> 3. If a small integer, can be extracted via RefanyOrInt.ToInt >> >> 4. Created either as a small integer or a REFANY >> >> Any other operations on it (including ISTYPE and TYPECASE, at least >> when the object is a small integer) would result in a checked runtime >> error. >> >> Note that with the declaration "RefanyOrInt.T = REFANY", the current >> compiler will as far as I know not accept any operations on >> RefanyOrInt.T outside of ISTYPE, TYPECASE, and NARROW (explicit or >> implicit). >> >> I wouldn't be surprised if most of what I'm proposing already works >> (i.e., crashes with a checked runtime error as it should) with the >> current runtime. Anything that slips through would need to be fixed >> up with a one-bit check of the LSB of the REFANY for the operations >> mentioned above. Unfortunately this has to be done for operations on >> every REFANY, not just the new type. >> >> I think that Modula-3 programmers are already aware that using >> REFANYs involves forcing the runtime to do extra type-checking work, >> so they already know not to use them if they are looking for maximum >> performance, so I don't think that burdening operations on REFANY >> with an extra one-bit check is too onerous. >> >> An advantage of my proposal is that the amount of code in the new >> proposed library is truly diminutive. In fact, I think I posted >> pretty much that code to the list a few weeks ago. >> >> (If you missed it, it's >> >> http://www.async.caltech.edu/~mika/interp/ >> >> ) >> >> Mika >> >> >> "Rodney M. Bates" writes: >>> I spent quite a bit of time playing with a more general system where >>> there is a set of "tagged" types, with (an implementation-defined >>> subrange of) INTEGER and a reference type both being a subtype of a >>> tagged type. It might have been tolerable, if it weren't for the >>> interaction with object subtypes and opaque types, which quickly >>> gets deep into a deep linguistic tar pit. >>> >>> Tony's approach is much simpler and would serve what I see as the >>> need. It does sacrifice any static checking of what reference type >>> is being tagged, and will also require an extra runtime ISTYPE/ >>> TYPECASE. >>> >>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>> also need to be an explicit conversion in that direction too, say >>> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >>> is a bit inconsistent with the usual Modula-3 assignability >>> philosophy, >>> but not requiring the explicit conversion already gets your toes >>> into tar. >>> >>> We would have to have something more like ISTYPE, though, which will >>> tell which type the value belongs to without risking a runtime error, >>> which VAL would do. >>> >>> An intermediate approach might be to have a set of tagged types >>> constructed by, say, TAGGED T, where I is a reference type, but >>> with no subtype relations on them at all, thus still requiring >>> the explicit conversions and checks. >>> >>> I do want to say, I _really_ want this capability somehow. I have >>> an ADT module whose internal data structure, for full generality, >>> needs to have two heap objects (the second because it has nonstatic >>> size) and 11 total words counting the orginal pointer, in the case of >>> values that would fit directly into the "pointer" word. Moreover, >>> these small cases are in the great majority. >>> >>> Besides the 11-to-one increase in actual occupied space, there >>> is extra time for allocation, periodic tracing, and collection, space >>> loss due to heap fragmentation, and time/space tradeoff loss due to >>> reduced locality of reference. So sometimes, it would be a big >>> performance gain if we could do it. >>> >>> >>> Tony Hosking wrote: >>> It is a much more pervasive hack than I would be comfortable with >>>> since it touches on the compiler (for all the type operations) as >>>> well >>>> as the run-time system in ways that are pretty gross. I would much >>>> rather have a new TAGGED builtin. ISTYPE would not work on it since >>>> that only works on references. The only thing you need is a way to >>>> extract the value -- we could overload VAL(x, T) where x can be a >>>> TAGGED and T can be REFANY or INTEGER. >>>> >>>> From hosking at cs.purdue.edu Tue Apr 7 03:00:46 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 11:00:46 +1000 Subject: [M3devel] Implementing the "Singleton pattern" in Modula-3 In-Reply-To: <200904062031.n36KVvC2094839@camembert.async.caltech.edu> References: <200904062031.n36KVvC2094839@camembert.async.caltech.edu> Message-ID: <110C0337-7E0A-4283-9F1C-BEBAF26929F8@cs.purdue.edu> I would exploit opaque types and branding. If T is opaque then you cannot instantiate T except in scopes where T's concrete type has been revealed or is known to be an object type. Thus, you could define an interface: GENERIC INTERFACE Singleton(Rep); TYPE T <: REFANY; VAR t: T; END Singleton. GENERIC MODULE Singleton(Rep); REVEAL T = BRANDED REF Rep.T; BEGIN t := NEW(T); END Singleton. where Rep defines the type T. You could do similar for object types. On 7 Apr 2009, at 06:31, Mika Nystrom wrote: > > Tony, Jay, you two seem to be most knowledgeable about this. > > Let's say I wanted to implement the "singleton pattern" in > Modula-3. At present there seems to be no way of doing this. > > What about changing RTAllocator.callback as follows (or adding > another callback): > > VAR callback : PROCEDURE(r : REFANY) : REFANY := NIL; > > (* If non-NIL, the allocator calls "callback(r)" just before returning > a new traced reference "r" and instead returns the result of > callback(r). > See "RTAllocStats" for an example client. It is a checked runtime > error > for the typecode of r to differ from the typecode of the return > value of > callback(r). *) > > Mika > > > From mika at async.caltech.edu Tue Apr 7 03:18:19 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 18:18:19 -0700 Subject: [M3devel] Implementing the "Singleton pattern" in Modula-3 In-Reply-To: Your message of "Tue, 07 Apr 2009 11:00:46 +1000." <110C0337-7E0A-4283-9F1C-BEBAF26929F8@cs.purdue.edu> Message-ID: <200904070118.n371IJQn002161@camembert.async.caltech.edu> Well I think the problem is with this "is known to be an object type"... You may in fact want to override the methods of the singleton, but ensure that only one ever gets instantiated. It's a minor problem, but it does sometimes bother me that it is difficult to prevent clients from NEWing pretty much anything they like. By the way, the "Modula-3 Type System" paper also talks about a nifty way to do narrowing very quickly (page 10, last paragraph). I remember this is occasionally problematic. (RTType.IsSubtype isn't great.) They speak of keeping an array of supertypes for each type, and recording the "depth" (distance from REFANY) of every type in, I guess, RT0.TypeDefn. This seems moderately space-efficient (better than a 2D array of all the typecodes), and very fast. Mika Tony Hosking writes: >I would exploit opaque types and branding. If T is opaque then you >cannot instantiate T except in scopes where T's concrete type has been >revealed or is known to be an object type. Thus, you could define an >interface: > >GENERIC INTERFACE Singleton(Rep); >TYPE T <: REFANY; >VAR t: T; >END Singleton. > >GENERIC MODULE Singleton(Rep); >REVEAL T = BRANDED REF Rep.T; >BEGIN > t := NEW(T); >END Singleton. > >where Rep defines the type T. You could do similar for object types. > > >On 7 Apr 2009, at 06:31, Mika Nystrom wrote: > >> >> Tony, Jay, you two seem to be most knowledgeable about this. >> >> Let's say I wanted to implement the "singleton pattern" in >> Modula-3. At present there seems to be no way of doing this. >> >> What about changing RTAllocator.callback as follows (or adding >> another callback): >> >> VAR callback : PROCEDURE(r : REFANY) : REFANY := NIL; >> >> (* If non-NIL, the allocator calls "callback(r)" just before returning >> a new traced reference "r" and instead returns the result of >> callback(r). >> See "RTAllocStats" for an example client. It is a checked runtime >> error >> for the typecode of r to differ from the typecode of the return >> value of >> callback(r). *) >> >> Mika >> >> >> From hosking at cs.purdue.edu Tue Apr 7 04:02:10 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 12:02:10 +1000 Subject: [M3devel] small objects In-Reply-To: <200904061529.n36FTTn0086974@camembert.async.caltech.edu> References: <200904061529.n36FTTn0086974@camembert.async.caltech.edu> Message-ID: <3F4FF36C-E96A-45F7-A345-4D557D424F52@cs.purdue.edu> On 7 Apr 2009, at 01:29, Mika Nystrom wrote: > Ah I should read my whole inbox before replying. As should I... ;-) > I take it you would worry that in my proposal (to do this all in a > library) the use of REFANY to store an integer could be abused > somehow. That the Modula-3 type system (as it exists now) explicitly > rules out doing such things, and therefore, a language change is > necessary.... My concern is the mismatch between NIL checking and tag-checking. I'd like to partition tagged references from regular references to keep things clean. I never liked overloading, especially for a systems language like Modula-3 where operations and typing should have a reasonable (and efficient) operational semantics. > > > Mika > > Tony Hosking writes: >> I like the notion of having a TAGGED INTEGER type that is a hybrid >> ordinal/reference. >> >> Subtyping rules for references would now be as follows: >> >> NULL <: REF T <: REFANY >> TAGGED INTEGER <: REF T <: REFANY >> >> ROOT <: REFANY >> NULL <: T OBJECT ... END <: T >> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: REFANY, >> not >> T <: ADDRESS) >> >> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >> type. Values of TAGGED INTEGER are non-pointer values similar to the >> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and NARROW(x, >> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to ISTYPE(x, >> NULL), NARROW(x, NULL), and TYPECODE(NULL). >> >> Because TAGGED INTEGER is an ordinal we can extract the integer value >> it holds using ORD(x). >> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >> INTEGER). >> >> ***The only problem with this scheme is how to efficiently perform >> run- >> time tests for dereferencing NULL, and TAGGED INTEGER?*** >> >> So, here is a slightly less elegant alternative that is probably >> straightforward to implement. Introduce a separate TAGGED hierarchy. >> >> NULL <: REF T <: REFANY >> NULL <: UNTRACED REF T <: ADDRESS >> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >> >> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >> >> ROOT <: REFANY >> TAGGED ROOT <: TAGGED REFANY >> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >> >> Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED >> REFANY. >> >> This way, tagged references only need a run-time test for the tag on >> dereference (we can throw an "attempt to dereference TAGGED INTEGER" >> at run time, just like we throw "attempt to dereference NIL" for >> untagged references). This check can be a straightforward test of >> the >> low bit tag. Of course, the weird thing here is now that we don't >> have a single NULL value for TAGGED references --- we have multiple >> null values VAL(x, TAGGED INTEGER). Instead of asking "x == NIL" we >> must ask "ISTYPE(x, TAGGED INTEGER)". >> >> Of course, because TAGGED INTEGER is an ordinal, we can also perform >> the usual ordinal operations like INC(x), DEC(x), wherever x is typed >> TAGGED INTEGER. >> >> >> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >> >>> I spent quite a bit of time playing with a more general system where >>> there is a set of "tagged" types, with (an implementation-defined >>> subrange of) INTEGER and a reference type both being a subtype of a >>> tagged type. It might have been tolerable, if it weren't for the >>> interaction with object subtypes and opaque types, which quickly >>> gets deep into a deep linguistic tar pit. >>> >>> Tony's approach is much simpler and would serve what I see as the >>> need. It does sacrifice any static checking of what reference type >>> is being tagged, and will also require an extra runtime ISTYPE/ >>> TYPECASE. >>> >>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>> also need to be an explicit conversion in that direction too, say >>> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >>> is a bit inconsistent with the usual Modula-3 assignability >>> philosophy, >>> but not requiring the explicit conversion already gets your toes >>> into tar. >>> >>> We would have to have something more like ISTYPE, though, which will >>> tell which type the value belongs to without risking a runtime >>> error, >>> which VAL would do. >>> >>> An intermediate approach might be to have a set of tagged types >>> constructed by, say, TAGGED T, where I is a reference type, but >>> with no subtype relations on them at all, thus still requiring >>> the explicit conversions and checks. >>> >>> I do want to say, I _really_ want this capability somehow. I have >>> an ADT module whose internal data structure, for full generality, >>> needs to have two heap objects (the second because it has nonstatic >>> size) and 11 total words counting the orginal pointer, in the case >>> of >>> values that would fit directly into the "pointer" word. Moreover, >>> these small cases are in the great majority. >>> >>> Besides the 11-to-one increase in actual occupied space, there >>> is extra time for allocation, periodic tracing, and collection, >>> space >>> loss due to heap fragmentation, and time/space tradeoff loss due to >>> reduced locality of reference. So sometimes, it would be a big >>> performance gain if we could do it. >>> >>> >>> Tony Hosking wrote: >>>> It is a much more pervasive hack than I would be comfortable with >>>> since it touches on the compiler (for all the type operations) as >>>> well >>>> as the run-time system in ways that are pretty gross. I would much >>>> rather have a new TAGGED builtin. ISTYPE would not work on it >>>> since >>>> that only works on references. The only thing you need is a way to >>>> extract the value -- we could overload VAL(x, T) where x can be a >>>> TAGGED and T can be REFANY or INTEGER. >>>> From hosking at cs.purdue.edu Tue Apr 7 04:03:35 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 12:03:35 +1000 Subject: [M3devel] small objects In-Reply-To: <200904062003.n36K3381094096@camembert.async.caltech.edu> References: <200904062003.n36K3381094096@camembert.async.caltech.edu> Message-ID: <92E0969B-63C7-43BE-A501-B78A5E520B55@cs.purdue.edu> On 7 Apr 2009, at 06:03, Mika Nystrom wrote: > "Rodney M. Bates" writes: >> At first, I just envisioned implementing a small object type >> entirely inside an UNSAFE module, using unsafe operations >> to construct/test/separate the values. I think if the GC were >> to just to ignore words in heap objects that the type system >> claims are unambiguously pointers but actually have misaligned >> values, this could be done. > > Right that's precisely what the module I posted does. > >> >> But it flies in the face of a fundamental principle of Modula-3, >> namely that an UNSAFE module, if coded correctly, can prevent >> all other code from consequences of the unsafety. Unfortunately, >> this can't be done with the small pointers, because, even if >> opaque, they are still reference types, and client code can >> dereference them (including the implicit dereference in accessing >> a method or field of an object) and do ISTYPE, NARROW, TYPECASE, >> and assignments that do an implicit NARROW. All these operations >> could be done outside the implementing module and all could >> suffer from misaligned values. > > Well yes that is true. But the client can't dereference REFANY. > Modula-3 doesn't permit that. That's an important practical point, > because now we're limited to the other things: ISTYPE, NARROW > (implicit and explicit), TYPECASE. (There are two more, actually, > and they are = and #.) As long as those can be guaranteed to fail > you're OK. [ Actually see my P.S. below! ] > >> >> In fact, misaligned integer "objects" violate another principle that >> the bit pattern must always be a valid representation of some value >> of the type. > > Yes I think maybe this is what Tony is worried about. But let's > just change the definition of REFANY to include anything with the > LSB set...? But then a "NULL" check needs to both test for zero and test for lsb set. I am not comfortable with this. > In Modula-3-ese it would be more like the following: > > "REFANY can hold three types of objects. NIL, REF something or an > implementation-defined other set of values that can only be accessed > in an UNSAFE module. It is a checked runtime error to pass a 'REFANY > of the third kind' to ISTYPE, NARROW, TYPECASE." [ Actually see my > P.S. below! ] > > Then I propose we punt the handling of the new REFANYs to this > unsafe module we spoke about above. As far as Modula-3 is concerned, > there's just a set of values of (apparently) very little utility > that can be represented by REFANY. If you think about it, this is > really not so crazy. Any module that uses REFANY today is designed > around to the fact that there are plenty of values of REFANY that > can be of no interest to that module except for passing along to > another module. (REFANY can easily represent a type which a module > has no way of accessing *any* declaration of beyond just REFANY.) > We're just adding some others, the only difference being that the > new values are of no interest to any non-UNSAFE module. (Eh, > technically this is already true for any reference type that is > declared in an UNSAFE module today so one might argue we have in > fact added nothing.) > >> >> However, this does suggest a different and very simple linguistic >> solution: Just have a new builtin type, say VERYOPAQUE, that >> supports no operations other than moving it around, i.e., >> assignment, bindings, passing as a parameter, etc. Only unsafe >> code could do anyhing with it, by using LOOPHOLE. The only >> problem is, would somebody then want one of these in a size other >> than one word? > > This is nice, and we already have a candidate type, in fact: ADDRESS. > But the problem is that the GC doesn't follow this even if the LSB > is clear... which we *do* want. > > Why are you worried about getting it in sizes other than one word? > That seems to me to be an application problem. If someone wants > an ARRAY OF VERYOPAQUE is that a problem? > > Mika > > P.S. Illustration of the above, in today's Modula-3: > > UNSAFE MODULE Unsafe; > > (* this module is just declared UNSAFE to conform with the definition > above, namely, that T can only be manipulated in an UNSAFE > module, which this is! *) > > TYPE T = BRANDED OBJECT END; > > BEGIN > Safe.P(NEW(T)) > END Unsafe. > > (****************************************) > > MODULE Safe; > > PROCEDURE P(r : REFANY) = > BEGIN > NARROW(r, X); (* checked runtime error for all X *) > > ISTYPE(r, X); (* returns FALSE for all X except REFANY itself *) > > TYPECASE r OF > X => (* only gets executed for X = REFANY *) > END; > END P; > > BEGIN END Safe. > > Actually is this behavior so bad for tagged integers? Since it is > the behavior of existing code... why not keep it? Then you can even > store a tagged integer in a RefList.T, say, even if that RefList.T > uses NARROW or ISTYPE on the argument (I don't see why it would, but > why not...?) > > > >> >> Mika Nystrom wrote: >>> Ah I should read my whole inbox before replying. >>> >>> I take it you would worry that in my proposal (to do this all in a >>> library) the use of REFANY to store an integer could be abused >>> somehow. That the Modula-3 type system (as it exists now) >>> explicitly >>> rules out doing such things, and therefore, a language change is >>> necessary.... >>> >>> Mika >>> >>> Tony Hosking writes: >>> >>>> I like the notion of having a TAGGED INTEGER type that is a hybrid >>>> ordinal/reference. >>>> >>>> Subtyping rules for references would now be as follows: >>>> >>>> NULL <: REF T <: REFANY >>>> TAGGED INTEGER <: REF T <: REFANY >>>> >>>> ROOT <: REFANY >>>> NULL <: T OBJECT ... END <: T >>>> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: >>>> REFANY, not >>>> T <: ADDRESS) >>>> >>>> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >>>> type. Values of TAGGED INTEGER are non-pointer values similar to >>>> the >>>> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and NARROW(x, >>>> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to >>>> ISTYPE(x, >>>> NULL), NARROW(x, NULL), and TYPECODE(NULL). >>>> >>>> Because TAGGED INTEGER is an ordinal we can extract the integer >>>> value >>>> it holds using ORD(x). >>>> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >>>> INTEGER). >>>> >>>> ***The only problem with this scheme is how to efficiently >>>> perform run- >>>> time tests for dereferencing NULL, and TAGGED INTEGER?*** >>> >>>> So, here is a slightly less elegant alternative that is probably >>>> straightforward to implement. Introduce a separate TAGGED >>>> hierarchy. >>>> >>>> NULL <: REF T <: REFANY >>>> NULL <: UNTRACED REF T <: ADDRESS >>>> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >>>> >>>> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >>>> >>>> ROOT <: REFANY >>>> TAGGED ROOT <: TAGGED REFANY >>>> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >>>> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >>>> >>>> Note that NULL is not a subtype of T OBJECT ... END where T <: >>>> TAGGED >>>> REFANY. >>>> >>>> This way, tagged references only need a run-time test for the tag >>>> on >>>> dereference (we can throw an "attempt to dereference TAGGED >>>> INTEGER" >>>> at run time, just like we throw "attempt to dereference NIL" for >>>> untagged references). This check can be a straightforward test >>>> of the >>>> low bit tag. Of course, the weird thing here is now that we don't >>>> have a single NULL value for TAGGED references --- we have multiple >>>> null values VAL(x, TAGGED INTEGER). Instead of asking "x == NIL" >>>> we >>>> must ask "ISTYPE(x, TAGGED INTEGER)". >>>> >>>> Of course, because TAGGED INTEGER is an ordinal, we can also >>>> perform >>>> the usual ordinal operations like INC(x), DEC(x), wherever x is >>>> typed >>>> TAGGED INTEGER. >>>> >>>> >>>> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >>>> >>>> >>>>> I spent quite a bit of time playing with a more general system >>>>> where >>>>> there is a set of "tagged" types, with (an implementation-defined >>>>> subrange of) INTEGER and a reference type both being a subtype >>>>> of a >>>>> tagged type. It might have been tolerable, if it weren't for the >>>>> interaction with object subtypes and opaque types, which quickly >>>>> gets deep into a deep linguistic tar pit. >>>>> >>>>> Tony's approach is much simpler and would serve what I see as the >>>>> need. It does sacrifice any static checking of what reference >>>>> type >>>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>>> TYPECASE. >>>>> >>>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>>> also need to be an explicit conversion in that direction too, say >>>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >>>>> is a bit inconsistent with the usual Modula-3 assignability >>>>> philosophy, >>>>> but not requiring the explicit conversion already gets your toes >>>>> into tar. >>>>> >>>>> We would have to have something more like ISTYPE, though, which >>>>> will >>>>> tell which type the value belongs to without risking a runtime >>>>> error, >>>>> which VAL would do. >>>>> >>>>> An intermediate approach might be to have a set of tagged types >>>>> constructed by, say, TAGGED T, where I is a reference type, but >>>>> with no subtype relations on them at all, thus still requiring >>>>> the explicit conversions and checks. >>>>> >>>>> I do want to say, I _really_ want this capability somehow. I have >>>>> an ADT module whose internal data structure, for full generality, >>>>> needs to have two heap objects (the second because it has >>>>> nonstatic >>>>> size) and 11 total words counting the orginal pointer, in the >>>>> case of >>>>> values that would fit directly into the "pointer" word. >>>>> Moreover, >>>>> these small cases are in the great majority. >>>>> >>>>> Besides the 11-to-one increase in actual occupied space, there >>>>> is extra time for allocation, periodic tracing, and collection, >>>>> space >>>>> loss due to heap fragmentation, and time/space tradeoff loss due >>>>> to >>>>> reduced locality of reference. So sometimes, it would be a big >>>>> performance gain if we could do it. >>>>> >>>>> >>>>> Tony Hosking wrote: >>>>> >>>>>> It is a much more pervasive hack than I would be comfortable with >>>>>> since it touches on the compiler (for all the type operations) as >>>>>> well >>>>>> as the run-time system in ways that are pretty gross. I would >>>>>> much >>>>>> rather have a new TAGGED builtin. ISTYPE would not work on it >>>>>> since >>>>>> that only works on references. The only thing you need is a >>>>>> way to >>>>>> extract the value -- we could overload VAL(x, T) where x can be a >>>>>> TAGGED and T can be REFANY or INTEGER. >>>>>> >>>>>> >>> >>> From hosking at cs.purdue.edu Tue Apr 7 04:04:51 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 12:04:51 +1000 Subject: [M3devel] small objects In-Reply-To: <200904062017.n36KHbcq094473@camembert.async.caltech.edu> References: <200904062017.n36KHbcq094473@camembert.async.caltech.edu> Message-ID: <06AB3448-B400-4D98-8283-399355263471@cs.purdue.edu> I still don't understand the objections to my proposal. I think it is a similarly small change that does not pollute the old REFANY hierarchy. On 7 Apr 2009, at 06:17, Mika Nystrom wrote: > Ok I admit I missed something important. > > TYPECODE. > > It's easy enough to allocate a special TYPECODE to the tagged > integer. One not used by any "real" type of course. > > It will break pickles and fingerprints. Pickles can be fixed, > check the typecode and call a routine in the TaggedInteger > interface (by default, user can override it?) to translate > to and fro. > > But what about fingerprints? Again I guess we can just > return the fingerprint of a nonexistent > type............................. > > Hummm humm. > > Ok, how about this... > > let's declare a completely hidden type ... > > UNSAFE MODULE TaggedInteger; > > TYPE T = BRANDED OBJECT x : INTEGER END; > > BEGIN END TaggedInteger. > > Now, fix up TYPECODE, ISTYPE, NARROW, TYPECASE so that they all > act *precisely* as if TaggedInteger.T were passed to them, > when they see a REFANY with the LSB set. fingerprinting the > type will give you the fingerprint of TaggedInteger.T. (But > you better not rely on that! Only UNSAFE modules can do anything > with this information, anyhow, so who cares, but see below.) > > I don't see how this breaks anything at all once we introduce the > 'REFANY of the third kind', which is so small a change to the > language's type system that I'm not sure it even qualifies as a > change. Pickles are already unsafe, so the fact that the current > pickles package would subvert the type system based on what I propose > is a non-issue (language wise), it just means a few extra lines of > code in the pickles package. > > The reason for the x : field above is that I propose that this > be how the tagged integer be un/pickled, as an instance of an > object of the (actual) type TaggedInteger.T. > > Mika > > > > > Mika Nystrom writes: >> "Rodney M. Bates" writes: >>> At first, I just envisioned implementing a small object type >>> entirely inside an UNSAFE module, using unsafe operations >>> to construct/test/separate the values. I think if the GC were >>> to just to ignore words in heap objects that the type system >>> claims are unambiguously pointers but actually have misaligned >>> values, this could be done. >> >> Right that's precisely what the module I posted does. >> >>> >>> But it flies in the face of a fundamental principle of Modula-3, >>> namely that an UNSAFE module, if coded correctly, can prevent >>> all other code from consequences of the unsafety. Unfortunately, >>> this can't be done with the small pointers, because, even if >>> opaque, they are still reference types, and client code can >>> dereference them (including the implicit dereference in accessing >>> a method or field of an object) and do ISTYPE, NARROW, TYPECASE, >>> and assignments that do an implicit NARROW. All these operations >>> could be done outside the implementing module and all could >>> suffer from misaligned values. >> >> Well yes that is true. But the client can't dereference REFANY. >> Modula-3 doesn't permit that. That's an important practical point, >> because now we're limited to the other things: ISTYPE, NARROW >> (implicit and explicit), TYPECASE. (There are two more, actually, >> and they are = and #.) As long as those can be guaranteed to fail >> you're OK. [ Actually see my P.S. below! ] >> >>> >>> In fact, misaligned integer "objects" violate another principle >>> that >>> the bit pattern must always be a valid representation of some value >>> of the type. >> >> Yes I think maybe this is what Tony is worried about. But let's >> just change the definition of REFANY to include anything with the >> LSB set...? >> >> In Modula-3-ese it would be more like the following: >> >> "REFANY can hold three types of objects. NIL, REF something or an >> implementation-defined other set of values that can only be accessed >> in an UNSAFE module. It is a checked runtime error to pass a 'REFANY >> of the third kind' to ISTYPE, NARROW, TYPECASE." [ Actually see my >> P.S. below! ] >> >> Then I propose we punt the handling of the new REFANYs to this >> unsafe module we spoke about above. As far as Modula-3 is concerned, >> there's just a set of values of (apparently) very little utility >> that can be represented by REFANY. If you think about it, this is >> really not so crazy. Any module that uses REFANY today is designed >> around to the fact that there are plenty of values of REFANY that >> can be of no interest to that module except for passing along to >> another module. (REFANY can easily represent a type which a module >> has no way of accessing *any* declaration of beyond just REFANY.) >> We're just adding some others, the only difference being that the >> new values are of no interest to any non-UNSAFE module. (Eh, >> technically this is already true for any reference type that is >> declared in an UNSAFE module today so one might argue we have in >> fact added nothing.) >> >>> >>> However, this does suggest a different and very simple linguistic >>> solution: Just have a new builtin type, say VERYOPAQUE, that >>> supports no operations other than moving it around, i.e., >>> assignment, bindings, passing as a parameter, etc. Only unsafe >>> code could do anyhing with it, by using LOOPHOLE. The only >>> problem is, would somebody then want one of these in a size other >>> than one word? >> >> This is nice, and we already have a candidate type, in fact: ADDRESS. >> But the problem is that the GC doesn't follow this even if the LSB >> is clear... which we *do* want. >> >> Why are you worried about getting it in sizes other than one word? >> That seems to me to be an application problem. If someone wants >> an ARRAY OF VERYOPAQUE is that a problem? >> >> Mika >> >> P.S. Illustration of the above, in today's Modula-3: >> >> UNSAFE MODULE Unsafe; >> >> (* this module is just declared UNSAFE to conform with the definition >> above, namely, that T can only be manipulated in an UNSAFE >> module, which this is! *) >> >> TYPE T = BRANDED OBJECT END; >> >> BEGIN >> Safe.P(NEW(T)) >> END Unsafe. >> >> (****************************************) >> >> MODULE Safe; >> >> PROCEDURE P(r : REFANY) = >> BEGIN >> NARROW(r, X); (* checked runtime error for all X *) >> >> ISTYPE(r, X); (* returns FALSE for all X except REFANY itself *) >> >> TYPECASE r OF >> X => (* only gets executed for X = REFANY *) >> END; >> END P; >> >> BEGIN END Safe. >> >> Actually is this behavior so bad for tagged integers? Since it is >> the behavior of existing code... why not keep it? Then you can even >> store a tagged integer in a RefList.T, say, even if that RefList.T >> uses NARROW or ISTYPE on the argument (I don't see why it would, but >> why not...?) >> >> >> >>> >>> Mika Nystrom wrote: >>>> Ah I should read my whole inbox before replying. >>>> >>>> I take it you would worry that in my proposal (to do this all in a >>>> library) the use of REFANY to store an integer could be abused >>>> somehow. That the Modula-3 type system (as it exists now) >>>> explicitly >>>> rules out doing such things, and therefore, a language change is >>>> necessary.... >>>> >>>> Mika >>>> >>>> Tony Hosking writes: >>>> >>>>> I like the notion of having a TAGGED INTEGER type that is a hybrid >>>>> ordinal/reference. >>>>> >>>>> Subtyping rules for references would now be as follows: >>>>> >>>>> NULL <: REF T <: REFANY >>>>> TAGGED INTEGER <: REF T <: REFANY >>>>> >>>>> ROOT <: REFANY >>>>> NULL <: T OBJECT ... END <: T >>>>> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: >>>>> REFANY, not >>>>> T <: ADDRESS) >>>>> >>>>> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >>>>> type. Values of TAGGED INTEGER are non-pointer values similar >>>>> to the >>>>> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and >>>>> NARROW(x, >>>>> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to >>>>> ISTYPE(x, >>>>> NULL), NARROW(x, NULL), and TYPECODE(NULL). >>>>> >>>>> Because TAGGED INTEGER is an ordinal we can extract the integer >>>>> value >>>>> it holds using ORD(x). >>>>> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >>>>> INTEGER). >>>>> >>>>> ***The only problem with this scheme is how to efficiently >>>>> perform run- >>>>> time tests for dereferencing NULL, and TAGGED INTEGER?*** >>>> >>>>> So, here is a slightly less elegant alternative that is probably >>>>> straightforward to implement. Introduce a separate TAGGED >>>>> hierarchy. >>>>> >>>>> NULL <: REF T <: REFANY >>>>> NULL <: UNTRACED REF T <: ADDRESS >>>>> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >>>>> >>>>> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >>>>> >>>>> ROOT <: REFANY >>>>> TAGGED ROOT <: TAGGED REFANY >>>>> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >>>>> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >>>>> >>>>> Note that NULL is not a subtype of T OBJECT ... END where T <: >>>>> TAGGED >>>>> REFANY. >>>>> >>>>> This way, tagged references only need a run-time test for the >>>>> tag on >>>>> dereference (we can throw an "attempt to dereference TAGGED >>>>> INTEGER" >>>>> at run time, just like we throw "attempt to dereference NIL" for >>>>> untagged references). This check can be a straightforward test >>>>> of the >>>>> low bit tag. Of course, the weird thing here is now that we don't >>>>> have a single NULL value for TAGGED references --- we have >>>>> multiple >>>>> null values VAL(x, TAGGED INTEGER). Instead of asking "x == >>>>> NIL" we >>>>> must ask "ISTYPE(x, TAGGED INTEGER)". >>>>> >>>>> Of course, because TAGGED INTEGER is an ordinal, we can also >>>>> perform >>>>> the usual ordinal operations like INC(x), DEC(x), wherever x is >>>>> typed >>>>> TAGGED INTEGER. >>>>> >>>>> >>>>> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >>>>> >>>>> >>>>>> I spent quite a bit of time playing with a more general system >>>>>> where >>>>>> there is a set of "tagged" types, with (an implementation-defined >>>>>> subrange of) INTEGER and a reference type both being a subtype >>>>>> of a >>>>>> tagged type. It might have been tolerable, if it weren't for the >>>>>> interaction with object subtypes and opaque types, which quickly >>>>>> gets deep into a deep linguistic tar pit. >>>>>> >>>>>> Tony's approach is much simpler and would serve what I see as the >>>>>> need. It does sacrifice any static checking of what reference >>>>>> type >>>>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>>>> TYPECASE. >>>>>> >>>>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>>>> also need to be an explicit conversion in that direction too, say >>>>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. >>>>>> It >>>>>> is a bit inconsistent with the usual Modula-3 assignability >>>>>> philosophy, >>>>>> but not requiring the explicit conversion already gets your toes >>>>>> into tar. >>>>>> >>>>>> We would have to have something more like ISTYPE, though, which >>>>>> will >>>>>> tell which type the value belongs to without risking a runtime >>>>>> error, >>>>>> which VAL would do. >>>>>> >>>>>> An intermediate approach might be to have a set of tagged types >>>>>> constructed by, say, TAGGED T, where I is a reference type, but >>>>>> with no subtype relations on them at all, thus still requiring >>>>>> the explicit conversions and checks. >>>>>> >>>>>> I do want to say, I _really_ want this capability somehow. I >>>>>> have >>>>>> an ADT module whose internal data structure, for full generality, >>>>>> needs to have two heap objects (the second because it has >>>>>> nonstatic >>>>>> size) and 11 total words counting the orginal pointer, in the >>>>>> case of >>>>>> values that would fit directly into the "pointer" word. >>>>>> Moreover, >>>>>> these small cases are in the great majority. >>>>>> >>>>>> Besides the 11-to-one increase in actual occupied space, there >>>>>> is extra time for allocation, periodic tracing, and collection, >>>>>> space >>>>>> loss due to heap fragmentation, and time/space tradeoff loss >>>>>> due to >>>>>> reduced locality of reference. So sometimes, it would be a big >>>>>> performance gain if we could do it. >>>>>> >>>>>> >>>>>> Tony Hosking wrote: >>>>>> >>>>>>> It is a much more pervasive hack than I would be comfortable >>>>>>> with >>>>>>> since it touches on the compiler (for all the type operations) >>>>>>> as >>>>>>> well >>>>>>> as the run-time system in ways that are pretty gross. I would >>>>>>> much >>>>>>> rather have a new TAGGED builtin. ISTYPE would not work on it >>>>>>> since >>>>>>> that only works on references. The only thing you need is a >>>>>>> way to >>>>>>> extract the value -- we could overload VAL(x, T) where x can >>>>>>> be a >>>>>>> TAGGED and T can be REFANY or INTEGER. >>>>>>> >>>>>>> >>>> >>>> From hosking at cs.purdue.edu Tue Apr 7 04:07:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 12:07:19 +1000 Subject: [M3devel] Implementing the "Singleton pattern" in Modula-3 In-Reply-To: <200904070118.n371IJQn002161@camembert.async.caltech.edu> References: <200904070118.n371IJQn002161@camembert.async.caltech.edu> Message-ID: On 7 Apr 2009, at 11:18, Mika Nystrom wrote: > Well I think the problem is with this "is known to be an object > type"... But if the opaque type T is T<:REFANY and the only revelation is branded and private to a module (not exported by its interfaces) then no-one can determine that it is an object type without forging the BRAND. > You may in fact want to override the methods of the singleton, but > ensure that only one ever gets instantiated. > > It's a minor problem, but it does sometimes bother me that it is > difficult to prevent clients from NEWing pretty much anything they > like. > > By the way, the "Modula-3 Type System" paper also talks about a > nifty way to do narrowing very quickly (page 10, last paragraph). > I remember this is occasionally problematic. (RTType.IsSubtype > isn't great.) They speak of keeping an array of supertypes > for each type, and recording the "depth" (distance from REFANY) > of every type in, I guess, RT0.TypeDefn. This seems moderately > space-efficient (better than a 2D array of all the typecodes), > and very fast. > > Mika > > Tony Hosking writes: >> I would exploit opaque types and branding. If T is opaque then you >> cannot instantiate T except in scopes where T's concrete type has >> been >> revealed or is known to be an object type. Thus, you could define an >> interface: >> >> GENERIC INTERFACE Singleton(Rep); >> TYPE T <: REFANY; >> VAR t: T; >> END Singleton. >> >> GENERIC MODULE Singleton(Rep); >> REVEAL T = BRANDED REF Rep.T; >> BEGIN >> t := NEW(T); >> END Singleton. >> >> where Rep defines the type T. You could do similar for object types. >> >> >> On 7 Apr 2009, at 06:31, Mika Nystrom wrote: >> >>> >>> Tony, Jay, you two seem to be most knowledgeable about this. >>> >>> Let's say I wanted to implement the "singleton pattern" in >>> Modula-3. At present there seems to be no way of doing this. >>> >>> What about changing RTAllocator.callback as follows (or adding >>> another callback): >>> >>> VAR callback : PROCEDURE(r : REFANY) : REFANY := NIL; >>> >>> (* If non-NIL, the allocator calls "callback(r)" just before >>> returning >>> a new traced reference "r" and instead returns the result of >>> callback(r). >>> See "RTAllocStats" for an example client. It is a checked runtime >>> error >>> for the typecode of r to differ from the typecode of the return >>> value of >>> callback(r). *) >>> >>> Mika >>> >>> >>> From hosking at cs.purdue.edu Tue Apr 7 04:16:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 12:16:29 +1000 Subject: [M3devel] small objects In-Reply-To: <200904070042.n370gNK3001242@camembert.async.caltech.edu> References: <200904070042.n370gNK3001242@camembert.async.caltech.edu> Message-ID: <9F2237E2-73A2-4926-A438-A6032F70B4F6@cs.purdue.edu> On 7 Apr 2009, at 10:42, Mika Nystrom wrote: > You mean this proposal (you had two, I think)? Yes, this is the proposal I converged on. It really is only minimal change to the type system: introduction of a third hierarchy of TAGGED reference types. I did something similar for orthogonal persistence a few years ago where it was useful to have a TRANSIENT reference hierarchy for things that should not persist. [The semantics was that every run of a program would initialize TRANSIENT references to NIL rather than have them have the persistent value. This was slightly messier in that I also permitted TRANSIENT REFANY <: REFANY, which was a little odd.] > -- > > NULL <: REF T <: REFANY > NULL <: UNTRACED REF T <: ADDRESS > TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY > > Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. > > ROOT <: REFANY > TAGGED ROOT <: TAGGED REFANY > NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS > TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY > > Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED > REFANY. > > --- > > I like it fine, I think... I'm just worried, generally, about > changing the type system. Hmmmm... you mean that the TAGGED > things would just be a separate hierarchy? The change is relatively minor in that it doesn't touch the original REFANY hierarchy. > So you'd just add TAGGED in front of the REFs for this new hierarchy. > But why no NULL? No NULL because then we need a test for both NIL and values of type TAGGED INTEGER on every dereference. You can easily declare: TYPE Null = TAGGED INTEGER; CONST Nil = VAL(0, TAGGED INTEGER); The point is that TAGGED INTEGER now lets you have a range of non- pointer reference values, whereas NIL is the singleton non-reference value in type NULL. > And you're comfortable with doing the conversions automatically? No, I said that the conversions needed to be explicit > > So > > tx : TAGGED INTEGER := 5; tx: TAGGED INTEGER := VAL(5,TAGGED INTEGER); > x : INTEGER := tx; x: INTEGER := ORD(tx); > would be OK? > > In that case it's just the m3tk that needs to be modified, and > that's just busy work, I think. If it works it's beautiful... As I said, I am almost done with the compiler changes, and only need to push it into the run-time. Things like m3tk and pickles will need to be smartened up as necessary. > > > Mika > > > > Tony Hosking writes: >> I really don't like your proposal for the reasons you mention. It >> makes regular REF more expensive than it currently is. What is it >> about my relatively minor changes to the type system that you object >> to? I've just about finished changing the compiler front-end (in >> relatively minor ways) to accomodate the proposal I made yesterday. >> And it has the advantage of separating REF from TAGGED REF so we keep >> the standard REF clean. >> >> On 7 Apr 2009, at 00:50, Mika Nystrom wrote: >> >>> Hi Rodney, >>> >>> I would like this capability too, but I am a bit wary of Tony's >>> idea of changing the Modula-3 language---even in a "minor" way. >>> I've been working for the last week or so on an application using >>> the Modula-3 Toolkit, and I must say I have realized that the >> Modula-3 type system has a lot more subtleties than I thought. I >>> would not want to make any real changes to it. There's a paper >>> called "The Modula-3 Type System" by Cardelli, Donahue, Kalsow, and >>> Nelson that is worth studying in detail before making any changes >>> whatsoever, I think. Also remember that changes to the type system >>> will affect m3tk and anything that depends on m3tk (which includes >>> two or three stub generators in the main tree and who knows how >>> many dependencies outside of it). >>> >>> I'm still not sure why we can't take the approach of Word.T . >>> Make a RefanyOrInt.T that can safely be: >>> >>> 1. Tested whether it is a small integer or a REFANY >>> >>> 2. If a REFANY, be dereferenced as normal, *or* via >>> RefanyOrInt.ToRefany >>> >>> 3. If a small integer, can be extracted via RefanyOrInt.ToInt >>> >>> 4. Created either as a small integer or a REFANY >>> >>> Any other operations on it (including ISTYPE and TYPECASE, at least >>> when the object is a small integer) would result in a checked >>> runtime >>> error. >>> >>> Note that with the declaration "RefanyOrInt.T = REFANY", the current >>> compiler will as far as I know not accept any operations on >>> RefanyOrInt.T outside of ISTYPE, TYPECASE, and NARROW (explicit or >>> implicit). >>> >>> I wouldn't be surprised if most of what I'm proposing already works >>> (i.e., crashes with a checked runtime error as it should) with the >>> current runtime. Anything that slips through would need to be fixed >>> up with a one-bit check of the LSB of the REFANY for the operations >>> mentioned above. Unfortunately this has to be done for operations >>> on >>> every REFANY, not just the new type. >>> >>> I think that Modula-3 programmers are already aware that using >>> REFANYs involves forcing the runtime to do extra type-checking work, >>> so they already know not to use them if they are looking for maximum >>> performance, so I don't think that burdening operations on REFANY >>> with an extra one-bit check is too onerous. >>> >>> An advantage of my proposal is that the amount of code in the new >>> proposed library is truly diminutive. In fact, I think I posted >>> pretty much that code to the list a few weeks ago. >>> >>> (If you missed it, it's >>> >>> http://www.async.caltech.edu/~mika/interp/ >>> >>> ) >>> >>> Mika >>> >>> >>> "Rodney M. Bates" writes: >>>> I spent quite a bit of time playing with a more general system >>>> where >>>> there is a set of "tagged" types, with (an implementation-defined >>>> subrange of) INTEGER and a reference type both being a subtype of a >>>> tagged type. It might have been tolerable, if it weren't for the >>>> interaction with object subtypes and opaque types, which quickly >>>> gets deep into a deep linguistic tar pit. >>>> >>>> Tony's approach is much simpler and would serve what I see as the >>>> need. It does sacrifice any static checking of what reference type >>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>> TYPECASE. >>>> >>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>> also need to be an explicit conversion in that direction too, say >>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >>>> is a bit inconsistent with the usual Modula-3 assignability >>>> philosophy, >>>> but not requiring the explicit conversion already gets your toes >>>> into tar. >>>> >>>> We would have to have something more like ISTYPE, though, which >>>> will >>>> tell which type the value belongs to without risking a runtime >>>> error, >>>> which VAL would do. >>>> >>>> An intermediate approach might be to have a set of tagged types >>>> constructed by, say, TAGGED T, where I is a reference type, but >>>> with no subtype relations on them at all, thus still requiring >>>> the explicit conversions and checks. >>>> >>>> I do want to say, I _really_ want this capability somehow. I have >>>> an ADT module whose internal data structure, for full generality, >>>> needs to have two heap objects (the second because it has nonstatic >>>> size) and 11 total words counting the orginal pointer, in the >>>> case of >>>> values that would fit directly into the "pointer" word. Moreover, >>>> these small cases are in the great majority. >>>> >>>> Besides the 11-to-one increase in actual occupied space, there >>>> is extra time for allocation, periodic tracing, and collection, >>>> space >>>> loss due to heap fragmentation, and time/space tradeoff loss due to >>>> reduced locality of reference. So sometimes, it would be a big >>>> performance gain if we could do it. >>>> >>>> >>>> Tony Hosking wrote: >>>> It is a much more pervasive hack than I would be comfortable with >>>>> since it touches on the compiler (for all the type operations) as >>>>> well >>>>> as the run-time system in ways that are pretty gross. I would >>>>> much >>>>> rather have a new TAGGED builtin. ISTYPE would not work on it >>>>> since >>>>> that only works on references. The only thing you need is a way >>>>> to >>>>> extract the value -- we could overload VAL(x, T) where x can be a >>>>> TAGGED and T can be REFANY or INTEGER. >>>>> >>>>> From rcoleburn at scires.com Tue Apr 7 04:27:42 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 06 Apr 2009 22:27:42 -0400 Subject: [M3devel] small objects In-Reply-To: <9F2237E2-73A2-4926-A438-A6032F70B4F6@cs.purdue.edu> References: <200904070042.n370gNK3001242@camembert.async.caltech.edu> <9F2237E2-73A2-4926-A438-A6032F70B4F6@cs.purdue.edu> Message-ID: <49DA8196.1E75.00D7.1@scires.com> Hey, will this proposal mean that packages like "stable" and "stubgen" need to be changed also, in addition to both versions of pickles? What about any package that deals with parsing of M3 code, e.g. pretty-printers, CM3IDE, etc.? Regards, Randy >>> Tony Hosking 4/6/2009 10:16 PM >>> On 7 Apr 2009, at 10:42, Mika Nystrom wrote: > You mean this proposal (you had two, I think)? Yes, this is the proposal I converged on. It really is only minimal change to the type system: introduction of a third hierarchy of TAGGED reference types. I did something similar for orthogonal persistence a few years ago where it was useful to have a TRANSIENT reference hierarchy for things that should not persist. [The semantics was that every run of a program would initialize TRANSIENT references to NIL rather than have them have the persistent value. This was slightly messier in that I also permitted TRANSIENT REFANY <: REFANY, which was a little odd.] > -- > > NULL <: REF T <: REFANY > NULL <: UNTRACED REF T <: ADDRESS > TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY > > Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. > > ROOT <: REFANY > TAGGED ROOT <: TAGGED REFANY > NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS > TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY > > Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED > REFANY. > > --- > > I like it fine, I think... I'm just worried, generally, about > changing the type system. Hmmmm... you mean that the TAGGED > things would just be a separate hierarchy? The change is relatively minor in that it doesn't touch the original REFANY hierarchy. > So you'd just add TAGGED in front of the REFs for this new hierarchy. > But why no NULL? No NULL because then we need a test for both NIL and values of type TAGGED INTEGER on every dereference. You can easily declare: TYPE Null = TAGGED INTEGER; CONST Nil = VAL(0, TAGGED INTEGER); The point is that TAGGED INTEGER now lets you have a range of non- pointer reference values, whereas NIL is the singleton non-reference value in type NULL. > And you're comfortable with doing the conversions automatically? No, I said that the conversions needed to be explicit > > So > > tx : TAGGED INTEGER := 5; tx: TAGGED INTEGER := VAL(5,TAGGED INTEGER); > x : INTEGER := tx; x: INTEGER := ORD(tx); > would be OK? > > In that case it's just the m3tk that needs to be modified, and > that's just busy work, I think. If it works it's beautiful... As I said, I am almost done with the compiler changes, and only need to push it into the run-time. Things like m3tk and pickles will need to be smartened up as necessary. > > > Mika > > > > Tony Hosking writes: >> I really don't like your proposal for the reasons you mention. It >> makes regular REF more expensive than it currently is. What is it >> about my relatively minor changes to the type system that you object >> to? I've just about finished changing the compiler front-end (in >> relatively minor ways) to accomodate the proposal I made yesterday. >> And it has the advantage of separating REF from TAGGED REF so we keep >> the standard REF clean. >> >> On 7 Apr 2009, at 00:50, Mika Nystrom wrote: >> >>> Hi Rodney, >>> >>> I would like this capability too, but I am a bit wary of Tony's >>> idea of changing the Modula-3 language---even in a "minor" way. >>> I've been working for the last week or so on an application using >>> the Modula-3 Toolkit, and I must say I have realized that the >> Modula-3 type system has a lot more subtleties than I thought. I >>> would not want to make any real changes to it. There's a paper >>> called "The Modula-3 Type System" by Cardelli, Donahue, Kalsow, and >>> Nelson that is worth studying in detail before making any changes >>> whatsoever, I think. Also remember that changes to the type system >>> will affect m3tk and anything that depends on m3tk (which includes >>> two or three stub generators in the main tree and who knows how >>> many dependencies outside of it). >>> >>> I'm still not sure why we can't take the approach of Word.T . >>> Make a RefanyOrInt.T that can safely be: >>> >>> 1. Tested whether it is a small integer or a REFANY >>> >>> 2. If a REFANY, be dereferenced as normal, *or* via >>> RefanyOrInt.ToRefany >>> >>> 3. If a small integer, can be extracted via RefanyOrInt.ToInt >>> >>> 4. Created either as a small integer or a REFANY >>> >>> Any other operations on it (including ISTYPE and TYPECASE, at least >>> when the object is a small integer) would result in a checked >>> runtime >>> error. >>> >>> Note that with the declaration "RefanyOrInt.T = REFANY", the current >>> compiler will as far as I know not accept any operations on >>> RefanyOrInt.T outside of ISTYPE, TYPECASE, and NARROW (explicit or >>> implicit). >>> >>> I wouldn't be surprised if most of what I'm proposing already works >>> (i.e., crashes with a checked runtime error as it should) with the >>> current runtime. Anything that slips through would need to be fixed >>> up with a one-bit check of the LSB of the REFANY for the operations >>> mentioned above. Unfortunately this has to be done for operations >>> on >>> every REFANY, not just the new type. >>> >>> I think that Modula-3 programmers are already aware that using >>> REFANYs involves forcing the runtime to do extra type-checking work, >>> so they already know not to use them if they are looking for maximum >>> performance, so I don't think that burdening operations on REFANY >>> with an extra one-bit check is too onerous. >>> >>> An advantage of my proposal is that the amount of code in the new >>> proposed library is truly diminutive. In fact, I think I posted >>> pretty much that code to the list a few weeks ago. >>> >>> (If you missed it, it's >>> >>> http://www.async.caltech.edu/~mika/interp/ >>> >>> ) >>> >>> Mika >>> >>> >>> "Rodney M. Bates" writes: >>>> I spent quite a bit of time playing with a more general system >>>> where >>>> there is a set of "tagged" types, with (an implementation-defined >>>> subrange of) INTEGER and a reference type both being a subtype of a >>>> tagged type. It might have been tolerable, if it weren't for the >>>> interaction with object subtypes and opaque types, which quickly >>>> gets deep into a deep linguistic tar pit. >>>> >>>> Tony's approach is much simpler and would serve what I see as the >>>> need. It does sacrifice any static checking of what reference type >>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>> TYPECASE. >>>> >>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>> also need to be an explicit conversion in that direction too, say >>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >>>> is a bit inconsistent with the usual Modula-3 assignability >>>> philosophy, >>>> but not requiring the explicit conversion already gets your toes >>>> into tar. >>>> >>>> We would have to have something more like ISTYPE, though, which >>>> will >>>> tell which type the value belongs to without risking a runtime >>>> error, >>>> which VAL would do. >>>> >>>> An intermediate approach might be to have a set of tagged types >>>> constructed by, say, TAGGED T, where I is a reference type, but >>>> with no subtype relations on them at all, thus still requiring >>>> the explicit conversions and checks. >>>> >>>> I do want to say, I _really_ want this capability somehow. I have >>>> an ADT module whose internal data structure, for full generality, >>>> needs to have two heap objects (the second because it has nonstatic >>>> size) and 11 total words counting the orginal pointer, in the >>>> case of >>>> values that would fit directly into the "pointer" word. Moreover, >>>> these small cases are in the great majority. >>>> >>>> Besides the 11-to-one increase in actual occupied space, there >>>> is extra time for allocation, periodic tracing, and collection, >>>> space >>>> loss due to heap fragmentation, and time/space tradeoff loss due to >>>> reduced locality of reference. So sometimes, it would be a big >>>> performance gain if we could do it. >>>> >>>> >>>> Tony Hosking wrote: >>>> It is a much more pervasive hack than I would be comfortable with >>>>> since it touches on the compiler (for all the type operations) as >>>>> well >>>>> as the run-time system in ways that are pretty gross. I would >>>>> much >>>>> rather have a new TAGGED builtin. ISTYPE would not work on it >>>>> since >>>>> that only works on references. The only thing you need is a way >>>>> to >>>>> extract the value -- we could overload VAL(x, T) where x can be a >>>>> TAGGED and T can be REFANY or INTEGER. >>>>> >>>>> 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 Tue Apr 7 04:52:59 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 12:52:59 +1000 Subject: [M3devel] small objects In-Reply-To: <49DA8196.1E75.00D7.1@scires.com> References: <200904070042.n370gNK3001242@camembert.async.caltech.edu> <9F2237E2-73A2-4926-A438-A6032F70B4F6@cs.purdue.edu> <49DA8196.1E75.00D7.1@scires.com> Message-ID: <985F59A0-82EA-4F55-B6C8-DA057B9E23DB@cs.purdue.edu> On 7 Apr 2009, at 12:27, Randy Coleburn wrote: > Hey, will this proposal mean that packages like "stable" and > "stubgen" need to be changed also, in addition to both versions of > pickles? They build on m3tk so should just work, modulo any builtin typecode information. TAGGED INTEGER will have a predefined typecode just like NULL. > What about any package that deals with parsing of M3 code, e.g. > pretty-printers, CM3IDE, etc.? Same. To that end, how do those cope with LONGINT right now? I did push the changes for LONGINT into m3tk. > Regards, > Randy > > >>> Tony Hosking 4/6/2009 10:16 PM >>> > On 7 Apr 2009, at 10:42, Mika Nystrom wrote: > > > You mean this proposal (you had two, I think)? > > Yes, this is the proposal I converged on. It really is only minimal > change to the type system: introduction of a third hierarchy of > TAGGED reference types. I did something similar for orthogonal > persistence a few years ago where it was useful to have a TRANSIENT > reference hierarchy for things that should not persist. [The > semantics was that every run of a program would initialize TRANSIENT > references to NIL rather than have them have the persistent value. > This was slightly messier in that I also permitted TRANSIENT REFANY <: > REFANY, which was a little odd.] > > > -- > > > > NULL <: REF T <: REFANY > > NULL <: UNTRACED REF T <: ADDRESS > > TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY > > > > Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. > > > > ROOT <: REFANY > > TAGGED ROOT <: TAGGED REFANY > > NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS > > TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY > > > > Note that NULL is not a subtype of T OBJECT ... END where T <: > TAGGED > > REFANY. > > > > --- > > > > I like it fine, I think... I'm just worried, generally, about > > changing the type system. Hmmmm... you mean that the TAGGED > > things would just be a separate hierarchy? > > The change is relatively minor in that it doesn't touch the original > REFANY hierarchy. > > > So you'd just add TAGGED in front of the REFs for this new > hierarchy. > > But why no NULL? > > No NULL because then we need a test for both NIL and values of type > TAGGED INTEGER on every dereference. You can easily declare: > > TYPE Null = TAGGED INTEGER; > CONST Nil = VAL(0, TAGGED INTEGER); > > The point is that TAGGED INTEGER now lets you have a range of non- > pointer reference values, whereas NIL is the singleton non-reference > value in type NULL. > > > And you're comfortable with doing the conversions automatically? > > No, I said that the conversions needed to be explicit > > > > > So > > > > tx : TAGGED INTEGER := 5; > > tx: TAGGED INTEGER := VAL(5,TAGGED INTEGER); > > > x : INTEGER := tx; > > x: INTEGER := ORD(tx); > > > would be OK? > > > > In that case it's just the m3tk that needs to be modified, and > > that's just busy work, I think. If it works it's beautiful... > > As I said, I am almost done with the compiler changes, and only need > to push it into the run-time. Things like m3tk and pickles will need > to be smartened up as necessary. > > > > > > > Mika > > > > > > > > Tony Hosking writes: > >> I really don't like your proposal for the reasons you mention. It > >> makes regular REF more expensive than it currently is. What is it > >> about my relatively minor changes to the type system that you > object > >> to? I've just about finished changing the compiler front-end (in > >> relatively minor ways) to accomodate the proposal I made yesterday. > >> And it has the advantage of separating REF from TAGGED REF so we > keep > >> the standard REF clean. > >> > >> On 7 Apr 2009, at 00:50, Mika Nystrom wrote: > >> > >>> Hi Rodney, > >>> > >>> I would like this capability too, but I am a bit wary of Tony's > >>> idea of changing the Modula-3 language---even in a "minor" way. > >>> I've been working for the last week or so on an application using > >>> the Modula-3 Toolkit, and I must say I have realized that the > >> Modula-3 type system has a lot more subtleties than I thought. I > >>> would not want to make any real changes to it. There's a paper > >>> called "The Modula-3 Type System" by Cardelli, Donahue, Kalsow, > and > >>> Nelson that is worth studying in detail before making any changes > >>> whatsoever, I think. Also remember that changes to the type > system > >>> will affect m3tk and anything that depends on m3tk (which includes > >>> two or three stub generators in the main tree and who knows how > >>> many dependencies outside of it). > >>> > >>> I'm still not sure why we can't take the approach of Word.T . > >>> Make a RefanyOrInt.T that can safely be: > >>> > >>> 1. Tested whether it is a small integer or a REFANY > >>> > >>> 2. If a REFANY, be dereferenced as normal, *or* via > >>> RefanyOrInt.ToRefany > >>> > >>> 3. If a small integer, can be extracted via RefanyOrInt.ToInt > >>> > >>> 4. Created either as a small integer or a REFANY > >>> > >>> Any other operations on it (including ISTYPE and TYPECASE, at > least > >>> when the object is a small integer) would result in a checked > >>> runtime > >>> error. > >>> > >>> Note that with the declaration "RefanyOrInt.T = REFANY", the > current > >>> compiler will as far as I know not accept any operations on > >>> RefanyOrInt.T outside of ISTYPE, TYPECASE, and NARROW (explicit or > >>> implicit). > >>> > >>> I wouldn't be surprised if most of what I'm proposing already > works > >>> (i.e., crashes with a checked runtime error as it should) with the > >>> current runtime. Anything that slips through would need to be > fixed > >>> up with a one-bit check of the LSB of the REFANY for the > operations > >>> mentioned above. Unfortunately this has to be done for operations > >>> on > >>> every REFANY, not just the new type. > >>> > >>> I think that Modula-3 programmers are already aware that using > >>> REFANYs involves forcing the runtime to do extra type-checking > work, > >>> so they already know not to use them if they are looking for > maximum > >>> performance, so I don't think that burdening operations on REFANY > >>> with an extra one-bit check is too onerous. > >>> > >>> An advantage of my proposal is that the amount of code in the new > >>> proposed library is truly diminutive. In fact, I think I posted > >>> pretty much that code to the list a few weeks ago. > >>> > >>> (If you missed it, it's > >>> > >>> http://www.async.caltech.edu/~mika/interp/ > >>> > >>> ) > >>> > >>> Mika > >>> > >>> > >>> "Rodney M. Bates" writes: > >>>> I spent quite a bit of time playing with a more general system > >>>> where > >>>> there is a set of "tagged" types, with (an implementation-defined > >>>> subrange of) INTEGER and a reference type both being a subtype > of a > >>>> tagged type. It might have been tolerable, if it weren't for the > >>>> interaction with object subtypes and opaque types, which quickly > >>>> gets deep into a deep linguistic tar pit. > >>>> > >>>> Tony's approach is much simpler and would serve what I see as the > >>>> need. It does sacrifice any static checking of what reference > type > >>>> is being tagged, and will also require an extra runtime ISTYPE/ > >>>> TYPECASE. > >>>> > >>>> Would INTEGER and REFANY be assignable to TAGGED, or would there > >>>> also need to be an explicit conversion in that direction too, say > >>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. > It > >>>> is a bit inconsistent with the usual Modula-3 assignability > >>>> philosophy, > >>>> but not requiring the explicit conversion already gets your toes > >>>> into tar. > >>>> > >>>> We would have to have something more like ISTYPE, though, which > >>>> will > >>>> tell which type the value belongs to without risking a runtime > >>>> error, > >>>> which VAL would do. > >>>> > >>>> An intermediate approach might be to have a set of tagged types > >>>> constructed by, say, TAGGED T, where I is a reference type, but > >>>> with no subtype relations on them at all, thus still requiring > >>>> the explicit conversions and checks. > >>>> > >>>> I do want to say, I _really_ want this capability somehow. I > have > >>>> an ADT module whose internal data structure, for full generality, > >>>> needs to have two heap objects (the second because it has > nonstatic > >>>> size) and 11 total words counting the orginal pointer, in the > >>>> case of > >>>> values that would fit directly into the "pointer" word. > Moreover, > >>>> these small cases are in the great majority. > >>>> > >>>> Besides the 11-to-one increase in actual occupied space, there > >>>> is extra time for allocation, periodic tracing, and collection, > >>>> space > >>>> loss due to heap fragmentation, and time/space tradeoff loss > due to > >>>> reduced locality of reference. So sometimes, it would be a big > >>>> performance gain if we could do it. > >>>> > >>>> > >>>> Tony Hosking wrote: > >>>> It is a much more pervasive hack than I would be comfortable with > >>>>> since it touches on the compiler (for all the type operations) > as > >>>>> well > >>>>> as the run-time system in ways that are pretty gross. I would > >>>>> much > >>>>> rather have a new TAGGED builtin. ISTYPE would not work on it > >>>>> since > >>>>> that only works on references. The only thing you need is a way > >>>>> to > >>>>> extract the value -- we could overload VAL(x, T) where x can > be a > >>>>> TAGGED and T can be REFANY or INTEGER. > >>>>> > >>>>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Apr 7 07:28:32 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 22:28:32 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Tue, 07 Apr 2009 12:16:29 +1000." <9F2237E2-73A2-4926-A438-A6032F70B4F6@cs.purdue.edu> Message-ID: <200904070528.n375SWNg010291@camembert.async.caltech.edu> Ok, I see. You've done this before! Then I think you are qualified to say that it's doable and straightforward. It certainly seems all right from what you say. It sounds like it's implementation-wise not very different from the library idea I was proposing, but much more elegant. But but... this NULL business. You don't think that we who want to use the TAGGED INTEGER deserve to pay an extra instruction for the convenience? Is there actually an instruction checking for NULL? You don't just let the system segfault the process? Is this because you might have an indexed pointer that might be persuaded to point into mapped memory even if 0 is an illegal address? (Could you insert the NULL check only for pointers to types that are larger than a certain size, say one page?) It seems a little inconvenient to me not to have a pointer that's NIL. What you suggest doesn't really work super-elegantly... I'm thinking: in my Scheme interpreter, I represent Scheme types as Modula-3 REFs (following Norvig's JScheme almost exactly). The empty list is just Modula-3's NIL. But what you're saying is that some integer should be selected as "special" to denote the empty list, the non-object, or whatever you want to call it. What if I want to represent that integer? In any case, the all-zeros bit pattern would not be a legal TAGGED type, would it, under your proposal? Or am I completely missing something here? Mika Tony Hosking writes: >On 7 Apr 2009, at 10:42, Mika Nystrom wrote: > >> You mean this proposal (you had two, I think)? > >Yes, this is the proposal I converged on. It really is only minimal >change to the type system: introduction of a third hierarchy of >TAGGED reference types. I did something similar for orthogonal >persistence a few years ago where it was useful to have a TRANSIENT >reference hierarchy for things that should not persist. [The >semantics was that every run of a program would initialize TRANSIENT >references to NIL rather than have them have the persistent value. >This was slightly messier in that I also permitted TRANSIENT REFANY <: >REFANY, which was a little odd.] > >> -- >> >> NULL <: REF T <: REFANY >> NULL <: UNTRACED REF T <: ADDRESS >> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >> >> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >> >> ROOT <: REFANY >> TAGGED ROOT <: TAGGED REFANY >> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >> >> Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED >> REFANY. >> >> --- >> >> I like it fine, I think... I'm just worried, generally, about >> changing the type system. Hmmmm... you mean that the TAGGED >> things would just be a separate hierarchy? > >The change is relatively minor in that it doesn't touch the original >REFANY hierarchy. > >> So you'd just add TAGGED in front of the REFs for this new hierarchy. >> But why no NULL? > >No NULL because then we need a test for both NIL and values of type >TAGGED INTEGER on every dereference. You can easily declare: > >TYPE Null = TAGGED INTEGER; >CONST Nil = VAL(0, TAGGED INTEGER); > >The point is that TAGGED INTEGER now lets you have a range of non- >pointer reference values, whereas NIL is the singleton non-reference >value in type NULL. > >> And you're comfortable with doing the conversions automatically? > >No, I said that the conversions needed to be explicit > >> >> So >> >> tx : TAGGED INTEGER := 5; > >tx: TAGGED INTEGER := VAL(5,TAGGED INTEGER); > >> x : INTEGER := tx; > >x: INTEGER := ORD(tx); > >> would be OK? >> >> In that case it's just the m3tk that needs to be modified, and >> that's just busy work, I think. If it works it's beautiful... > >As I said, I am almost done with the compiler changes, and only need >to push it into the run-time. Things like m3tk and pickles will need >to be smartened up as necessary. > >> >> >> Mika >> >> >> >> Tony Hosking writes: >>> I really don't like your proposal for the reasons you mention. It >>> makes regular REF more expensive than it currently is. What is it >>> about my relatively minor changes to the type system that you object >>> to? I've just about finished changing the compiler front-end (in >>> relatively minor ways) to accomodate the proposal I made yesterday. >>> And it has the advantage of separating REF from TAGGED REF so we keep >>> the standard REF clean. >>> >>> On 7 Apr 2009, at 00:50, Mika Nystrom wrote: >>> >>>> Hi Rodney, >>>> >>>> I would like this capability too, but I am a bit wary of Tony's >>>> idea of changing the Modula-3 language---even in a "minor" way. >>>> I've been working for the last week or so on an application using >>>> the Modula-3 Toolkit, and I must say I have realized that the >>> Modula-3 type system has a lot more subtleties than I thought. I >>>> would not want to make any real changes to it. There's a paper >>>> called "The Modula-3 Type System" by Cardelli, Donahue, Kalsow, and >>>> Nelson that is worth studying in detail before making any changes >>>> whatsoever, I think. Also remember that changes to the type system >>>> will affect m3tk and anything that depends on m3tk (which includes >>>> two or three stub generators in the main tree and who knows how >>>> many dependencies outside of it). >>>> >>>> I'm still not sure why we can't take the approach of Word.T . >>>> Make a RefanyOrInt.T that can safely be: >>>> >>>> 1. Tested whether it is a small integer or a REFANY >>>> >>>> 2. If a REFANY, be dereferenced as normal, *or* via >>>> RefanyOrInt.ToRefany >>>> >>>> 3. If a small integer, can be extracted via RefanyOrInt.ToInt >>>> >>>> 4. Created either as a small integer or a REFANY >>>> >>>> Any other operations on it (including ISTYPE and TYPECASE, at least >>>> when the object is a small integer) would result in a checked >>> runtime >>>> error. >>>> >>>> Note that with the declaration "RefanyOrInt.T = REFANY", the current >>>> compiler will as far as I know not accept any operations on >>>> RefanyOrInt.T outside of ISTYPE, TYPECASE, and NARROW (explicit or >>>> implicit). >>>> >>>> I wouldn't be surprised if most of what I'm proposing already works >>>> (i.e., crashes with a checked runtime error as it should) with the >>>> current runtime. Anything that slips through would need to be fixed >>>> up with a one-bit check of the LSB of the REFANY for the operations >>>> mentioned above. Unfortunately this has to be done for operations >>>> on >>>> every REFANY, not just the new type. >>>> >>>> I think that Modula-3 programmers are already aware that using >>>> REFANYs involves forcing the runtime to do extra type-checking work, >>>> so they already know not to use them if they are looking for maximum >>>> performance, so I don't think that burdening operations on REFANY >>>> with an extra one-bit check is too onerous. >>>> >>>> An advantage of my proposal is that the amount of code in the new >>>> proposed library is truly diminutive. In fact, I think I posted >>>> pretty much that code to the list a few weeks ago. >>>> >>>> (If you missed it, it's >>>> >>>> http://www.async.caltech.edu/~mika/interp/ >>>> >>>> ) >>>> >>>> Mika >>>> >>>> >>>> "Rodney M. Bates" writes: >>>>> I spent quite a bit of time playing with a more general system >>>>> where >>>>> there is a set of "tagged" types, with (an implementation-defined >>>>> subrange of) INTEGER and a reference type both being a subtype of a >>>>> tagged type. It might have been tolerable, if it weren't for the >>>>> interaction with object subtypes and opaque types, which quickly >>>>> gets deep into a deep linguistic tar pit. >>>>> >>>>> Tony's approach is much simpler and would serve what I see as the >>>>> need. It does sacrifice any static checking of what reference type >>>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>>> TYPECASE. >>>>> >>>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>>> also need to be an explicit conversion in that direction too, say >>>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. It >>>>> is a bit inconsistent with the usual Modula-3 assignability >>>>> philosophy, >>>>> but not requiring the explicit conversion already gets your toes >>>>> into tar. >>>>> >>>>> We would have to have something more like ISTYPE, though, which >>>>> will >>>>> tell which type the value belongs to without risking a runtime >>>>> error, >>>>> which VAL would do. >>>>> >>>>> An intermediate approach might be to have a set of tagged types >>>>> constructed by, say, TAGGED T, where I is a reference type, but >>>>> with no subtype relations on them at all, thus still requiring >>>>> the explicit conversions and checks. >>>>> >>>>> I do want to say, I _really_ want this capability somehow. I have >>>>> an ADT module whose internal data structure, for full generality, >>>>> needs to have two heap objects (the second because it has nonstatic >>>>> size) and 11 total words counting the orginal pointer, in the >>>>> case of >>>>> values that would fit directly into the "pointer" word. Moreover, >>>>> these small cases are in the great majority. >>>>> >>>>> Besides the 11-to-one increase in actual occupied space, there >>>>> is extra time for allocation, periodic tracing, and collection, >>>>> space >>>>> loss due to heap fragmentation, and time/space tradeoff loss due to >>>>> reduced locality of reference. So sometimes, it would be a big >>>>> performance gain if we could do it. >>>> >>>>> >>>>> Tony Hosking wrote: >>>>> It is a much more pervasive hack than I would be comfortable with >>>>>> since it touches on the compiler (for all the type operations) as >>>>>> well >>>>>> as the run-time system in ways that are pretty gross. I would >>>>>> much >>>>>> rather have a new TAGGED builtin. ISTYPE would not work on it >>>>>> since >>>>>> that only works on references. The only thing you need is a way >>>>>> to >>>>>> extract the value -- we could overload VAL(x, T) where x can be a >>>>>> TAGGED and T can be REFANY or INTEGER. >>>>>> >>>>>> From mika at async.caltech.edu Tue Apr 7 07:39:17 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 06 Apr 2009 22:39:17 -0700 Subject: [M3devel] Implementing the "Singleton pattern" in Modula-3 In-Reply-To: Your message of "Tue, 07 Apr 2009 12:07:19 +1000." Message-ID: <200904070539.n375dHGR010710@camembert.async.caltech.edu> Hmm, well ... so in C++ and Smalltalk you can accomplish something along these lines: INTERFACE Singleton; TYPE T = SomeSuperTypeIReallyWantToSubClass OBJECT METHODS m(); END; END Singleton. (****************************************) MODULE Client; BEGIN theSingleton := NEW(Singleton.T, m := MyM); theSingleton2 := NEW(Singleton.T, m := MyM); END Client. And by some magic involving overriding "new methods", you are guaranteed that theSingleton and theSingleton2 are the same object... In Modula-3 you can do something similar by providing an appropriate init, but this can still get a bit hairy since the client can override init and then you're back where you started. As I said this is really quite a minor issue but it has annoyed me a few times that I have to be very careful about allocating only one of something, especially when it might be allocated from lots of places and you want to make sure only one ever gets allocated in a single program execution. (E.g., various types of "registries"...) Mika Tony Hosking writes: >On 7 Apr 2009, at 11:18, Mika Nystrom wrote: > >> Well I think the problem is with this "is known to be an object >> type"... > >But if the opaque type T is T<:REFANY and the only revelation is >branded and private to a module (not exported by its interfaces) then >no-one can determine that it is an object type without forging the >BRAND. > >> You may in fact want to override the methods of the singleton, but >> ensure that only one ever gets instantiated. >> >> It's a minor problem, but it does sometimes bother me that it is >> difficult to prevent clients from NEWing pretty much anything they >> like. >> >> By the way, the "Modula-3 Type System" paper also talks about a >> nifty way to do narrowing very quickly (page 10, last paragraph). >> I remember this is occasionally problematic. (RTType.IsSubtype >> isn't great.) They speak of keeping an array of supertypes >> for each type, and recording the "depth" (distance from REFANY) >> of every type in, I guess, RT0.TypeDefn. This seems moderately >> space-efficient (better than a 2D array of all the typecodes), >> and very fast. >> >> Mika >> >> Tony Hosking writes: >>> I would exploit opaque types and branding. If T is opaque then you >>> cannot instantiate T except in scopes where T's concrete type has >>> been >>> revealed or is known to be an object type. Thus, you could define an >>> interface: >>> >>> GENERIC INTERFACE Singleton(Rep); >>> TYPE T <: REFANY; >>> VAR t: T; >>> END Singleton. >>> >>> GENERIC MODULE Singleton(Rep); >>> REVEAL T = BRANDED REF Rep.T; >>> BEGIN >>> t := NEW(T); >>> END Singleton. >>> >>> where Rep defines the type T. You could do similar for object types. >>> >>> >>> On 7 Apr 2009, at 06:31, Mika Nystrom wrote: >>> >>>> >>>> Tony, Jay, you two seem to be most knowledgeable about this. >>>> >>>> Let's say I wanted to implement the "singleton pattern" in >>>> Modula-3. At present there seems to be no way of doing this. >>>> >>>> What about changing RTAllocator.callback as follows (or adding >>>> another callback): >>>> >>>> VAR callback : PROCEDURE(r : REFANY) : REFANY := NIL; >>>> >>>> (* If non-NIL, the allocator calls "callback(r)" just before >>>> returning >>>> a new traced reference "r" and instead returns the result of >>>> callback(r). >>>> See "RTAllocStats" for an example client. It is a checked runtime >>>> error >>>> for the typecode of r to differ from the typecode of the return >>>> value of >>>> callback(r). *) >>>> >>>> Mika >>>> >>>> >>>> From hosking at cs.purdue.edu Tue Apr 7 08:15:50 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 16:15:50 +1000 Subject: [M3devel] Implementing the "Singleton pattern" in Modula-3 In-Reply-To: <200904070539.n375dHGR010710@camembert.async.caltech.edu> References: <200904070539.n375dHGR010710@camembert.async.caltech.edu> Message-ID: <2D76BEAC-54E2-48FB-BFF3-90339E0E1F75@cs.purdue.edu> Yes, I admit this is cumbersome: GENERIC MODULE Singleton(Super, Impl); REVEAL T = Super BRANDED OBJECT OVERRIDES m := Impl.m END; BEGIN t := NEW(T); END Singleton. On 7 Apr 2009, at 15:39, Mika Nystrom wrote: > > Hmm, well ... so in C++ and Smalltalk you can accomplish something > along these lines: > > INTERFACE Singleton; > > TYPE > T = SomeSuperTypeIReallyWantToSubClass OBJECT METHODS > m(); > END; > > END Singleton. > > (****************************************) > > MODULE Client; > > BEGIN > > theSingleton := NEW(Singleton.T, m := MyM); > theSingleton2 := NEW(Singleton.T, m := MyM); > > END Client. > > And by some magic involving overriding "new methods", you are > guaranteed that theSingleton and theSingleton2 are the same object... > > In Modula-3 you can do something similar by providing an appropriate > init, but this can still get a bit hairy since the client can > override init and then you're back where you started. > > As I said this is really quite a minor issue but it has annoyed me > a few times that I have to be very careful about allocating only one > of something, especially when it might be allocated from lots of > places and you want to make sure only one ever gets allocated in a > single > program execution. (E.g., various types of "registries"...) > > Mika > > Tony Hosking writes: >> On 7 Apr 2009, at 11:18, Mika Nystrom wrote: >> >>> Well I think the problem is with this "is known to be an object >>> type"... >> >> But if the opaque type T is T<:REFANY and the only revelation is >> branded and private to a module (not exported by its interfaces) then >> no-one can determine that it is an object type without forging the >> BRAND. >> >>> You may in fact want to override the methods of the singleton, but >>> ensure that only one ever gets instantiated. >>> >>> It's a minor problem, but it does sometimes bother me that it is >>> difficult to prevent clients from NEWing pretty much anything they >>> like. >>> >>> By the way, the "Modula-3 Type System" paper also talks about a >>> nifty way to do narrowing very quickly (page 10, last paragraph). >>> I remember this is occasionally problematic. (RTType.IsSubtype >>> isn't great.) They speak of keeping an array of supertypes >>> for each type, and recording the "depth" (distance from REFANY) >>> of every type in, I guess, RT0.TypeDefn. This seems moderately >>> space-efficient (better than a 2D array of all the typecodes), >>> and very fast. >>> >>> Mika >>> >>> Tony Hosking writes: >>>> I would exploit opaque types and branding. If T is opaque then you >>>> cannot instantiate T except in scopes where T's concrete type has >>>> been >>>> revealed or is known to be an object type. Thus, you could >>>> define an >>>> interface: >>>> >>>> GENERIC INTERFACE Singleton(Rep); >>>> TYPE T <: REFANY; >>>> VAR t: T; >>>> END Singleton. >>>> >>>> GENERIC MODULE Singleton(Rep); >>>> REVEAL T = BRANDED REF Rep.T; >>>> BEGIN >>>> t := NEW(T); >>>> END Singleton. >>>> >>>> where Rep defines the type T. You could do similar for object >>>> types. >>>> >>>> >>>> On 7 Apr 2009, at 06:31, Mika Nystrom wrote: >>>> >>>>> >>>>> Tony, Jay, you two seem to be most knowledgeable about this. >>>>> >>>>> Let's say I wanted to implement the "singleton pattern" in >>>>> Modula-3. At present there seems to be no way of doing this. >>>>> >>>>> What about changing RTAllocator.callback as follows (or adding >>>>> another callback): >>>>> >>>>> VAR callback : PROCEDURE(r : REFANY) : REFANY := NIL; >>>>> >>>>> (* If non-NIL, the allocator calls "callback(r)" just before >>>>> returning >>>>> a new traced reference "r" and instead returns the result of >>>>> callback(r). >>>>> See "RTAllocStats" for an example client. It is a checked runtime >>>>> error >>>>> for the typecode of r to differ from the typecode of the return >>>>> value of >>>>> callback(r). *) >>>>> >>>>> Mika >>>>> >>>>> >>>>> From hosking at cs.purdue.edu Tue Apr 7 08:27:41 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 16:27:41 +1000 Subject: [M3devel] small objects In-Reply-To: <200904070528.n375SWNg010291@camembert.async.caltech.edu> References: <200904070528.n375SWNg010291@camembert.async.caltech.edu> Message-ID: <8D54C0C3-478C-4E87-BBD7-216215FF2921@cs.purdue.edu> No, you are right on the money. I was just trying to avoid attempts to dereference tagged integers with a run-time check like a nil-check. I am starting to come around to your library idea. As you say, TaggedInteger.T would give a static error on dereference, so no need for a run-time check. Similarly, because one cannot NARROW (implicitly or explicitly) a TaggedInteger.T it is impossible to assign to anything other than a REFANY which avoids polluting other reference fields and so eliminates my initial concern. Hmmm.... ;-) On 7 Apr 2009, at 15:28, Mika Nystrom wrote: > > Ok, I see. You've done this before! Then I think you are qualified > to say that it's doable and straightforward. It certainly seems all > right from what you say. It sounds like it's implementation-wise not > very different from the library idea I was proposing, but much more > elegant. > > But but... this NULL business. You don't think that we who want to > use the TAGGED INTEGER deserve to pay an extra instruction for the > convenience? Is there actually an instruction checking for NULL? > You don't just let the system segfault the process? Is this because > you might have an indexed pointer that might be persuaded to point > into > mapped memory even if 0 is an illegal address? (Could you insert the > NULL check only for pointers to types that are larger than a certain > size, say one page?) > > It seems a little inconvenient to me not to have a pointer that's > NIL. What you suggest doesn't really work super-elegantly... > > I'm thinking: in my Scheme interpreter, I represent Scheme types as > Modula-3 REFs (following Norvig's JScheme almost exactly). The > empty list is just Modula-3's NIL. > > But what you're saying is that some integer should be selected as > "special" to denote the empty list, the non-object, or whatever you > want to call it. What if I want to represent that integer? > > In any case, the all-zeros bit pattern would not be a legal TAGGED > type, would it, under your proposal? > > Or am I completely missing something here? > > Mika > > Tony Hosking writes: >> On 7 Apr 2009, at 10:42, Mika Nystrom wrote: >> >>> You mean this proposal (you had two, I think)? >> >> Yes, this is the proposal I converged on. It really is only minimal >> change to the type system: introduction of a third hierarchy of >> TAGGED reference types. I did something similar for orthogonal >> persistence a few years ago where it was useful to have a TRANSIENT >> reference hierarchy for things that should not persist. [The >> semantics was that every run of a program would initialize TRANSIENT >> references to NIL rather than have them have the persistent value. >> This was slightly messier in that I also permitted TRANSIENT REFANY >> <: >> REFANY, which was a little odd.] >> >>> -- >>> >>> NULL <: REF T <: REFANY >>> NULL <: UNTRACED REF T <: ADDRESS >>> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >>> >>> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >>> >>> ROOT <: REFANY >>> TAGGED ROOT <: TAGGED REFANY >>> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >>> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >>> >>> Note that NULL is not a subtype of T OBJECT ... END where T <: >>> TAGGED >>> REFANY. >>> >>> --- >>> >>> I like it fine, I think... I'm just worried, generally, about >>> changing the type system. Hmmmm... you mean that the TAGGED >>> things would just be a separate hierarchy? >> >> The change is relatively minor in that it doesn't touch the original >> REFANY hierarchy. >> >>> So you'd just add TAGGED in front of the REFs for this new >>> hierarchy. >>> But why no NULL? >> >> No NULL because then we need a test for both NIL and values of type >> TAGGED INTEGER on every dereference. You can easily declare: >> >> TYPE Null = TAGGED INTEGER; >> CONST Nil = VAL(0, TAGGED INTEGER); >> >> The point is that TAGGED INTEGER now lets you have a range of non- >> pointer reference values, whereas NIL is the singleton non-reference >> value in type NULL. >> >>> And you're comfortable with doing the conversions automatically? >> >> No, I said that the conversions needed to be explicit >> >>> >>> So >>> >>> tx : TAGGED INTEGER := 5; >> >> tx: TAGGED INTEGER := VAL(5,TAGGED INTEGER); >> >>> x : INTEGER := tx; >> >> x: INTEGER := ORD(tx); >> >>> would be OK? >>> >>> In that case it's just the m3tk that needs to be modified, and >>> that's just busy work, I think. If it works it's beautiful... >> >> As I said, I am almost done with the compiler changes, and only need >> to push it into the run-time. Things like m3tk and pickles will need >> to be smartened up as necessary. >> >>> >>> >>> Mika >>> >>> >>> >>> Tony Hosking writes: >>>> I really don't like your proposal for the reasons you mention. It >>>> makes regular REF more expensive than it currently is. What is it >>>> about my relatively minor changes to the type system that you >>>> object >>>> to? I've just about finished changing the compiler front-end (in >>>> relatively minor ways) to accomodate the proposal I made yesterday. >>>> And it has the advantage of separating REF from TAGGED REF so we >>>> keep >>>> the standard REF clean. >>>> >>>> On 7 Apr 2009, at 00:50, Mika Nystrom wrote: >>>> >>>>> Hi Rodney, >>>>> >>>>> I would like this capability too, but I am a bit wary of Tony's >>>>> idea of changing the Modula-3 language---even in a "minor" way. >>>>> I've been working for the last week or so on an application using >>>>> the Modula-3 Toolkit, and I must say I have realized that the >>>> Modula-3 type system has a lot more subtleties than I thought. I >>>>> would not want to make any real changes to it. There's a paper >>>>> called "The Modula-3 Type System" by Cardelli, Donahue, Kalsow, >>>>> and >>>>> Nelson that is worth studying in detail before making any changes >>>>> whatsoever, I think. Also remember that changes to the type >>>>> system >>>>> will affect m3tk and anything that depends on m3tk (which includes >>>>> two or three stub generators in the main tree and who knows how >>>>> many dependencies outside of it). >>>>> >>>>> I'm still not sure why we can't take the approach of Word.T . >>>>> Make a RefanyOrInt.T that can safely be: >>>>> >>>>> 1. Tested whether it is a small integer or a REFANY >>>>> >>>>> 2. If a REFANY, be dereferenced as normal, *or* via >>>>> RefanyOrInt.ToRefany >>>>> >>>>> 3. If a small integer, can be extracted via RefanyOrInt.ToInt >>>>> >>>>> 4. Created either as a small integer or a REFANY >>>>> >>>>> Any other operations on it (including ISTYPE and TYPECASE, at >>>>> least >>>>> when the object is a small integer) would result in a checked >>>> runtime >>>>> error. >>>>> >>>>> Note that with the declaration "RefanyOrInt.T = REFANY", the >>>>> current >>>>> compiler will as far as I know not accept any operations on >>>>> RefanyOrInt.T outside of ISTYPE, TYPECASE, and NARROW (explicit or >>>>> implicit). >>>>> >>>>> I wouldn't be surprised if most of what I'm proposing already >>>>> works >>>>> (i.e., crashes with a checked runtime error as it should) with the >>>>> current runtime. Anything that slips through would need to be >>>>> fixed >>>>> up with a one-bit check of the LSB of the REFANY for the >>>>> operations >>>>> mentioned above. Unfortunately this has to be done for operations >>>>> on >>>>> every REFANY, not just the new type. >>>>> >>>>> I think that Modula-3 programmers are already aware that using >>>>> REFANYs involves forcing the runtime to do extra type-checking >>>>> work, >>>>> so they already know not to use them if they are looking for >>>>> maximum >>>>> performance, so I don't think that burdening operations on REFANY >>>>> with an extra one-bit check is too onerous. >>>>> >>>>> An advantage of my proposal is that the amount of code in the new >>>>> proposed library is truly diminutive. In fact, I think I posted >>>>> pretty much that code to the list a few weeks ago. >>>>> >>>>> (If you missed it, it's >>>>> >>>>> http://www.async.caltech.edu/~mika/interp/ >>>>> >>>>> ) >>>>> >>>>> Mika >>>>> >>>>> >>>>> "Rodney M. Bates" writes: >>>>>> I spent quite a bit of time playing with a more general system >>>>>> where >>>>>> there is a set of "tagged" types, with (an implementation-defined >>>>>> subrange of) INTEGER and a reference type both being a subtype >>>>>> of a >>>>>> tagged type. It might have been tolerable, if it weren't for the >>>>>> interaction with object subtypes and opaque types, which quickly >>>>>> gets deep into a deep linguistic tar pit. >>>>>> >>>>>> Tony's approach is much simpler and would serve what I see as the >>>>>> need. It does sacrifice any static checking of what reference >>>>>> type >>>>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>>>> TYPECASE. >>>>>> >>>>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>>>> also need to be an explicit conversion in that direction too, say >>>>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. >>>>>> It >>>>>> is a bit inconsistent with the usual Modula-3 assignability >>>>>> philosophy, >>>>>> but not requiring the explicit conversion already gets your toes >>>>>> into tar. >>>>>> >>>>>> We would have to have something more like ISTYPE, though, which >>>>>> will >>>>>> tell which type the value belongs to without risking a runtime >>>>>> error, >>>>>> which VAL would do. >>>>>> >>>>>> An intermediate approach might be to have a set of tagged types >>>>>> constructed by, say, TAGGED T, where I is a reference type, but >>>>>> with no subtype relations on them at all, thus still requiring >>>>>> the explicit conversions and checks. >>>>>> >>>>>> I do want to say, I _really_ want this capability somehow. I >>>>>> have >>>>>> an ADT module whose internal data structure, for full generality, >>>>>> needs to have two heap objects (the second because it has >>>>>> nonstatic >>>>>> size) and 11 total words counting the orginal pointer, in the >>>>>> case of >>>>>> values that would fit directly into the "pointer" word. >>>>>> Moreover, >>>>>> these small cases are in the great majority. >>>>>> >>>>>> Besides the 11-to-one increase in actual occupied space, there >>>>>> is extra time for allocation, periodic tracing, and collection, >>>>>> space >>>>>> loss due to heap fragmentation, and time/space tradeoff loss >>>>>> due to >>>>>> reduced locality of reference. So sometimes, it would be a big >>>>>> performance gain if we could do it. >>>>> >>>>>> >>>>>> Tony Hosking wrote: >>>>>> It is a much more pervasive hack than I would be comfortable with >>>>>>> since it touches on the compiler (for all the type operations) >>>>>>> as >>>>>>> well >>>>>>> as the run-time system in ways that are pretty gross. I would >>>>>>> much >>>>>>> rather have a new TAGGED builtin. ISTYPE would not work on it >>>>>>> since >>>>>>> that only works on references. The only thing you need is a way >>>>>>> to >>>>>>> extract the value -- we could overload VAL(x, T) where x can >>>>>>> be a >>>>>>> TAGGED and T can be REFANY or INTEGER. >>>>>>> >>>>>>> From hosking at cs.purdue.edu Tue Apr 7 08:55:12 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 16:55:12 +1000 Subject: [M3devel] small objects In-Reply-To: <200904062039.n36KdIsY095003@camembert.async.caltech.edu> References: <200904062039.n36KdIsY095003@camembert.async.caltech.edu> Message-ID: After all of this -- I may simply be coming back around to your original proposal -- why not simply declare: TaggedInteger.T = REFANY; ? You can't instantiate a REFANY. All we really need is the LOOPHOLEing of your original proposal to extract the integer values, and to make sure that ISTYPE and NARROW have the behavior you describe for tagged REFANY. Does it make sense that TYPECODE(r) = TYPECODE(REFANY) for any tagged REFANY? What else are we missing? On 7 Apr 2009, at 06:39, Mika Nystrom wrote: > And finally, to forestall a possible objection to the scheme > I proposed: > > Yes, it is true that even a non-UNSAFE module can allocate a > TaggedInteger.T by calling > > new := RTAllocator.NewTraced(TYPECODE(r)) > > where r is a tagged integer. > > But since it cannot dereference that new value or do anything else > with it, I don't think this is a problem. The Pickler (built into > the TaggedInteger module, one must assume) would simply have to > be on the lookout for values of the "real" TaggedInteger.T versus > those that are just numbers with the LSB set, and act accordingly. > Since the T declaration is only visible within the UNSAFE module > there can never be any question of another module's muddling the > two types up. > > Mika > > Mika Nystrom writes: >> "Rodney M. Bates" writes: >>> At first, I just envisioned implementing a small object type >>> entirely inside an UNSAFE module, using unsafe operations >>> to construct/test/separate the values. I think if the GC were >>> to just to ignore words in heap objects that the type system >>> claims are unambiguously pointers but actually have misaligned >>> values, this could be done. >> >> Right that's precisely what the module I posted does. >> >>> >>> But it flies in the face of a fundamental principle of Modula-3, >>> namely that an UNSAFE module, if coded correctly, can prevent >>> all other code from consequences of the unsafety. Unfortunately, >>> this can't be done with the small pointers, because, even if >>> opaque, they are still reference types, and client code can >>> dereference them (including the implicit dereference in accessing >>> a method or field of an object) and do ISTYPE, NARROW, TYPECASE, >>> and assignments that do an implicit NARROW. All these operations >>> could be done outside the implementing module and all could >>> suffer from misaligned values. >> >> Well yes that is true. But the client can't dereference REFANY. >> Modula-3 doesn't permit that. That's an important practical point, >> because now we're limited to the other things: ISTYPE, NARROW >> (implicit and explicit), TYPECASE. (There are two more, actually, >> and they are = and #.) As long as those can be guaranteed to fail >> you're OK. [ Actually see my P.S. below! ] >> >>> >>> In fact, misaligned integer "objects" violate another principle >>> that >>> the bit pattern must always be a valid representation of some value >>> of the type. >> >> Yes I think maybe this is what Tony is worried about. But let's >> just change the definition of REFANY to include anything with the >> LSB set...? >> >> In Modula-3-ese it would be more like the following: >> >> "REFANY can hold three types of objects. NIL, REF something or an >> implementation-defined other set of values that can only be accessed >> in an UNSAFE module. It is a checked runtime error to pass a 'REFANY >> of the third kind' to ISTYPE, NARROW, TYPECASE." [ Actually see my >> P.S. below! ] >> >> Then I propose we punt the handling of the new REFANYs to this >> unsafe module we spoke about above. As far as Modula-3 is concerned, >> there's just a set of values of (apparently) very little utility >> that can be represented by REFANY. If you think about it, this is >> really not so crazy. Any module that uses REFANY today is designed >> around to the fact that there are plenty of values of REFANY that >> can be of no interest to that module except for passing along to >> another module. (REFANY can easily represent a type which a module >> has no way of accessing *any* declaration of beyond just REFANY.) >> We're just adding some others, the only difference being that the >> new values are of no interest to any non-UNSAFE module. (Eh, >> technically this is already true for any reference type that is >> declared in an UNSAFE module today so one might argue we have in >> fact added nothing.) >> >>> >>> However, this does suggest a different and very simple linguistic >>> solution: Just have a new builtin type, say VERYOPAQUE, that >>> supports no operations other than moving it around, i.e., >>> assignment, bindings, passing as a parameter, etc. Only unsafe >>> code could do anyhing with it, by using LOOPHOLE. The only >>> problem is, would somebody then want one of these in a size other >>> than one word? >> >> This is nice, and we already have a candidate type, in fact: ADDRESS. >> But the problem is that the GC doesn't follow this even if the LSB >> is clear... which we *do* want. >> >> Why are you worried about getting it in sizes other than one word? >> That seems to me to be an application problem. If someone wants >> an ARRAY OF VERYOPAQUE is that a problem? >> >> Mika >> >> P.S. Illustration of the above, in today's Modula-3: >> >> UNSAFE MODULE Unsafe; >> >> (* this module is just declared UNSAFE to conform with the definition >> above, namely, that T can only be manipulated in an UNSAFE >> module, which this is! *) >> >> TYPE T = BRANDED OBJECT END; >> >> BEGIN >> Safe.P(NEW(T)) >> END Unsafe. >> >> (****************************************) >> >> MODULE Safe; >> >> PROCEDURE P(r : REFANY) = >> BEGIN >> NARROW(r, X); (* checked runtime error for all X *) >> >> ISTYPE(r, X); (* returns FALSE for all X except REFANY itself *) >> >> TYPECASE r OF >> X => (* only gets executed for X = REFANY *) >> END; >> END P; >> >> BEGIN END Safe. >> >> Actually is this behavior so bad for tagged integers? Since it is >> the behavior of existing code... why not keep it? Then you can even >> store a tagged integer in a RefList.T, say, even if that RefList.T >> uses NARROW or ISTYPE on the argument (I don't see why it would, but >> why not...?) >> >> >> >>> >>> Mika Nystrom wrote: >>>> Ah I should read my whole inbox before replying. >>>> >>>> I take it you would worry that in my proposal (to do this all in a >>>> library) the use of REFANY to store an integer could be abused >>>> somehow. That the Modula-3 type system (as it exists now) >>>> explicitly >>>> rules out doing such things, and therefore, a language change is >>>> necessary.... >>>> >>>> Mika >>>> >>>> Tony Hosking writes: >>>> >>>>> I like the notion of having a TAGGED INTEGER type that is a hybrid >>>>> ordinal/reference. >>>>> >>>>> Subtyping rules for references would now be as follows: >>>>> >>>>> NULL <: REF T <: REFANY >>>>> TAGGED INTEGER <: REF T <: REFANY >>>>> >>>>> ROOT <: REFANY >>>>> NULL <: T OBJECT ... END <: T >>>>> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: >>>>> REFANY, not >>>>> T <: ADDRESS) >>>>> >>>>> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >>>>> type. Values of TAGGED INTEGER are non-pointer values similar >>>>> to the >>>>> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and >>>>> NARROW(x, >>>>> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to >>>>> ISTYPE(x, >>>>> NULL), NARROW(x, NULL), and TYPECODE(NULL). >>>>> >>>>> Because TAGGED INTEGER is an ordinal we can extract the integer >>>>> value >>>>> it holds using ORD(x). >>>>> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >>>>> INTEGER). >>>>> >>>>> ***The only problem with this scheme is how to efficiently >>>>> perform run- >>>>> time tests for dereferencing NULL, and TAGGED INTEGER?*** >>>> >>>>> So, here is a slightly less elegant alternative that is probably >>>>> straightforward to implement. Introduce a separate TAGGED >>>>> hierarchy. >>>>> >>>>> NULL <: REF T <: REFANY >>>>> NULL <: UNTRACED REF T <: ADDRESS >>>>> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >>>>> >>>>> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >>>>> >>>>> ROOT <: REFANY >>>>> TAGGED ROOT <: TAGGED REFANY >>>>> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >>>>> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >>>>> >>>>> Note that NULL is not a subtype of T OBJECT ... END where T <: >>>>> TAGGED >>>>> REFANY. >>>>> >>>>> This way, tagged references only need a run-time test for the >>>>> tag on >>>>> dereference (we can throw an "attempt to dereference TAGGED >>>>> INTEGER" >>>>> at run time, just like we throw "attempt to dereference NIL" for >>>>> untagged references). This check can be a straightforward test >>>>> of the >>>>> low bit tag. Of course, the weird thing here is now that we don't >>>>> have a single NULL value for TAGGED references --- we have >>>>> multiple >>>>> null values VAL(x, TAGGED INTEGER). Instead of asking "x == >>>>> NIL" we >>>>> must ask "ISTYPE(x, TAGGED INTEGER)". >>>>> >>>>> Of course, because TAGGED INTEGER is an ordinal, we can also >>>>> perform >>>>> the usual ordinal operations like INC(x), DEC(x), wherever x is >>>>> typed >>>>> TAGGED INTEGER. >>>>> >>>>> >>>>> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >>>>> >>>>> >>>>>> I spent quite a bit of time playing with a more general system >>>>>> where >>>>>> there is a set of "tagged" types, with (an implementation-defined >>>>>> subrange of) INTEGER and a reference type both being a subtype >>>>>> of a >>>>>> tagged type. It might have been tolerable, if it weren't for the >>>>>> interaction with object subtypes and opaque types, which quickly >>>>>> gets deep into a deep linguistic tar pit. >>>>>> >>>>>> Tony's approach is much simpler and would serve what I see as the >>>>>> need. It does sacrifice any static checking of what reference >>>>>> type >>>>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>>>> TYPECASE. >>>>>> >>>>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>>>> also need to be an explicit conversion in that direction too, say >>>>>> VAL(x, TAGGED)? I think I favor the explicit conversion here. >>>>>> It >>>>>> is a bit inconsistent with the usual Modula-3 assignability >>>>>> philosophy, >>>>>> but not requiring the explicit conversion already gets your toes >>>>>> into tar. >>>>>> >>>>>> We would have to have something more like ISTYPE, though, which >>>>>> will >>>>>> tell which type the value belongs to without risking a runtime >>>>>> error, >>>>>> which VAL would do. >>>>>> >>>>>> An intermediate approach might be to have a set of tagged types >>>>>> constructed by, say, TAGGED T, where I is a reference type, but >>>>>> with no subtype relations on them at all, thus still requiring >>>>>> the explicit conversions and checks. >>>>>> >>>>>> I do want to say, I _really_ want this capability somehow. I >>>>>> have >>>>>> an ADT module whose internal data structure, for full generality, >>>>>> needs to have two heap objects (the second because it has >>>>>> nonstatic >>>>>> size) and 11 total words counting the orginal pointer, in the >>>>>> case of >>>>>> values that would fit directly into the "pointer" word. >>>>>> Moreover, >>>>>> these small cases are in the great majority. >>>>>> >>>>>> Besides the 11-to-one increase in actual occupied space, there >>>>>> is extra time for allocation, periodic tracing, and collection, >>>>>> space >>>>>> loss due to heap fragmentation, and time/space tradeoff loss >>>>>> due to >>>>>> reduced locality of reference. So sometimes, it would be a big >>>>>> performance gain if we could do it. >>>>>> >>>>>> >>>>>> Tony Hosking wrote: >>>>>> >>>>>>> It is a much more pervasive hack than I would be comfortable >>>>>>> with >>>>>>> since it touches on the compiler (for all the type operations) >>>>>>> as >>>>>>> well >>>>>>> as the run-time system in ways that are pretty gross. I would >>>>>>> much >>>>>>> rather have a new TAGGED builtin. ISTYPE would not work on it >>>>>>> since >>>>>>> that only works on references. The only thing you need is a >>>>>>> way to >>>>>>> extract the value -- we could overload VAL(x, T) where x can >>>>>>> be a >>>>>>> TAGGED and T can be REFANY or INTEGER. >>>>>>> >>>>>>> >>>> >>>> From hosking at cs.purdue.edu Tue Apr 7 08:58:43 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 16:58:43 +1000 Subject: [M3devel] small objects In-Reply-To: References: <200904062039.n36KdIsY095003@camembert.async.caltech.edu> Message-ID: erratum: TYPECODE(r) = RT0.RefanyTypecode if r is a tagged REFANY. (It is a static error to say TYPECODE(REFANY)) On 7 Apr 2009, at 16:55, Tony Hosking wrote: > After all of this -- I may simply be coming back around to your > original proposal -- why not simply declare: > > TaggedInteger.T = REFANY; > > ? > > You can't instantiate a REFANY. > > All we really need is the LOOPHOLEing of your original proposal to > extract the integer values, and to make sure that ISTYPE and NARROW > have the behavior you describe for tagged REFANY. Does it make > sense that TYPECODE(r) = TYPECODE(REFANY) for any tagged REFANY? > What else are we missing? > > On 7 Apr 2009, at 06:39, Mika Nystrom wrote: > >> And finally, to forestall a possible objection to the scheme >> I proposed: >> >> Yes, it is true that even a non-UNSAFE module can allocate a >> TaggedInteger.T by calling >> >> new := RTAllocator.NewTraced(TYPECODE(r)) >> >> where r is a tagged integer. >> >> But since it cannot dereference that new value or do anything else >> with it, I don't think this is a problem. The Pickler (built into >> the TaggedInteger module, one must assume) would simply have to >> be on the lookout for values of the "real" TaggedInteger.T versus >> those that are just numbers with the LSB set, and act accordingly. >> Since the T declaration is only visible within the UNSAFE module >> there can never be any question of another module's muddling the >> two types up. >> >> Mika >> >> Mika Nystrom writes: >>> "Rodney M. Bates" writes: >>>> At first, I just envisioned implementing a small object type >>>> entirely inside an UNSAFE module, using unsafe operations >>>> to construct/test/separate the values. I think if the GC were >>>> to just to ignore words in heap objects that the type system >>>> claims are unambiguously pointers but actually have misaligned >>>> values, this could be done. >>> >>> Right that's precisely what the module I posted does. >>> >>>> >>>> But it flies in the face of a fundamental principle of Modula-3, >>>> namely that an UNSAFE module, if coded correctly, can prevent >>>> all other code from consequences of the unsafety. Unfortunately, >>>> this can't be done with the small pointers, because, even if >>>> opaque, they are still reference types, and client code can >>>> dereference them (including the implicit dereference in accessing >>>> a method or field of an object) and do ISTYPE, NARROW, TYPECASE, >>>> and assignments that do an implicit NARROW. All these operations >>>> could be done outside the implementing module and all could >>>> suffer from misaligned values. >>> >>> Well yes that is true. But the client can't dereference REFANY. >>> Modula-3 doesn't permit that. That's an important practical point, >>> because now we're limited to the other things: ISTYPE, NARROW >>> (implicit and explicit), TYPECASE. (There are two more, actually, >>> and they are = and #.) As long as those can be guaranteed to fail >>> you're OK. [ Actually see my P.S. below! ] >>> >>>> >>>> In fact, misaligned integer "objects" violate another principle >>>> that >>>> the bit pattern must always be a valid representation of some value >>>> of the type. >>> >>> Yes I think maybe this is what Tony is worried about. But let's >>> just change the definition of REFANY to include anything with the >>> LSB set...? >>> >>> In Modula-3-ese it would be more like the following: >>> >>> "REFANY can hold three types of objects. NIL, REF something or an >>> implementation-defined other set of values that can only be accessed >>> in an UNSAFE module. It is a checked runtime error to pass a >>> 'REFANY >>> of the third kind' to ISTYPE, NARROW, TYPECASE." [ Actually see my >>> P.S. below! ] >>> >>> Then I propose we punt the handling of the new REFANYs to this >>> unsafe module we spoke about above. As far as Modula-3 is >>> concerned, >>> there's just a set of values of (apparently) very little utility >>> that can be represented by REFANY. If you think about it, this is >>> really not so crazy. Any module that uses REFANY today is designed >>> around to the fact that there are plenty of values of REFANY that >>> can be of no interest to that module except for passing along to >>> another module. (REFANY can easily represent a type which a module >>> has no way of accessing *any* declaration of beyond just REFANY.) >>> We're just adding some others, the only difference being that the >>> new values are of no interest to any non-UNSAFE module. (Eh, >>> technically this is already true for any reference type that is >>> declared in an UNSAFE module today so one might argue we have in >>> fact added nothing.) >>> >>>> >>>> However, this does suggest a different and very simple linguistic >>>> solution: Just have a new builtin type, say VERYOPAQUE, that >>>> supports no operations other than moving it around, i.e., >>>> assignment, bindings, passing as a parameter, etc. Only unsafe >>>> code could do anyhing with it, by using LOOPHOLE. The only >>>> problem is, would somebody then want one of these in a size other >>>> than one word? >>> >>> This is nice, and we already have a candidate type, in fact: >>> ADDRESS. >>> But the problem is that the GC doesn't follow this even if the LSB >>> is clear... which we *do* want. >>> >>> Why are you worried about getting it in sizes other than one word? >>> That seems to me to be an application problem. If someone wants >>> an ARRAY OF VERYOPAQUE is that a problem? >>> >>> Mika >>> >>> P.S. Illustration of the above, in today's Modula-3: >>> >>> UNSAFE MODULE Unsafe; >>> >>> (* this module is just declared UNSAFE to conform with the >>> definition >>> above, namely, that T can only be manipulated in an UNSAFE >>> module, which this is! *) >>> >>> TYPE T = BRANDED OBJECT END; >>> >>> BEGIN >>> Safe.P(NEW(T)) >>> END Unsafe. >>> >>> (****************************************) >>> >>> MODULE Safe; >>> >>> PROCEDURE P(r : REFANY) = >>> BEGIN >>> NARROW(r, X); (* checked runtime error for all X *) >>> >>> ISTYPE(r, X); (* returns FALSE for all X except REFANY itself *) >>> >>> TYPECASE r OF >>> X => (* only gets executed for X = REFANY *) >>> END; >>> END P; >>> >>> BEGIN END Safe. >>> >>> Actually is this behavior so bad for tagged integers? Since it is >>> the behavior of existing code... why not keep it? Then you can even >>> store a tagged integer in a RefList.T, say, even if that RefList.T >>> uses NARROW or ISTYPE on the argument (I don't see why it would, but >>> why not...?) >>> >>> >>> >>>> >>>> Mika Nystrom wrote: >>>>> Ah I should read my whole inbox before replying. >>>>> >>>>> I take it you would worry that in my proposal (to do this all in a >>>>> library) the use of REFANY to store an integer could be abused >>>>> somehow. That the Modula-3 type system (as it exists now) >>>>> explicitly >>>>> rules out doing such things, and therefore, a language change is >>>>> necessary.... >>>>> >>>>> Mika >>>>> >>>>> Tony Hosking writes: >>>>> >>>>>> I like the notion of having a TAGGED INTEGER type that is a >>>>>> hybrid >>>>>> ordinal/reference. >>>>>> >>>>>> Subtyping rules for references would now be as follows: >>>>>> >>>>>> NULL <: REF T <: REFANY >>>>>> TAGGED INTEGER <: REF T <: REFANY >>>>>> >>>>>> ROOT <: REFANY >>>>>> NULL <: T OBJECT ... END <: T >>>>>> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: >>>>>> REFANY, not >>>>>> T <: ADDRESS) >>>>>> >>>>>> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >>>>>> type. Values of TAGGED INTEGER are non-pointer values similar >>>>>> to the >>>>>> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and >>>>>> NARROW(x, >>>>>> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to >>>>>> ISTYPE(x, >>>>>> NULL), NARROW(x, NULL), and TYPECODE(NULL). >>>>>> >>>>>> Because TAGGED INTEGER is an ordinal we can extract the integer >>>>>> value >>>>>> it holds using ORD(x). >>>>>> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >>>>>> INTEGER). >>>>>> >>>>>> ***The only problem with this scheme is how to efficiently >>>>>> perform run- >>>>>> time tests for dereferencing NULL, and TAGGED INTEGER?*** >>>>> >>>>>> So, here is a slightly less elegant alternative that is probably >>>>>> straightforward to implement. Introduce a separate TAGGED >>>>>> hierarchy. >>>>>> >>>>>> NULL <: REF T <: REFANY >>>>>> NULL <: UNTRACED REF T <: ADDRESS >>>>>> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >>>>>> >>>>>> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >>>>>> >>>>>> ROOT <: REFANY >>>>>> TAGGED ROOT <: TAGGED REFANY >>>>>> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >>>>>> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >>>>>> >>>>>> Note that NULL is not a subtype of T OBJECT ... END where T <: >>>>>> TAGGED >>>>>> REFANY. >>>>>> >>>>>> This way, tagged references only need a run-time test for the >>>>>> tag on >>>>>> dereference (we can throw an "attempt to dereference TAGGED >>>>>> INTEGER" >>>>>> at run time, just like we throw "attempt to dereference NIL" for >>>>>> untagged references). This check can be a straightforward test >>>>>> of the >>>>>> low bit tag. Of course, the weird thing here is now that we >>>>>> don't >>>>>> have a single NULL value for TAGGED references --- we have >>>>>> multiple >>>>>> null values VAL(x, TAGGED INTEGER). Instead of asking "x == >>>>>> NIL" we >>>>>> must ask "ISTYPE(x, TAGGED INTEGER)". >>>>>> >>>>>> Of course, because TAGGED INTEGER is an ordinal, we can also >>>>>> perform >>>>>> the usual ordinal operations like INC(x), DEC(x), wherever x is >>>>>> typed >>>>>> TAGGED INTEGER. >>>>>> >>>>>> >>>>>> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >>>>>> >>>>>> >>>>>>> I spent quite a bit of time playing with a more general system >>>>>>> where >>>>>>> there is a set of "tagged" types, with (an implementation- >>>>>>> defined >>>>>>> subrange of) INTEGER and a reference type both being a subtype >>>>>>> of a >>>>>>> tagged type. It might have been tolerable, if it weren't for >>>>>>> the >>>>>>> interaction with object subtypes and opaque types, which quickly >>>>>>> gets deep into a deep linguistic tar pit. >>>>>>> >>>>>>> Tony's approach is much simpler and would serve what I see as >>>>>>> the >>>>>>> need. It does sacrifice any static checking of what reference >>>>>>> type >>>>>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>>>>> TYPECASE. >>>>>>> >>>>>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>>>>> also need to be an explicit conversion in that direction too, >>>>>>> say >>>>>>> VAL(x, TAGGED)? I think I favor the explicit conversion >>>>>>> here. It >>>>>>> is a bit inconsistent with the usual Modula-3 assignability >>>>>>> philosophy, >>>>>>> but not requiring the explicit conversion already gets your toes >>>>>>> into tar. >>>>>>> >>>>>>> We would have to have something more like ISTYPE, though, >>>>>>> which will >>>>>>> tell which type the value belongs to without risking a runtime >>>>>>> error, >>>>>>> which VAL would do. >>>>>>> >>>>>>> An intermediate approach might be to have a set of tagged types >>>>>>> constructed by, say, TAGGED T, where I is a reference type, but >>>>>>> with no subtype relations on them at all, thus still requiring >>>>>>> the explicit conversions and checks. >>>>>>> >>>>>>> I do want to say, I _really_ want this capability somehow. I >>>>>>> have >>>>>>> an ADT module whose internal data structure, for full >>>>>>> generality, >>>>>>> needs to have two heap objects (the second because it has >>>>>>> nonstatic >>>>>>> size) and 11 total words counting the orginal pointer, in the >>>>>>> case of >>>>>>> values that would fit directly into the "pointer" word. >>>>>>> Moreover, >>>>>>> these small cases are in the great majority. >>>>>>> >>>>>>> Besides the 11-to-one increase in actual occupied space, there >>>>>>> is extra time for allocation, periodic tracing, and >>>>>>> collection, space >>>>>>> loss due to heap fragmentation, and time/space tradeoff loss >>>>>>> due to >>>>>>> reduced locality of reference. So sometimes, it would be a big >>>>>>> performance gain if we could do it. >>>>>>> >>>>>>> >>>>>>> Tony Hosking wrote: >>>>>>> >>>>>>>> It is a much more pervasive hack than I would be comfortable >>>>>>>> with >>>>>>>> since it touches on the compiler (for all the type >>>>>>>> operations) as >>>>>>>> well >>>>>>>> as the run-time system in ways that are pretty gross. I >>>>>>>> would much >>>>>>>> rather have a new TAGGED builtin. ISTYPE would not work on >>>>>>>> it since >>>>>>>> that only works on references. The only thing you need is a >>>>>>>> way to >>>>>>>> extract the value -- we could overload VAL(x, T) where x can >>>>>>>> be a >>>>>>>> TAGGED and T can be REFANY or INTEGER. >>>>>>>> >>>>>>>> >>>>> >>>>> From mika at async.caltech.edu Tue Apr 7 09:27:13 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 07 Apr 2009 00:27:13 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Tue, 07 Apr 2009 16:58:43 +1000." Message-ID: <200904070727.n377RDug014714@camembert.async.caltech.edu> Oh I see. I think... You're saying that because RT0.RefanyTypecode is essentially "useless", it's OK to have values with that typecode since no (existing) module can do anything with that knowledge? So...this proposal says that ISTYPE returns FALSE for everything except ISTYPE(r,REFANY). TYPECASE, same. TYPECODE, as you say, RT0.RefanyTypecode. In other words, it's a useless value except for whatever unsafe code is lurking inside TaggedInteger. So normally, TYPECODE never returns RT0.RefanyTypecode? That's the only thing that would change as far as I can tell... I can't see how that could possibly break anything. Checking for the tagged integers can then be done by checking whether TYPECODE returns RT0.RefanyTypecode. The pickler would build an object when it sees that and pickle that, instead of the tagged integer. So change the language spec to allow the above behavior for a value of type REFANY and to say that unsafe modules may be able to do some other implementation-dependent things with these 'REFANYs of the third kind'? Mika Tony Hosking writes: >erratum: > >TYPECODE(r) = RT0.RefanyTypecode if r is a tagged REFANY. > >(It is a static error to say TYPECODE(REFANY)) > >On 7 Apr 2009, at 16:55, Tony Hosking wrote: > >> After all of this -- I may simply be coming back around to your >> original proposal -- why not simply declare: >> >> TaggedInteger.T = REFANY; >> >> ? >> >> You can't instantiate a REFANY. >> >> All we really need is the LOOPHOLEing of your original proposal to >> extract the integer values, and to make sure that ISTYPE and NARROW >> have the behavior you describe for tagged REFANY. Does it make >> sense that TYPECODE(r) = TYPECODE(REFANY) for any tagged REFANY? >> What else are we missing? >> >> On 7 Apr 2009, at 06:39, Mika Nystrom wrote: >> >>> And finally, to forestall a possible objection to the scheme >>> I proposed: >>> >>> Yes, it is true that even a non-UNSAFE module can allocate a >>> TaggedInteger.T by calling >>> >>> new := RTAllocator.NewTraced(TYPECODE(r)) >>> >>> where r is a tagged integer. >>> >>> But since it cannot dereference that new value or do anything else >>> with it, I don't think this is a problem. The Pickler (built into >>> the TaggedInteger module, one must assume) would simply have to >>> be on the lookout for values of the "real" TaggedInteger.T versus >>> those that are just numbers with the LSB set, and act accordingly. >>> Since the T declaration is only visible within the UNSAFE module >>> there can never be any question of another module's muddling the >>> two types up. >>> >>> Mika >>> >>> Mika Nystrom writes: >>>> "Rodney M. Bates" writes: >>>>> At first, I just envisioned implementing a small object type >>>>> entirely inside an UNSAFE module, using unsafe operations >>>>> to construct/test/separate the values. I think if the GC were >>>>> to just to ignore words in heap objects that the type system >>>>> claims are unambiguously pointers but actually have misaligned >>>>> values, this could be done. >>>> >>>> Right that's precisely what the module I posted does. >>>> >>>>> >>>>> But it flies in the face of a fundamental principle of Modula-3, >>>>> namely that an UNSAFE module, if coded correctly, can prevent >>>>> all other code from consequences of the unsafety. Unfortunately, >>>>> this can't be done with the small pointers, because, even if >>>>> opaque, they are still reference types, and client code can >>>>> dereference them (including the implicit dereference in accessing >>>>> a method or field of an object) and do ISTYPE, NARROW, TYPECASE, >>>>> and assignments that do an implicit NARROW. All these operations >>>>> could be done outside the implementing module and all could >>>>> suffer from misaligned values. >>>> >>>> Well yes that is true. But the client can't dereference REFANY. >>>> Modula-3 doesn't permit that. That's an important practical point, >>>> because now we're limited to the other things: ISTYPE, NARROW >>>> (implicit and explicit), TYPECASE. (There are two more, actually, >>>> and they are = and #.) As long as those can be guaranteed to fail >>>> you're OK. [ Actually see my P.S. below! ] >>>> >>>>> >>>>> In fact, misaligned integer "objects" violate another principle >>>>> that >>>>> the bit pattern must always be a valid representation of some value >>>>> of the type. >>>> >>>> Yes I think maybe this is what Tony is worried about. But let's >>>> just change the definition of REFANY to include anything with the >>>> LSB set...? >>>> >>>> In Modula-3-ese it would be more like the following: >>>> >>>> "REFANY can hold three types of objects. NIL, REF something or an >>>> implementation-defined other set of values that can only be accessed >>>> in an UNSAFE module. It is a checked runtime error to pass a >>>> 'REFANY >>>> of the third kind' to ISTYPE, NARROW, TYPECASE." [ Actually see my >>>> P.S. below! ] >>>> >>>> Then I propose we punt the handling of the new REFANYs to this >>>> unsafe module we spoke about above. As far as Modula-3 is >>>> concerned, >>>> there's just a set of values of (apparently) very little utility >>>> that can be represented by REFANY. If you think about it, this is >>>> really not so crazy. Any module that uses REFANY today is designed >>>> around to the fact that there are plenty of values of REFANY that >>>> can be of no interest to that module except for passing along to >>>> another module. (REFANY can easily represent a type which a module >>>> has no way of accessing *any* declaration of beyond just REFANY.) >>>> We're just adding some others, the only difference being that the >>>> new values are of no interest to any non-UNSAFE module. (Eh, >>>> technically this is already true for any reference type that is >>>> declared in an UNSAFE module today so one might argue we have in >>>> fact added nothing.) >>>> >>>>> >>>>> However, this does suggest a different and very simple linguistic >>>>> solution: Just have a new builtin type, say VERYOPAQUE, that >>>>> supports no operations other than moving it around, i.e., >>>>> assignment, bindings, passing as a parameter, etc. Only unsafe >>>>> code could do anyhing with it, by using LOOPHOLE. The only >>>>> problem is, would somebody then want one of these in a size other >>>>> than one word? >>>> >>>> This is nice, and we already have a candidate type, in fact: >>>> ADDRESS. >>>> But the problem is that the GC doesn't follow this even if the LSB >>>> is clear... which we *do* want. >>>> >>>> Why are you worried about getting it in sizes other than one word? >>>> That seems to me to be an application problem. If someone wants >>>> an ARRAY OF VERYOPAQUE is that a problem? >>>> >>>> Mika >>>> >>>> P.S. Illustration of the above, in today's Modula-3: >>>> >>>> UNSAFE MODULE Unsafe; >>>> >>>> (* this module is just declared UNSAFE to conform with the >>>> definition >>>> above, namely, that T can only be manipulated in an UNSAFE >>>> module, which this is! *) >>>> >>>> TYPE T = BRANDED OBJECT END; >>>> >>>> BEGIN >>>> Safe.P(NEW(T)) >>>> END Unsafe. >>>> >>>> (****************************************) >>>> >>>> MODULE Safe; >>>> >>>> PROCEDURE P(r : REFANY) = >>>> BEGIN >>>> NARROW(r, X); (* checked runtime error for all X *) >>>> >>>> ISTYPE(r, X); (* returns FALSE for all X except REFANY itself *) >>>> >>>> TYPECASE r OF >>>> X => (* only gets executed for X = REFANY *) >>>> END; >>>> END P; >>>> >>>> BEGIN END Safe. >>>> >>>> Actually is this behavior so bad for tagged integers? Since it is >>>> the behavior of existing code... why not keep it? Then you can even >>>> store a tagged integer in a RefList.T, say, even if that RefList.T >>>> uses NARROW or ISTYPE on the argument (I don't see why it would, but >>>> why not...?) >>>> >>>> >>>> >>>>> >>>>> Mika Nystrom wrote: >>>>>> Ah I should read my whole inbox before replying. >>>>>> >>>>>> I take it you would worry that in my proposal (to do this all in a >>>>>> library) the use of REFANY to store an integer could be abused >>>>>> somehow. That the Modula-3 type system (as it exists now) >>>>>> explicitly >>>>>> rules out doing such things, and therefore, a language change is >>>>>> necessary.... >>>>>> >>>>>> Mika >>>>>> >>>>>> Tony Hosking writes: >>>>>> >>>>>>> I like the notion of having a TAGGED INTEGER type that is a >>>>>>> hybrid >>>>>>> ordinal/reference. >>>>>>> >>>>>>> Subtyping rules for references would now be as follows: >>>>>>> >>>>>>> NULL <: REF T <: REFANY >>>>>>> TAGGED INTEGER <: REF T <: REFANY >>>>>>> >>>>>>> ROOT <: REFANY >>>>>>> NULL <: T OBJECT ... END <: T >>>>>>> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: >>>>>>> REFANY, not >>>>>>> T <: ADDRESS) >>>>>>> >>>>>>> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >>>>>>> type. Values of TAGGED INTEGER are non-pointer values similar >>>>>>> to the >>>>>>> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and >>>>>>> NARROW(x, >>>>>>> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to >>>>>>> ISTYPE(x, >>>>>>> NULL), NARROW(x, NULL), and TYPECODE(NULL). >>>>>> >>>>>>> Because TAGGED INTEGER is an ordinal we can extract the integer >>>>>>> value >>>>>>> it holds using ORD(x). >>>>>>> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >>>>>>> INTEGER). >>>>>>> >>>>>>> ***The only problem with this scheme is how to efficiently >>>>>>> perform run- >>>>>>> time tests for dereferencing NULL, and TAGGED INTEGER?*** >>>>>> >>>>>>> So, here is a slightly less elegant alternative that is probably >>>>>>> straightforward to implement. Introduce a separate TAGGED >>>>>>> hierarchy. >>>>>>> >>>>>>> NULL <: REF T <: REFANY >>>>>>> NULL <: UNTRACED REF T <: ADDRESS >>>>>>> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >>>>>>> >>>>>>> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >>>>>>> >>>>>>> ROOT <: REFANY >>>>>>> TAGGED ROOT <: TAGGED REFANY >>>>>>> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >>>>>>> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >>>>>>> >>>>>>> Note that NULL is not a subtype of T OBJECT ... END where T <: >>>>>>> TAGGED >>>>>>> REFANY. >>>>>>> >>>>>>> This way, tagged references only need a run-time test for the >>>>>>> tag on >>>>>>> dereference (we can throw an "attempt to dereference TAGGED >>>>>>> INTEGER" >>>>>>> at run time, just like we throw "attempt to dereference NIL" for >>>>>>> untagged references). This check can be a straightforward test >>>>>>> of the >>>>>>> low bit tag. Of course, the weird thing here is now that we >>>>>>> don't >>>>>>> have a single NULL value for TAGGED references --- we have >>>>>>> multiple >>>>>>> null values VAL(x, TAGGED INTEGER). Instead of asking "x == >>>>>>> NIL" we >>>>>>> must ask "ISTYPE(x, TAGGED INTEGER)". >>>>>>> >>>>>>> Of course, because TAGGED INTEGER is an ordinal, we can also >>>>>>> perform >>>>>>> the usual ordinal operations like INC(x), DEC(x), wherever x is >>>>>>> typed >>>>>>> TAGGED INTEGER. >>>>>>> >>>>>>> >>>>>>> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >>>>>>> >>>>>>> >>>>>>>> I spent quite a bit of time playing with a more general system >>>>>>>> where >>>>>>>> there is a set of "tagged" types, with (an implementation- >>>>>>>> defined >>>>>>>> subrange of) INTEGER and a reference type both being a subtype >>>>>>>> of a >>>>>>>> tagged type. It might have been tolerable, if it weren't for >>>>>>>> the >>>>>>>> interaction with object subtypes and opaque types, which quickly >>>>>>>> gets deep into a deep linguistic tar pit. >>>>>>>> >>>>>>>> Tony's approach is much simpler and would serve what I see as >>>>>>>> the >>>>>>>> need. It does sacrifice any static checking of what reference >>>>>>>> type >>>>>>>> is being tagged, and will also require an extra runtime ISTYPE/ >>>>>>>> TYPECASE. >>>>>>>> >>>>>>>> Would INTEGER and REFANY be assignable to TAGGED, or would there >>>>>>>> also need to be an explicit conversion in that direction too, >>>>>>>> say >>>>>>>> VAL(x, TAGGED)? I think I favor the explicit conversion >>>>>>>> here. It >>>>>>>> is a bit inconsistent with the usual Modula-3 assignability >>>>>>>> philosophy, >>>>>>>> but not requiring the explicit conversion already gets your toes >>>>>>>> into tar. >>>>>>>> >>>>>>>> We would have to have something more like ISTYPE, though, >>>>>>>> which will >>>>>>>> tell which type the value belongs to without risking a runtime >>>>>>>> error, >>>>>>>> which VAL would do. >>>>>>>> >>>>>>>> An intermediate approach might be to have a set of tagged types >>>>>>>> constructed by, say, TAGGED T, where I is a reference type, but >>>>>>>> with no subtype relations on them at all, thus still requiring >>>>>>>> the explicit conversions and checks. >>>>>>>> >>>>>>>> I do want to say, I _really_ want this capability somehow. I >>>>>>>> have >>>>>>>> an ADT module whose internal data structure, for full >>>>>>>> generality, >>>>>>>> needs to have two heap objects (the second because it has >>>>>>>> nonstatic >>>>>>>> size) and 11 total words counting the orginal pointer, in the >>>>>>>> case of >>>>>>>> values that would fit directly into the "pointer" word. >>>>>>>> Moreover, >>>>>>>> these small cases are in the great majority. >>>>>>>> >>>>>>>> Besides the 11-to-one increase in actual occupied space, there >>>>>>>> is extra time for allocation, periodic tracing, and >>>>>>>> collection, space >>>>>>>> loss due to heap fragmentation, and time/space tradeoff loss >>>>>>>> due to >>>>>>>> reduced locality of reference. So sometimes, it would be a big >>>>>>>> performance gain if we could do it. >>>>>>>> >>>>>>>> >>>>>>>> Tony Hosking wrote: >>>>>>>> >>>>>>>>> It is a much more pervasive hack than I would be comfortable >>>>>>>>> with >>>>>>>>> since it touches on the compiler (for all the type >>>>>>>>> operations) as >>>>>>>>> well >>>>>>>>> as the run-time system in ways that are pretty gross. I >>>>>>>>> would much >>>>>>>>> rather have a new TAGGED builtin. ISTYPE would not work on >>>>>>>>> it since >>>>>>>>> that only works on references. The only thing you need is a >>>>>>>>> way to >>>>>>>>> extract the value -- we could overload VAL(x, T) where x can >>>>>>>>> be a >>>>>>>>> TAGGED and T can be REFANY or INTEGER. >>>>>>>>> >>>>>>>>> >>>>>> >>>>>> From hosking at cs.purdue.edu Tue Apr 7 11:27:04 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 19:27:04 +1000 Subject: [M3devel] small objects In-Reply-To: <200904070727.n377RDug014714@camembert.async.caltech.edu> References: <200904070727.n377RDug014714@camembert.async.caltech.edu> Message-ID: <46A56B65-6B75-47E8-ABDC-CBFC357594CE@cs.purdue.edu> Exactly! I really like this. But why wouldn't the pickler have a special for tagged REFANY? By the way, I think it is language definition agnostic - the behaviours are consistent with the spec: > ISTYPE (x: Reference; T: RefType) : BOOLEAN x a tagged REFANY returns FALSE, unless T is REFANY > ISTYPE(x, T) is TRUE if and only if x is a member of T. T must be an > object type or traced reference type, and x must be assignable to T. > NARROW (x: Reference; T: RefType): T > x a tagged REFANY causes a runtime error > NARROW(x, T) returns x after checking that x is a member of T. If > the check fails, a runtime error occurs. T must be an object type or > traced reference type, and x must be assignable to T. > > TYPECODE (T: RefType) : CARDINAL > (r: REFANY) : CARDINAL > r a tagged REFANY returns RT0.RefanyTypecode > (r: UNTRACED ROOT) : CARDINAL > > Every object type or traced reference type (including NULL) has an > associated integer code. Different types have different codes. The > code for a type is constant for any single execution of a program, > but may differ for different executions. TYPECODE(T) returns the > code for the type T and TYPECODE(r) returns the code for the > allocated type of r. It is a static error if T is REFANY or is not > an object type or traced reference type. Does anyone have a good reason why TYPECODE(REFANY) should be a static error? On 7 Apr 2009, at 17:27, Mika Nystrom wrote: > Oh I see. I think... > > You're saying that because RT0.RefanyTypecode is essentially > "useless", it's OK to have values with that typecode since no > (existing) module can do anything with that knowledge? > > So...this proposal says that ISTYPE returns FALSE for everything > except ISTYPE(r,REFANY). > > TYPECASE, same. > > TYPECODE, as you say, RT0.RefanyTypecode. > > In other words, it's a useless value except for whatever unsafe code > is lurking inside TaggedInteger. > > So normally, TYPECODE never returns RT0.RefanyTypecode? That's the > only thing that would change as far as I can tell... I can't see how > that could possibly break anything. > > Checking for the tagged integers can then be done by checking whether > TYPECODE returns RT0.RefanyTypecode. The pickler would build an > object when it sees that and pickle that, instead of the tagged > integer. > > So change the language spec to allow the above behavior for a value > of type REFANY and to say that unsafe modules may be able to do > some other implementation-dependent things with these 'REFANYs of > the third kind'? > > Mika > > > Tony Hosking writes: >> erratum: >> >> TYPECODE(r) = RT0.RefanyTypecode if r is a tagged REFANY. >> >> (It is a static error to say TYPECODE(REFANY)) >> >> On 7 Apr 2009, at 16:55, Tony Hosking wrote: >> >>> After all of this -- I may simply be coming back around to your >>> original proposal -- why not simply declare: >>> >>> TaggedInteger.T = REFANY; >>> >>> ? >>> >>> You can't instantiate a REFANY. >>> >>> All we really need is the LOOPHOLEing of your original proposal to >>> extract the integer values, and to make sure that ISTYPE and NARROW >>> have the behavior you describe for tagged REFANY. Does it make >>> sense that TYPECODE(r) = TYPECODE(REFANY) for any tagged REFANY? >>> What else are we missing? >>> >>> On 7 Apr 2009, at 06:39, Mika Nystrom wrote: >>> >>>> And finally, to forestall a possible objection to the scheme >>>> I proposed: >>>> >>>> Yes, it is true that even a non-UNSAFE module can allocate a >>>> TaggedInteger.T by calling >>>> >>>> new := RTAllocator.NewTraced(TYPECODE(r)) >>>> >>>> where r is a tagged integer. >>>> >>>> But since it cannot dereference that new value or do anything else >>>> with it, I don't think this is a problem. The Pickler (built into >>>> the TaggedInteger module, one must assume) would simply have to >>>> be on the lookout for values of the "real" TaggedInteger.T versus >>>> those that are just numbers with the LSB set, and act accordingly. >>>> Since the T declaration is only visible within the UNSAFE module >>>> there can never be any question of another module's muddling the >>>> two types up. >>>> >>>> Mika >>>> >>>> Mika Nystrom writes: >>>>> "Rodney M. Bates" writes: >>>>>> At first, I just envisioned implementing a small object type >>>>>> entirely inside an UNSAFE module, using unsafe operations >>>>>> to construct/test/separate the values. I think if the GC were >>>>>> to just to ignore words in heap objects that the type system >>>>>> claims are unambiguously pointers but actually have misaligned >>>>>> values, this could be done. >>>>> >>>>> Right that's precisely what the module I posted does. >>>>> >>>>>> >>>>>> But it flies in the face of a fundamental principle of Modula-3, >>>>>> namely that an UNSAFE module, if coded correctly, can prevent >>>>>> all other code from consequences of the unsafety. Unfortunately, >>>>>> this can't be done with the small pointers, because, even if >>>>>> opaque, they are still reference types, and client code can >>>>>> dereference them (including the implicit dereference in accessing >>>>>> a method or field of an object) and do ISTYPE, NARROW, TYPECASE, >>>>>> and assignments that do an implicit NARROW. All these operations >>>>>> could be done outside the implementing module and all could >>>>>> suffer from misaligned values. >>>>> >>>>> Well yes that is true. But the client can't dereference REFANY. >>>>> Modula-3 doesn't permit that. That's an important practical >>>>> point, >>>>> because now we're limited to the other things: ISTYPE, NARROW >>>>> (implicit and explicit), TYPECASE. (There are two more, actually, >>>>> and they are = and #.) As long as those can be guaranteed to fail >>>>> you're OK. [ Actually see my P.S. below! ] >>>>> >>>>>> >>>>>> In fact, misaligned integer "objects" violate another principle >>>>>> that >>>>>> the bit pattern must always be a valid representation of some >>>>>> value >>>>>> of the type. >>>>> >>>>> Yes I think maybe this is what Tony is worried about. But let's >>>>> just change the definition of REFANY to include anything with the >>>>> LSB set...? >>>>> >>>>> In Modula-3-ese it would be more like the following: >>>>> >>>>> "REFANY can hold three types of objects. NIL, REF something or an >>>>> implementation-defined other set of values that can only be >>>>> accessed >>>>> in an UNSAFE module. It is a checked runtime error to pass a >>>>> 'REFANY >>>>> of the third kind' to ISTYPE, NARROW, TYPECASE." [ Actually see my >>>>> P.S. below! ] >>>>> >>>>> Then I propose we punt the handling of the new REFANYs to this >>>>> unsafe module we spoke about above. As far as Modula-3 is >>>>> concerned, >>>>> there's just a set of values of (apparently) very little utility >>>>> that can be represented by REFANY. If you think about it, this is >>>>> really not so crazy. Any module that uses REFANY today is >>>>> designed >>>>> around to the fact that there are plenty of values of REFANY that >>>>> can be of no interest to that module except for passing along to >>>>> another module. (REFANY can easily represent a type which a >>>>> module >>>>> has no way of accessing *any* declaration of beyond just REFANY.) >>>>> We're just adding some others, the only difference being that the >>>>> new values are of no interest to any non-UNSAFE module. (Eh, >>>>> technically this is already true for any reference type that is >>>>> declared in an UNSAFE module today so one might argue we have in >>>>> fact added nothing.) >>>>> >>>>>> >>>>>> However, this does suggest a different and very simple linguistic >>>>>> solution: Just have a new builtin type, say VERYOPAQUE, that >>>>>> supports no operations other than moving it around, i.e., >>>>>> assignment, bindings, passing as a parameter, etc. Only unsafe >>>>>> code could do anyhing with it, by using LOOPHOLE. The only >>>>>> problem is, would somebody then want one of these in a size other >>>>>> than one word? >>>>> >>>>> This is nice, and we already have a candidate type, in fact: >>>>> ADDRESS. >>>>> But the problem is that the GC doesn't follow this even if the LSB >>>>> is clear... which we *do* want. >>>>> >>>>> Why are you worried about getting it in sizes other than one word? >>>>> That seems to me to be an application problem. If someone wants >>>>> an ARRAY OF VERYOPAQUE is that a problem? >>>>> >>>>> Mika >>>>> >>>>> P.S. Illustration of the above, in today's Modula-3: >>>>> >>>>> UNSAFE MODULE Unsafe; >>>>> >>>>> (* this module is just declared UNSAFE to conform with the >>>>> definition >>>>> above, namely, that T can only be manipulated in an UNSAFE >>>>> module, which this is! *) >>>>> >>>>> TYPE T = BRANDED OBJECT END; >>>>> >>>>> BEGIN >>>>> Safe.P(NEW(T)) >>>>> END Unsafe. >>>>> >>>>> (****************************************) >>>>> >>>>> MODULE Safe; >>>>> >>>>> PROCEDURE P(r : REFANY) = >>>>> BEGIN >>>>> NARROW(r, X); (* checked runtime error for all X *) >>>>> >>>>> ISTYPE(r, X); (* returns FALSE for all X except REFANY itself *) >>>>> >>>>> TYPECASE r OF >>>>> X => (* only gets executed for X = REFANY *) >>>>> END; >>>>> END P; >>>>> >>>>> BEGIN END Safe. >>>>> >>>>> Actually is this behavior so bad for tagged integers? Since it is >>>>> the behavior of existing code... why not keep it? Then you can >>>>> even >>>>> store a tagged integer in a RefList.T, say, even if that RefList.T >>>>> uses NARROW or ISTYPE on the argument (I don't see why it would, >>>>> but >>>>> why not...?) >>>>> >>>>> >>>>> >>>>>> >>>>>> Mika Nystrom wrote: >>>>>>> Ah I should read my whole inbox before replying. >>>>>>> >>>>>>> I take it you would worry that in my proposal (to do this all >>>>>>> in a >>>>>>> library) the use of REFANY to store an integer could be abused >>>>>>> somehow. That the Modula-3 type system (as it exists now) >>>>>>> explicitly >>>>>>> rules out doing such things, and therefore, a language change is >>>>>>> necessary.... >>>>>>> >>>>>>> Mika >>>>>>> >>>>>>> Tony Hosking writes: >>>>>>> >>>>>>>> I like the notion of having a TAGGED INTEGER type that is a >>>>>>>> hybrid >>>>>>>> ordinal/reference. >>>>>>>> >>>>>>>> Subtyping rules for references would now be as follows: >>>>>>>> >>>>>>>> NULL <: REF T <: REFANY >>>>>>>> TAGGED INTEGER <: REF T <: REFANY >>>>>>>> >>>>>>>> ROOT <: REFANY >>>>>>>> NULL <: T OBJECT ... END <: T >>>>>>>> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: >>>>>>>> REFANY, not >>>>>>>> T <: ADDRESS) >>>>>>>> >>>>>>>> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/ >>>>>>>> reference >>>>>>>> type. Values of TAGGED INTEGER are non-pointer values similar >>>>>>>> to the >>>>>>>> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and >>>>>>>> NARROW(x, >>>>>>>> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to >>>>>>>> ISTYPE(x, >>>>>>>> NULL), NARROW(x, NULL), and TYPECODE(NULL). >>>>>>> >>>>>>>> Because TAGGED INTEGER is an ordinal we can extract the integer >>>>>>>> value >>>>>>>> it holds using ORD(x). >>>>>>>> Similarly, we can construct a TAGGED INTEGER using VAL(x, >>>>>>>> TAGGED >>>>>>>> INTEGER). >>>>>>>> >>>>>>>> ***The only problem with this scheme is how to efficiently >>>>>>>> perform run- >>>>>>>> time tests for dereferencing NULL, and TAGGED INTEGER?*** >>>>>>> >>>>>>>> So, here is a slightly less elegant alternative that is >>>>>>>> probably >>>>>>>> straightforward to implement. Introduce a separate TAGGED >>>>>>>> hierarchy. >>>>>>>> >>>>>>>> NULL <: REF T <: REFANY >>>>>>>> NULL <: UNTRACED REF T <: ADDRESS >>>>>>>> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >>>>>>>> >>>>>>>> Note that NULL is not a subtype of TAGGED REF T or TAGGED >>>>>>>> REFANY. >>>>>>>> >>>>>>>> ROOT <: REFANY >>>>>>>> TAGGED ROOT <: TAGGED REFANY >>>>>>>> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >>>>>>>> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED >>>>>>>> REFANY >>>>>>>> >>>>>>>> Note that NULL is not a subtype of T OBJECT ... END where T <: >>>>>>>> TAGGED >>>>>>>> REFANY. >>>>>>>> >>>>>>>> This way, tagged references only need a run-time test for the >>>>>>>> tag on >>>>>>>> dereference (we can throw an "attempt to dereference TAGGED >>>>>>>> INTEGER" >>>>>>>> at run time, just like we throw "attempt to dereference NIL" >>>>>>>> for >>>>>>>> untagged references). This check can be a straightforward test >>>>>>>> of the >>>>>>>> low bit tag. Of course, the weird thing here is now that we >>>>>>>> don't >>>>>>>> have a single NULL value for TAGGED references --- we have >>>>>>>> multiple >>>>>>>> null values VAL(x, TAGGED INTEGER). Instead of asking "x == >>>>>>>> NIL" we >>>>>>>> must ask "ISTYPE(x, TAGGED INTEGER)". >>>>>>>> >>>>>>>> Of course, because TAGGED INTEGER is an ordinal, we can also >>>>>>>> perform >>>>>>>> the usual ordinal operations like INC(x), DEC(x), wherever x is >>>>>>>> typed >>>>>>>> TAGGED INTEGER. >>>>>>>> >>>>>>>> >>>>>>>> On 6 Apr 2009, at 11:44, Rodney M. Bates wrote: >>>>>>>> >>>>>>>> >>>>>>>>> I spent quite a bit of time playing with a more general system >>>>>>>>> where >>>>>>>>> there is a set of "tagged" types, with (an implementation- >>>>>>>>> defined >>>>>>>>> subrange of) INTEGER and a reference type both being a subtype >>>>>>>>> of a >>>>>>>>> tagged type. It might have been tolerable, if it weren't for >>>>>>>>> the >>>>>>>>> interaction with object subtypes and opaque types, which >>>>>>>>> quickly >>>>>>>>> gets deep into a deep linguistic tar pit. >>>>>>>>> >>>>>>>>> Tony's approach is much simpler and would serve what I see as >>>>>>>>> the >>>>>>>>> need. It does sacrifice any static checking of what reference >>>>>>>>> type >>>>>>>>> is being tagged, and will also require an extra runtime >>>>>>>>> ISTYPE/ >>>>>>>>> TYPECASE. >>>>>>>>> >>>>>>>>> Would INTEGER and REFANY be assignable to TAGGED, or would >>>>>>>>> there >>>>>>>>> also need to be an explicit conversion in that direction too, >>>>>>>>> say >>>>>>>>> VAL(x, TAGGED)? I think I favor the explicit conversion >>>>>>>>> here. It >>>>>>>>> is a bit inconsistent with the usual Modula-3 assignability >>>>>>>>> philosophy, >>>>>>>>> but not requiring the explicit conversion already gets your >>>>>>>>> toes >>>>>>>>> into tar. >>>>>>>>> >>>>>>>>> We would have to have something more like ISTYPE, though, >>>>>>>>> which will >>>>>>>>> tell which type the value belongs to without risking a runtime >>>>>>>>> error, >>>>>>>>> which VAL would do. >>>>>>>>> >>>>>>>>> An intermediate approach might be to have a set of tagged >>>>>>>>> types >>>>>>>>> constructed by, say, TAGGED T, where I is a reference type, >>>>>>>>> but >>>>>>>>> with no subtype relations on them at all, thus still requiring >>>>>>>>> the explicit conversions and checks. >>>>>>>>> >>>>>>>>> I do want to say, I _really_ want this capability somehow. I >>>>>>>>> have >>>>>>>>> an ADT module whose internal data structure, for full >>>>>>>>> generality, >>>>>>>>> needs to have two heap objects (the second because it has >>>>>>>>> nonstatic >>>>>>>>> size) and 11 total words counting the orginal pointer, in the >>>>>>>>> case of >>>>>>>>> values that would fit directly into the "pointer" word. >>>>>>>>> Moreover, >>>>>>>>> these small cases are in the great majority. >>>>>>>>> >>>>>>>>> Besides the 11-to-one increase in actual occupied space, there >>>>>>>>> is extra time for allocation, periodic tracing, and >>>>>>>>> collection, space >>>>>>>>> loss due to heap fragmentation, and time/space tradeoff loss >>>>>>>>> due to >>>>>>>>> reduced locality of reference. So sometimes, it would be a >>>>>>>>> big >>>>>>>>> performance gain if we could do it. >>>>>>>>> >>>>>>>>> >>>>>>>>> Tony Hosking wrote: >>>>>>>>> >>>>>>>>>> It is a much more pervasive hack than I would be comfortable >>>>>>>>>> with >>>>>>>>>> since it touches on the compiler (for all the type >>>>>>>>>> operations) as >>>>>>>>>> well >>>>>>>>>> as the run-time system in ways that are pretty gross. I >>>>>>>>>> would much >>>>>>>>>> rather have a new TAGGED builtin. ISTYPE would not work on >>>>>>>>>> it since >>>>>>>>>> that only works on references. The only thing you need is a >>>>>>>>>> way to >>>>>>>>>> extract the value -- we could overload VAL(x, T) where x can >>>>>>>>>> be a >>>>>>>>>> TAGGED and T can be REFANY or INTEGER. >>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Apr 7 13:49:58 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 7 Apr 2009 07:49:58 -0400 Subject: [M3devel] small objects In-Reply-To: <985F59A0-82EA-4F55-B6C8-DA057B9E23DB@cs.purdue.edu> References: <200904070042.n370gNK3001242@camembert.async.caltech.edu> <9F2237E2-73A2-4926-A438-A6032F70B4F6@cs.purdue.edu> <49DA8196.1E75.00D7.1@scires.com> <985F59A0-82EA-4F55-B6C8-DA057B9E23DB@cs.purdue.edu> Message-ID: <20090407114957.GA27695@topoi.pooq.com> On Tue, Apr 07, 2009 at 12:52:59PM +1000, Tony Hosking wrote: > On 7 Apr 2009, at 12:27, Randy Coleburn wrote: > > >Hey, will this proposal mean that packages like "stable" and > >"stubgen" need to be changed also, in addition to both versions of > >pickles? > > They build on m3tk so should just work, modulo any builtin typecode > information. TAGGED INTEGER will have a predefined typecode just like > NULL. I'm confused. I thought the only tagged types were reference types. -- hendrik From hendrik at topoi.pooq.com Tue Apr 7 14:12:17 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 7 Apr 2009 08:12:17 -0400 Subject: [M3devel] small objects In-Reply-To: References: <200904062039.n36KdIsY095003@camembert.async.caltech.edu> Message-ID: <20090407121217.GB27695@topoi.pooq.com> On Tue, Apr 07, 2009 at 04:55:12PM +1000, Tony Hosking wrote: > After all of this -- I may simply be coming back around to your > original proposal -- why not simply declare: > > TaggedInteger.T = REFANY; You'd be adding a range of integers to the set of things a REFANY could hold. Might that enable one to pass these integers as REFANYs to existing code that isn't expecting it? Might code that checks its input for suitable preconditions then let this case slide? Or would any test that checks that a REFANY holds an appropriate reference or NIL automatically manage to exclude tagged integers, just as it excludes inappropriate references? I don't mind the proposed semantics for REFANY -- if it had been there from the beginning. But with a lot of existing code in existing libraries, would it be safer to use a new type for this new meaning? You could, of course, stull have an unsafe module that defines TaggedInteger.T = NEWTYPEWITHNEWNAME; -- hendrik From hendrik at topoi.pooq.com Tue Apr 7 14:21:28 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 7 Apr 2009 08:21:28 -0400 Subject: [M3devel] small objects In-Reply-To: <200904070727.n377RDug014714@camembert.async.caltech.edu> References: <200904070727.n377RDug014714@camembert.async.caltech.edu> Message-ID: <20090407122128.GC27695@topoi.pooq.com> On Tue, Apr 07, 2009 at 12:27:13AM -0700, Mika Nystrom wrote: > Oh I see. I think... > > You're saying that because RT0.RefanyTypecode is essentially > "useless", it's OK to have values with that typecode since no > (existing) module can do anything with that knowledge? This looks like inelegant semantics. A way of retrofitting a new feature in an existing semantic gap. The kind of patch that will bite us if ever there is a proper use for the typecode for REFANY. (I can imagine someday someone might have a use for such a thing, such as a dynamic test on typecodes to determine whether one type is a subtypoe of another ... I can't really imagine what someone might need in the future). But I thing this kind of thing might really stand in the way. REFANY is about references. Let's have a new type, with its own typecode, for things that can be other than references. -- hendrik From hosking at cs.purdue.edu Tue Apr 7 14:26:08 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Apr 2009 22:26:08 +1000 Subject: [M3devel] small objects In-Reply-To: <20090407121217.GB27695@topoi.pooq.com> References: <200904062039.n36KdIsY095003@camembert.async.caltech.edu> <20090407121217.GB27695@topoi.pooq.com> Message-ID: You can't do anything directly with a REFANY. To use it you need to narrow to a concrete type. We would disallow that for tagged values with a run-time check. Existing code needs to check (using ISTYPE or TYPECASE), or know by design, what type is safe to narrow to, before narrowing anyway. So I think all is ok. On 7 Apr 2009, at 22:12, hendrik at topoi.pooq.com wrote: > On Tue, Apr 07, 2009 at 04:55:12PM +1000, Tony Hosking wrote: >> After all of this -- I may simply be coming back around to your >> original proposal -- why not simply declare: >> >> TaggedInteger.T = REFANY; > > You'd be adding a range of integers to the set of things a REFANY > could > hold. Might that enable one to pass these integers as REFANYs to > existing code that isn't expecting it? Might code that checks its > input > for suitable preconditions then let this case slide? Or would any > test > that checks that a REFANY holds an appropriate reference or NIL > automatically manage to exclude tagged integers, just as it excludes > inappropriate references? > > I don't mind the proposed semantics for REFANY -- if it had been > there from the beginning. But with a lot of existing code in existing > libraries, would it be safer to use a new type for this new meaning? > > You could, of course, stull have an unsafe module that defines > > TaggedInteger.T = NEWTYPEWITHNEWNAME; > > -- hendrik From mika at async.caltech.edu Tue Apr 7 19:12:55 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 07 Apr 2009 10:12:55 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Tue, 07 Apr 2009 22:26:08 +1000." Message-ID: <200904071712.n37HCtda030844@camembert.async.caltech.edu> Tony, I think you have convinced me that what you say is workable. However I share Hendrik's concern that using RT0.RefanyTypecode might hurt some day in the future, even if I think you have shown pretty convincingly that it doesn't hurt today. How about my "second proposal". Do pretty much what you suggest but instead of returning RT0.RefanyTypecode, return TYPECODE(TaggedInteger.T), where TaggedInteger.T is an object type that is declared entirely privately to the TaggedInteger unsafe module... this also gives a completely obvious implementation for pickling the tagged integers. Simply convert them to TaggedInteger.T and pickle that. An implementation that doesn't support tagged integers in pointers could also allocate "real" TaggedInteger.Ts.... not sure that is useful though or if it just confuses. Actually I think it is useful, because it lets you represent the values even if unpickling in a system that doesn't support tagged integers in REFANYs. I would go so far as saying this... I believe it is possible to guarantee that any safe code outside of the TaggedInteger module couldn't distinguish between a REFANY that holds a tagged integer vs. one that holds a reference to a (heap-allocated) TaggedInteger.T. How's that for not breaking the language definition? Hendrik, I think Tony's and my arguments that you can't break any existing code by allowing the squirreling away of integers into REFANYs are pretty solid. Pre-existing code simply can't do anything useful with unrevealed REFANYs. There are also good reasons for permitting this oddness (vide Smalltalk and Scheme small integers). Mika Tony Hosking writes: >You can't do anything directly with a REFANY. To use it you need to >narrow to a concrete type. We would disallow that for tagged values >with a run-time check. Existing code needs to check (using ISTYPE or >TYPECASE), or know by design, what type is safe to narrow to, before >narrowing anyway. So I think all is ok. > >On 7 Apr 2009, at 22:12, hendrik at topoi.pooq.com wrote: > >> On Tue, Apr 07, 2009 at 04:55:12PM +1000, Tony Hosking wrote: >>> After all of this -- I may simply be coming back around to your >>> original proposal -- why not simply declare: >>> >>> TaggedInteger.T = REFANY; >> >> You'd be adding a range of integers to the set of things a REFANY >> could >> hold. Might that enable one to pass these integers as REFANYs to >> existing code that isn't expecting it? Might code that checks its >> input >> for suitable preconditions then let this case slide? Or would any >> test >> that checks that a REFANY holds an appropriate reference or NIL >> automatically manage to exclude tagged integers, just as it excludes >> inappropriate references? >> >> I don't mind the proposed semantics for REFANY -- if it had been >> there from the beginning. But with a lot of existing code in existing >> libraries, would it be safer to use a new type for this new meaning? >> >> You could, of course, stull have an unsafe module that defines >> >> TaggedInteger.T = NEWTYPEWITHNEWNAME; >> >> -- hendrik From rodney.m.bates at cox.net Tue Apr 7 18:11:48 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Tue, 07 Apr 2009 11:11:48 -0500 Subject: [M3devel] small objects In-Reply-To: <40B7AD71-FBDD-4321-837F-D294DD4A3D45@cs.purdue.edu> References: <200903300333.n2U3XBME062502@camembert.async.caltech.edu> <49D95E70.6000004@wichita.edu> <40B7AD71-FBDD-4321-837F-D294DD4A3D45@cs.purdue.edu> Message-ID: <49DB7B44.2000000@cox.net> Tagged types and object type hierarchies: At first, I was imagining that you could create an object subtype of a TAGGED type: (* An untagged hierarchy: *) TYPE O1 = OBJECT F1: INTEGER END; TYPE O2 = O1 OBJECT F2: CHAR END; TYPE O3 = O2 OBJECT F3: BOOLEAN END: (* Tag each one directly: *) TYPE TO1 = TAGGED O1; TYPE TO2 = TAGGED O2; TYPE TO3 = TAGGED O3; (* A tagged hierarchy: *) TYPE TO2S = TO1 OBJECT F2: CHAR END; TYPE TO3S = TO2S OBJECT F3: BOOLEAN END; Is TO2S = TO2 and TO3S = TO3? Is O2 <: TO2S and O3 <: TO3S? Therein lies tar. The type equality and subtype relations are getting awfully elaborate for a language that advertises relative simplicity. Then I thought about two parallel hierarchies, one tagged and one not, as Tony's second proposal. But that leaves it awfully inconvenient to have both a tagged and untagged counterpart that are otherwise the same, and you need the untagged counterpart to do ISTYPE/NARROW/TYPECASE/:= to get the "definitely-a-heap-reference" value out of a tagged type. If I read it right, Tony's first proposal does not allow to subclass an already tagged type (i.e., no "tagged hierarchy" as above). Is that what you meant, Tony? If so, I think this is enough, and avoids the complicated type equality and subtype relations. A separate issue: On the INTEGER side of this, I think we need a builtin type that is an implementation-defined subrange of INTEGER, that can hold just the integer values a tagged type can hold. Maybe "TAG"? (Actually, this name is a poor choice, since it's not the tag itself, but it's the best I can think right now, so I will use it in discussion). If we really want to constrain the implementation to always use exactly the low bit as the tag, then CARDINAL would do for this. A new builtin type would leave open other tagging representations with other ranges of representable integers, as well as the low-bit tag with signed integers. Then we could also allow ISTYPE(x, TAG), etc. to get the "definitely-an- integer" value out. This gives fully type-safe support for small objects, which I really prefer, if not too complicated. Tony Hosking wrote: > I like the notion of having a TAGGED INTEGER type that is a hybrid > ordinal/reference. > > Subtyping rules for references would now be as follows: > > NULL <: REF T <: REFANY > TAGGED INTEGER <: REF T <: REFANY > > ROOT <: REFANY > NULL <: T OBJECT ... END <: T > TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: REFANY, not > T <: ADDRESS) > > Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference > type. Values of TAGGED INTEGER are non-pointer values similar to the > value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and NARROW(x, > TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to ISTYPE(x, > NULL), NARROW(x, NULL), and TYPECODE(NULL). > > Because TAGGED INTEGER is an ordinal we can extract the integer value > it holds using ORD(x). > Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED > INTEGER). > > ***The only problem with this scheme is how to efficiently perform > run-time tests for dereferencing NULL, and TAGGED INTEGER?*** > > So, here is a slightly less elegant alternative that is probably > straightforward to implement. Introduce a separate TAGGED hierarchy. > > NULL <: REF T <: REFANY > NULL <: UNTRACED REF T <: ADDRESS > TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY > > Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. > > ROOT <: REFANY > TAGGED ROOT <: TAGGED REFANY > NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS > TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY > > Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED > REFANY. > > This way, tagged references only need a run-time test for the tag on > dereference (we can throw an "attempt to dereference TAGGED INTEGER" > at run time, just like we throw "attempt to dereference NIL" for > untagged references). This check can be a straightforward test of the > low bit tag. Of course, the weird thing here is now that we don't > have a single NULL value for TAGGED references --- we have multiple > null values VAL(x, TAGGED INTEGER). Instead of asking "x == NIL" we > must ask "ISTYPE(x, TAGGED INTEGER)". > > Of course, because TAGGED INTEGER is an ordinal, we can also perform > the usual ordinal operations like INC(x), DEC(x), wherever x is typed > TAGGED INTEGER. > From mika at async.caltech.edu Tue Apr 7 20:33:05 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 07 Apr 2009 11:33:05 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Tue, 07 Apr 2009 11:11:48 CDT." <49DB7B44.2000000@cox.net> Message-ID: <200904071833.n37IX5Hg033221@camembert.async.caltech.edu> So following my previous email, I suggest the following, which doesn't change the language definition at all: INTERFACE TaggedInteger; IMPORT Word; TYPE T <: REFANY; V = [ TaggedMin .. TaggedMax ]; CONST TaggedMin = -Word.Shift(1,BITSIZE(REFANY)-2); TaggedMax = Word.Shift(1,BITSIZE(REFANY)-2) - 1; PROCECURE Extract(t : T) : V; PROCEDURE New(v : V) : T; (* ...the usual generic support routines... *) END TaggedInteger. The compiler, runtime, and the implementation of this interface would be responsible for hiding the values in REFANYs, doing the correct thing for NARROW, ISTYPE, TYPECASE, TYPECODE, # and =... What functionality is missing? I think the compiler/runtime changes are pretty much the same no matter which of the proposals you go with... Mika "Rodney M. Bates" writes: >Tagged types and object type hierarchies: > >At first, I was imagining that you could create >an object subtype of a TAGGED type: > >(* An untagged hierarchy: *) >TYPE O1 = OBJECT F1: INTEGER END; >TYPE O2 = O1 OBJECT F2: CHAR END; >TYPE O3 = O2 OBJECT F3: BOOLEAN END: > >(* Tag each one directly: *) >TYPE TO1 = TAGGED O1; >TYPE TO2 = TAGGED O2; >TYPE TO3 = TAGGED O3; > >(* A tagged hierarchy: *) >TYPE TO2S = TO1 OBJECT F2: CHAR END; >TYPE TO3S = TO2S OBJECT F3: BOOLEAN END; > >Is TO2S = TO2 and TO3S = TO3? > >Is O2 <: TO2S and O3 <: TO3S? > >Therein lies tar. The type equality and subtype relations are getting >awfully elaborate for a language that advertises relative simplicity. > >Then I thought about two parallel hierarchies, one tagged and one not, >as Tony's second proposal. But that leaves it awfully inconvenient >to have both a tagged and untagged counterpart that are otherwise the >same, and you need the untagged counterpart to do ISTYPE/NARROW/TYPECASE/:= >to get the "definitely-a-heap-reference" value out of a tagged type. > >If I read it right, Tony's first proposal does not allow to subclass an >already tagged type (i.e., no "tagged hierarchy" as above). Is that >what you meant, Tony? If so, I think this is enough, and avoids the >complicated type equality and subtype relations. > >A separate issue: > >On the INTEGER side of this, I think we need a builtin type that is an >implementation-defined subrange of INTEGER, that can hold just the >integer values a tagged type can hold. Maybe "TAG"? (Actually, this >name is a poor choice, since it's not the tag itself, but it's the best >I can think right now, so I will use it in discussion). > >If we really want to constrain the implementation to always use exactly >the low bit as the tag, then CARDINAL would do for this. A new builtin >type would leave open other tagging representations with other ranges of >representable integers, as well as the low-bit tag with signed integers. > >Then we could also allow ISTYPE(x, TAG), etc. to get the "definitely-an- >integer" value out. > >This gives fully type-safe support for small objects, which I really >prefer, if not too complicated. > > > >Tony Hosking wrote: >> I like the notion of having a TAGGED INTEGER type that is a hybrid >> ordinal/reference. >> >> Subtyping rules for references would now be as follows: >> >> NULL <: REF T <: REFANY >> TAGGED INTEGER <: REF T <: REFANY >> >> ROOT <: REFANY >> NULL <: T OBJECT ... END <: T >> TAGGED INTEGER <: T OBJECT ... END <: T (but only for T <: REFANY, not >> T <: ADDRESS) >> >> Thus, TAGGED INTEGER is a funny sort of hybrid ordinal/reference >> type. Values of TAGGED INTEGER are non-pointer values similar to the >> value NIL. We can then do ISTYPE(x, TAGGED INTEGER), and NARROW(x, >> TAGGED INTEGER), and TYPECODE(TAGGED INTEGER), similarly to ISTYPE(x, >> NULL), NARROW(x, NULL), and TYPECODE(NULL). >> >> Because TAGGED INTEGER is an ordinal we can extract the integer value >> it holds using ORD(x). >> Similarly, we can construct a TAGGED INTEGER using VAL(x, TAGGED >> INTEGER). >> >> ***The only problem with this scheme is how to efficiently perform >> run-time tests for dereferencing NULL, and TAGGED INTEGER?*** >> >> So, here is a slightly less elegant alternative that is probably >> straightforward to implement. Introduce a separate TAGGED hierarchy. >> >> NULL <: REF T <: REFANY >> NULL <: UNTRACED REF T <: ADDRESS >> TAGGED INTEGER <: TAGGED REF T <: TAGGED REFANY >> >> Note that NULL is not a subtype of TAGGED REF T or TAGGED REFANY. >> >> ROOT <: REFANY >> TAGGED ROOT <: TAGGED REFANY >> NULL <: T OBJECT END <: T where T <: REFANY or T <: ADDRESS >> TAGGED INTEGER <: T OBJECT ... END <: T where T <: TAGGED REFANY >> >> Note that NULL is not a subtype of T OBJECT ... END where T <: TAGGED >> REFANY. >> >> This way, tagged references only need a run-time test for the tag on >> dereference (we can throw an "attempt to dereference TAGGED INTEGER" >> at run time, just like we throw "attempt to dereference NIL" for >> untagged references). This check can be a straightforward test of the >> low bit tag. Of course, the weird thing here is now that we don't >> have a single NULL value for TAGGED references --- we have multiple >> null values VAL(x, TAGGED INTEGER). Instead of asking "x == NIL" we >> must ask "ISTYPE(x, TAGGED INTEGER)". >> >> Of course, because TAGGED INTEGER is an ordinal, we can also perform >> the usual ordinal operations like INC(x), DEC(x), wherever x is typed >> TAGGED INTEGER. >> From hendrik at topoi.pooq.com Tue Apr 7 23:28:53 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 7 Apr 2009 17:28:53 -0400 Subject: [M3devel] small objects In-Reply-To: <200904071712.n37HCtda030844@camembert.async.caltech.edu> References: <200904071712.n37HCtda030844@camembert.async.caltech.edu> Message-ID: <20090407212853.GB32252@topoi.pooq.com> On Tue, Apr 07, 2009 at 10:12:55AM -0700, Mika Nystrom wrote: > Tony, > > I think you have convinced me that what you say is workable. > > However I share Hendrik's concern that using RT0.RefanyTypecode > might hurt some day in the future, even if I think you have shown > pretty convincingly that it doesn't hurt today. I share this concern :-) > How about my "second > proposal". Do pretty much what you suggest but instead of returning > RT0.RefanyTypecode, return TYPECODE(TaggedInteger.T), where > TaggedInteger.T is an object type that is declared entirely privately > to the TaggedInteger unsafe module... this also gives a completely > obvious implementation for pickling the tagged integers. Simply > convert them to TaggedInteger.T and pickle that. An implementation > that doesn't support tagged integers in pointers could also allocate > "real" TaggedInteger.Ts.... not sure that is useful though or if > it just confuses. Actually I think it is useful, because it lets > you represent the values even if unpickling in a system that doesn't > support tagged integers in REFANYs. That may even work. It would take some thinking to be sure it always works, though. And ... could the "real" TaggedInteger.T's be used even when the integers that would be packed into pointers end up being out-of-bounds? > > I would go so far as saying this... I believe it is possible to > guarantee that any safe code outside of the TaggedInteger module > couldn't distinguish between a REFANY that holds a tagged integer > vs. one that holds a reference to a (heap-allocated) TaggedInteger.T. > How's that for not breaking the language definition? I agree. > > Hendrik, I think Tony's and my arguments that you can't break any > existing code by allowing the squirreling away of integers into > REFANYs are pretty solid. Pre-existing code simply can't do anything > useful with unrevealed REFANYs. There are also good reasons for > permitting this oddness (vide Smalltalk and Scheme small integers). > > Mika From hendrik at topoi.pooq.com Tue Apr 7 23:31:12 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 7 Apr 2009 17:31:12 -0400 Subject: [M3devel] small objects In-Reply-To: <49DB7B44.2000000@cox.net> References: <200903300333.n2U3XBME062502@camembert.async.caltech.edu> <49D95E70.6000004@wichita.edu> <40B7AD71-FBDD-4321-837F-D294DD4A3D45@cs.purdue.edu> <49DB7B44.2000000@cox.net> Message-ID: <20090407213112.GC32252@topoi.pooq.com> On Tue, Apr 07, 2009 at 11:11:48AM -0500, Rodney M. Bates wrote: > > A separate issue: > > On the INTEGER side of this, I think we need a builtin type that is an > implementation-defined subrange of INTEGER, that can hold just the > integer values a tagged type can hold. Maybe "TAG"? (Actually, this > name is a poor choice, since it's not the tag itself, but it's the best > I can think right now, so I will use it in discussion). Choosing good names is always difficult. -- hendrik From mika at async.caltech.edu Wed Apr 8 00:14:08 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 07 Apr 2009 15:14:08 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Tue, 07 Apr 2009 17:25:25 EDT." <20090407212524.GA32252@topoi.pooq.com> Message-ID: <200904072214.n37ME8Pj039105@camembert.async.caltech.edu> > >I'm inclined to accept these arguments. Now it's time to come up with >really good names for these things. > >-- hendrik Smalltalk punnily calls them "SmallIntegers". In Scheme they are "fixnums". Oh... I should add, if Tony can figure out a way to do what I proposed, an advantage of providing the interface is that a trivial, safe implementation can be used for compatibility with older compilers. (Yes I still sometimes use PM3 even though I am in fact slowly converting.) Mika From jay.krell at cornell.edu Wed Apr 8 03:03:06 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 8 Apr 2009 01:03:06 +0000 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: <20090406175119.5nknbzf9dwkcwkks@mail.elegosoft.com> References: <200904061532.n36FWunc087102@camembert.async.caltech.edu> <20090406175119.5nknbzf9dwkcwkks@mail.elegosoft.com> Message-ID: Relinking upon install I still think provides desired results and is not a terrible idea, but it is more work to implement. I think the perf is probably acceptable. I don't like to expose too many options to uninformed users, but making this an option might be good. It will have an acceptable default, which makes it being an option much less bad. It's not just one option. There is: 1) using the local machine's install point -- /usr/local/cm3/lib, 2) vs. using $ORIGIN/../lib. Not available on all systems. 3) vs. using package store paths 4) vs. using source tree paths and they can be combined, in various orders. Plus Darwin is different, though maybe Darwin 10.5 is the same. (certainly not pre-10.5 though). I also still think this is related to "buildlocal" vs. " buildship". In fact that is already partly accounted for. I think I didn't understand the full state of things. [I think] You were always getting big runpaths. [I think] They were either to installed libraries or uninstalled libraries. If they were to uinstalled binaries, you could not ship -- buildlocal. [I think] Now we are moving toward always small runpaths, always pointing to installed libraries. This is dubious for buildlocal. [I think] Buildlocal should probably retain its old behavior -- big runpaths, into the source tree. Or maybe a list of paths, source tree followed by install tree. So user might build some of his own shared libraries, but not necessarily all. I should set that -Wl,-R thing based on local vs. global. I didn't look into how to detect that. More later. Yes, this is a more general question of how to find dependant shared libraries. I don't think anyone has solved it all that well, nor do I believe we will, but there are still some better and worse options. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.m.bates at cox.net Wed Apr 8 03:49:46 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Tue, 07 Apr 2009 20:49:46 -0500 Subject: [M3devel] small objects In-Reply-To: <200904071712.n37HCtda030844@camembert.async.caltech.edu> References: <200904071712.n37HCtda030844@camembert.async.caltech.edu> Message-ID: <49DC02BA.8080900@cox.net> Mika Nystrom wrote: > Tony, > > I think you have convinced me that what you say is workable. > > However I share Hendrik's concern that using RT0.RefanyTypecode > might hurt some day in the future, even if I think you have shown > pretty convincingly that it doesn't hurt today. How about my "second > proposal". Do pretty much what you suggest but instead of returning > RT0.RefanyTypecode, return TYPECODE(TaggedInteger.T), where > TaggedInteger.T is an object type that is declared entirely privately > to the TaggedInteger unsafe module... this also gives a completely > obvious implementation for pickling the tagged integers. Simply > convert them to TaggedInteger.T and pickle that. An implementation > that doesn't support tagged integers in pointers could also allocate > "real" TaggedInteger.Ts.... not sure that is useful though or if > it just confuses. Actually I think it is useful, because it lets > you represent the values even if unpickling in a system that doesn't > support tagged integers in REFANYs. > > I would go so far as saying this... I believe it is possible to > guarantee that any safe code outside of the TaggedInteger module > couldn't distinguish between a REFANY that holds a tagged integer > vs. one that holds a reference to a (heap-allocated) TaggedInteger.T. > How's that for not breaking the language definition? > > Hendrik, I think Tony's and my arguments that you can't break any > existing code by allowing the squirreling away of integers into > REFANYs are pretty solid. Pre-existing code simply can't do anything > useful with unrevealed REFANYs. This is only true of _unrevealed opaque subtypes_ of REFANY, not of REFANY itself. There is lots of existing code that uses REFANY, and there, ISTYPE, NARROW, TYPECASE, and assigment can be and regularly are used on it. It is essential not to alter the semantics there. Aside from actual semantic changes, I agree with Tony that we should not burden any existing type with additional runtime work. Even though I expect small objects to support big performance gains in certain important cases, non-tagged references will still greatly predominate in most code. Create new type(s) for tagged references. > There are also good reasons for > permitting this oddness (vide Smalltalk and Scheme small integers). > From hosking at cs.purdue.edu Wed Apr 8 04:26:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 8 Apr 2009 12:26:57 +1000 Subject: [M3devel] small objects In-Reply-To: <49DC02BA.8080900@cox.net> References: <200904071712.n37HCtda030844@camembert.async.caltech.edu> <49DC02BA.8080900@cox.net> Message-ID: <3B067900-F4D0-430A-A328-38C1F548B97F@cs.purdue.edu> On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: > Mika Nystrom wrote: >> >> Hendrik, I think Tony's and my arguments that you can't break any >> existing code by allowing the squirreling away of integers into >> REFANYs are pretty solid. Pre-existing code simply can't do anything >> useful with unrevealed REFANYs. > > This is only true of _unrevealed opaque subtypes_ of REFANY, > not of REFANY itself. There is lots of existing code that uses > REFANY, > and there, ISTYPE, NARROW, TYPECASE, and assigment can be and > regularly are used on it. It is essential not to alter the > semantics there. Pre-existing code won't be able to do anything useful with tagged REFANYs: Suppose we have VAR r: REFANY = SmallInteger.FromInt(0); then ISTYPE(r, REFANY) => TRUE ISTYPE(r, T) => FALSE for any T # REFANY Similarly, for TYPECASE, r will only trigger the REFANY branch. NARROW(r, REFANY) => r NARROW(r, T) => run-time error for any T #REFANY VAR x: REFANY => assignment succeeds VAR x: T := r => run-time error for any T # REFANY (because of implicit NARROW) It is impossible to dereference an expression statically typed as REFANY, so there is no need for a "tagged" check on dereference. Because a tagged REFANY cannot be assigned to anything other than something typed REFANY, it can never propagate to a place where it can be dereferenced. > Aside from actual semantic changes, I agree with Tony that we should > not burden any existing type with additional runtime work. Even > though > I expect small objects to support big performance gains in certain > important cases, non-tagged references will still greatly predominate > in most code. Create new type(s) for tagged references. I'm not sure that we are seeing any semantic changes at all. And with Mika's definition of SmallInteger.T as a "boxed" INTEGER object (actually it would be a subrange for values that fit into BITSIZE(Word.T)-1 bits), it is essentially transparent. It just happens to be a run-time optimization that unboxes the INTEGER value. I think I can implement the compiler and run-time support for this very quickly. From mika at async.caltech.edu Wed Apr 8 05:22:21 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 07 Apr 2009 20:22:21 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Wed, 08 Apr 2009 12:26:57 +1000." <3B067900-F4D0-430A-A328-38C1F548B97F@cs.purdue.edu> Message-ID: <200904080322.n383MLuu048696@camembert.async.caltech.edu> Tony Hosking writes: ... > >It is impossible to dereference an expression statically typed as >REFANY, so there is no need for a "tagged" check on dereference. >Because a tagged REFANY cannot be assigned to anything other than >something typed REFANY, it can never propagate to a place where it can >be dereferenced. ... But it's correct, isn't it, that you get an extra one-bit check for ISTYPE, TYPECASE, TYPECODE, and NARROW? There's no problem with dereferencing, nor is there a problem with assignment. No need to introduce overhead for either of those, since dereferencing can't happen and assignment is transparent (or an implicit NARROW). I was going to say to Rodney that I think that Modula-3 programmers know that using REFANY does cause some overhead (it must), and in any case the normal ISTYPE code is going to be hundreds of times slower than the single-bit check, and no one (except me) seems to have had any problem with this so far. So yes, the change does affect existing code, but only code that's already using REFANY, ISTYPE, TYPECASE, and the extra overhead is very minor compared to the work ISTYPE and TYPECASE are already doing. I think I really like the idea of boxing it in this other opaque type if that doesn't cause any problems, specifically because it doesn't make any semantic change to the language at all. Actually, it is important for the application of embedded interpreters that these tagged types be compatible with a standard REFANY. The whole point is to be able to write a fast interpreter that deals in normal Modula-3 types and not in a special parallel hierarchy... Look at how the various languages embedded in Java (JScheme, Groovy, Jython(?)) do these things: it's really pretty nifty. But *they* can't do efficient small integers! Mika From hendrik at topoi.pooq.com Wed Apr 8 05:38:04 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 7 Apr 2009 23:38:04 -0400 Subject: [M3devel] small objects In-Reply-To: <92E0969B-63C7-43BE-A501-B78A5E520B55@cs.purdue.edu> References: <200904062003.n36K3381094096@camembert.async.caltech.edu> <92E0969B-63C7-43BE-A501-B78A5E520B55@cs.purdue.edu> Message-ID: <20090408033804.GA2137@topoi.pooq.com> On Tue, Apr 07, 2009 at 12:03:35PM +1000, Tony Hosking wrote: > On 7 Apr 2009, at 06:03, Mika Nystrom wrote: > > > >Yes I think maybe this is what Tony is worried about. But let's > >just change the definition of REFANY to include anything with the > >LSB set...? > > But then a "NULL" check needs to both test for zero and test for lsb > set. I am not comfortable with this. Nor am I, for both efficiency and conceptual reasons. AN INTEGER isn't a reference, and we shouldn't treat it as if it were. So I'd like a separate type. REFANY is for references. It's bad enough that NIL is in there, too. Except for major incompatibility with almost all past software, I'd like to consider having separate types for pointers that can be NIL and those that can't. But that's too much a deviation from the existing language (and cause all kinds of troubles with variables that are declared before they are initialised, a discussion I've had here sometime last year). -- hendrik. From hendrik at topoi.pooq.com Wed Apr 8 05:42:26 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 7 Apr 2009 23:42:26 -0400 Subject: [M3devel] small objects In-Reply-To: <3B067900-F4D0-430A-A328-38C1F548B97F@cs.purdue.edu> References: <200904071712.n37HCtda030844@camembert.async.caltech.edu> <49DC02BA.8080900@cox.net> <3B067900-F4D0-430A-A328-38C1F548B97F@cs.purdue.edu> Message-ID: <20090408034226.GB2137@topoi.pooq.com> On Wed, Apr 08, 2009 at 12:26:57PM +1000, Tony Hosking wrote: > > I'm not sure that we are seeing any semantic changes at all. And with > Mika's definition of SmallInteger.T as a "boxed" INTEGER object > (actually it would be a subrange for values that fit into > BITSIZE(Word.T)-1 bits), it is essentially transparent. It just > happens to be a run-time optimization that unboxes the INTEGER value. You should also be able to box a CARDINAL. Isn't that a subrange of integers that can be encoded in the right bit width? Hardwarewise, it would be decoded with a logical shift instead of an arithmetic shift. -- hendrik P.S. Apologies for the word "Hardwarewise". It's late here, and I don't have enough brain left for both English and technical content. -- hendrik From mika at async.caltech.edu Wed Apr 8 05:51:24 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 07 Apr 2009 20:51:24 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Tue, 07 Apr 2009 23:42:26 EDT." <20090408034226.GB2137@topoi.pooq.com> Message-ID: <200904080351.n383pOeR049888@camembert.async.caltech.edu> hendrik at topoi.pooq.com writes: >On Wed, Apr 08, 2009 at 12:26:57PM +1000, Tony Hosking wrote: >> >> I'm not sure that we are seeing any semantic changes at all. And with >> Mika's definition of SmallInteger.T as a "boxed" INTEGER object >> (actually it would be a subrange for values that fit into >> BITSIZE(Word.T)-1 bits), it is essentially transparent. It just >> happens to be a run-time optimization that unboxes the INTEGER value. > >You should also be able to box a CARDINAL. Isn't that a subrange of >integers that can be encoded in the right bit width? Hardwarewise, it >would be decoded with a logical shift instead of an arithmetic shift. I think you can do either, but not both... a REFANY containing 0xffffffff stands for either the boxed CARDINAL 2,147,483,647 or the boxed INTEGER -1. It can't really be both... I think INTEGERs are more useful, since you can get [0..2^30-1] in there? > >-- hendrik > >P.S. Apologies for the word "Hardwarewise". It's late here, and I >don't have enough brain left for both English and technical content. > >-- hendrik From hosking at cs.purdue.edu Wed Apr 8 05:55:00 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 8 Apr 2009 13:55:00 +1000 Subject: [M3devel] small objects In-Reply-To: <200904080322.n383MLuu048696@camembert.async.caltech.edu> References: <200904080322.n383MLuu048696@camembert.async.caltech.edu> Message-ID: <5B98E111-7E4F-4FC7-9B8C-2281CEBCDE6C@cs.purdue.edu> On 8 Apr 2009, at 13:22, Mika Nystrom wrote: > Tony Hosking writes: > ... >> >> It is impossible to dereference an expression statically typed as >> REFANY, so there is no need for a "tagged" check on dereference. >> Because a tagged REFANY cannot be assigned to anything other than >> something typed REFANY, it can never propagate to a place where it >> can >> be dereferenced. > ... > > But it's correct, isn't it, that you get an extra one-bit check for > ISTYPE, TYPECASE, TYPECODE, and NARROW? There's no problem with > dereferencing, nor is there a problem with assignment. No need to > introduce overhead for either of those, since dereferencing can't > happen and assignment is transparent (or an implicit NARROW). Correct. > I was going to say to Rodney that I think that Modula-3 programmers > know that using REFANY does cause some overhead (it must), and in > any case the normal ISTYPE code is going to be hundreds of times > slower than the single-bit check, and no one (except me) seems to > have had any problem with this so far. Right. > So yes, the change does affect existing code, but only code that's > already using REFANY, ISTYPE, TYPECASE, and the extra overhead is > very minor compared to the work ISTYPE and TYPECASE are already > doing. It affects only performance. Existing code won't know about SmallInteger.T, so will never test for that type. > I think I really like the idea of boxing it in this other opaque > type if that doesn't cause any problems, specifically because it > doesn't make any semantic change to the language at all. Yeah. It should probably be BRANDED REF [FIRST(INTEGER) DIV 2 .. LAST(INTEGER) DIV 2] instead of an object type. I don't want to think about having "builtin" methods that apply to this type. I'd rather implement it like the builtin Word.T operations. I think the following interface is about right: INTERFACE ValRef; TYPE T <: REFANY; CONST First = FIRST(INTEGER) DIV 2; Last = LAST(INTEGER) DIV 2; TYPE Range = [First .. Last]; PROCEDURE New(val: Range): T; PROCEDURE Val(ref: T): Range; END ValRef. On further thought, the notion that someone could do RTAllocator.NewTraced(TYPECODE(ValRef.T)) makes me a little nervous. We would need to intercept that in RTAllocator.NewTraced and return ValRef.New(0). Of course, there is no way to create any ValRef.T that has a value other than 0 in this way. The pickler would need to have a pickle special for TYPECODE(ValRef.T) that simply extracts the value as the pickled representation, and invokes ValRef.New(value) when unpickliing. > Actually, it is important for the application of embedded interpreters > that these tagged types be compatible with a standard REFANY. The > whole point is to be able to write a fast interpreter that deals > in normal Modula-3 types and not in a special parallel hierarchy... > Look at how the various languages embedded in Java (JScheme, Groovy, > Jython(?)) do these things: it's really pretty nifty. But *they* > can't do efficient small integers! Indeed. From hendrik at topoi.pooq.com Wed Apr 8 05:54:20 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 7 Apr 2009 23:54:20 -0400 Subject: [M3devel] trackOutside and trackOffScreen behave strangely. Message-ID: <20090408035419.GA2391@topoi.pooq.com> I'm trying to track the mouse. I set a cage like: VBT.SetCage(self, VBT.CageFromPosition(cd.cp, trackOutside := TRUE)); and it would not track the mouse when it was outside my window, but still on the screen. But when I coded VBT.SetCage(self, VBT.CageFromPosition(cd.cp, trackOutside := TRUE, trackOffScreen := TRUE)); it suddenly started tracking properly, following the mouse outside the window. The mouse pointer never left the screen during either test. It can't. In case it makes a difference, I'm using icewm on Xorg on a Debian Lenny system on an 32-bit AMD processor. -- hendrik. From wagner at elegosoft.com Wed Apr 8 08:43:32 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 08 Apr 2009 08:43:32 +0200 Subject: [M3devel] installation archives for AMD64_LINUX for test and tinderbox status Message-ID: <20090408084332.k76kazqnc4804cwc@mail.elegosoft.com> I've made some small extensions to the installer and to the packaging script make-bin-dist-min.sh (which is now wrongly named), so that they both use Jay's new style config files by default. The old behaviour is still available with some switches. The archives are in the uploaded-archives section of www.opencm3.net: -rw-rw-r-- 1 wagner m3 24568485 2009-04-08 08:24 cm3-bin-core-POSIX-AMD64_LINUX-d5.7.1.tgz -rw-rw-r-- 1 wagner m3 59741158 2009-04-08 08:24 cm3-bin-std-POSIX-AMD64_LINUX-d5.7.1.tgz I haven't really tested them; would anybody care to try one of these? They are rather huge; one contains the core distribution and one the complete std package set in binary format. But it seems to be consensus that large archives containing everything is preferred to small archives with more complex installation. I know that the cminstall program doesn't now do much except copying the files to their destination and checking for diskspace (which may still be wrong, by the way), but it still _could_ also perform customizations and install patches etc. So it's no big overhead, and this way the migration will be easier especially regarding the automated regression scripts. If nobody objects, we can use these for a new release in some weeks. If you think this isn't really useful, please don't hesitate to say so, too. Regarding tinderbox, I haven't been able to log into the administration pages yet, but Michael will surely fix that today. Some basic things are working, but some documentation and configuraion seems to be lost. I'll see what I can restore. I'll be on holiday starting tomorrow, but I'll take my notebook with me and hope for some good connections ;-) CVSup isn't installed yet, which is why the FreeBSD tests from Elego are still missing. Michael will probably work on it next week. Thanks for your help and patience, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From carson at taltos.org Wed Apr 8 11:39:18 2009 From: carson at taltos.org (Carson Gaspar) Date: Wed, 08 Apr 2009 02:39:18 -0700 Subject: [M3devel] What happened to Utypes.i3? Message-ID: <49DC70C6.1000600@taltos.org> Trying to use the recently uploaded 5.7.1 Linux packages, Utypes.i3 has been gutted. Breaking cvsup. Again. Specifically, dev_t, mode_t, ino_t, etc. are all gone. Can someone comment on what's going on with these interfaces? Is there a method behind the path of destruction being left? -- Carson From jay.krell at cornell.edu Wed Apr 8 12:44:09 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 8 Apr 2009 10:44:09 +0000 Subject: [M3devel] What happened to Utypes.i3? In-Reply-To: <49DC70C6.1000600@taltos.org> References: <49DC70C6.1000600@taltos.org> Message-ID: m3-libs/m3core/src/Unix/*/*.i3 was a very large chunk of tedious error-prone dangerous (if errors occur) mostly dead platform specific code. It was one of the largest things to work on when porting to a new platform, and largely wasted work. (The other pieces are debugging whatever goes wrong, that's about it, porting is often pretty easy..) It is drastically reduced now, and often replaced by much safer C code. There is still a little more to do here. dev_t, mode_t, ino_t, were mosty only used along with stat. Those uses are gone. This is the exact danger however -- of breaking Modula-3 code outside the cm3 tree, that uses "low level" non-Modula-3 interfaces. Anything that just uses the higher level Modula-3 interfaces is not broken. I'll have to look at cvsup and see if it is easy to make the same sort of transform -- replace small pieces of Modula-3 that are dependent on tedious error prone Modula-3 with small portable C wrappers. If the only problem is really those three types, they can be restored, reluctantly. I'd much rather change cvsup to not use them. - Jay > Date: Wed, 8 Apr 2009 02:39:18 -0700 > From: carson at taltos.org > To: m3devel at elegosoft.com > Subject: [M3devel] What happened to Utypes.i3? > > Trying to use the recently uploaded 5.7.1 Linux packages, Utypes.i3 has > been gutted. Breaking cvsup. Again. Specifically, dev_t, mode_t, ino_t, > etc. are all gone. > > Can someone comment on what's going on with these interfaces? Is there a > method behind the path of destruction being left? > > -- > Carson -------------- next part -------------- An HTML attachment was scrubbed... URL: From carson at taltos.org Wed Apr 8 12:57:11 2009 From: carson at taltos.org (Carson Gaspar) Date: Wed, 08 Apr 2009 03:57:11 -0700 Subject: [M3devel] What happened to Utypes.i3? In-Reply-To: <49DC70C6.1000600@taltos.org> References: <49DC70C6.1000600@taltos.org> Message-ID: <49DC8307.7060906@taltos.org> Similarly, 5.7.0 and 5.7.1 are both missing TextF.i3, also breaking cvsup. *sigh* Carson Gaspar wrote: > Trying to use the recently uploaded 5.7.1 Linux packages, Utypes.i3 has > been gutted. Breaking cvsup. Again. Specifically, dev_t, mode_t, ino_t, > etc. are all gone. > > Can someone comment on what's going on with these interfaces? Is there a > method behind the path of destruction being left? > From carson at taltos.org Wed Apr 8 13:04:48 2009 From: carson at taltos.org (Carson Gaspar) Date: Wed, 08 Apr 2009 04:04:48 -0700 Subject: [M3devel] What happened to Utypes.i3? In-Reply-To: References: <49DC70C6.1000600@taltos.org> Message-ID: <49DC84D0.4030701@taltos.org> Jay wrote: > I'll have to look at cvsup and see if it is easy to make the same sort > of transform -- replace small pieces of Modula-3 that are dependent on > tedious error prone Modula-3 with small portable C wrappers. > > If the only problem is really those three types, they can be restored, > reluctantly. > I'd much rather change cvsup to not use them. The problems are larger that just those, sadly, as a build attempt will quickly reveal. The universe would be very happy to have a working, maintained modula-3 compiler that would build cvsup. Whether that involves more patches to cvsup or changes to cm3, either way it would be a Good Thing(tm). Sadly, my almost non-extant modula-3 foo isn't up to the task, or I'd volunteer. Given my deadlines, I'm going to punt and try and get 5.4.0 to work and give up a clean 64-bit version. -- Carson From jay.krell at cornell.edu Wed Apr 8 14:27:21 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 8 Apr 2009 12:27:21 +0000 Subject: [M3devel] What happened to Utypes.i3? In-Reply-To: <49DC8307.7060906@taltos.org> References: <49DC70C6.1000600@taltos.org> <49DC8307.7060906@taltos.org> Message-ID: I thought TextF got deleted way back in 4.1, when Unicode support came in. I can look later...probably not Wednesday or Thursday though. - Jay > Date: Wed, 8 Apr 2009 03:57:11 -0700 > From: carson at taltos.org > To: m3devel at elegosoft.com > Subject: Re: [M3devel] What happened to Utypes.i3? > > Similarly, 5.7.0 and 5.7.1 are both missing TextF.i3, also breaking > cvsup. *sigh* > > Carson Gaspar wrote: > > Trying to use the recently uploaded 5.7.1 Linux packages, Utypes.i3 has > > been gutted. Breaking cvsup. Again. Specifically, dev_t, mode_t, ino_t, > > etc. are all gone. > > > > Can someone comment on what's going on with these interfaces? Is there a > > method behind the path of destruction being left? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carson at taltos.org Wed Apr 8 14:42:36 2009 From: carson at taltos.org (Carson Gaspar) Date: Wed, 08 Apr 2009 05:42:36 -0700 Subject: [M3devel] What happened to Utypes.i3? In-Reply-To: References: <49DC70C6.1000600@taltos.org> <49DC8307.7060906@taltos.org> Message-ID: <49DC9BBC.5040600@taltos.org> Jay wrote: > I thought TextF got deleted way back in 4.1, when Unicode support came in. > I can look later...probably not Wednesday or Thursday though. It's in my 31-Jan-2009 CVS checkout... and is in the 5.4.0 tarball. -- Carson From wagner at elegosoft.com Wed Apr 8 14:51:15 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 08 Apr 2009 14:51:15 +0200 Subject: [M3devel] runpath/unshipped vs. shipped binaries In-Reply-To: References: <200904061532.n36FWunc087102@camembert.async.caltech.edu> <20090406175119.5nknbzf9dwkcwkks@mail.elegosoft.com> Message-ID: <20090408145115.hgx4t0to0o4s0gg0@mail.elegosoft.com> Quoting Jay : > > Relinking upon install I still think provides desired results and > is not a terrible idea, but it is more work to implement. > I think the perf is probably acceptable. > > I don't like to expose too many options to uninformed users, but > making this an option might be good. It will have an acceptable default, > which makes it being an option much less bad. I'm still not convinced that this is the correct behaviour. I find the whole concept of fixed location paths questionable. I'll have to relink my libraries for every location change. Seems simply wrong to me :-/ > It's not just one option. > There is: > 1) using the local machine's install point -- /usr/local/cm3/lib, > 2) vs. using $ORIGIN/../lib. > Not available on all systems. > 3) vs. using package store paths This should be the default IMHO. And no relinking by default. Better still remove the paths completely from the libraries. Others will probably disagree ;-) Olaf > 4) vs. using source tree paths > > > > > and they can be combined, in various orders. > > > > > Plus Darwin is different, though maybe Darwin 10.5 is the same. > (certainly not pre-10.5 though). > > > > > > I also still think this is related to "buildlocal" vs. " buildship". > In fact that is already partly accounted for. > > > > > I think I didn't understand the full state of things. > > > > > [I think] You were always getting big runpaths. > [I think] They were either to installed libraries or uninstalled libraries. > > If they were to uinstalled binaries, you could not ship -- buildlocal. > [I think] Now we are moving toward always small runpaths, always > pointing to installed libraries. This is dubious for buildlocal. > > > > > [I think] Buildlocal should probably retain its old behavior -- big > runpaths, into > the source tree. Or maybe a list of paths, source tree followed by > install tree. > So user might build some of his own shared libraries, but not > necessarily all. > > > > > I should set that -Wl,-R thing based on local vs. global. > I didn't look into how to detect that. > > > > > More later. > > > > > > Yes, this is a more general question of how to find dependant shared > libraries. > > I don't think anyone has solved it all that well, nor do I believe > we will, but there are still some better and worse options. > > > > > - 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 Wed Apr 8 22:08:09 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 08 Apr 2009 15:08:09 -0500 Subject: [M3devel] small objects Message-ID: <49DD0429.5000306@cox.net> Here are two integrated proposals for language changes to allow small objects, while preserving the principles of the language. Neither of them changes the semantics of any existing type or burdens any existing code with extra runtime computation. The unsafe proposal: This is a much simpler proposal. It could also be used in more general ways than just using a tag bit to distinguish a true pointer from an in-word value. This is at the cost of requiring unsafe coding techniques in a module implementing the abstraction, which also inevitably means implementation-dependent too. Using it for small objects as discussed still requires the garbage collector not to be confused by trying to trace a reference with a misaligned value. There is a new builtin type OPAQUE. The only things you can do with it in safe code are copy values around (assigment, pass by VALUE, RETURN, etc.) and make reference bindings to it (pass by reference, WITH bindings). Not that this ia a _lot_ more opaque than opaque types. OPAQUE is known to be the same size as Word.T. In unsafe code, you can use this fact to LOOPHOLE it to anything you want and bit-twiddle to your heart's content from there. So an unsafe module could implement procedures that take OPAQUE parameters. Variation: Allow an opaque subtype of OPAQUE, which can be revealed to be any type with statically the same size. This would make it possible to prevent client code from mixing up two different unrelated abstractions that both happened to use OPAQUE. In fact, without this, the proposal really fails to preserve the existing principles of safe/unsafe code. This would require that the revelation be BRANDED, which would either mean restricting the revelation to a reference type (which could still be LOOPHOLEd to anything else) or allowing other types to be BRANDED. Example: INTERFACE ADT; TYPE T <: OPAQUE; PROCEDURE P (x:T); ... END ADT UNSAFE MODULE ADT; TYPE R = RECORD ... END; REVEAL T = BRANDED REF R; PROCEDURE P (x:T) VAR I: INTEGER; BEGIN IF LOOPHOLE(x,INTEGER) MOD 2 # 0 THEN I := Word.Shift(LOOPHOLE(x,INTEGER),-1); (* Use integer value I ... *) ELSE (* Use reference value x, according to its declared type. Prior to the check above, we couldn't afford to risk doing anything with it. ... *) END (* IF *); END P; ... END ADT; The safe proposal: This is more complicated and less general, but allows small object abstractions to be done in an entirely safe and implementation- independent way. It abstracts away all the bit-level representation questions. There is a new type TAG, which is a subrange of INTEGER, with implementation-defined bounds (which would then be accessible by FIRST/LAST). There is a new type constructor TAGGED. If T is any traced reference type or any untraced object type, TAGGED T defines a type, called a _tagged_ type, whose value set is the union of the value sets of TAG and T. TAG <: TAGGED T and T <: TAGGED T. There are no other subtype relations involving TAGGED T. Values of a tagged type can be copied and bound-to. The static rules for ISTYPE, NARROW, TYPECASE, and assignability of a type to a type are liberalized to allow their application to a tagged type, and to allow the type to be checked/converted-to to be any subtype of the tagged type. Already existing rules would require a runtime check that the value is a member of the stated type. No other operations are possible on a tagged type. A tagged type is not a reference type and does not have a typecode. Example: INTERFACE ADT; TYPE Op <: REFANY; TYPE T = TAGGED Op; PROCEDURE P (x:T); ... END ADT MODULE ADT; TYPE R = RECORD ... END; REVEAL Op = BRANDED REF R; PROCEDURE P (x:T) BEGIN TYPECASE x OF TAG (I) => (* Use integer value I ... *) | Op (RR) => (* Use reference value RR ... *) END (* IF *); END P; ... END ADT; Note: TAG is like CARDINAL in that it is "just like" a subrange of INTEGER, but not equal to that subrange. This enabled pickles to change the size of values of type TAG and of tagged types, as it now does with CARDINAL. Variation: The 4 runtime-checking operations can also be applied to any ordinal type and can check that an ordinal or tagged type has a value belonging to any subrange of the base type (or maybe just of the type being narrowed). This is pure fluff (well, maybe it is syntactic sugar), but adds some consistency and has a real use: How many times have I coded the following? IF FIRST(SomeOrdinalType <= x AND x <= LAST(SomeOrdinalType) THEN ... or worse, IF FIRST(SomeOrdinalType <= F(x) AND F(x) <= LAST(SomeOrdinalType) THEN ... which I then feel morally obligated to recode using a local variable or WITH-temp to eliminate the duplicated calls F(x). It could then become: IF ISTYPE (F(x), SomeOrdinalType) THEN ... From rodney.m.bates at cox.net Wed Apr 8 22:13:33 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 08 Apr 2009 15:13:33 -0500 Subject: [M3devel] What happened to Utypes.i3? In-Reply-To: References: <49DC70C6.1000600@taltos.org> <49DC8307.7060906@taltos.org> Message-ID: <49DD056D.5050205@cox.net> TextF is still sitting out there in the CM3 repository, but what it declares is a lie in CM3. If you try to use it to compile code that assumes the PM3 text representation in CM3, something bad will surely happen. Probably a link-time failure because of contradictory revelations, or something. Such code will inevitably have to be modified to get it to compile and work in CM3. TextF is also unused in the CM3 repo. Jay wrote: > I thought TextF got deleted way back in 4.1, when Unicode support came in > From rodney.m.bates at cox.net Thu Apr 9 02:15:21 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 08 Apr 2009 19:15:21 -0500 Subject: [M3devel] small objects In-Reply-To: <3B067900-F4D0-430A-A328-38C1F548B97F@cs.purdue.edu> References: <200904071712.n37HCtda030844@camembert.async.caltech.edu> <49DC02BA.8080900@cox.net> <3B067900-F4D0-430A-A328-38C1F548B97F@cs.purdue.edu> Message-ID: <49DD3E19.20209@cox.net> Tony Hosking wrote: > On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: > >> Mika Nystrom wrote: >>> >>> Hendrik, I think Tony's and my arguments that you can't break any >>> existing code by allowing the squirreling away of integers into >>> REFANYs are pretty solid. Pre-existing code simply can't do anything >>> useful with unrevealed REFANYs. >> >> This is only true of _unrevealed opaque subtypes_ of REFANY, >> not of REFANY itself. There is lots of existing code that uses REFANY, >> and there, ISTYPE, NARROW, TYPECASE, and assigment can be and >> regularly are used on it. It is essential not to alter the >> semantics there. > > Pre-existing code won't be able to do anything useful with tagged > REFANYs: > > Suppose we have > > VAR r: REFANY = SmallInteger.FromInt(0); > > then > > ISTYPE(r, REFANY) => TRUE > ISTYPE(r, T) => FALSE for any T # REFANY > > Similarly, for TYPECASE, r will only trigger the REFANY branch. > > NARROW(r, REFANY) => r > NARROW(r, T) => run-time error for any T #REFANY > > VAR x: REFANY => assignment succeeds > VAR x: T := r => run-time error for any T # REFANY (because of > implicit NARROW) I think I am getting a bit lost in all the proposals, variations, counterproposals, etc., but from this argument I am inferring that your plan is that only variables declared REFANY and not any proper subtype of REFANY can ever have a value with a tag bit set? Then the 4 narrowing operations, when and only when applied to an expression of static type REFANY, would change to make a runtime check for a tag bit and fail if it's set? It would take this to prevent a tagged value from getting into a variable declared a proper subtype of REFANY, which can be dereferenced. This would preclude making your abstract data type an opaque subtype of REFANY, and would mean all supposedly unrelated ADT modules that used the tag technique could be broken by client code that mixed up the REFANY values of one of them with those of another. I consider this a definite breach of Modula-3's otherwise bulletproof type safety. > > It is impossible to dereference an expression statically typed as > REFANY, so there is no need for a "tagged" check on dereference. > Because a tagged REFANY cannot be assigned to anything other than > something typed REFANY, it can never propagate to a place where it can > be dereferenced. > >> Aside from actual semantic changes, I agree with Tony that we should >> not burden any existing type with additional runtime work. Even though >> I expect small objects to support big performance gains in certain >> important cases, non-tagged references will still greatly predominate >> in most code. Create new type(s) for tagged references. > > I'm not sure that we are seeing any semantic changes at all. And with > Mika's definition of SmallInteger.T as a "boxed" INTEGER object > (actually it would be a subrange for values that fit into > BITSIZE(Word.T)-1 bits), it is essentially transparent. It just > happens to be a run-time optimization that unboxes the INTEGER value. > > > I think I can implement the compiler and run-time support for this > very quickly. > > From mika at async.caltech.edu Thu Apr 9 02:23:12 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 08 Apr 2009 17:23:12 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Wed, 08 Apr 2009 15:08:09 CDT." <49DD0429.5000306@cox.net> Message-ID: <200904090023.n390NC2b096664@camembert.async.caltech.edu> Hmm, if you're going to do something along these lines, isn't the logical thing to do to introduce a new root of the (traced) type system, that is REFANY <: REFORINT SMALLINT = [MinSmallInteger .. MaxSmallInteger] SMALLINT <: REFORINT a REFORINT can be a REFANY or a small integer. It stands to reason that it is a supertype of REFANY as well as of SMALLINT, because isn't that exactly what we're looking for? The problem with this proposal (as well as both of yours) is that you get to go through and inspect all existing code that takes REFANY and wonder whether maybe it should take REFORINT instead.... The proposal that Tony and I seem to have agreed on, on the other hand, allows the implementation to hide small integers completely transparently in the already existing REFANY, at the cost of an LSB check on a number of operations, such as ISTYPE, TYPECASE, etc., to any REFANY. I maintain the following: I. Since hiding integers in REFANY is intended to be entirely transparent, you could have it as a compile or even run-time option. Yes, ok this is ugly. II.Assume we go with REFORINT, or OPAQUE, or TAGGED. What existing uses of REFANY, in any code of importance, is going to stay REFANY, and what uses will we want to convert to the new types? I would suggest considering the following argument: A. The new types are strictly more useful than REFANY; they can represent more values because they can represent all of REFANY plus other values (after all that was the point all along). B. Existing uses of REFANY are either 1. uses of REFANY because the code is intended to be very generic. Programmers will want to migrate such code to the new type, so that they can process the new type as well (since the code is generic it should work for either). 2. uses of REFANY because the programmer was too lazy to instantiate a generic for his specific type and decided to cast the values to REFANY (e.g., to insert in a RefList) and back. Such programmers deserve what they get. I conclude that code that continues to want to use REFANY rather than the new type is code that is not performance sensitive. Hence, I conclude that using REFANY directly to represent small integers is as reasonable as introducing a new type, and does it with less work, both in updating the language definition and in updating all the libraries in libm3 and elsewhere. What current uses of REFANY do not fit the cases in II.B.? Some trickery to simulate multiple inheritance? Even in those you should have created a common supertype, I think. Mika "Rodney M. Bates" writes: >Here are two integrated proposals for language changes to allow small >objects, while preserving the principles of the language. Neither of >them changes the semantics of any existing type or burdens any >existing code with extra runtime computation. > >The unsafe proposal: > >This is a much simpler proposal. It could also be used in more >general ways than just using a tag bit to distinguish a true pointer >from an in-word value. This is at the cost of requiring unsafe coding >techniques in a module implementing the abstraction, which also >inevitably means implementation-dependent too. Using it for small >objects as discussed still requires the garbage collector not to be >confused by trying to trace a reference with a misaligned value. > >There is a new builtin type OPAQUE. The only things you can do with >it in safe code are copy values around (assigment, pass by VALUE, >RETURN, etc.) and make reference bindings to it (pass by reference, >WITH bindings). Not that this ia a _lot_ more opaque than opaque >types. > >OPAQUE is known to be the same size as Word.T. In unsafe code, you >can use this fact to LOOPHOLE it to anything you want and bit-twiddle >to your heart's content from there. So an unsafe module could >implement procedures that take OPAQUE parameters. > >Variation: > >Allow an opaque subtype of OPAQUE, which can be revealed to be any >type with statically the same size. This would make it possible to >prevent client code from mixing up two different unrelated >abstractions that both happened to use OPAQUE. In fact, without this, >the proposal really fails to preserve the existing principles of >safe/unsafe code. This would require that the revelation be BRANDED, >which would either mean restricting the revelation to a reference type >(which could still be LOOPHOLEd to anything else) or allowing other >types to be BRANDED. > >Example: > >INTERFACE ADT; > TYPE T <: OPAQUE; > PROCEDURE P (x:T); > ... >END ADT > >UNSAFE MODULE ADT; > TYPE R = RECORD ... END; > REVEAL T = BRANDED REF R; > > PROCEDURE P (x:T) > VAR I: INTEGER; > BEGIN > IF LOOPHOLE(x,INTEGER) MOD 2 # 0 > THEN > I := Word.Shift(LOOPHOLE(x,INTEGER),-1); > (* Use integer value I ... *) > ELSE > (* Use reference value x, according to its declared type. > Prior to the check above, we couldn't afford to risk > doing anything with it. ... *) > END (* IF *); > END P; > ... >END ADT; > >The safe proposal: > >This is more complicated and less general, but allows small object >abstractions to be done in an entirely safe and implementation- >independent way. It abstracts away all the bit-level representation >questions. > >There is a new type TAG, which is a subrange of INTEGER, with >implementation-defined bounds (which would then be accessible by >FIRST/LAST). > >There is a new type constructor TAGGED. If T is any traced reference >type or any untraced object type, TAGGED T defines a type, called a >_tagged_ type, whose value set is the union of the value sets of TAG >and T. > >TAG <: TAGGED T and T <: TAGGED T. > >There are no other subtype relations involving TAGGED T. > >Values of a tagged type can be copied and bound-to. > >The static rules for ISTYPE, NARROW, TYPECASE, and assignability of a >type to a type are liberalized to allow their application to a tagged >type, and to allow the type to be checked/converted-to to be any >subtype of the tagged type. Already existing rules would require a >runtime check that the value is a member of the stated type. > >No other operations are possible on a tagged type. A tagged type is >not a reference type and does not have a typecode. > >Example: > >INTERFACE ADT; > TYPE Op <: REFANY; > TYPE T = TAGGED Op; > PROCEDURE P (x:T); > ... >END ADT > >MODULE ADT; > TYPE R = RECORD ... END; > REVEAL Op = BRANDED REF R; > > PROCEDURE P (x:T) > BEGIN > TYPECASE x > OF TAG (I) > => (* Use integer value I ... *) > | Op (RR) > => (* Use reference value RR ... *) > END (* IF *); > END P; > ... >END ADT; > >Note: TAG is like CARDINAL in that it is "just like" a subrange of >INTEGER, but not equal to that subrange. This enabled pickles to >change the size of values of type TAG and of tagged types, as it now >does with CARDINAL. > >Variation: > >The 4 runtime-checking operations can also be applied to any ordinal >type and can check that an ordinal or tagged type has a value >belonging to any subrange of the base type (or maybe just of the type >being narrowed). This is pure fluff (well, maybe it is syntactic >sugar), but adds some consistency and has a real use: > >How many times have I coded the following? > >IF FIRST(SomeOrdinalType <= x AND x <= LAST(SomeOrdinalType) THEN ... > >or worse, > >IF FIRST(SomeOrdinalType <= F(x) AND F(x) <= LAST(SomeOrdinalType) THEN ... > >which I then feel morally obligated to recode using a local variable or >WITH-temp to eliminate the duplicated calls F(x). > >It could then become: > >IF ISTYPE (F(x), SomeOrdinalType) THEN ... > > > > > > From mika at async.caltech.edu Thu Apr 9 02:38:23 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 08 Apr 2009 17:38:23 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Wed, 08 Apr 2009 19:15:21 CDT." <49DD3E19.20209@cox.net> Message-ID: <200904090038.n390cNsg097270@camembert.async.caltech.edu> Hmm, ok, there's one big difference between what you're saying and what Tony and I have been talking about. (I think your understanding sounds pretty correct.) You want to do objects other than small integers. Like what? And why? I was thinking the trick would apply only to one specific type of integer. Hmm, so your idea is to statically determine what type the references can have if they are non-references. So you are thinking to put various kinds of subranges into the "TAGGED" types. But you have to be able to determine, statically, which subrange it is... am I understanding this correctly? Mika "Rodney M. Bates" writes: >Tony Hosking wrote: >> On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: >> >>> Mika Nystrom wrote: >>>> >>>> Hendrik, I think Tony's and my arguments that you can't break any >>>> existing code by allowing the squirreling away of integers into >>>> REFANYs are pretty solid. Pre-existing code simply can't do anything >>>> useful with unrevealed REFANYs. >>> >>> This is only true of _unrevealed opaque subtypes_ of REFANY, >>> not of REFANY itself. There is lots of existing code that uses REFANY, >>> and there, ISTYPE, NARROW, TYPECASE, and assigment can be and >>> regularly are used on it. It is essential not to alter the >>> semantics there. >> >> Pre-existing code won't be able to do anything useful with tagged >> REFANYs: >> >> Suppose we have >> >> VAR r: REFANY = SmallInteger.FromInt(0); >> >> then >> >> ISTYPE(r, REFANY) => TRUE >> ISTYPE(r, T) => FALSE for any T # REFANY >> >> Similarly, for TYPECASE, r will only trigger the REFANY branch. >> >> NARROW(r, REFANY) => r >> NARROW(r, T) => run-time error for any T #REFANY >> >> VAR x: REFANY => assignment succeeds >> VAR x: T := r => run-time error for any T # REFANY (because of >> implicit NARROW) > >I think I am getting a bit lost in all the proposals, variations, >counterproposals, etc., but >from this argument I am inferring that your plan is that only variables >declared REFANY >and not any proper subtype of REFANY can ever have a value with a tag >bit set? Then >the 4 narrowing operations, when and only when applied to an expression >of static >type REFANY, would change to make a runtime check for a tag bit and fail >if it's set? >It would take this to prevent a tagged value from getting into a >variable declared a >proper subtype of REFANY, which can be dereferenced. > >This would preclude making your abstract data type an opaque subtype of >REFANY, >and would mean all supposedly unrelated ADT modules that used the tag >technique >could be broken by client code that mixed up the REFANY values of one of >them with >those of another. I consider this a definite breach of Modula-3's >otherwise bulletproof >type safety. >> >> It is impossible to dereference an expression statically typed as >> REFANY, so there is no need for a "tagged" check on dereference. >> Because a tagged REFANY cannot be assigned to anything other than >> something typed REFANY, it can never propagate to a place where it can >> be dereferenced. >> >>> Aside from actual semantic changes, I agree with Tony that we should >>> not burden any existing type with additional runtime work. Even though >>> I expect small objects to support big performance gains in certain >>> important cases, non-tagged references will still greatly predominate >>> in most code. Create new type(s) for tagged references. >> >> I'm not sure that we are seeing any semantic changes at all. And with >> Mika's definition of SmallInteger.T as a "boxed" INTEGER object >> (actually it would be a subrange for values that fit into >> BITSIZE(Word.T)-1 bits), it is essentially transparent. It just >> happens to be a run-time optimization that unboxes the INTEGER value. >> >> >> I think I can implement the compiler and run-time support for this >> very quickly. >> >> From hosking at cs.purdue.edu Thu Apr 9 03:39:50 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 9 Apr 2009 11:39:50 +1000 Subject: [M3devel] What happened to Utypes.i3? In-Reply-To: <49DD056D.5050205@cox.net> References: <49DC70C6.1000600@taltos.org> <49DC8307.7060906@taltos.org> <49DD056D.5050205@cox.net> Message-ID: <83F0F22E-19BA-493D-9185-2107A92D29C4@cs.purdue.edu> TextF is not part of the installed code-base for m3core. The old source is there, but does not get built. I know I have built CVS up since *after* TextF went away. There were a few minor patches needed. Of course, that was all before Utypes got pruned away. I really don't think it can possibly be too hard to build CVSup against the current CM3 head. Yes, there may be some declarations needed for various Unix foibles, but ideally we could hide those away behind C helper code as Jay suggests. On 9 Apr 2009, at 06:13, Rodney M. Bates wrote: > TextF is still sitting out there in the CM3 repository, but what it > declares is a lie in CM3. If you try to use it to compile code that > assumes the PM3 text representation in CM3, something bad > will surely happen. Probably a link-time failure because of > contradictory revelations, or something. Such code will inevitably > have to be modified to get it to compile and work in CM3. > TextF is also unused in the CM3 repo. > Jay wrote: >> I thought TextF got deleted way back in 4.1, when Unicode support >> came in >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Apr 9 03:51:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 9 Apr 2009 11:51:36 +1000 Subject: [M3devel] small objects In-Reply-To: <49DD3E19.20209@cox.net> References: <200904071712.n37HCtda030844@camembert.async.caltech.edu> <49DC02BA.8080900@cox.net> <3B067900-F4D0-430A-A328-38C1F548B97F@cs.purdue.edu> <49DD3E19.20209@cox.net> Message-ID: <8AA8B3CE-12D0-45E3-8F24-5B2A6FED13CF@cs.purdue.edu> On 9 Apr 2009, at 10:15, Rodney M. Bates wrote: > I think I am getting a bit lost in all the proposals, variations, > counterproposals, etc., but > from this argument I am inferring that your plan is that only > variables declared REFANY > and not any proper subtype of REFANY can ever have a value with a > tag bit set? Then > the 4 narrowing operations, when and only when applied to an > expression of static > type REFANY, would change to make a runtime check for a tag bit and > fail if it's set? > It would take this to prevent a tagged value from getting into a > variable declared a > proper subtype of REFANY, which can be dereferenced. Yes, that's the minimalist proposal that Mika initiated and I refined slightly to handle TYPECODE. > This would preclude making your abstract data type an opaque subtype > of REFANY, > and would mean all supposedly unrelated ADT modules that used the > tag technique > could be broken by client code that mixed up the REFANY values of > one of them with > those of another. I consider this a definite breach of Modula-3's > otherwise bulletproof > type safety. Umm. I don't see how they can "break". Can you offer a scenario? Either a REFANY is tagged or it is not. "Unrelated ADT modules that use the tag technique" would all still work. Are you saying you want a way to stamp out differently typed tagged REFANYs? Seems a little tricky given that we are proposing just a single bit to distinguish tagged from untagged REFANY. Unless you propose a completely static type constructor that stamps out different tagged reference types that are completely unrelated, and cannot be stored in a REFANY? But that breaks the whole purpose of tagging which is to support values embedded in references. From hosking at cs.purdue.edu Thu Apr 9 03:57:35 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 9 Apr 2009 11:57:35 +1000 Subject: [M3devel] small objects In-Reply-To: <200904090023.n390NC2b096664@camembert.async.caltech.edu> References: <200904090023.n390NC2b096664@camembert.async.caltech.edu> Message-ID: Thanks Mika, nicely summarised. I'll just add that from the language design perspective we have made no change. The only thing we are doing is introducing a run-time *optimisation* that allows things that look like: T = BRANDED "SmallInt.T" REF [FIRST(INTEGER) DIV 2.. LAST(INTEGER) DIV 2] to be *represented* by the run-time system as a tagged reference by packing the value into the non-tag bits of the reference. The main thing to protect against is that someone bypasses the opaque definition of this type as <: REFANY and actually allocates a heap value of the above type. The only way to do that is to use RTAllocator.NewTraced(tc) with TYPECODE(T). The run-time system can explicitly check for that in RTAllocator and return a properly tagged reference. On 9 Apr 2009, at 10:23, Mika Nystrom wrote: > Hmm, if you're going to do something along these lines, isn't the > logical > thing to do to introduce a new root of the (traced) type system, that > is > > REFANY <: REFORINT > SMALLINT = [MinSmallInteger .. MaxSmallInteger] > SMALLINT <: REFORINT > > a REFORINT can be a REFANY or a small integer. It stands to reason > that > it is a supertype of REFANY as well as of SMALLINT, because isn't > that exactly what we're looking for? > > The problem with this proposal (as well as both of yours) is that > you get to go through and inspect all existing code that takes > REFANY and wonder whether maybe it should take REFORINT instead.... > > The proposal that Tony and I seem to have agreed on, on the other > hand, allows the implementation to hide small integers completely > transparently in the already existing REFANY, at the cost of an LSB > check on a number of operations, such as ISTYPE, TYPECASE, etc., > to any REFANY. > > I maintain the following: > > I. Since hiding integers in REFANY is intended to be entirely > transparent, you could have it as a compile or even run-time > option. Yes, ok this is ugly. > > II.Assume we go with REFORINT, or OPAQUE, or TAGGED. What existing > uses of REFANY, in any code of importance, is going to stay > REFANY, and what uses will we want to convert to the new types? > > I would suggest considering the following argument: > > A. The new types are strictly more useful than REFANY; they can > represent more values because they can represent all of REFANY > plus other values (after all that was the point all along). > > B. Existing uses of REFANY are either > 1. uses of REFANY because the code is intended to be very generic. > Programmers will want to migrate such code to the new type, > so that they can process the new type as well (since the code > is > generic it should work for either). > 2. uses of REFANY because the programmer was too lazy to > instantiate > a generic for his specific type and decided to cast the values > to REFANY (e.g., to insert in a RefList) and back. Such > programmers > deserve what they get. > > I conclude that code that continues to want to use REFANY rather > than the new type is code that is not performance sensitive. Hence, > I conclude that using REFANY directly to represent small integers > is as reasonable as introducing a new type, and does it with less > work, > both in updating the language definition and in updating all the > libraries in libm3 and elsewhere. > > What current uses of REFANY do not fit the cases in II.B.? Some > trickery to simulate multiple inheritance? Even in those you should > have created a common supertype, I think. > > Mika > > "Rodney M. Bates" writes: >> Here are two integrated proposals for language changes to allow small >> objects, while preserving the principles of the language. Neither of >> them changes the semantics of any existing type or burdens any >> existing code with extra runtime computation. >> >> The unsafe proposal: >> >> This is a much simpler proposal. It could also be used in more >> general ways than just using a tag bit to distinguish a true pointer >> from an in-word value. This is at the cost of requiring unsafe >> coding >> techniques in a module implementing the abstraction, which also >> inevitably means implementation-dependent too. Using it for small >> objects as discussed still requires the garbage collector not to be >> confused by trying to trace a reference with a misaligned value. >> >> There is a new builtin type OPAQUE. The only things you can do with >> it in safe code are copy values around (assigment, pass by VALUE, >> RETURN, etc.) and make reference bindings to it (pass by reference, >> WITH bindings). Not that this ia a _lot_ more opaque than opaque >> types. >> >> OPAQUE is known to be the same size as Word.T. In unsafe code, you >> can use this fact to LOOPHOLE it to anything you want and bit-twiddle >> to your heart's content from there. So an unsafe module could >> implement procedures that take OPAQUE parameters. >> >> Variation: >> >> Allow an opaque subtype of OPAQUE, which can be revealed to be any >> type with statically the same size. This would make it possible to >> prevent client code from mixing up two different unrelated >> abstractions that both happened to use OPAQUE. In fact, without >> this, >> the proposal really fails to preserve the existing principles of >> safe/unsafe code. This would require that the revelation be BRANDED, >> which would either mean restricting the revelation to a reference >> type >> (which could still be LOOPHOLEd to anything else) or allowing other >> types to be BRANDED. >> >> Example: >> >> INTERFACE ADT; >> TYPE T <: OPAQUE; >> PROCEDURE P (x:T); >> ... >> END ADT >> >> UNSAFE MODULE ADT; >> TYPE R = RECORD ... END; >> REVEAL T = BRANDED REF R; >> >> PROCEDURE P (x:T) >> VAR I: INTEGER; >> BEGIN >> IF LOOPHOLE(x,INTEGER) MOD 2 # 0 >> THEN >> I := Word.Shift(LOOPHOLE(x,INTEGER),-1); >> (* Use integer value I ... *) >> ELSE >> (* Use reference value x, according to its declared type. >> Prior to the check above, we couldn't afford to risk >> doing anything with it. ... *) >> END (* IF *); >> END P; >> ... >> END ADT; >> >> The safe proposal: >> >> This is more complicated and less general, but allows small object >> abstractions to be done in an entirely safe and implementation- >> independent way. It abstracts away all the bit-level representation >> questions. >> >> There is a new type TAG, which is a subrange of INTEGER, with >> implementation-defined bounds (which would then be accessible by >> FIRST/LAST). >> >> There is a new type constructor TAGGED. If T is any traced reference >> type or any untraced object type, TAGGED T defines a type, called a >> _tagged_ type, whose value set is the union of the value sets of TAG >> and T. >> >> TAG <: TAGGED T and T <: TAGGED T. >> >> There are no other subtype relations involving TAGGED T. >> >> Values of a tagged type can be copied and bound-to. >> >> The static rules for ISTYPE, NARROW, TYPECASE, and assignability of a >> type to a type are liberalized to allow their application to a tagged >> type, and to allow the type to be checked/converted-to to be any >> subtype of the tagged type. Already existing rules would require a >> runtime check that the value is a member of the stated type. >> >> No other operations are possible on a tagged type. A tagged type is >> not a reference type and does not have a typecode. >> >> Example: >> >> INTERFACE ADT; >> TYPE Op <: REFANY; >> TYPE T = TAGGED Op; >> PROCEDURE P (x:T); >> ... >> END ADT >> >> MODULE ADT; >> TYPE R = RECORD ... END; >> REVEAL Op = BRANDED REF R; >> >> PROCEDURE P (x:T) >> BEGIN >> TYPECASE x >> OF TAG (I) >> => (* Use integer value I ... *) >> | Op (RR) >> => (* Use reference value RR ... *) >> END (* IF *); >> END P; >> ... >> END ADT; >> >> Note: TAG is like CARDINAL in that it is "just like" a subrange of >> INTEGER, but not equal to that subrange. This enabled pickles to >> change the size of values of type TAG and of tagged types, as it now >> does with CARDINAL. >> >> Variation: >> >> The 4 runtime-checking operations can also be applied to any ordinal >> type and can check that an ordinal or tagged type has a value >> belonging to any subrange of the base type (or maybe just of the type >> being narrowed). This is pure fluff (well, maybe it is syntactic >> sugar), but adds some consistency and has a real use: >> >> How many times have I coded the following? >> >> IF FIRST(SomeOrdinalType <= x AND x <= LAST(SomeOrdinalType) THEN ... >> >> or worse, >> >> IF FIRST(SomeOrdinalType <= F(x) AND F(x) <= LAST(SomeOrdinalType) >> THEN ... >> >> which I then feel morally obligated to recode using a local >> variable or >> WITH-temp to eliminate the duplicated calls F(x). >> >> It could then become: >> >> IF ISTYPE (F(x), SomeOrdinalType) THEN ... >> >> >> >> >> >> From rodney.m.bates at cox.net Thu Apr 9 04:13:47 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 08 Apr 2009 21:13:47 -0500 Subject: [M3devel] small objects In-Reply-To: <200904090038.n390cNsg097270@camembert.async.caltech.edu> References: <200904090038.n390cNsg097270@camembert.async.caltech.edu> Message-ID: <49DD59DB.4050404@cox.net> Mika Nystrom wrote: > Hmm, ok, there's one big difference between what you're saying and > what Tony and I have been talking about. (I think your understanding > sounds pretty correct.) > > You want to do objects other than small integers. Like what? And why? > I was thinking the trick would apply only to one specific type of integer. > Yes, I want a language mechanism that can be used by various modules to implement various abstract data types, each of which can perform the sometimes dramatic space optimization of putting values that are common and will fit directly in the word. One module I spoke of implements general sets of integers with dynamically variable and sometimes large range. This differs from the builtin SET OF.., which must have a static (and probably relatively small) base subrange. Thus the general, heap-allocated values contain open arrays of Word.T, treated as sets, or if you prefer, packed arrays of booleans, although I manipulate them with bit-twiddling operations from Word. There is another, static-sized, heap-allocated object in front of each array, containing biases on what bits correspond to what integers in the abstract set, etc. It all works fine now, but the usage pattern of some clients has a high percentage very small sets that would fit in a word, and there would be an 11-to-1 space savings if that could be done. BTW, there are also two different kinds of heap objects, one that represents a range set by just its bounds. So I am TYPECASEing these already. It would be very convenient if I could just add another alternative to the TYPECASE for in-word values. In another case, I need truly dynamically variable sized arrays of integers in [0..15], and the great majority are 7 elements or less, which would fit directly in the word, but I still the need full generality to be available, so it's open arrays all the time, with three additional words each. If you can pack a union of a pointer and an integer into a word and can separate them with runtime checks, then you can use the separated integer any way you want, with bit twiddling, type conversions, LOOPHOLE, or whatever. That is what I am trying to get, not just Smalltalk-like integers. Note that Smalltalk has zero static typing, so only one internal representation must do for the union of all possible values in the language. In Modula-3, it would be very inconsistent with the language's philosophy to be this restricted. > Hmm, so your idea is to statically determine what type the references > can have if they are non-references. So you are thinking to put various > kinds of subranges into the "TAGGED" types. But you have to be able to > determine, statically, which subrange it is... am I understanding this > correctly? > From the language, all I want is to be able to dynamically determine whether it is a true pointer to a heap object or a value stored directly in the word, while preserving the safety principles and the semantics of everything already there. So I want some new types, different from any existing types, that statically are known to hold this kind of valueset union and can be converted/assigned to a variable of existing type that is statically known to be either a pointer or an integer (but not both), with a suitable runtime check. It is also necessary to have a way to do this without risking a runtime error, if your code doesn't know yet which kind of value it has. Various ADT modules can take it from there. > Mika > > "Rodney M. Bates" writes: > >> Tony Hosking wrote: >> >>> On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: >>> >>> >>>> Mika Nystrom wrote: >>>> >>>>> Hendrik, I think Tony's and my arguments that you can't break any >>>>> existing code by allowing the squirreling away of integers into >>>>> REFANYs are pretty solid. Pre-existing code simply can't do anything >>>>> useful with unrevealed REFANYs. >>>>> >>>> This is only true of _unrevealed opaque subtypes_ of REFANY, >>>> not of REFANY itself. There is lots of existing code that uses REFANY, >>>> and there, ISTYPE, NARROW, TYPECASE, and assigment can be and >>>> regularly are used on it. It is essential not to alter the >>>> semantics there. >>>> >>> Pre-existing code won't be able to do anything useful with tagged >>> REFANYs: >>> >>> Suppose we have >>> >>> VAR r: REFANY = SmallInteger.FromInt(0); >>> >>> then >>> >>> ISTYPE(r, REFANY) => TRUE >>> ISTYPE(r, T) => FALSE for any T # REFANY >>> >>> Similarly, for TYPECASE, r will only trigger the REFANY branch. >>> >>> NARROW(r, REFANY) => r >>> NARROW(r, T) => run-time error for any T #REFANY >>> >>> VAR x: REFANY => assignment succeeds >>> VAR x: T := r => run-time error for any T # REFANY (because of >>> implicit NARROW) >>> >> I think I am getting a bit lost in all the proposals, variations, >> counterproposals, etc., but >> > >from this argument I am inferring that your plan is that only variables > >> declared REFANY >> and not any proper subtype of REFANY can ever have a value with a tag >> bit set? Then >> the 4 narrowing operations, when and only when applied to an expression >> of static >> type REFANY, would change to make a runtime check for a tag bit and fail >> if it's set? >> It would take this to prevent a tagged value from getting into a >> variable declared a >> proper subtype of REFANY, which can be dereferenced. >> >> This would preclude making your abstract data type an opaque subtype of >> REFANY, >> and would mean all supposedly unrelated ADT modules that used the tag >> technique >> could be broken by client code that mixed up the REFANY values of one of >> them with >> those of another. I consider this a definite breach of Modula-3's >> otherwise bulletproof >> type safety. >> >>> It is impossible to dereference an expression statically typed as >>> REFANY, so there is no need for a "tagged" check on dereference. >>> Because a tagged REFANY cannot be assigned to anything other than >>> something typed REFANY, it can never propagate to a place where it can >>> be dereferenced. >>> >>> >>>> Aside from actual semantic changes, I agree with Tony that we should >>>> not burden any existing type with additional runtime work. Even though >>>> I expect small objects to support big performance gains in certain >>>> important cases, non-tagged references will still greatly predominate >>>> in most code. Create new type(s) for tagged references. >>>> >>> I'm not sure that we are seeing any semantic changes at all. And with >>> Mika's definition of SmallInteger.T as a "boxed" INTEGER object >>> (actually it would be a subrange for values that fit into >>> BITSIZE(Word.T)-1 bits), it is essentially transparent. It just >>> happens to be a run-time optimization that unboxes the INTEGER value. >>> >>> >>> I think I can implement the compiler and run-time support for this >>> very quickly. >>> >>> >>> > > From hosking at cs.purdue.edu Thu Apr 9 05:01:13 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 9 Apr 2009 13:01:13 +1000 Subject: [M3devel] small objects In-Reply-To: <49DD59DB.4050404@cox.net> References: <200904090038.n390cNsg097270@camembert.async.caltech.edu> <49DD59DB.4050404@cox.net> Message-ID: <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> Sounds like you want something like: TAGGED REFANY FOR T where T must be a type that fits into BITS(REFANY)-1? Branding could be used to prevent mixing otherwise structurally equivalent TAGGED REFANY. TAGGED BRANDED REFANY FOR T Where this breaks down is what are the subtyping rules, since I assume you'd like to store these in a REFANY and dynamically test for the appropriate tagged type: TAGGED REFANY FOR T <: REFANY But then how do we distinguish all the different TAGGED REFANY from each other at run-time? On 9 Apr 2009, at 12:13, Rodney M. Bates wrote: > Mika Nystrom wrote: >> Hmm, ok, there's one big difference between what you're saying and >> what Tony and I have been talking about. (I think your understanding >> sounds pretty correct.) >> >> You want to do objects other than small integers. Like what? And >> why? >> I was thinking the trick would apply only to one specific type of >> integer. >> > > Yes, I want a language mechanism that can be used by various > modules to implement various abstract data types, each of which > can perform the sometimes dramatic space optimization of putting > values that are common and will fit directly in the word. > One module I spoke of implements general sets of integers with > dynamically variable and sometimes large range. This differs from > the builtin SET OF.., which must have a static (and probably > relatively > small) base subrange. Thus the general, heap-allocated values contain > open arrays of Word.T, treated as sets, or if you prefer, packed > arrays > of booleans, although I manipulate them with bit-twiddling operations > from Word. > There is another, static-sized, heap-allocated object in front of > each array, > containing biases on what bits correspond to what integers in the > abstract set, etc. It all works fine now, but the usage pattern of > some > clients has a high percentage very small sets that would fit in a > word, > and there would be an 11-to-1 space savings if that could be done. > BTW, there are also two different kinds of heap objects, one that > represents a range set by just its bounds. So I am TYPECASEing > these already. It would be very convenient if I could just add > another > alternative to the TYPECASE for in-word values. > > In another case, I need truly dynamically variable sized arrays of > integers in [0..15], and the great majority are 7 elements or less, > which would fit directly in the word, but I still the need full > generality > to be available, so it's open arrays all the time, with three > additional > words each. > > If you can pack a union of a pointer and an integer into a word and > can separate them with runtime checks, then you can use the > separated integer any way you want, with bit twiddling, type > conversions, > LOOPHOLE, or whatever. That is what I am trying to get, not just > Smalltalk-like integers. > Note that Smalltalk has zero static typing, so only one internal > representation must do for the union of all possible values in > the language. In Modula-3, it would be very inconsistent with > the language's philosophy to be this restricted. >> Hmm, so your idea is to statically determine what type the references >> can have if they are non-references. So you are thinking to put >> various >> kinds of subranges into the "TAGGED" types. But you have to be >> able to >> determine, statically, which subrange it is... am I understanding >> this >> correctly? >> > > From the language, all I want is to be able to dynamically determine > whether it is a true pointer to a heap object or a value stored > directly in the word, while preserving the safety principles and > the semantics of everything already there. So I want some new > types, different from any existing types, that statically are known > to hold this kind of valueset union and can be converted/assigned > to a variable of existing type that is statically known to be either a > pointer or an integer (but not both), with a suitable runtime check. > It is also necessary to have a way to do this without risking a > runtime > error, if your code doesn't know yet which kind of value it has. > Various ADT modules can take it from there. >> Mika >> >> "Rodney M. Bates" writes: >> >>> Tony Hosking wrote: >>> >>>> On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: >>>> >>>> >>>>> Mika Nystrom wrote: >>>>> >>>>>> Hendrik, I think Tony's and my arguments that you can't break any >>>>>> existing code by allowing the squirreling away of integers into >>>>>> REFANYs are pretty solid. Pre-existing code simply can't do >>>>>> anything >>>>>> useful with unrevealed REFANYs. >>>>>> >>>>> This is only true of _unrevealed opaque subtypes_ of REFANY, >>>>> not of REFANY itself. There is lots of existing code that uses >>>>> REFANY, >>>>> and there, ISTYPE, NARROW, TYPECASE, and assigment can be and >>>>> regularly are used on it. It is essential not to alter the >>>>> semantics there. >>>>> >>>> Pre-existing code won't be able to do anything useful with tagged >>>> REFANYs: >>>> >>>> Suppose we have >>>> >>>> VAR r: REFANY = SmallInteger.FromInt(0); >>>> >>>> then >>>> >>>> ISTYPE(r, REFANY) => TRUE >>>> ISTYPE(r, T) => FALSE for any T # REFANY >>>> >>>> Similarly, for TYPECASE, r will only trigger the REFANY branch. >>>> >>>> NARROW(r, REFANY) => r >>>> NARROW(r, T) => run-time error for any T #REFANY >>>> >>>> VAR x: REFANY => assignment succeeds >>>> VAR x: T := r => run-time error for any T # REFANY (because of >>>> implicit NARROW) >>>> >>> I think I am getting a bit lost in all the proposals, variations, >>> counterproposals, etc., but >>> >> >from this argument I am inferring that your plan is that only >> variables >>> declared REFANY >>> and not any proper subtype of REFANY can ever have a value with a >>> tag bit set? Then >>> the 4 narrowing operations, when and only when applied to an >>> expression of static >>> type REFANY, would change to make a runtime check for a tag bit >>> and fail if it's set? >>> It would take this to prevent a tagged value from getting into a >>> variable declared a >>> proper subtype of REFANY, which can be dereferenced. >>> >>> This would preclude making your abstract data type an opaque >>> subtype of REFANY, >>> and would mean all supposedly unrelated ADT modules that used the >>> tag technique >>> could be broken by client code that mixed up the REFANY values of >>> one of them with >>> those of another. I consider this a definite breach of Modula-3's >>> otherwise bulletproof >>> type safety. >>>> It is impossible to dereference an expression statically typed as >>>> REFANY, so there is no need for a "tagged" check on dereference. >>>> Because a tagged REFANY cannot be assigned to anything other than >>>> something typed REFANY, it can never propagate to a place where >>>> it can be dereferenced. >>>> >>>> >>>>> Aside from actual semantic changes, I agree with Tony that we >>>>> should >>>>> not burden any existing type with additional runtime work. Even >>>>> though >>>>> I expect small objects to support big performance gains in certain >>>>> important cases, non-tagged references will still greatly >>>>> predominate >>>>> in most code. Create new type(s) for tagged references. >>>>> >>>> I'm not sure that we are seeing any semantic changes at all. And >>>> with Mika's definition of SmallInteger.T as a "boxed" INTEGER >>>> object (actually it would be a subrange for values that fit into >>>> BITSIZE(Word.T)-1 bits), it is essentially transparent. It just >>>> happens to be a run-time optimization that unboxes the INTEGER >>>> value. >>>> >>>> >>>> I think I can implement the compiler and run-time support for >>>> this very quickly. >>>> >>>> >>>> >> >> From jay.krell at cornell.edu Thu Apr 9 05:59:02 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 9 Apr 2009 03:59:02 +0000 Subject: [M3devel] small objects In-Reply-To: <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> References: <200904090038.n390cNsg097270@camembert.async.caltech.edu> <49DD59DB.4050404@cox.net> <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> Message-ID: Um, what do folks think of, like: struct { void* Type; union { size_t Integer; void* Pointer; } Value; } Variant; ? You know -- something that is two pointers, one pointer for the type, one for the value or integer? void* Type would actually be a pointer to something actually defined and elaborate. Obviously this is twice as large, not as small as it could be, but much more general and portable. No need to determine how many of bits can be the tag. And hope/assume for perf that such a small struct is passed in registers. On x86/NT 4 and 8 byte structs I think are. Type could also be an integer, index into some table, with some predefined values. #define TYPE_INTEGER 0 #define TYPE_FLOAT 1 #define TYPE_DOUBLE 2 #define TYPE_ADDRESS 3 more generally the union would have a float, and maybe a double on 64bit platforms. OR, on 64bit platforms, you probably can, with some porting work, dedicate a whole 8 bits or so to a type index, and still the thing in one "word". How many bits of address space does any 64bit platform these days or forseeable future actually implement? But 32 bits doesn't seem big enough to afford that, and still this is a portability problem -- anything less than a full pointer. - Jay > From: hosking at cs.purdue.edu > To: rodney.m.bates at cox.net > Date: Thu, 9 Apr 2009 13:01:13 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] small objects > > Sounds like you want something like: > > TAGGED REFANY FOR T > > where T must be a type that fits into BITS(REFANY)-1? > > Branding could be used to prevent mixing otherwise structurally > equivalent TAGGED REFANY. > > TAGGED BRANDED REFANY FOR T > > Where this breaks down is what are the subtyping rules, since I assume > you'd like to store these in a REFANY and dynamically test for the > appropriate tagged type: > > TAGGED REFANY FOR T <: REFANY > > But then how do we distinguish all the different TAGGED REFANY from > each other at run-time? > > On 9 Apr 2009, at 12:13, Rodney M. Bates wrote: > > > Mika Nystrom wrote: > >> Hmm, ok, there's one big difference between what you're saying and > >> what Tony and I have been talking about. (I think your understanding > >> sounds pretty correct.) > >> > >> You want to do objects other than small integers. Like what? And > >> why? > >> I was thinking the trick would apply only to one specific type of > >> integer. > >> > > > > Yes, I want a language mechanism that can be used by various > > modules to implement various abstract data types, each of which > > can perform the sometimes dramatic space optimization of putting > > values that are common and will fit directly in the word. > > One module I spoke of implements general sets of integers with > > dynamically variable and sometimes large range. This differs from > > the builtin SET OF.., which must have a static (and probably > > relatively > > small) base subrange. Thus the general, heap-allocated values contain > > open arrays of Word.T, treated as sets, or if you prefer, packed > > arrays > > of booleans, although I manipulate them with bit-twiddling operations > > from Word. > > There is another, static-sized, heap-allocated object in front of > > each array, > > containing biases on what bits correspond to what integers in the > > abstract set, etc. It all works fine now, but the usage pattern of > > some > > clients has a high percentage very small sets that would fit in a > > word, > > and there would be an 11-to-1 space savings if that could be done. > > BTW, there are also two different kinds of heap objects, one that > > represents a range set by just its bounds. So I am TYPECASEing > > these already. It would be very convenient if I could just add > > another > > alternative to the TYPECASE for in-word values. > > > > In another case, I need truly dynamically variable sized arrays of > > integers in [0..15], and the great majority are 7 elements or less, > > which would fit directly in the word, but I still the need full > > generality > > to be available, so it's open arrays all the time, with three > > additional > > words each. > > > > If you can pack a union of a pointer and an integer into a word and > > can separate them with runtime checks, then you can use the > > separated integer any way you want, with bit twiddling, type > > conversions, > > LOOPHOLE, or whatever. That is what I am trying to get, not just > > Smalltalk-like integers. > > Note that Smalltalk has zero static typing, so only one internal > > representation must do for the union of all possible values in > > the language. In Modula-3, it would be very inconsistent with > > the language's philosophy to be this restricted. > >> Hmm, so your idea is to statically determine what type the references > >> can have if they are non-references. So you are thinking to put > >> various > >> kinds of subranges into the "TAGGED" types. But you have to be > >> able to > >> determine, statically, which subrange it is... am I understanding > >> this > >> correctly? > >> > > > > From the language, all I want is to be able to dynamically determine > > whether it is a true pointer to a heap object or a value stored > > directly in the word, while preserving the safety principles and > > the semantics of everything already there. So I want some new > > types, different from any existing types, that statically are known > > to hold this kind of valueset union and can be converted/assigned > > to a variable of existing type that is statically known to be either a > > pointer or an integer (but not both), with a suitable runtime check. > > It is also necessary to have a way to do this without risking a > > runtime > > error, if your code doesn't know yet which kind of value it has. > > Various ADT modules can take it from there. > >> Mika > >> > >> "Rodney M. Bates" writes: > >> > >>> Tony Hosking wrote: > >>> > >>>> On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: > >>>> > >>>> > >>>>> Mika Nystrom wrote: > >>>>> > >>>>>> Hendrik, I think Tony's and my arguments that you can't break any > >>>>>> existing code by allowing the squirreling away of integers into > >>>>>> REFANYs are pretty solid. Pre-existing code simply can't do > >>>>>> anything > >>>>>> useful with unrevealed REFANYs. > >>>>>> > >>>>> This is only true of _unrevealed opaque subtypes_ of REFANY, > >>>>> not of REFANY itself. There is lots of existing code that uses > >>>>> REFANY, > >>>>> and there, ISTYPE, NARROW, TYPECASE, and assigment can be and > >>>>> regularly are used on it. It is essential not to alter the > >>>>> semantics there. > >>>>> > >>>> Pre-existing code won't be able to do anything useful with tagged > >>>> REFANYs: > >>>> > >>>> Suppose we have > >>>> > >>>> VAR r: REFANY = SmallInteger.FromInt(0); > >>>> > >>>> then > >>>> > >>>> ISTYPE(r, REFANY) => TRUE > >>>> ISTYPE(r, T) => FALSE for any T # REFANY > >>>> > >>>> Similarly, for TYPECASE, r will only trigger the REFANY branch. > >>>> > >>>> NARROW(r, REFANY) => r > >>>> NARROW(r, T) => run-time error for any T #REFANY > >>>> > >>>> VAR x: REFANY => assignment succeeds > >>>> VAR x: T := r => run-time error for any T # REFANY (because of > >>>> implicit NARROW) > >>>> > >>> I think I am getting a bit lost in all the proposals, variations, > >>> counterproposals, etc., but > >>> > >> >from this argument I am inferring that your plan is that only > >> variables > >>> declared REFANY > >>> and not any proper subtype of REFANY can ever have a value with a > >>> tag bit set? Then > >>> the 4 narrowing operations, when and only when applied to an > >>> expression of static > >>> type REFANY, would change to make a runtime check for a tag bit > >>> and fail if it's set? > >>> It would take this to prevent a tagged value from getting into a > >>> variable declared a > >>> proper subtype of REFANY, which can be dereferenced. > >>> > >>> This would preclude making your abstract data type an opaque > >>> subtype of REFANY, > >>> and would mean all supposedly unrelated ADT modules that used the > >>> tag technique > >>> could be broken by client code that mixed up the REFANY values of > >>> one of them with > >>> those of another. I consider this a definite breach of Modula-3's > >>> otherwise bulletproof > >>> type safety. > >>>> It is impossible to dereference an expression statically typed as > >>>> REFANY, so there is no need for a "tagged" check on dereference. > >>>> Because a tagged REFANY cannot be assigned to anything other than > >>>> something typed REFANY, it can never propagate to a place where > >>>> it can be dereferenced. > >>>> > >>>> > >>>>> Aside from actual semantic changes, I agree with Tony that we > >>>>> should > >>>>> not burden any existing type with additional runtime work. Even > >>>>> though > >>>>> I expect small objects to support big performance gains in certain > >>>>> important cases, non-tagged references will still greatly > >>>>> predominate > >>>>> in most code. Create new type(s) for tagged references. > >>>>> > >>>> I'm not sure that we are seeing any semantic changes at all. And > >>>> with Mika's definition of SmallInteger.T as a "boxed" INTEGER > >>>> object (actually it would be a subrange for values that fit into > >>>> BITSIZE(Word.T)-1 bits), it is essentially transparent. It just > >>>> happens to be a run-time optimization that unboxes the INTEGER > >>>> value. > >>>> > >>>> > >>>> I think I can implement the compiler and run-time support for > >>>> this very quickly. > >>>> > >>>> > >>>> > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Apr 9 06:22:52 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 9 Apr 2009 14:22:52 +1000 Subject: [M3devel] small objects In-Reply-To: References: <200904090038.n390cNsg097270@camembert.async.caltech.edu> <49DD59DB.4050404@cox.net> <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> Message-ID: <6DADF96B-7A17-45E8-8084-48A66372ED2D@cs.purdue.edu> I don't know what you are saving over just allocating: NEW(OBJECT i: INTEGER END) NEW(OBJECT r: REFANY END) Each is only 2 words: one for the object header and the other for the value. On 9 Apr 2009, at 13:59, Jay wrote: > Um, what do folks think of, like: > > struct > { > void* Type; > union > { > size_t Integer; > void* Pointer; > } Value; > } Variant; > > ? > You know -- something that is two pointers, one pointer for the > type, one for the value or integer? > void* Type would actually be a pointer to something actually defined > and elaborate. > > Obviously this is twice as large, not as small as it could be, but > much more general and portable. No need to determine how many of > bits can be the tag. > > And hope/assume for perf that such a small struct is passed in > registers. > On x86/NT 4 and 8 byte structs I think are. > > Type could also be an integer, index into some table, with some > predefined values. > #define TYPE_INTEGER 0 > #define TYPE_FLOAT 1 > #define TYPE_DOUBLE 2 > #define TYPE_ADDRESS 3 > > more generally the union would have a float, and maybe a double on > 64bit platforms. > > OR, on 64bit platforms, you probably can, with some porting work, > dedicate a whole 8 bits or so to a type index, and still the thing > in one "word". How many bits of address space does any 64bit > platform these days or forseeable future actually implement? > > But 32 bits doesn't seem big enough to afford that, and still this > is a portability problem -- anything less than a full pointer. > > - Jay > > > > From: hosking at cs.purdue.edu > > To: rodney.m.bates at cox.net > > Date: Thu, 9 Apr 2009 13:01:13 +1000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] small objects > > > > Sounds like you want something like: > > > > TAGGED REFANY FOR T > > > > where T must be a type that fits into BITS(REFANY)-1? > > > > Branding could be used to prevent mixing otherwise structurally > > equivalent TAGGED REFANY. > > > > TAGGED BRANDED REFANY FOR T > > > > Where this breaks down is what are the subtyping rules, since I > assume > > you'd like to store these in a REFANY and dynamically test for the > > appropriate tagged type: > > > > TAGGED REFANY FOR T <: REFANY > > > > But then how do we distinguish all the different TAGGED REFANY from > > each other at run-time? > > > > On 9 Apr 2009, at 12:13, Rodney M. Bates wrote: > > > > > Mika Nystrom wrote: > > >> Hmm, ok, there's one big difference between what you're saying > and > > >> what Tony and I have been talking about. (I think your > understanding > > >> sounds pretty correct.) > > >> > > >> You want to do objects other than small integers. Like what? And > > >> why? > > >> I was thinking the trick would apply only to one specific type of > > >> integer. > > >> > > > > > > Yes, I want a language mechanism that can be used by various > > > modules to implement various abstract data types, each of which > > > can perform the sometimes dramatic space optimization of putting > > > values that are common and will fit directly in the word. > > > One module I spoke of implements general sets of integers with > > > dynamically variable and sometimes large range. This differs from > > > the builtin SET OF.., which must have a static (and probably > > > relatively > > > small) base subrange. Thus the general, heap-allocated values > contain > > > open arrays of Word.T, treated as sets, or if you prefer, packed > > > arrays > > > of booleans, although I manipulate them with bit-twiddling > operations > > > from Word. > > > There is another, static-sized, heap-allocated object in front of > > > each array, > > > containing biases on what bits correspond to what integers in the > > > abstract set, etc. It all works fine now, but the usage pattern of > > > some > > > clients has a high percentage very small sets that would fit in a > > > word, > > > and there would be an 11-to-1 space savings if that could be done. > > > BTW, there are also two different kinds of heap objects, one that > > > represents a range set by just its bounds. So I am TYPECASEing > > > these already. It would be very convenient if I could just add > > > another > > > alternative to the TYPECASE for in-word values. > > > > > > In another case, I need truly dynamically variable sized arrays of > > > integers in [0..15], and the great majority are 7 elements or > less, > > > which would fit directly in the word, but I still the need full > > > generality > > > to be available, so it's open arrays all the time, with three > > > additional > > > words each. > > > > > > If you can pack a union of a pointer and an integer into a word > and > > > can separate them with runtime checks, then you can use the > > > separated integer any way you want, with bit twiddling, type > > > conversions, > > > LOOPHOLE, or whatever. That is what I am trying to get, not just > > > Smalltalk-like integers. > > > Note that Smalltalk has zero static typing, so only one internal > > > representation must do for the union of all possible values in > > > the language. In Modula-3, it would be very inconsistent with > > > the language's philosophy to be this restricted. > > >> Hmm, so your idea is to statically determine what type the > references > > >> can have if they are non-references. So you are thinking to put > > >> various > > >> kinds of subranges into the "TAGGED" types. But you have to be > > >> able to > > >> determine, statically, which subrange it is... am I understanding > > >> this > > >> correctly? > > >> > > > > > > From the language, all I want is to be able to dynamically > determine > > > whether it is a true pointer to a heap object or a value stored > > > directly in the word, while preserving the safety principles and > > > the semantics of everything already there. So I want some new > > > types, different from any existing types, that statically are > known > > > to hold this kind of valueset union and can be converted/assigned > > > to a variable of existing type that is statically known to be > either a > > > pointer or an integer (but not both), with a suitable runtime > check. > > > It is also necessary to have a way to do this without risking a > > > runtime > > > error, if your code doesn't know yet which kind of value it has. > > > Various ADT modules can take it from there. > > >> Mika > > >> > > >> "Rodney M. Bates" writes: > > >> > > >>> Tony Hosking wrote: > > >>> > > >>>> On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: > > >>>> > > >>>> > > >>>>> Mika Nystrom wrote: > > >>>>> > > >>>>>> Hendrik, I think Tony's and my arguments that you can't > break any > > >>>>>> existing code by allowing the squirreling away of integers > into > > >>>>>> REFANYs are pretty solid. Pre-existing code simply can't do > > >>>>>> anything > > >>>>>> useful with unrevealed REFANYs. > > >>>>>> > > >>>>> This is only true of _unrevealed opaque subtypes_ of REFANY, > > >>>>> not of REFANY itself. There is lots of existing code that uses > > >>>>> REFANY, > > >>>>> and there, ISTYPE, NARROW, TYPECASE, and assigment can be and > > >>>>> regularly are used on it. It is essential not to alter the > > >>>>> semantics there. > > >>>>> > > >>>> Pre-existing code won't be able to do anything useful with > tagged > > >>>> REFANYs: > > >>>> > > >>>> Suppose we have > > >>>> > > >>>> VAR r: REFANY = SmallInteger.FromInt(0); > > >>>> > > >>>> then > > >>>> > > >>>> ISTYPE(r, REFANY) => TRUE > > >>>> ISTYPE(r, T) => FALSE for any T # REFANY > > >>>> > > >>>> Similarly, for TYPECASE, r will only trigger the REFANY branch. > > >>>> > > >>>> NARROW(r, REFANY) => r > > >>>> NARROW(r, T) => run-time error for any T #REFANY > > >>>> > > >>>> VAR x: REFANY => assignment succeeds > > >>>> VAR x: T := r => run-time error for any T # REFANY (because of > > >>>> implicit NARROW) > > >>>> > > >>> I think I am getting a bit lost in all the proposals, > variations, > > >>> counterproposals, etc., but > > >>> > > >> >from this argument I am inferring that your plan is that only > > >> variables > > >>> declared REFANY > > >>> and not any proper subtype of REFANY can ever have a value > with a > > >>> tag bit set? Then > > >>> the 4 narrowing operations, when and only when applied to an > > >>> expression of static > > >>> type REFANY, would change to make a runtime check for a tag bit > > >>> and fail if it's set? > > >>> It would take this to prevent a tagged value from getting into a > > >>> variable declared a > > >>> proper subtype of REFANY, which can be dereferenced. > > >>> > > >>> This would preclude making your abstract data type an opaque > > >>> subtype of REFANY, > > >>> and would mean all supposedly unrelated ADT modules that used > the > > >>> tag technique > > >>> could be broken by client code that mixed up the REFANY values > of > > >>> one of them with > > >>> those of another. I consider this a definite breach of > Modula-3's > > >>> otherwise bulletproof > > >>> type safety. > > >>>> It is impossible to dereference an expression statically > typed as > > >>>> REFANY, so there is no need for a "tagged" check on > dereference. > > >>>> Because a tagged REFANY cannot be assigned to anything other > than > > >>>> something typed REFANY, it can never propagate to a place where > > >>>> it can be dereferenced. > > >>>> > > >>>> > > >>>>> Aside from actual semantic changes, I agree with Tony that we > > >>>>> should > > >>>>> not burden any existing type with additional runtime work. > Even > > >>>>> though > > >>>>> I expect small objects to support big performance gains in > certain > > >>>>> important cases, non-tagged references will still greatly > > >>>>> predominate > > >>>>> in most code. Create new type(s) for tagged references. > > >>>>> > > >>>> I'm not sure that we are seeing any semantic changes at all. > And > > >>>> with Mika's definition of SmallInteger.T as a "boxed" INTEGER > > >>>> object (actually it would be a subrange for values that fit > into > > >>>> BITSIZE(Word.T)-1 bits), it is essentially transparent. It just > > >>>> happens to be a run-time optimization that unboxes the INTEGER > > >>>> value. > > >>>> > > >>>> > > >>>> I think I can implement the compiler and run-time support for > > >>>> this very quickly. > > >>>> > > >>>> > > >>>> > > >> > > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 9 07:36:49 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 9 Apr 2009 05:36:49 +0000 Subject: [M3devel] small objects In-Reply-To: <6DADF96B-7A17-45E8-8084-48A66372ED2D@cs.purdue.edu> References: <200904090038.n390cNsg097270@camembert.async.caltech.edu> <49DD59DB.4050404@cox.net> <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> <6DADF96B-7A17-45E8-8084-48A66372ED2D@cs.purdue.edu> Message-ID: The heap allocation and pressure on the garbage collector -- such a small struct is reasonably efficient to pass around by value. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Thu, 9 Apr 2009 14:22:52 +1000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] small objects I don't know what you are saving over just allocating: NEW(OBJECT i: INTEGER END) NEW(OBJECT r: REFANY END) Each is only 2 words: one for the object header and the other for the value. On 9 Apr 2009, at 13:59, Jay wrote: Um, what do folks think of, like: struct { void* Type; union { size_t Integer; void* Pointer; } Value; } Variant; ? You know -- something that is two pointers, one pointer for the type, one for the value or integer? void* Type would actually be a pointer to something actually defined and elaborate. Obviously this is twice as large, not as small as it could be, but much more general and portable. No need to determine how many of bits can be the tag. And hope/assume for perf that such a small struct is passed in registers. On x86/NT 4 and 8 byte structs I think are. Type could also be an integer, index into some table, with some predefined values. #define TYPE_INTEGER 0 #define TYPE_FLOAT 1 #define TYPE_DOUBLE 2 #define TYPE_ADDRESS 3 more generally the union would have a float, and maybe a double on 64bit platforms. OR, on 64bit platforms, you probably can, with some porting work, dedicate a whole 8 bits or so to a type index, and still the thing in one "word". How many bits of address space does any 64bit platform these days or forseeable future actually implement? But 32 bits doesn't seem big enough to afford that, and still this is a portability problem -- anything less than a full pointer. - Jay > From: hosking at cs.purdue.edu > To: rodney.m.bates at cox.net > Date: Thu, 9 Apr 2009 13:01:13 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] small objects > > Sounds like you want something like: > > TAGGED REFANY FOR T > > where T must be a type that fits into BITS(REFANY)-1? > > Branding could be used to prevent mixing otherwise structurally > equivalent TAGGED REFANY. > > TAGGED BRANDED REFANY FOR T > > Where this breaks down is what are the subtyping rules, since I assume > you'd like to store these in a REFANY and dynamically test for the > appropriate tagged type: > > TAGGED REFANY FOR T <: REFANY > > But then how do we distinguish all the different TAGGED REFANY from > each other at run-time? > > On 9 Apr 2009, at 12:13, Rodney M. Bates wrote: > > > Mika Nystrom wrote: > >> Hmm, ok, there's one big difference between what you're saying and > >> what Tony and I have been talking about. (I think your understanding > >> sounds pretty correct.) > >> > >> You want to do objects other than small integers. Like what? And > >> why? > >> I was thinking the trick would apply only to one specific type of > >> integer. > >> > > > > Yes, I want a language mechanism that can be used by various > > modules to implement various abstract data types, each of which > > can perform the sometimes dramatic space optimization of putting > > values that are common and will fit directly in the word. > > One module I spoke of implements general sets of integers with > > dynamically variable and sometimes large range. This differs from > > the builtin SET OF.., which must have a static (and probably > > relatively > > small) base subrange. Thus the general, heap-allocated values contain > > open arrays of Word.T, treated as sets, or if you prefer, packed > > arrays > > of booleans, although I manipulate them with bit-twiddling operations > > from Word. > > There is another, static-sized, heap-allocated object in front of > > each array, > > containing biases on what bits correspond to what integers in the > > abstract set, etc. It all works fine now, but the usage pattern of > > some > > clients has a high percentage very small sets that would fit in a > > word, > > and there would be an 11-to-1 space savings if that could be done. > > BTW, there are also two different kinds of heap objects, one that > > represents a range set by just its bounds. So I am TYPECASEing > > these already. It would be very convenient if I could just add > > another > > alternative to the TYPECASE for in-word values. > > > > In another case, I need truly dynamically variable sized arrays of > > integers in [0..15], and the great majority are 7 elements or less, > > which would fit directly in the word, but I still the need full > > generality > > to be available, so it's open arrays all the time, with three > > additional > > words each. > > > > If you can pack a union of a pointer and an integer into a word and > > can separate them with runtime checks, then you can use the > > separated integer any way you want, with bit twiddling, type > > conversions, > > LOOPHOLE, or whatever. That is what I am trying to get, not just > > Smalltalk-like integers. > > Note that Smalltalk has zero static typing, so only one internal > > representation must do for the union of all possible values in > > the language. In Modula-3, it would be very inconsistent with > > the language's philosophy to be this restricted. > >> Hmm, so your idea is to statically determine what type the references > >> can have if they are non-references. So you are thinking to put > >> various > >> kinds of subranges into the "TAGGED" types. But you have to be > >> able to > >> determine, statically, which subrange it is... am I understanding > >> this > >> correctly? > >> > > > > From the language, all I want is to be able to dynamically determine > > whether it is a true pointer to a heap object or a value stored > > directly in the word, while preserving the safety principles and > > the semantics of everything already there. So I want some new > > types, different from any existing types, that statically are known > > to hold this kind of valueset union and can be converted/assigned > > to a variable of existing type that is statically known to be either a > > pointer or an integer (but not both), with a suitable runtime check. > > It is also necessary to have a way to do this without risking a > > runtime > > error, if your code doesn't know yet which kind of value it has. > > Various ADT modules can take it from there. > >> Mika > >> > >> "Rodney M. Bates" writes: > >> > >>> Tony Hosking wrote: > >>> > >>>> On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: > >>>> > >>>> > >>>>> Mika Nystrom wrote: > >>>>> > >>>>>> Hendrik, I think Tony's and my arguments that you can't break any > >>>>>> existing code by allowing the squirreling away of integers into > >>>>>> REFANYs are pretty solid. Pre-existing code simply can't do > >>>>>> anything > >>>>>> useful with unrevealed REFANYs. > >>>>>> > >>>>> This is only true of _unrevealed opaque subtypes_ of REFANY, > >>>>> not of REFANY itself. There is lots of existing code that uses > >>>>> REFANY, > >>>>> and there, ISTYPE, NARROW, TYPECASE, and assigment can be and > >>>>> regularly are used on it. It is essential not to alter the > >>>>> semantics there. > >>>>> > >>>> Pre-existing code won't be able to do anything useful with tagged > >>>> REFANYs: > >>>> > >>>> Suppose we have > >>>> > >>>> VAR r: REFANY = SmallInteger.FromInt(0); > >>>> > >>>> then > >>>> > >>>> ISTYPE(r, REFANY) => TRUE > >>>> ISTYPE(r, T) => FALSE for any T # REFANY > >>>> > >>>> Similarly, for TYPECASE, r will only trigger the REFANY branch. > >>>> > >>>> NARROW(r, REFANY) => r > >>>> NARROW(r, T) => run-time error for any T #REFANY > >>>> > >>>> VAR x: REFANY => assignment succeeds > >>>> VAR x: T := r => run-time error for any T # REFANY (because of > >>>> implicit NARROW) > >>>> > >>> I think I am getting a bit lost in all the proposals, variations, > >>> counterproposals, etc., but > >>> > >> >from this argument I am inferring that your plan is that only > >> variables > >>> declared REFANY > >>> and not any proper subtype of REFANY can ever have a value with a > >>> tag bit set? Then > >>> the 4 narrowing operations, when and only when applied to an > >>> expression of static > >>> type REFANY, would change to make a runtime check for a tag bit > >>> and fail if it's set? > >>> It would take this to prevent a tagged value from getting into a > >>> variable declared a > >>> proper subtype of REFANY, which can be dereferenced. > >>> > >>> This would preclude making your abstract data type an opaque > >>> subtype of REFANY, > >>> and would mean all supposedly unrelated ADT modules that used the > >>> tag technique > >>> could be broken by client code that mixed up the REFANY values of > >>> one of them with > >>> those of another. I consider this a definite breach of Modula-3's > >>> otherwise bulletproof > >>> type safety. > >>>> It is impossible to dereference an expression statically typed as > >>>> REFANY, so there is no need for a "tagged" check on dereference. > >>>> Because a tagged REFANY cannot be assigned to anything other than > >>>> something typed REFANY, it can never propagate to a place where > >>>> it can be dereferenced. > >>>> > >>>> > >>>>> Aside from actual semantic changes, I agree with Tony that we > >>>>> should > >>>>> not burden any existing type with additional runtime work. Even > >>>>> though > >>>>> I expect small objects to support big performance gains in certain > >>>>> important cases, non-tagged references will still greatly > >>>>> predominate > >>>>> in most code. Create new type(s) for tagged references. > >>>>> > >>>> I'm not sure that we are seeing any semantic changes at all. And > >>>> with Mika's definition of SmallInteger.T as a "boxed" INTEGER > >>>> object (actually it would be a subrange for values that fit into > >>>> BITSIZE(Word.T)-1 bits), it is essentially transparent. It just > >>>> happens to be a run-time optimization that unboxes the INTEGER > >>>> value. > >>>> > >>>> > >>>> I think I can implement the compiler and run-time support for > >>>> this very quickly. > >>>> > >>>> > >>>> > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Apr 9 13:55:39 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 9 Apr 2009 07:55:39 -0400 Subject: [M3devel] small objects In-Reply-To: References: <200904090038.n390cNsg097270@camembert.async.caltech.edu> <49DD59DB.4050404@cox.net> <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> <6DADF96B-7A17-45E8-8084-48A66372ED2D@cs.purdue.edu> Message-ID: <20090409115539.GA12685@topoi.pooq.com> On Thu, Apr 09, 2009 at 05:36:49AM +0000, Jay wrote: > > The heap allocation and pressure on the garbage collector -- such a small struct is reasonably efficient to pass around by value. > Generalizing: So one thing wanted is disjoint unions, like the ones Algol 68 has. The advantage of this and types with multiple subtypes is the lack of reference overhead. This suggests that if I ever get around to data structure optimisation in my Algol 68 compiler, I should implement unions between small data types and references to aligned data by the low-order bit method. And this provided an implementation technique for compact pointer/integer punning that works on machines where all bit patterns are valid object pointers. (Are there still any of these around? The last one I used was a CDC CYBER in the 70's) -- hendrik > > > - Jay > > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Thu, 9 Apr 2009 14:22:52 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] small objects > > > > > I don't know what you are saving over just allocating: > > > NEW(OBJECT i: INTEGER END) > NEW(OBJECT r: REFANY END) > > > Each is only 2 words: one for the object header and the other for the value > > > - Jay From mika at async.caltech.edu Thu Apr 9 16:10:44 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 09 Apr 2009 07:10:44 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Thu, 09 Apr 2009 13:01:13 +1000." <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> Message-ID: <200904091410.n39EAiQ4028393@camembert.async.caltech.edu> I don't know why we're having such a tough time understanding each other here :-) I think that what Rodney says is that he wants (in pseudo-modula-2 syntax): T = CASE LSB OF 1 : SmallInt | 0 : U END; SmallInt = [SmallMin..SmallMax]; for any reference type U. That is what TAGGED U would mean, no? Maybe it should be called INTUNION U or INTVARIANT U And then he wants to be able to have just U as well (so it's optional). I.e., no type safety for the SmallInt (beyond the fact that it range checks etc), but the full range of Modula-3 reference types and type checking if it's a reference. The only problem I have with this (except for the changes necessary to Modula-3) is that it can't be held in a REFANY, and that's part of the design. Of course we could go halfway and let it be held in a REFANY, but then you get the runtime LSB check again, for all instances of REFANY, but maybe it doesn't break anything else. Although you do in any case get LSB checks all over the place (in safe code!) where the TAGGED U is revealed to be a TAGGED U. Note that, as we probably all know, the Modula-3 designers expressly considered, and rejected, full variant records. Mika Tony Hosking writes: >Sounds like you want something like: > >TAGGED REFANY FOR T > >where T must be a type that fits into BITS(REFANY)-1? > >Branding could be used to prevent mixing otherwise structurally >equivalent TAGGED REFANY. > >TAGGED BRANDED REFANY FOR T > >Where this breaks down is what are the subtyping rules, since I assume >you'd like to store these in a REFANY and dynamically test for the >appropriate tagged type: > >TAGGED REFANY FOR T <: REFANY > >But then how do we distinguish all the different TAGGED REFANY from >each other at run-time? > >On 9 Apr 2009, at 12:13, Rodney M. Bates wrote: > >> Mika Nystrom wrote: >>> Hmm, ok, there's one big difference between what you're saying and >>> what Tony and I have been talking about. (I think your understanding >>> sounds pretty correct.) >>> >>> You want to do objects other than small integers. Like what? And >>> why? >>> I was thinking the trick would apply only to one specific type of >>> integer. >> >> >> Yes, I want a language mechanism that can be used by various >> modules to implement various abstract data types, each of which >> can perform the sometimes dramatic space optimization of putting >> values that are common and will fit directly in the word. >> One module I spoke of implements general sets of integers with >> dynamically variable and sometimes large range. This differs from >> the builtin SET OF.., which must have a static (and probably >> relatively >> small) base subrange. Thus the general, heap-allocated values contain >> open arrays of Word.T, treated as sets, or if you prefer, packed >> arrays >> of booleans, although I manipulate them with bit-twiddling operations >> from Word. >> There is another, static-sized, heap-allocated object in front of >> each array, >> containing biases on what bits correspond to what integers in the >> abstract set, etc. It all works fine now, but the usage pattern of >> some >> clients has a high percentage very small sets that would fit in a >> word, >> and there would be an 11-to-1 space savings if that could be done. >> BTW, there are also two different kinds of heap objects, one that >> represents a range set by just its bounds. So I am TYPECASEing >> these already. It would be very convenient if I could just add >> another >> alternative to the TYPECASE for in-word values. >> >> In another case, I need truly dynamically variable sized arrays of >> integers in [0..15], and the great majority are 7 elements or less, >> which would fit directly in the word, but I still the need full >> generality >> to be available, so it's open arrays all the time, with three >> additional >> words each. >> >> If you can pack a union of a pointer and an integer into a word and >> can separate them with runtime checks, then you can use the >> separated integer any way you want, with bit twiddling, type >> conversions, >> LOOPHOLE, or whatever. That is what I am trying to get, not just >> Smalltalk-like integers. >> Note that Smalltalk has zero static typing, so only one internal >> representation must do for the union of all possible values in >> the language. In Modula-3, it would be very inconsistent with >> the language's philosophy to be this restricted. >>> Hmm, so your idea is to statically determine what type the references >>> can have if they are non-references. So you are thinking to put >>> various >>> kinds of subranges into the "TAGGED" types. But you have to be >>> able to >>> determine, statically, which subrange it is... am I understanding >>> this >>> correctly? >>> >> >> From the language, all I want is to be able to dynamically determine >> whether it is a true pointer to a heap object or a value stored >> directly in the word, while preserving the safety principles and >> the semantics of everything already there. So I want some new >> types, different from any existing types, that statically are known >> to hold this kind of valueset union and can be converted/assigned >> to a variable of existing type that is statically known to be either a >> pointer or an integer (but not both), with a suitable runtime check. >> It is also necessary to have a way to do this without risking a >> runtime >> error, if your code doesn't know yet which kind of value it has. >> Various ADT modules can take it from there. >>> Mika >>> >>> "Rodney M. Bates" writes: >>> >>>> Tony Hosking wrote: >>>> >>>>> On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: >>>>> >>>>> >>>>>> Mika Nystrom wrote: >>>>>> >>>>>>> Hendrik, I think Tony's and my arguments that you can't break any >>>>>>> existing code by allowing the squirreling away of integers into >>>>>>> REFANYs are pretty solid. Pre-existing code simply can't do >>>>>>> anything >>>>>>> useful with unrevealed REFANYs. >>>>>>> >>>>>> This is only true of _unrevealed opaque subtypes_ of REFANY, >>>>>> not of REFANY itself. There is lots of existing code that uses >>>>>> REFANY, >>>>>> and there, ISTYPE, NARROW, TYPECASE, and assigment can be and >>>>>> regularly are used on it. It is essential not to alter the >>>>>> semantics there. >>>>>> >>>>> Pre-existing code won't be able to do anything useful with tagged >>>>> REFANYs: >>>>> >>>>> Suppose we have >>>>> >>>>> VAR r: REFANY = SmallInteger.FromInt(0); >>>>> >>>>> then >>>>> >>>>> ISTYPE(r, REFANY) => TRUE >>>>> ISTYPE(r, T) => FALSE for any T # REFANY >>>>> >>>>> Similarly, for TYPECASE, r will only trigger the REFANY branch. >>>>> >>>>> NARROW(r, REFANY) => r >>>>> NARROW(r, T) => run-time error for any T #REFANY >>>>> >>>>> VAR x: REFANY => assignment succeeds >>>>> VAR x: T := r => run-time error for any T # REFANY (because of >>>> implicit NARROW) >>>>> >>>> I think I am getting a bit lost in all the proposals, variations, >>>> counterproposals, etc., but >>>> >>> >from this argument I am inferring that your plan is that only >>> variables >>>> declared REFANY >>>> and not any proper subtype of REFANY can ever have a value with a >>>> tag bit set? Then >>>> the 4 narrowing operations, when and only when applied to an >>>> expression of static >>>> type REFANY, would change to make a runtime check for a tag bit >>>> and fail if it's set? >>>> It would take this to prevent a tagged value from getting into a >>>> variable declared a >>>> proper subtype of REFANY, which can be dereferenced. >>>> >>>> This would preclude making your abstract data type an opaque >>>> subtype of REFANY, >>>> and would mean all supposedly unrelated ADT modules that used the >>>> tag technique >>>> could be broken by client code that mixed up the REFANY values of >>>> one of them with >>>> those of another. I consider this a definite breach of Modula-3's >>>> otherwise bulletproof >>>> type safety. >>>>> It is impossible to dereference an expression statically typed as >>>>> REFANY, so there is no need for a "tagged" check on dereference. >>>>> Because a tagged REFANY cannot be assigned to anything other than >>>>> something typed REFANY, it can never propagate to a place where >>>>> it can be dereferenced. >>>>> >>>>> >>>>>> Aside from actual semantic changes, I agree with Tony that we >>>>>> should >>>>>> not burden any existing type with additional runtime work. Even >>>>>> though >>>>>> I expect small objects to support big performance gains in certain >>>>>> important cases, non-tagged references will still greatly >>>>>> predominate >>>>>> in most code. Create new type(s) for tagged references. >>>>>> >>>>> I'm not sure that we are seeing any semantic changes at all. And >>>>> with Mika's definition of SmallInteger.T as a "boxed" INTEGER >>>>> object (actually it would be a subrange for values that fit into >>>>> BITSIZE(Word.T)-1 bits), it is essentially transparent. It just >>>>> happens to be a run-time optimization that unboxes the INTEGER >>>>> value. >>>>> >>>>> >>>>> I think I can implement the compiler and run-time support for >>>>> this very quickly. >>>>> >>>>> >>>>> >>> >>> From mika at async.caltech.edu Thu Apr 9 16:13:38 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 09 Apr 2009 07:13:38 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Thu, 09 Apr 2009 03:59:02 -0000." Message-ID: <200904091413.n39EDcjV028497@camembert.async.caltech.edu> Well the point of what I was suggesting, anyhow, was that it would be very nice to store an integer in a REFANY. A REFANY is only a single word, and I don't think it's practical to expand it to two words. Certainly no more so than requiring an LSB check for certain (hopefully relatively rare) operations on REFANY... Mika Jay writes: >--_a0534b8e-9f94-40d7-a78a-5bfcfeb668e5_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Um=2C what do folks think of=2C like: > >=20 > >struct > >{ > void* Type=3B > > union > > { > size_t Integer=3B > > void* Pointer=3B > > } Value=3B > >} Variant=3B > >=20 > >? > >You know -- something that is two pointers=2C one pointer for the type=2C o= >ne for the value or integer? > >void* Type would actually be a pointer to something actually defined and el= >aborate. > >=20 > >Obviously this is twice as large=2C not as small as it could be=2C but much= > more general and portable. No need to determine how many of bits can be th= >e tag. > >=20 > >And hope/assume for perf that such a small struct is passed in registers. > >On x86/NT 4 and 8 byte structs I think are. > >=20 > >Type could also be an integer=2C index into some table=2C with some predefi= >ned values. > >#define TYPE_INTEGER 0 > >#define TYPE_FLOAT 1 > >#define TYPE_DOUBLE 2 > >#define TYPE_ADDRESS 3 > >=20 > >more generally the union would have a float=2C and maybe a double on 64bit = >platforms. > >=20 > >OR=2C on 64bit platforms=2C you probably can=2C with some porting work=2C d= >edicate a whole 8 bits or so to a type index=2C and still the thing in one = >"word". How many bits of address space does any 64bit platform these days o= >r forseeable future actually implement? > >=20 > >But 32 bits doesn't seem big enough to afford that=2C and still this is a p= >ortability problem -- anything less than a full pointer. > >=20 > > - Jay > >=20 >> From: hosking at cs.purdue.edu >> To: rodney.m.bates at cox.net >> Date: Thu=2C 9 Apr 2009 13:01:13 +1000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] small objects >>=20 >> Sounds like you want something like: >>=20 >> TAGGED REFANY FOR T >>=20 >> where T must be a type that fits into BITS(REFANY)-1? >>=20 >> Branding could be used to prevent mixing otherwise structurally=20 >> equivalent TAGGED REFANY. >>=20 >> TAGGED BRANDED REFANY FOR T >>=20 >> Where this breaks down is what are the subtyping rules=2C since I assume= >=20 >> you'd like to store these in a REFANY and dynamically test for the=20 >> appropriate tagged type: >>=20 >> TAGGED REFANY FOR T <: REFANY >>=20 >> But then how do we distinguish all the different TAGGED REFANY from=20 >> each other at run-time? >>=20 >> On 9 Apr 2009=2C at 12:13=2C Rodney M. Bates wrote: >>=20 >> > Mika Nystrom wrote: >> >> Hmm=2C ok=2C there's one big difference between what you're saying and >> >> what Tony and I have been talking about. (I think your understanding >> >> sounds pretty correct.) >> >> >> >> You want to do objects other than small integers. Like what? And=20 >> >> why? >> >> I was thinking the trick would apply only to one specific type of=20 >> >> integer. >> >> >> > >> > Yes=2C I want a language mechanism that can be used by various >> > modules to implement various abstract data types=2C each of which >> > can perform the sometimes dramatic space optimization of putting >> > values that are common and will fit directly in the word. >> > One module I spoke of implements general sets of integers with >> > dynamically variable and sometimes large range. This differs from >> > the builtin SET OF..=2C which must have a static (and probably=20 >> > relatively >> > small) base subrange. Thus the general=2C heap-allocated values contain >> > open arrays of Word.T=2C treated as sets=2C or if you prefer=2C packed= >=20 >> > arrays >> > of booleans=2C although I manipulate them with bit-twiddling operations >> > from Word. >> > There is another=2C static-sized=2C heap-allocated object in front of=20 >> > each array=2C >> > containing biases on what bits correspond to what integers in the >> > abstract set=2C etc. It all works fine now=2C but the usage pattern of= >=20 >> > some >> > clients has a high percentage very small sets that would fit in a=20 >> > word=2C >> > and there would be an 11-to-1 space savings if that could be done. >> > BTW=2C there are also two different kinds of heap objects=2C one that >> > represents a range set by just its bounds. So I am TYPECASEing >> > these already. It would be very convenient if I could just add=20 >> > another >> > alternative to the TYPECASE for in-word values. >> > >> > In another case=2C I need truly dynamically variable sized arrays of >> > integers in [0..15]=2C and the great majority are 7 elements or less=2C >> > which would fit directly in the word=2C but I still the need full=20 >> > generality >> > to be available=2C so it's open arrays all the time=2C with three=20 >> > additional >> > words each. >> > >> > If you can pack a union of a pointer and an integer into a word and >> > can separate them with runtime checks=2C then you can use the >> > separated integer any way you want=2C with bit twiddling=2C type=20 >> > conversions=2C >> > LOOPHOLE=2C or whatever. That is what I am trying to get=2C not just >> > Smalltalk-like integers. >> > Note that Smalltalk has zero static typing=2C so only one internal >> > representation must do for the union of all possible values in >> > the language. In Modula-3=2C it would be very inconsistent with >> > the language's philosophy to be this restricted. >> >> Hmm=2C so your idea is to statically determine what type the reference= >s >> >> can have if they are non-references. So you are thinking to put=20 >> >> various >> >> kinds of subranges into the "TAGGED" types. But you have to be=20 >> >> able to >> >> determine=2C statically=2C which subrange it is... am I understanding= >=20 >> >> this >> >> correctly? >> >> >> > >> > From the language=2C all I want is to be able to dynamically determine >> > whether it is a true pointer to a heap object or a value stored >> > directly in the word=2C while preserving the safety principles and >> > the semantics of everything already there. So I want some new >> > types=2C different from any existing types=2C that statically are known >> > to hold this kind of valueset union and can be converted/assigned >> > to a variable of existing type that is statically known to be either a >> > pointer or an integer (but not both)=2C with a suitable runtime check. >> > It is also necessary to have a way to do this without risking a=20 >> > runtime >> > error=2C if your code doesn't know yet which kind of value it has. >> > Various ADT modules can take it from there. >> >> Mika >> >> >> >> "Rodney M. Bates" writes: >> >> >> >>> Tony Hosking wrote: >> >>> >> >>>> On 8 Apr 2009=2C at 11:49=2C Rodney M. Bates wrote: >> >>>> >> >>>> >> >>>>> Mika Nystrom wrote: >> >>>>> >> >>>>>> Hendrik=2C I think Tony's and my arguments that you can't break an= >y >> >>>>>> existing code by allowing the squirreling away of integers into >> >>>>>> REFANYs are pretty solid. Pre-existing code simply can't do=20 >> >>>>>> anything >> >>>>>> useful with unrevealed REFANYs. >> >>>>>> >> >>>>> This is only true of _unrevealed opaque subtypes_ of REFANY=2C >> >>>>> not of REFANY itself. There is lots of existing code that uses=20 >> >>>>> REFANY=2C >> >>>>> and there=2C ISTYPE=2C NARROW=2C TYPECASE=2C and assigment can be a= >nd >> >>>>> regularly are used on it. It is essential not to alter the=20 >> >>>>> semantics there. >> >>>>> >> >>>> Pre-existing code won't be able to do anything useful with tagged=20 >> >>>> REFANYs: >> >>>> >> >>>> Suppose we have >> >>>> >> >>>> VAR r: REFANY =3D SmallInteger.FromInt(0)=3B >> >>>> >> >>>> then >> >>>> >> >>>> ISTYPE(r=2C REFANY) =3D> TRUE >> >>>> ISTYPE(r=2C T) =3D> FALSE for any T # REFANY >> >>>> >> >>>> Similarly=2C for TYPECASE=2C r will only trigger the REFANY branch. >> >>>> >> >>>> NARROW(r=2C REFANY) =3D> r >> >>>> NARROW(r=2C T) =3D> run-time error for any T #REFANY >> >>>> >> >>>> VAR x: REFANY =3D> assignment succeeds >> >>>> VAR x: T :=3D r =3D> run-time error for any T # REFANY (because of=20 >> >>>> implicit NARROW) >> >>>> >> >>> I think I am getting a bit lost in all the proposals=2C variations=2C= >=20 >> >>> counterproposals=2C etc.=2C but >> >>> >> >> >from this argument I am inferring that your plan is that only=20 >> >> variables >> >>> declared REFANY >> >>> and not any proper subtype of REFANY can ever have a value with a=20 >> >>> tag bit set? Then >> >>> the 4 narrowing operations=2C when and only when applied to an=20 >> >>> expression of static >> >>> type REFANY=2C would change to make a runtime check for a tag bit=20 >> >>> and fail if it's set? >> >>> It would take this to prevent a tagged value from getting into a=20 >> >>> variable declared a >> >>> proper subtype of REFANY=2C which can be dereferenced. >> >>> >> >>> This would preclude making your abstract data type an opaque=20 >> >>> subtype of REFANY=2C >> >>> and would mean all supposedly unrelated ADT modules that used the=20 >> >>> tag technique >> >>> could be broken by client code that mixed up the REFANY values of=20 >> >>> one of them with >> >>> those of another. I consider this a definite breach of Modula-3's=20 >> >>> otherwise bulletproof >> >>> type safety. >> >>>> It is impossible to dereference an expression statically typed as=20 >> >>>> REFANY=2C so there is no need for a "tagged" check on dereference. >> >>>> Because a tagged REFANY cannot be assigned to anything other than=20 >> >>>> something typed REFANY=2C it can never propagate to a place where=20 >> >>>> it can be dereferenced. >> >>>> >> >>>> >> >>>>> Aside from actual semantic changes=2C I agree with Tony that we=20 >> >>>>> should >> >>>>> not burden any existing type with additional runtime work. Even=20 >> >>>>> though >> >>>>> I expect small objects to support big performance gains in certain >> >>>>> important cases=2C non-tagged references will still greatly=20 >> >>>>> predominate >> >>>>> in most code. Create new type(s) for tagged references. >> >>>>> >> >>>> I'm not sure that we are seeing any semantic changes at all. And=20 >> >>>> with Mika's definition of SmallInteger.T as a "boxed" INTEGER=20 >> >>>> object (actually it would be a subrange for values that fit into=20 >> >>>> BITSIZE(Word.T)-1 bits)=2C it is essentially transparent. It just=20 >> >>>> happens to be a run-time optimization that unboxes the INTEGER=20 >> >>>> value. >> >>>> >> >>>> >> >>>> I think I can implement the compiler and run-time support for=20 >> >>>> this very quickly. >> >>>> >> >>>> >> >>>> >> >> >> >> >>=20 > >--_a0534b8e-9f94-40d7-a78a-5bfcfeb668e5_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Um=2C what do folks think of=2C like:
> =3B
>struct
>{
 =3B =3B =3B void* Type=3B
> =3B =3B =3B union
> =3B =3B =3B {
 =3B =3B =3B =3B =3B = >=3B size_t =3BInteger=3B
> =3B =3B =3B =3B =3B =3B void* Pointer=3B
> =3B =3B =3B =3B } Value=3B
>} =3BVariant=3B
> =3B
>?
>You know -- something that is two pointers=2C one pointer for the type=2C o= >ne for the value or integer?
>void* Type would actually be a pointer to something actually defined and el= >aborate.
> =3B
>Obviously this is twice as large=2C not as small as it could be=2C but much= > more general and portable. No need to determine how many of bits can be th= >e tag.
> =3B
>And hope/assume for perf that such a small struct is passed in registers.R> >On x86/NT 4 and 8 byte structs I think are.
> =3B
>Type could also be an integer=2C index into some table=2C with some predefi= >ned values.
>#define TYPE_INTEGER 0
>#define TYPE_FLOAT 1
>#define TYPE_DOUBLE 2
>#define TYPE_ADDRESS 3
> =3B
>more generally the union would have a float=2C and maybe a double on 64bit = >platforms.
> =3B
>OR=2C on 64bit platforms=2C you probably can=2C with some porting work=2C d= >edicate a whole 8 bits or so to a type index=2C and still the thing in one = >"word". How many bits of address space does any 64bit platform these days o= >r forseeable future actually implement?
> =3B
>But 32 bits doesn't seem big enough to afford that=2C and still this is a p= >ortability problem -- anything less than a full pointer.
> =3B
> =3B- Jay

 =3B
>=3B From: hosking at cs.purdue.edu
>= >=3B To: rodney.m.bates at cox.net
>=3B Date: Thu=2C 9 Apr 2009 13:01:13 += >1000
>=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] s= >mall objects
>=3B
>=3B Sounds like you want something like:
&= >gt=3B
>=3B TAGGED REFANY FOR T
>=3B
>=3B where T must be a= > type that fits into BITS(REFANY)-1?
>=3B
>=3B Branding could be= > used to prevent mixing otherwise structurally
>=3B equivalent TAGGED= > REFANY.
>=3B
>=3B TAGGED BRANDED REFANY FOR T
>=3B
>= >=3B Where this breaks down is what are the subtyping rules=2C since I assum= >e
>=3B you'd like to store these in a REFANY and dynamically test for= > the
>=3B appropriate tagged type:
>=3B
>=3B TAGGED REFANY= > FOR T <=3B: REFANY
>=3B
>=3B But then how do we distinguish a= >ll the different TAGGED REFANY from
>=3B each other at run-time?
&= >gt=3B
>=3B On 9 Apr 2009=2C at 12:13=2C Rodney M. Bates wrote:
>= >=3B
>=3B >=3B Mika Nystrom wrote:
>=3B >=3B>=3B Hmm=2C ok= >=2C there's one big difference between what you're saying and
>=3B >= >=3B>=3B what Tony and I have been talking about. (I think your understand= >ing
>=3B >=3B>=3B sounds pretty correct.)
>=3B >=3B>=3BR>>=3B >=3B>=3B You want to do objects other than small integers. Lik= >e what? And
>=3B >=3B>=3B why?
>=3B >=3B>=3B I was think= >ing the trick would apply only to one specific type of
>=3B >=3B>= >=3B integer.
>=3B >=3B>=3B
>=3B >=3B
>=3B >=3B Yes= >=2C I want a language mechanism that can be used by various
>=3B >= >=3B modules to implement various abstract data types=2C each of which
&g= >t=3B >=3B can perform the sometimes dramatic space optimization of puttin= >g
>=3B >=3B values that are common and will fit directly in the word= >.
>=3B >=3B One module I spoke of implements general sets of integer= >s with
>=3B >=3B dynamically variable and sometimes large range. Thi= >s differs from
>=3B >=3B the builtin SET OF..=2C which must have a s= >tatic (and probably
>=3B >=3B relatively
>=3B >=3B small) ba= >se subrange. Thus the general=2C heap-allocated values contain
>=3B &g= >t=3B open arrays of Word.T=2C treated as sets=2C or if you prefer=2C packed= >
>=3B >=3B arrays
>=3B >=3B of booleans=2C although I manipu= >late them with bit-twiddling operations
>=3B >=3B from Word.
>= >=3B >=3B There is another=2C static-sized=2C heap-allocated object in fro= >nt of
>=3B >=3B each array=2C
>=3B >=3B containing biases on= > what bits correspond to what integers in the
>=3B >=3B abstract set= >=2C etc. It all works fine now=2C but the usage pattern of
>=3B >= >=3B some
>=3B >=3B clients has a high percentage very small sets tha= >t would fit in a
>=3B >=3B word=2C
>=3B >=3B and there would= > be an 11-to-1 space savings if that could be done.
>=3B >=3B BTW=2C= > there are also two different kinds of heap objects=2C one that
>=3B &= >gt=3B represents a range set by just its bounds. So I am TYPECASEing
>= >=3B >=3B these already. It would be very convenient if I could just add <= >BR>>=3B >=3B another
>=3B >=3B alternative to the TYPECASE for i= >n-word values.
>=3B >=3B
>=3B >=3B In another case=2C I need = >truly dynamically variable sized arrays of
>=3B >=3B integers in [0.= >.15]=2C and the great majority are 7 elements or less=2C
>=3B >=3B w= >hich would fit directly in the word=2C but I still the need full
>=3B= > >=3B generality
>=3B >=3B to be available=2C so it's open arrays = >all the time=2C with three
>=3B >=3B additional
>=3B >=3B wo= >rds each.
>=3B >=3B
>=3B >=3B If you can pack a union of a po= >inter and an integer into a word and
>=3B >=3B can separate them wit= >h runtime checks=2C then you can use the
>=3B >=3B separated integer= > any way you want=2C with bit twiddling=2C type
>=3B >=3B conversio= >ns=2C
>=3B >=3B LOOPHOLE=2C or whatever. That is what I am trying to= > get=2C not just
>=3B >=3B Smalltalk-like integers.
>=3B >=3B= > Note that Smalltalk has zero static typing=2C so only one internal
>= >=3B >=3B representation must do for the union of all possible values inR>>=3B >=3B the language. In Modula-3=2C it would be very inconsistent = >with
>=3B >=3B the language's philosophy to be this restricted.
&= >gt=3B >=3B>=3B Hmm=2C so your idea is to statically determine what type= > the references
>=3B >=3B>=3B can have if they are non-references.= > So you are thinking to put
>=3B >=3B>=3B various
>=3B >= >=3B>=3B kinds of subranges into the "TAGGED" types. But you have to be R>>=3B >=3B>=3B able to
>=3B >=3B>=3B determine=2C staticall= >y=2C which subrange it is... am I understanding
>=3B >=3B>=3B thi= >s
>=3B >=3B>=3B correctly?
>=3B >=3B>=3B
>=3B >=3B= >
>=3B >=3B From the language=2C all I want is to be able to dynamica= >lly determine
>=3B >=3B whether it is a true pointer to a heap objec= >t or a value stored
>=3B >=3B directly in the word=2C while preservi= >ng the safety principles and
>=3B >=3B the semantics of everything a= >lready there. So I want some new
>=3B >=3B types=2C different from a= >ny existing types=2C that statically are known
>=3B >=3B to hold thi= >s kind of valueset union and can be converted/assigned
>=3B >=3B to = >a variable of existing type that is statically known to be either a
>= >=3B >=3B pointer or an integer (but not both)=2C with a suitable runtime = >check.
>=3B >=3B It is also necessary to have a way to do this witho= >ut risking a
>=3B >=3B runtime
>=3B >=3B error=2C if your co= >de doesn't know yet which kind of value it has.
>=3B >=3B Various AD= >T modules can take it from there.
>=3B >=3B>=3B Mika
>=3B >= >=3B>=3B
>=3B >=3B>=3B "Rodney M. Bates" writes:
>=3B >=3B= >>=3B
>=3B >=3B>=3B>=3B Tony Hosking wrote:
>=3B >=3B>= >=3B>=3B
>=3B >=3B>=3B>=3B>=3B On 8 Apr 2009=2C at 11:49=2C R= >odney M. Bates wrote:
>=3B >=3B>=3B>=3B>=3B
>=3B >=3B&g= >t=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B>=3B Mika Nystrom wrot= >e:
>=3B >=3B>=3B>=3B>=3B>=3B
>=3B >=3B>=3B>=3B>= >=3B>=3B>=3B Hendrik=2C I think Tony's and my arguments that you can't b= >reak any
>=3B >=3B>=3B>=3B>=3B>=3B>=3B existing code by al= >lowing the squirreling away of integers into
>=3B >=3B>=3B>=3B&g= >t=3B>=3B>=3B REFANYs are pretty solid. Pre-existing code simply can't d= >o
>=3B >=3B>=3B>=3B>=3B>=3B>=3B anything
>=3B >=3B= >>=3B>=3B>=3B>=3B>=3B useful with unrevealed REFANYs.
>=3B &g= >t=3B>=3B>=3B>=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B>=3B= > This is only true of _unrevealed opaque subtypes_ of REFANY=2C
>=3B &= >gt=3B>=3B>=3B>=3B>=3B not of REFANY itself. There is lots of existi= >ng code that uses
>=3B >=3B>=3B>=3B>=3B>=3B REFANY=2C
&g= >t=3B >=3B>=3B>=3B>=3B>=3B and there=2C ISTYPE=2C NARROW=2C TYPECA= >SE=2C and assigment can be and
>=3B >=3B>=3B>=3B>=3B>=3B reg= >ularly are used on it. It is essential not to alter the
>=3B >=3B&g= >t=3B>=3B>=3B>=3B semantics there.
>=3B >=3B>=3B>=3B>=3B&= >gt=3B
>=3B >=3B>=3B>=3B>=3B Pre-existing code won't be able to= > do anything useful with tagged
>=3B >=3B>=3B>=3B>=3B REFANYs= >:
>=3B >=3B>=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B Sup= >pose we have
>=3B >=3B>=3B>=3B>=3B
>=3B >=3B>=3B>= >=3B>=3B VAR r: REFANY =3D SmallInteger.FromInt(0)=3B
>=3B >=3B>= >=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B then
>=3B >=3B>= >=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B ISTYPE(r=2C REFANY) =3D&= >gt=3B TRUE
>=3B >=3B>=3B>=3B>=3B ISTYPE(r=2C T) =3D>=3B FALS= >E for any T # REFANY
>=3B >=3B>=3B>=3B>=3B
>=3B >=3B>= >=3B>=3B>=3B Similarly=2C for TYPECASE=2C r will only trigger the REFANY= > branch.
>=3B >=3B>=3B>=3B>=3B
>=3B >=3B>=3B>=3B>= >=3B NARROW(r=2C REFANY) =3D>=3B r
>=3B >=3B>=3B>=3B>=3B NARR= >OW(r=2C T) =3D>=3B run-time error for any T #REFANY
>=3B >=3B>= >=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B VAR x: REFANY =3D>=3B = >assignment succeeds
>=3B >=3B>=3B>=3B>=3B VAR x: T :=3D r =3D&= >gt=3B run-time error for any T # REFANY (because of
>=3B >=3B>=3B= >>=3B>=3B implicit NARROW)
>=3B >=3B>=3B>=3B>=3B
>=3B = >>=3B>=3B>=3B I think I am getting a bit lost in all the proposals=2C = >variations=2C
>=3B >=3B>=3B>=3B counterproposals=2C etc.=2C but= >
>=3B >=3B>=3B>=3B
>=3B >=3B>=3B >=3Bfrom this argume= >nt I am inferring that your plan is that only
>=3B >=3B>=3B varia= >bles
>=3B >=3B>=3B>=3B declared REFANY
>=3B >=3B>=3B>= >=3B and not any proper subtype of REFANY can ever have a value with a
&= >gt=3B >=3B>=3B>=3B tag bit set? Then
>=3B >=3B>=3B>=3B the= > 4 narrowing operations=2C when and only when applied to an
>=3B >= >=3B>=3B>=3B expression of static
>=3B >=3B>=3B>=3B type REFA= >NY=2C would change to make a runtime check for a tag bit
>=3B >=3B&= >gt=3B>=3B and fail if it's set?
>=3B >=3B>=3B>=3B It would tak= >e this to prevent a tagged value from getting into a
>=3B >=3B>= >=3B>=3B variable declared a
>=3B >=3B>=3B>=3B proper subtype o= >f REFANY=2C which can be dereferenced.
>=3B >=3B>=3B>=3B
>= >=3B >=3B>=3B>=3B This would preclude making your abstract data type a= >n opaque
>=3B >=3B>=3B>=3B subtype of REFANY=2C
>=3B >= >=3B>=3B>=3B and would mean all supposedly unrelated ADT modules that us= >ed the
>=3B >=3B>=3B>=3B tag technique
>=3B >=3B>=3B&g= >t=3B could be broken by client code that mixed up the REFANY values of
= >>=3B >=3B>=3B>=3B one of them with
>=3B >=3B>=3B>=3B tho= >se of another. I consider this a definite breach of Modula-3's
>=3B &= >gt=3B>=3B>=3B otherwise bulletproof
>=3B >=3B>=3B>=3B type s= >afety.
>=3B >=3B>=3B>=3B>=3B It is impossible to dereference a= >n expression statically typed as
>=3B >=3B>=3B>=3B>=3B REFANY= >=2C so there is no need for a "tagged" check on dereference.
>=3B >= >=3B>=3B>=3B>=3B Because a tagged REFANY cannot be assigned to anythin= >g other than
>=3B >=3B>=3B>=3B>=3B something typed REFANY=2C = >it can never propagate to a place where
>=3B >=3B>=3B>=3B>=3B= > it can be dereferenced.
>=3B >=3B>=3B>=3B>=3B
>=3B >= >=3B>=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B>=3B Aside from a= >ctual semantic changes=2C I agree with Tony that we
>=3B >=3B>=3B= >>=3B>=3B>=3B should
>=3B >=3B>=3B>=3B>=3B>=3B not burd= >en any existing type with additional runtime work. Even
>=3B >=3B&g= >t=3B>=3B>=3B>=3B though
>=3B >=3B>=3B>=3B>=3B>=3B I ex= >pect small objects to support big performance gains in certain
>=3B &g= >t=3B>=3B>=3B>=3B>=3B important cases=2C non-tagged references will = >still greatly
>=3B >=3B>=3B>=3B>=3B>=3B predominate
>= >=3B >=3B>=3B>=3B>=3B>=3B in most code. Create new type(s) for tag= >ged references.
>=3B >=3B>=3B>=3B>=3B>=3B
>=3B >=3B&g= >t=3B>=3B>=3B I'm not sure that we are seeing any semantic changes at al= >l. And
>=3B >=3B>=3B>=3B>=3B with Mika's definition of SmallI= >nteger.T as a "boxed" INTEGER
>=3B >=3B>=3B>=3B>=3B object (a= >ctually it would be a subrange for values that fit into
>=3B >=3B&g= >t=3B>=3B>=3B BITSIZE(Word.T)-1 bits)=2C it is essentially transparent. = >It just
>=3B >=3B>=3B>=3B>=3B happens to be a run-time optimi= >zation that unboxes the INTEGER
>=3B >=3B>=3B>=3B>=3B value.<= >BR>>=3B >=3B>=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B
&g= >t=3B >=3B>=3B>=3B>=3B I think I can implement the compiler and run-= >time support for
>=3B >=3B>=3B>=3B>=3B this very quickly.
= >>=3B >=3B>=3B>=3B>=3B
>=3B >=3B>=3B>=3B>=3B
>= >=3B >=3B>=3B>=3B>=3B
>=3B >=3B>=3B
>=3B >=3B>=3B<= >BR>>=3B
>= > >--_a0534b8e-9f94-40d7-a78a-5bfcfeb668e5_-- From hendrik at topoi.pooq.com Thu Apr 9 16:34:40 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 9 Apr 2009 10:34:40 -0400 Subject: [M3devel] small objects In-Reply-To: <200904091410.n39EAiQ4028393@camembert.async.caltech.edu> References: <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> <200904091410.n39EAiQ4028393@camembert.async.caltech.edu> Message-ID: <20090409143440.GA13374@topoi.pooq.com> On Thu, Apr 09, 2009 at 07:10:44AM -0700, Mika Nystrom wrote: > I don't know why we're having such a tough time understanding each > other here :-) > > I think that what Rodney says is that he wants (in pseudo-modula-2 > syntax): > > T = CASE LSB OF > 1 : SmallInt > | > 0 : U > END; > > SmallInt = [SmallMin..SmallMax]; > > for any reference type U. Yes. That's what I wanted too, originally. I can accept the restriction that the reference type U might be restricted to be REFANY. > > That is what TAGGED U would mean, no? Maybe it should be called > INTUNION U or INTVARIANT U Or even UNION(SmallInt, U)? This would allow several variations on the theme if we were ever to want to go further along this route. But it would not require us to do so. > > And then he wants to be able to have just U as well (so it's > optional). > > I.e., no type safety for the SmallInt (beyond the fact that it > range checks etc), but the full range of Modula-3 reference > types and type checking if it's a reference. > > The only problem I have with this (except for the changes necessary > to Modula-3) is that it can't be held in a REFANY, and that's part > of the design. Much better not to pervert REFANY, but use a new type instead. > > Of course we could go halfway and let it be held in a REFANY, but > then you get the runtime LSB check again, for all instances of > REFANY, I really don't like requiriny a run-time check on REFANY. That's why I want it to be a separate type. > but maybe it doesn't break anything else. Although you do > in any case get LSB checks all over the place (in safe code!) where > the TAGGED U is revealed to be a TAGGED U. > > Note that, as we probably all know, the Modula-3 designers expressly > considered, and rejected, full variant records. Are these the factors they based their decision on? (1) The ones in Pascal are insecure without a lot of run-time checking. (2) Objects and inheritance take care of much of the functionality. (3) The ones in Algol 68 involve copying entire records when construction and deconstructing unions of records. What we're considering not is the case in which (2) provides excessive indirection and garbage-collector load, and in which the copying in (3) is really cheap. There are applications for which this feature could have major effects on efficiency. I have some I'd consider rewriting from C/C++ to Modula 3 if this feature were available. -- hendrik > > Mika > > > Tony Hosking writes: > >Sounds like you want something like: > > > >TAGGED REFANY FOR T > > > >where T must be a type that fits into BITS(REFANY)-1? > > > >Branding could be used to prevent mixing otherwise structurally > >equivalent TAGGED REFANY. > > > >TAGGED BRANDED REFANY FOR T > > > >Where this breaks down is what are the subtyping rules, since I assume > >you'd like to store these in a REFANY and dynamically test for the > >appropriate tagged type: > > > >TAGGED REFANY FOR T <: REFANY > > > >But then how do we distinguish all the different TAGGED REFANY from > >each other at run-time? > > > >On 9 Apr 2009, at 12:13, Rodney M. Bates wrote: > > > >> Mika Nystrom wrote: > >>> Hmm, ok, there's one big difference between what you're saying and > >>> what Tony and I have been talking about. (I think your understanding > >>> sounds pretty correct.) > >>> > >>> You want to do objects other than small integers. Like what? And > >>> why? > >>> I was thinking the trick would apply only to one specific type of > >>> integer. > >> > >> > >> Yes, I want a language mechanism that can be used by various > >> modules to implement various abstract data types, each of which > >> can perform the sometimes dramatic space optimization of putting > >> values that are common and will fit directly in the word. > >> One module I spoke of implements general sets of integers with > >> dynamically variable and sometimes large range. This differs from > >> the builtin SET OF.., which must have a static (and probably > >> relatively > >> small) base subrange. Thus the general, heap-allocated values contain > >> open arrays of Word.T, treated as sets, or if you prefer, packed > >> arrays > >> of booleans, although I manipulate them with bit-twiddling operations > >> from Word. > >> There is another, static-sized, heap-allocated object in front of > >> each array, > >> containing biases on what bits correspond to what integers in the > >> abstract set, etc. It all works fine now, but the usage pattern of > >> some > >> clients has a high percentage very small sets that would fit in a > >> word, > >> and there would be an 11-to-1 space savings if that could be done. > >> BTW, there are also two different kinds of heap objects, one that > >> represents a range set by just its bounds. So I am TYPECASEing > >> these already. It would be very convenient if I could just add > >> another > >> alternative to the TYPECASE for in-word values. > >> > >> In another case, I need truly dynamically variable sized arrays of > >> integers in [0..15], and the great majority are 7 elements or less, > >> which would fit directly in the word, but I still the need full > >> generality > >> to be available, so it's open arrays all the time, with three > >> additional > >> words each. > >> > >> If you can pack a union of a pointer and an integer into a word and > >> can separate them with runtime checks, then you can use the > >> separated integer any way you want, with bit twiddling, type > >> conversions, > >> LOOPHOLE, or whatever. That is what I am trying to get, not just > >> Smalltalk-like integers. > >> Note that Smalltalk has zero static typing, so only one internal > >> representation must do for the union of all possible values in > >> the language. In Modula-3, it would be very inconsistent with > >> the language's philosophy to be this restricted. > >>> Hmm, so your idea is to statically determine what type the references > >>> can have if they are non-references. So you are thinking to put > >>> various > >>> kinds of subranges into the "TAGGED" types. But you have to be > >>> able to > >>> determine, statically, which subrange it is... am I understanding > >>> this > >>> correctly? > >>> > >> > >> From the language, all I want is to be able to dynamically determine > >> whether it is a true pointer to a heap object or a value stored > >> directly in the word, while preserving the safety principles and > >> the semantics of everything already there. So I want some new > >> types, different from any existing types, that statically are known > >> to hold this kind of valueset union and can be converted/assigned > >> to a variable of existing type that is statically known to be either a > >> pointer or an integer (but not both), with a suitable runtime check. > >> It is also necessary to have a way to do this without risking a > >> runtime > >> error, if your code doesn't know yet which kind of value it has. > >> Various ADT modules can take it from there. > >>> Mika > >>> > >>> "Rodney M. Bates" writes: > >>> > >>>> Tony Hosking wrote: > >>>> > >>>>> On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: > >>>>> > >>>>> > >>>>>> Mika Nystrom wrote: > >>>>>> > >>>>>>> Hendrik, I think Tony's and my arguments that you can't break any > >>>>>>> existing code by allowing the squirreling away of integers into > >>>>>>> REFANYs are pretty solid. Pre-existing code simply can't do > >>>>>>> anything > >>>>>>> useful with unrevealed REFANYs. > >>>>>>> > >>>>>> This is only true of _unrevealed opaque subtypes_ of REFANY, > >>>>>> not of REFANY itself. There is lots of existing code that uses > >>>>>> REFANY, > >>>>>> and there, ISTYPE, NARROW, TYPECASE, and assigment can be and > >>>>>> regularly are used on it. It is essential not to alter the > >>>>>> semantics there. > >>>>>> > >>>>> Pre-existing code won't be able to do anything useful with tagged > >>>>> REFANYs: > >>>>> > >>>>> Suppose we have > >>>>> > >>>>> VAR r: REFANY = SmallInteger.FromInt(0); > >>>>> > >>>>> then > >>>>> > >>>>> ISTYPE(r, REFANY) => TRUE > >>>>> ISTYPE(r, T) => FALSE for any T # REFANY > >>>>> > >>>>> Similarly, for TYPECASE, r will only trigger the REFANY branch. > >>>>> > >>>>> NARROW(r, REFANY) => r > >>>>> NARROW(r, T) => run-time error for any T #REFANY > >>>>> > >>>>> VAR x: REFANY => assignment succeeds > >>>>> VAR x: T := r => run-time error for any T # REFANY (because of > >>>> implicit NARROW) > >>>>> > >>>> I think I am getting a bit lost in all the proposals, variations, > >>>> counterproposals, etc., but > >>>> > >>> >from this argument I am inferring that your plan is that only > >>> variables > >>>> declared REFANY > >>>> and not any proper subtype of REFANY can ever have a value with a > >>>> tag bit set? Then > >>>> the 4 narrowing operations, when and only when applied to an > >>>> expression of static > >>>> type REFANY, would change to make a runtime check for a tag bit > >>>> and fail if it's set? > >>>> It would take this to prevent a tagged value from getting into a > >>>> variable declared a > >>>> proper subtype of REFANY, which can be dereferenced. > >>>> > >>>> This would preclude making your abstract data type an opaque > >>>> subtype of REFANY, > >>>> and would mean all supposedly unrelated ADT modules that used the > >>>> tag technique > >>>> could be broken by client code that mixed up the REFANY values of > >>>> one of them with > >>>> those of another. I consider this a definite breach of Modula-3's > >>>> otherwise bulletproof > >>>> type safety. > >>>>> It is impossible to dereference an expression statically typed as > >>>>> REFANY, so there is no need for a "tagged" check on dereference. > >>>>> Because a tagged REFANY cannot be assigned to anything other than > >>>>> something typed REFANY, it can never propagate to a place where > >>>>> it can be dereferenced. > >>>>> > >>>>> > >>>>>> Aside from actual semantic changes, I agree with Tony that we > >>>>>> should > >>>>>> not burden any existing type with additional runtime work. Even > >>>>>> though > >>>>>> I expect small objects to support big performance gains in certain > >>>>>> important cases, non-tagged references will still greatly > >>>>>> predominate > >>>>>> in most code. Create new type(s) for tagged references. > >>>>>> > >>>>> I'm not sure that we are seeing any semantic changes at all. And > >>>>> with Mika's definition of SmallInteger.T as a "boxed" INTEGER > >>>>> object (actually it would be a subrange for values that fit into > >>>>> BITSIZE(Word.T)-1 bits), it is essentially transparent. It just > >>>>> happens to be a run-time optimization that unboxes the INTEGER > >>>>> value. > >>>>> > >>>>> > >>>>> I think I can implement the compiler and run-time support for > >>>>> this very quickly. > >>>>> > >>>>> > >>>>> > >>> > >>> From mika at async.caltech.edu Thu Apr 9 17:27:11 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 09 Apr 2009 08:27:11 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Thu, 09 Apr 2009 10:34:40 EDT." <20090409143440.GA13374@topoi.pooq.com> Message-ID: <200904091527.n39FRBF0031475@camembert.async.caltech.edu> hendrik at topoi.pooq.com writes: >On Thu, Apr 09, 2009 at 07:10:44AM -0700, Mika Nystrom wrote: >> I don't know why we're having such a tough time understanding each >> other here :-) >> >> I think that what Rodney says is that he wants (in pseudo-modula-2 >> syntax): >> >> T = CASE LSB OF >> 1 : SmallInt >> | >> 0 : U >> END; >> >> SmallInt = [SmallMin..SmallMax]; >> >> for any reference type U. > >Yes. That's what I wanted too, originally. I can accept the >restriction that the reference type U might be restricted to be >REFANY. I think this is what Tony says he's implemented, essentially... ... >> >> The only problem I have with this (except for the changes necessary >> to Modula-3) is that it can't be held in a REFANY, and that's part >> of the design. > >Much better not to pervert REFANY, but use a new type instead. Are you sure? I want a type---some type---that can hold "any reference, even a tagged one", and I would rewrite most library code that today takes REFANY to take that instead. Why not? Why would I want to limit it to REFANY when it performs no operations that couldn't legally be performed on TAGGED REFANY. > >> >> Of course we could go halfway and let it be held in a REFANY, but >> then you get the runtime LSB check again, for all instances of >> REFANY, > >I really don't like requiriny a run-time check on REFANY. That's why >I want it to be a separate type. All the operations in question already require (*much* more complicated) run-time checks on REFANY.... and most uses of REFANY still wouldn't require the LSB check. I really think the runtime issue is a non-issue, and as I said above, if it turns out to be a real issue, one can either abandon the change (since the whole thing can be implemented transparently with a library) or else re-root ROOT and all the REF types in a new NOTQUITEREFANY type. This would be a backward-compatible change (in every sense) with Tony's runtime changes: REFANY ; (* Tony's, with the LSB trick *) NOTQUITEREFANY <: REFANY; ROOT <: NOTQUITEREFANY; REF T <: NOTQUITEREFANY; (* for all T *) After that, future, change, people who want to avoid the LSB check on REFANY can instead use NOTQUITEREFANY. I think barely anyone will bother. Come to think of it, Modula-3 doesn't specify that there's no intermediate type between REFANY and ROOT and the other REF T's, so there's no way it could break the current language. In fact you don't have to "reveal" this new type in the language specification at all. It could just be a library type NotQuiteRefany.T. You could then introduce separately, a la Rodney, TAGGED T <: REFANY; (* for all T *) (* but *not* TAGGED T <: NOTQUITEREFANY *) > >> but maybe it doesn't break anything else. Although you do >> in any case get LSB checks all over the place (in safe code!) where >> the TAGGED U is revealed to be a TAGGED U. >> >> Note that, as we probably all know, the Modula-3 designers expressly >> considered, and rejected, full variant records. > >Are these the factors they based their decision on? > >(1) The ones in Pascal are insecure without a lot of run-time checking. > >(2) Objects and inheritance take care of much of the functionality. > >(3) The ones in Algol 68 involve copying entire records when >construction and deconstructing unions of records. (1) and (2) at least. I'll quote: "[talk about runtime errors due to freeing still-used references] Another well-known runtime error is to assign to the tag of a variant record in a way that subverts the type system. Distinguishing subversive assignments from benign assignments in the language definition is error-prone and arbitrary. The objects and classes first introduced in Simula and adopted in Oberon and Object Pascal are more general than variant records, and they are safe, so we have discarded variant records and adopted objects. [talk about objects]" (See Cardelli et al., "The Modula-3 Type System" (c) 1989 ACM.) Mika > >What we're considering not is the case in which (2) provides >excessive indirection and garbage-collector load, and in which >the copying in (3) is really cheap. There are applications >for which this feature could have major effects on efficiency. >I have some I'd consider rewriting from C/C++ to Modula 3 >if this feature were available. > >-- hendrik .... From jay.krell at cornell.edu Thu Apr 9 19:06:21 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 9 Apr 2009 17:06:21 +0000 Subject: [M3devel] FW: cvsup In-Reply-To: <20090409170205.0D1CF60C150@birch.elegosoft.com> References: <20090409170205.0D1CF60C150@birch.elegosoft.com> Message-ID: This is the first time I've used cvs import. Hopefully I don't mess it up much. This is just an initial import with no changes, no attempt to build it, etc. I think that's the right approach. Thanks, - Jay ---------------------------------------- > Date: Thu, 9 Apr 2009 19:02:04 +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/04/09 19:02:04 > > cm3/m3-tools/cvsup > > Update of /usr/cvs/cm3/m3-tools/cvsup > In directory birch:/tmp/cvs-serv5883 > > Log Message: > import cvsup-snap-16.1h > > Status: > > Vendor Tag: cvsup > Release Tags: cvsup-snap-16_1h > > N cm3/m3-tools/cvsup/Blurb > N cm3/m3-tools/cvsup/Install > N cm3/m3-tools/cvsup/License > N cm3/m3-tools/cvsup/Announce > N cm3/m3-tools/cvsup/Makefile > N cm3/m3-tools/cvsup/ChangeLog > N cm3/m3-tools/cvsup/Acknowledgments > N cm3/m3-tools/cvsup/doc/faq_ru.tail > N cm3/m3-tools/cvsup/doc/faq.tail > N cm3/m3-tools/cvsup/doc/faq_ru.faq > N cm3/m3-tools/cvsup/doc/faq.faq > N cm3/m3-tools/cvsup/doc/Protocol > N cm3/m3-tools/cvsup/doc/faqgen.awk > N cm3/m3-tools/cvsup/doc/Makefile > N cm3/m3-tools/cvsup/doc/faq.head > N cm3/m3-tools/cvsup/doc/Checkouts > N cm3/m3-tools/cvsup/doc/Attributes > N cm3/m3-tools/cvsup/doc/faq_ru.head > N cm3/m3-tools/cvsup/doc/images/yelnew.gif > N cm3/m3-tools/cvsup/doc/images/cvsup128.gif > N cm3/m3-tools/cvsup/client/Makefile > N cm3/m3-tools/cvsup/client/src/RegularUpdater.i3 > N cm3/m3-tools/cvsup/client/src/RegularUpdater.m3 > N cm3/m3-tools/cvsup/client/src/exit.pbm > N cm3/m3-tools/cvsup/client/src/TextPortLogger.i3 > N cm3/m3-tools/cvsup/client/src/Receive.i3 > N cm3/m3-tools/cvsup/client/src/TreeList.i3 > N cm3/m3-tools/cvsup/client/src/RsyncUpdater.m3 > N cm3/m3-tools/cvsup/client/src/Auth.i3 > N cm3/m3-tools/cvsup/client/src/SyncQueue.mg > N cm3/m3-tools/cvsup/client/src/SupGUI.m3 > N cm3/m3-tools/cvsup/client/src/tape_play.pbm > N cm3/m3-tools/cvsup/client/src/Version.i3 > N cm3/m3-tools/cvsup/client/src/SupFile.m3 > N cm3/m3-tools/cvsup/client/src/CheckoutUpdater.i3 > N cm3/m3-tools/cvsup/client/src/EventSync.m3 > N cm3/m3-tools/cvsup/client/src/SupFile.i3 > N cm3/m3-tools/cvsup/client/src/CheckoutUpdater.m3 > N cm3/m3-tools/cvsup/client/src/TreeList.m3 > N cm3/m3-tools/cvsup/client/src/Auth.m3 > N cm3/m3-tools/cvsup/client/src/FSClient.i3 > N cm3/m3-tools/cvsup/client/src/TextVBTLogger.i3 > N cm3/m3-tools/cvsup/client/src/CheckoutCreator.m3 > N cm3/m3-tools/cvsup/client/src/cvsup.1 > N cm3/m3-tools/cvsup/client/src/Updater.m3 > N cm3/m3-tools/cvsup/client/src/BackoffTimer.m3 > N cm3/m3-tools/cvsup/client/src/FSClient.m3 > N cm3/m3-tools/cvsup/client/src/disk.pbm > N cm3/m3-tools/cvsup/client/src/RCSUpdater.m3 > N cm3/m3-tools/cvsup/client/src/EventSync.i3 > N cm3/m3-tools/cvsup/client/src/Detailer.i3 > N cm3/m3-tools/cvsup/client/src/cvsup.cat > N cm3/m3-tools/cvsup/client/src/CheckoutCreator.i3 > N cm3/m3-tools/cvsup/client/src/Receive.m3 > N cm3/m3-tools/cvsup/client/src/Main.m3 > N cm3/m3-tools/cvsup/client/src/RegularCreator.i3 > N cm3/m3-tools/cvsup/client/src/FileUpdater.i3 > N cm3/m3-tools/cvsup/client/src/RsyncUpdater.i3 > N cm3/m3-tools/cvsup/client/src/syncqueue.tmpl > N cm3/m3-tools/cvsup/client/src/stop.pbm > N cm3/m3-tools/cvsup/client/src/FileUpdater.m3 > N cm3/m3-tools/cvsup/client/src/TextVBTLogger.m3 > N cm3/m3-tools/cvsup/client/src/SupGUIFake.m3 > N cm3/m3-tools/cvsup/client/src/m3makefile > N cm3/m3-tools/cvsup/client/src/BackoffTimer.i3 > N cm3/m3-tools/cvsup/client/src/RegularCreator.m3 > N cm3/m3-tools/cvsup/client/src/TextPortLogger.m3 > N cm3/m3-tools/cvsup/client/src/SupGUI.i3 > N cm3/m3-tools/cvsup/client/src/Copyright.txt > N cm3/m3-tools/cvsup/client/src/SyncQueue.ig > N cm3/m3-tools/cvsup/client/src/RCSUpdater.i3 > N cm3/m3-tools/cvsup/client/src/Detailer.m3 > N cm3/m3-tools/cvsup/client/src/Updater.i3 > N cm3/m3-tools/cvsup/client/src/info.pbm > N cm3/m3-tools/cvsup/client/src/Fixup.i3 > N cm3/m3-tools/cvsup/client/src/SupGUI.fv > N cm3/m3-tools/cvsup/cvpasswd/Makefile > N cm3/m3-tools/cvsup/cvpasswd/src/Secret.i3 > N cm3/m3-tools/cvsup/cvpasswd/src/Secret.m3 > N cm3/m3-tools/cvsup/cvpasswd/src/Main.m3 > N cm3/m3-tools/cvsup/cvpasswd/src/m3makefile > N cm3/m3-tools/cvsup/cvpasswd/src/Upass.i3 > N cm3/m3-tools/cvsup/cvpasswd/src/cvpasswd.cat > N cm3/m3-tools/cvsup/cvpasswd/src/cvpasswd.1 > N cm3/m3-tools/cvsup/examples/supfile.cvs > N cm3/m3-tools/cvsup/examples/README > N cm3/m3-tools/cvsup/contrib/README > N cm3/m3-tools/cvsup/contrib/cvsup2httplog/cvsup2httplog > N cm3/m3-tools/cvsup/contrib/cvsup2httplog/README > N cm3/m3-tools/cvsup/contrib/cvsupwho/README > N cm3/m3-tools/cvsup/contrib/cvsupwho/cvsupwho > N cm3/m3-tools/cvsup/contrib/cvsupchk/README > N cm3/m3-tools/cvsup/contrib/cvsupchk/cvsupchk > N cm3/m3-tools/cvsup/contrib/cvsup2html/cvsup2html.awk > N cm3/m3-tools/cvsup/contrib/cvsup2html/README > N cm3/m3-tools/cvsup/contrib/cvsuplog2html/README > N cm3/m3-tools/cvsup/contrib/cvsuplog2html/cvsuplog2html > N cm3/m3-tools/cvsup/suplib/Makefile > N cm3/m3-tools/cvsup/suplib/src/RsyncFile.i3 > N cm3/m3-tools/cvsup/suplib/src/RsyncBlock.m3 > N cm3/m3-tools/cvsup/suplib/src/IOWatchDog.m3 > N cm3/m3-tools/cvsup/suplib/src/RCSRevNum.i3 > N cm3/m3-tools/cvsup/suplib/src/FileAttrRep.i3 > N cm3/m3-tools/cvsup/suplib/src/EscapedRd.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSError.i3 > N cm3/m3-tools/cvsup/suplib/src/Merger.ig > N cm3/m3-tools/cvsup/suplib/src/merger.tmpl > N cm3/m3-tools/cvsup/suplib/src/UgzipP.i3 > N cm3/m3-tools/cvsup/suplib/src/GzipRd.m3 > N cm3/m3-tools/cvsup/suplib/src/WatchDog.m3 > N cm3/m3-tools/cvsup/suplib/src/RCSString.m3 > N cm3/m3-tools/cvsup/suplib/src/ErrMsg.m3 > N cm3/m3-tools/cvsup/suplib/src/AuthMD5.i3 > N cm3/m3-tools/cvsup/suplib/src/SplitLogger.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSPhrase.i3 > N cm3/m3-tools/cvsup/suplib/src/MD5.i3 > N cm3/m3-tools/cvsup/suplib/src/DirEntry.i3 > N cm3/m3-tools/cvsup/suplib/src/SupMisc.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSString.i3 > N cm3/m3-tools/cvsup/suplib/src/SupMisc.m3 > N cm3/m3-tools/cvsup/suplib/src/IOWatchDog.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSEdit.i3 > N cm3/m3-tools/cvsup/suplib/src/FileAttr.i3 > N cm3/m3-tools/cvsup/suplib/src/ExecRec.i3 > N cm3/m3-tools/cvsup/suplib/src/Merger.mg > N cm3/m3-tools/cvsup/suplib/src/MySyslog.i3 > N cm3/m3-tools/cvsup/suplib/src/FileStatus.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSAccess.i3 > N cm3/m3-tools/cvsup/suplib/src/TimeStampLogger.i3 > N cm3/m3-tools/cvsup/suplib/src/SysLogger.m3 > N cm3/m3-tools/cvsup/suplib/src/GzipWr.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSDelta.m3 > N cm3/m3-tools/cvsup/suplib/src/DevT.i3 > N cm3/m3-tools/cvsup/suplib/src/TokScan.m3 > N cm3/m3-tools/cvsup/suplib/src/UnixMisc.m3 > N cm3/m3-tools/cvsup/suplib/src/Attic.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSAccess.m3 > N cm3/m3-tools/cvsup/suplib/src/CVTree.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSFile.m3 > N cm3/m3-tools/cvsup/suplib/src/WatchDog.i3 > N cm3/m3-tools/cvsup/suplib/src/RegEx.m3 > N cm3/m3-tools/cvsup/suplib/src/SplitLogger.m3 > N cm3/m3-tools/cvsup/suplib/src/MD5Digest.m3 > N cm3/m3-tools/cvsup/suplib/src/StatusFile.i3 > N cm3/m3-tools/cvsup/suplib/src/Reaper.i3 > N cm3/m3-tools/cvsup/suplib/src/DirEntry.m3 > N cm3/m3-tools/cvsup/suplib/src/Umd5.i3 > N cm3/m3-tools/cvsup/suplib/src/TimeStampLogger.m3 > N cm3/m3-tools/cvsup/suplib/src/FileStatusRaw.i3 > N cm3/m3-tools/cvsup/suplib/src/Attic.m3 > N cm3/m3-tools/cvsup/suplib/src/SupFileRec.m3 > N cm3/m3-tools/cvsup/suplib/src/GzipRd.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSTag.m3 > N cm3/m3-tools/cvsup/suplib/src/FileAttr.m3 > N cm3/m3-tools/cvsup/suplib/src/Ugzip.i3 > N cm3/m3-tools/cvsup/suplib/src/StatusFile.m3 > N cm3/m3-tools/cvsup/suplib/src/MD5Wr.m3 > N cm3/m3-tools/cvsup/suplib/src/ProcTitle.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSDelta.i3 > N cm3/m3-tools/cvsup/suplib/src/RsyncFile.m3 > N cm3/m3-tools/cvsup/suplib/src/EscapedWr.m3 > N cm3/m3-tools/cvsup/suplib/src/RCSDate.m3 > N cm3/m3-tools/cvsup/suplib/src/RCSPhrases.i3 > N cm3/m3-tools/cvsup/suplib/src/CText.i3 > N cm3/m3-tools/cvsup/suplib/src/AuthMD5.m3 > N cm3/m3-tools/cvsup/suplib/src/EscapedWr.i3 > N cm3/m3-tools/cvsup/suplib/src/CVProto.m3 > N cm3/m3-tools/cvsup/suplib/src/Glob.m3 > N cm3/m3-tools/cvsup/suplib/src/EscapedRd.m3 > N cm3/m3-tools/cvsup/suplib/src/RCSPhrases.m3 > N cm3/m3-tools/cvsup/suplib/src/SigHandler.i3 > N cm3/m3-tools/cvsup/suplib/src/UnixMiscC.c > N cm3/m3-tools/cvsup/suplib/src/Uglob.i3 > N cm3/m3-tools/cvsup/suplib/src/LoggerClass.i3 > N cm3/m3-tools/cvsup/suplib/src/Logger.i3 > N cm3/m3-tools/cvsup/suplib/src/GlobTree.i3 > N cm3/m3-tools/cvsup/suplib/src/GlobTree.m3 > N cm3/m3-tools/cvsup/suplib/src/Reaper.m3 > N cm3/m3-tools/cvsup/suplib/src/Logger.m3 > N cm3/m3-tools/cvsup/suplib/src/SigHandler.m3 > N cm3/m3-tools/cvsup/suplib/src/RCSDate.i3 > N cm3/m3-tools/cvsup/suplib/src/UnixMisc.i3 > N cm3/m3-tools/cvsup/suplib/src/CVTree.m3 > N cm3/m3-tools/cvsup/suplib/src/WrLogger.m3 > N cm3/m3-tools/cvsup/suplib/src/LockFile.m3 > N cm3/m3-tools/cvsup/suplib/src/m3makefile > N cm3/m3-tools/cvsup/suplib/src/ChannelMux.i3 > N cm3/m3-tools/cvsup/suplib/src/TokScan.i3 > N cm3/m3-tools/cvsup/suplib/src/ErrMsg.i3 > N cm3/m3-tools/cvsup/suplib/src/ChannelMux.m3 > N cm3/m3-tools/cvsup/suplib/src/FileStatus.m3 > N cm3/m3-tools/cvsup/suplib/src/PathComp.i3 > N cm3/m3-tools/cvsup/suplib/src/MD5Digest.i3 > N cm3/m3-tools/cvsup/suplib/src/GzipError.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSKeyword.i3 > N cm3/m3-tools/cvsup/suplib/src/MD5.m3 > N cm3/m3-tools/cvsup/suplib/src/PathComp.m3 > N cm3/m3-tools/cvsup/suplib/src/GzipError.m3 > N cm3/m3-tools/cvsup/suplib/src/SysLogger.i3 > N cm3/m3-tools/cvsup/suplib/src/FileID.m3 > N cm3/m3-tools/cvsup/suplib/src/MD5Wr.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSPhrase.m3 > N cm3/m3-tools/cvsup/suplib/src/RegEx.i3 > N cm3/m3-tools/cvsup/suplib/src/Glob.i3 > N cm3/m3-tools/cvsup/suplib/src/FileID.i3 > N cm3/m3-tools/cvsup/suplib/src/SupFileRec.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSTag.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSKeyword.m3 > N cm3/m3-tools/cvsup/suplib/src/WrLogger.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSDeltaClass.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSRevNum.m3 > N cm3/m3-tools/cvsup/suplib/src/CVProto.i3 > N cm3/m3-tools/cvsup/suplib/src/RCSFile.i3 > N cm3/m3-tools/cvsup/suplib/src/LockFile.i3 > N cm3/m3-tools/cvsup/suplib/src/Ugzip.m3 > N cm3/m3-tools/cvsup/suplib/src/RsyncBlock.i3 > N cm3/m3-tools/cvsup/suplib/src/GzipWr.m3 > N cm3/m3-tools/cvsup/suplib/src/libmd/md5hl.c > N cm3/m3-tools/cvsup/suplib/src/libmd/md5.h > N cm3/m3-tools/cvsup/suplib/src/libmd/md5c.c > N cm3/m3-tools/cvsup/suplib/src/libmd/m3makefile > N cm3/m3-tools/cvsup/suplib/src/libmd/md5.copyright > N cm3/m3-tools/cvsup/suplib/src/libglob/fnmatch.h > N cm3/m3-tools/cvsup/suplib/src/libglob/fnmatch.c > N cm3/m3-tools/cvsup/suplib/src/libglob/m3makefile > N cm3/m3-tools/cvsup/suplib/src/dev_t_linux/DevTLinux.i3 > N cm3/m3-tools/cvsup/suplib/src/dev_t_linux/m3makefile > N cm3/m3-tools/cvsup/suplib/src/dev_t_linux/DevT.m3 > N cm3/m3-tools/cvsup/suplib/src/POSIX/ProcTitle.m3 > N cm3/m3-tools/cvsup/suplib/src/POSIX/m3makefile > N cm3/m3-tools/cvsup/suplib/src/POSIX/FileAttrOS.m3 > N cm3/m3-tools/cvsup/suplib/src/text_cm3/SupMiscText.m3 > N cm3/m3-tools/cvsup/suplib/src/text_cm3/CText.m3 > N cm3/m3-tools/cvsup/suplib/src/text_cm3/m3makefile > N cm3/m3-tools/cvsup/suplib/src/text_pm3/SupMiscText.m3 > N cm3/m3-tools/cvsup/suplib/src/text_pm3/CText.m3 > N cm3/m3-tools/cvsup/suplib/src/text_pm3/m3makefile > N cm3/m3-tools/cvsup/suplib/src/FreeBSD/UProcTitle.c > N cm3/m3-tools/cvsup/suplib/src/FreeBSD/FileAttrOS.i3 > N cm3/m3-tools/cvsup/suplib/src/FreeBSD/ProcTitle.m3 > N cm3/m3-tools/cvsup/suplib/src/FreeBSD/m3makefile > N cm3/m3-tools/cvsup/suplib/src/FreeBSD/UProcTitle.i3 > N cm3/m3-tools/cvsup/suplib/src/FreeBSD/FileAttrOS.m3 > N cm3/m3-tools/cvsup/suplib/src/dev_t_posix/m3makefile > N cm3/m3-tools/cvsup/suplib/src/dev_t_posix/DevT.m3 > N cm3/m3-tools/cvsup/config/src/m3makefile > N cm3/m3-tools/cvsup/suptcp/Makefile > N cm3/m3-tools/cvsup/suptcp/src/COPYRIGHT > N cm3/m3-tools/cvsup/suptcp/src/README > N cm3/m3-tools/cvsup/suptcp/src/m3makefile > N cm3/m3-tools/cvsup/suptcp/src/POSIX/COPYRIGHT > N cm3/m3-tools/cvsup/suptcp/src/POSIX/SupTCPHackNull.m3 > N cm3/m3-tools/cvsup/suptcp/src/POSIX/SupTCPHack.i3 > N cm3/m3-tools/cvsup/suptcp/src/POSIX/SupTCP.m3 > N cm3/m3-tools/cvsup/suptcp/src/POSIX/SockOptOther.m3 > N cm3/m3-tools/cvsup/suptcp/src/POSIX/SockOpt.i3 > N cm3/m3-tools/cvsup/suptcp/src/POSIX/SupTCPHack.m3 > N cm3/m3-tools/cvsup/suptcp/src/POSIX/SupTCPPosix.i3 > N cm3/m3-tools/cvsup/suptcp/src/POSIX/m3makefile > N cm3/m3-tools/cvsup/suptcp/src/POSIX/SockOptFBSD.m3 > N cm3/m3-tools/cvsup/suptcp/src/common/StreamWrClass.m3 > N cm3/m3-tools/cvsup/suptcp/src/common/COPYRIGHT > N cm3/m3-tools/cvsup/suptcp/src/common/StreamRdClass.m3 > N cm3/m3-tools/cvsup/suptcp/src/common/TCPMisc.i3 > N cm3/m3-tools/cvsup/suptcp/src/common/StreamRd.i3 > N cm3/m3-tools/cvsup/suptcp/src/common/SupConnRW.i3 > N cm3/m3-tools/cvsup/suptcp/src/common/SupConnFD.i3 > N cm3/m3-tools/cvsup/suptcp/src/common/SupErrno.i3 > N cm3/m3-tools/cvsup/suptcp/src/common/m3makefile > N cm3/m3-tools/cvsup/suptcp/src/common/SupTCP.i3 > N cm3/m3-tools/cvsup/suptcp/src/common/StreamWrClass.i3 > N cm3/m3-tools/cvsup/suptcp/src/common/SupErrnoC.c > N cm3/m3-tools/cvsup/suptcp/src/common/StreamWr.i3 > N cm3/m3-tools/cvsup/suptcp/src/common/SupConnRW.m3 > N cm3/m3-tools/cvsup/suptcp/src/common/StreamRdClass.i3 > N cm3/m3-tools/cvsup/quake/cvsup.quake > N cm3/m3-tools/cvsup/server/Makefile > N cm3/m3-tools/cvsup/server/src/ClassDB.m3 > N cm3/m3-tools/cvsup/server/src/ClientClass.i3 > N cm3/m3-tools/cvsup/server/src/FSServer.m3 > N cm3/m3-tools/cvsup/server/src/cvsupd.cat > N cm3/m3-tools/cvsup/server/src/Passwd.i3 > N cm3/m3-tools/cvsup/server/src/Version.i3 > N cm3/m3-tools/cvsup/server/src/ClientClass.m3 > N cm3/m3-tools/cvsup/server/src/cvsupd.class.cat > N cm3/m3-tools/cvsup/server/src/FSServerU.m3 > N cm3/m3-tools/cvsup/server/src/FSServer.i3 > N cm3/m3-tools/cvsup/server/src/AccessRules.i3 > N cm3/m3-tools/cvsup/server/src/ParsedDelta.m3 > N cm3/m3-tools/cvsup/server/src/Main.m3 > N cm3/m3-tools/cvsup/server/src/cvsupd.8 > N cm3/m3-tools/cvsup/server/src/AccessRules.m3 > N cm3/m3-tools/cvsup/server/src/TreeComp.i3 > N cm3/m3-tools/cvsup/server/src/ClassDB.i3 > N cm3/m3-tools/cvsup/server/src/FileInfo.i3 > N cm3/m3-tools/cvsup/server/src/Passwd.m3 > N cm3/m3-tools/cvsup/server/src/m3makefile > N cm3/m3-tools/cvsup/server/src/FileInfo.m3 > N cm3/m3-tools/cvsup/server/src/RCSComp.i3 > N cm3/m3-tools/cvsup/server/src/ParsedDelta.i3 > N cm3/m3-tools/cvsup/server/src/cvsupd.class.5 > N cm3/m3-tools/cvsup/server/src/TreeComp.m3 > N cm3/m3-tools/cvsup/server/src/RCSComp.m3 > N cm3/m3-tools/cvsup/server/src/FSServerRep.i3 > > No conflicts created by this import > From hendrik at topoi.pooq.com Thu Apr 9 21:43:37 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 9 Apr 2009 15:43:37 -0400 Subject: [M3devel] small objects In-Reply-To: <200904091527.n39FRBF0031475@camembert.async.caltech.edu> References: <20090409143440.GA13374@topoi.pooq.com> <200904091527.n39FRBF0031475@camembert.async.caltech.edu> Message-ID: <20090409194337.GA14441@topoi.pooq.com> On Thu, Apr 09, 2009 at 08:27:11AM -0700, Mika Nystrom wrote: > > hendrik at topoi.pooq.com writes: > >> > >> Note that, as we probably all know, the Modula-3 designers expressly > >> considered, and rejected, full variant records. > > > >Are these the factors they based their decision on? > > > >(1) The ones in Pascal are insecure without a lot of run-time checking. > > > >(2) Objects and inheritance take care of much of the functionality. > > > >(3) The ones in Algol 68 involve copying entire records when > >construction and deconstructing unions of records. > > (1) and (2) at least. I'll quote: > > "[talk about runtime errors due to freeing still-used references] > > Another well-known runtime error is to assign to the tag of a variant > record in a way that subverts the type system. Distinguishing > subversive assignments from benign assignments in the language > definition is error-prone and arbitrary. If I recall the Pascal definition correctly, the only assignment that was allowed to the tag of a variant was to assign the entire record, including the tag and the variant. I don't know of any Pascal compiler that even tries to check this. > The objects and classes > first introduced in Simula and adopted in Oberon and Object Pascal > are more general than variant records, and they are safe, so we > have discarded variant records and adopted objects. > > [talk about objects]" > > (See Cardelli et al., "The Modula-3 Type System" (c) 1989 ACM.) > > Mika > > > > >What we're considering not is the case in which (2) provides > >excessive indirection and garbage-collector load, and in which > >the copying in (3) is really cheap. There are applications > >for which this feature could have major effects on efficiency. > >I have some I'd consider rewriting from C/C++ to Modula 3 > >if this feature were available. > > > >-- hendrik > .... From martinbishop at bellsouth.net Thu Apr 9 22:28:58 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Thu, 09 Apr 2009 15:28:58 -0500 Subject: [M3devel] CM3 Release Message-ID: <49DE5A8A.5070307@bellsouth.net> A few days ago there was more talk of a proper "release" for CM3. I think this is very important. Even if this proper release is just full binary versions, I think it would make a big difference. These could then be used to make .deb packages for Debian/Ubuntu, and hopefully other Linux/BSD distributions. Does the Windows version come with an installer? If not, I think it should. Also, along with easy to install releases, I think a good book/tutorial should be available online for Modula-3. We already know Nelson's book is caught up with copyright stuff, but I wonder if the same is true for Harbison's book? If neither can be released online, perhaps we should try to improve the existing tutorial? (http://www.opencm3.net/doc/tutorial/m3/m3_toc.html) A lot of people right off Modula-3 as being dead because they don't even know that a good, free implementation like CM3 exists. I think the above ideas would help. From jay.krell at cornell.edu Thu Apr 9 23:53:20 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 9 Apr 2009 21:53:20 +0000 Subject: [M3devel] CM3 Release In-Reply-To: <49DE5A8A.5070307@bellsouth.net> References: <49DE5A8A.5070307@bellsouth.net> Message-ID: Historically the Windows version came with the command line cminstall. It also looked in the registry for stuff. A GUI installer that is just a glorofied unzipper is easy enough and I agree has some value. I put one together a few weeks ago. Something that does a little more to find the compiler/linker or setup a "shortcut" to a command line with environment variables might be nice. >> Even if this proper release is just full binary versions, I think it >> would make a big difference. These could then be used to make .deb Uploaded-archives already exists, with a bunch of fairly current archives.. Try them? (Thanks to Carson for trying them, wrt cvsup; I'm addressing that.) >>>>>> Just does qualifies as a release anyway? <<<<<<< More testing?? What are people's thoughts/abilities/experience on getting into: *BSD ports -- well, FreeBSD already has ezm3, that counts for something Debian, Ubuntu, Suse, Fedora, etc. repositories? You need to wrangle an approved developer into submitting the package? Olaf is clearly working on something here -- improving cminstall. I'm working on: get cvsup building, this won't take long Debugging the formsedit crash; this might take long. Moving FreeBSD/x86 to new smaller Unix/*.i3 files. This shouldn't take long. Bootstrapping from whatever platform I first did yielded invalid assembly. I'm going to try from Cygwin instead before I debug further -- something simple about how the PIC "get PC" stub's section is generated..linkonce or not, I tried editing it with Perl to match C compiler output but got it wrong. This will leave I386_DARWIN, AMD64_DARWIN as the main holdouts -- I don't have hardware for them (yet). Fixing up issues around paths to shared libraries, $ORIGIN, etc. - Like, restore buildlocal to old behavior; keep buildglobal with new behavior - move FreeBSD/x86 to use $ORIGIN with buildglobal After that, I'll probably introduce new platforms I386_LINUX, I386_FREEBSD, SPARC32_SOLARIS, I386_NT, I386_CYGWIN, I386_MINGW that are equivalent to today's LINUXLIBC6, FreeBSD4, SOLgnu/SOLsun, NT386, NT386GNU, NT386MINGNU. And put together some "boot" archives that factor out C ABI issues, OS major version variants, are very cross buildable, and produce not just cm3, but "everything" -- you compile the C and link on the target system. This way, perhaps, a lot of producing a release can fully automated on one build host. (And after all that, maybe get back to ARM_LINUX_OLDABI_UCLIBC or whatever it should be called...but a new ARM device is en route, maybe ARM_LINUX_NEWABI_GLIBC. :)) I also need to get m3gdb and cm3ide into my releases, that's comes before introducing new platform names. This entire list is not required for making a release, but m3gdb and cm3ide probably are. Some of the uploaded archives should be updated too, such as SPARC32_{LINUX,OPENBSD}. There's also a bunch of other ports I'd like to get through but they don't block a release. We should maybe split platforms into "tier 1" and "tier 2". Just because I released something, doesn't make it to tier 1. :) Tier 2 can be missing from a release or having bugs, without holding up other releases. - Jay > Date: Thu, 9 Apr 2009 15:28:58 -0500 > From: martinbishop at bellsouth.net > To: m3devel at elegosoft.com > Subject: [M3devel] CM3 Release > > A few days ago there was more talk of a proper "release" for CM3. I > think this is very important. > > Even if this proper release is just full binary versions, I think it > would make a big difference. These could then be used to make .deb > packages for Debian/Ubuntu, and hopefully other Linux/BSD distributions. > > Does the Windows version come with an installer? If not, I think it should. > > Also, along with easy to install releases, I think a good book/tutorial > should be available online for Modula-3. We already know Nelson's book > is caught up with copyright stuff, but I wonder if the same is true for > Harbison's book? > > If neither can be released online, perhaps we should try to improve the > existing tutorial? (http://www.opencm3.net/doc/tutorial/m3/m3_toc.html) > > A lot of people right off Modula-3 as being dead because they don't even > know that a good, free implementation like CM3 exists. I think the > above ideas would help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.m.bates at cox.net Fri Apr 10 00:13:52 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Thu, 09 Apr 2009 17:13:52 -0500 Subject: [M3devel] small objects In-Reply-To: <200904091527.n39FRBF0031475@camembert.async.caltech.edu> References: <200904091527.n39FRBF0031475@camembert.async.caltech.edu> Message-ID: <49DE7320.6090506@cox.net> Mika Nystrom wrote: > hendrik at topoi.pooq.com writes: > >> On Thu, Apr 09, 2009 at 07:10:44AM -0700, Mika Nystrom wrote: >> >>> I don't know why we're having such a tough time understanding each >>> other here :-) >>> >>> I think that what Rodney says is that he wants (in pseudo-modula-2 >>> syntax): >>> >>> T = CASE LSB OF >>> 1 : SmallInt >>> | >>> 0 : U >>> END; >>> >>> SmallInt = [SmallMin..SmallMax]; >>> >>> for any reference type U. >>> >> Yes. That's what I wanted too, originally. I can accept the >> restriction that the reference type U might be restricted to be >> REFANY. >> > > I think this is what Tony says he's implemented, essentially... > > ... > >>> The only problem I have with this (except for the changes necessary >>> to Modula-3) is that it can't be held in a REFANY, and that's part >>> of the design. >>> >> Much better not to pervert REFANY, but use a new type instead. >> > > Are you sure? I want a type---some type---that can hold "any > reference, even a tagged one", and I would rewrite most library > code that today takes REFANY to take that instead. Why not? Why > would I want to limit it to REFANY when it performs no operations > that couldn't legally be performed on TAGGED REFANY. > I believe my "safe" proposal would make this very simple, if I am thinking of the kind of library code you are. I envision a container data structure that takes in things and returns them without performing operations on them other than moving them around and storing them, e.g. the ever belabored stack. The values going in and out are declared REFANY, and the client passes in values of some proper subtype of REFANY, which get assigned to the REFANY parameters. When it gets them back, it narrows them to this type. In this pattern, just changing the declared type of the container values from REFANY to TAGGED REFANY would do it. The library code's storage and copying of the values would all work as before, and the client's passing to TAGGED REFANY and later narrowing it to whatever reference type it put in would also work as before, using the extended semantics of assignments and narrowing operations. > >>> Of course we could go halfway and let it be held in a REFANY, but >>> then you get the runtime LSB check again, for all instances of >>> REFANY, >>> >> I really don't like requiriny a run-time check on REFANY. That's why >> I want it to be a separate type. >> > > All the operations in question already require (*much* more > complicated) run-time checks on REFANY.... and most uses of REFANY > still wouldn't require the LSB check. > > I really think the runtime issue is a non-issue, and as I said > above, if it turns out to be a real issue, one can either abandon > the change (since the whole thing can be implemented transparently > with a library) or else re-root ROOT and all the REF types in a new > NOTQUITEREFANY type. This would be a backward-compatible change > (in every sense) with Tony's runtime changes: > > REFANY ; (* Tony's, with the LSB trick *) > > NOTQUITEREFANY <: REFANY; > > ROOT <: NOTQUITEREFANY; > > REF T <: NOTQUITEREFANY; (* for all T *) > > After that, future, change, people who want to avoid the LSB check > on REFANY can instead use NOTQUITEREFANY. I think barely anyone > will bother. > > Come to think of it, Modula-3 doesn't specify that there's no > intermediate type between REFANY and ROOT and the other REF T's, > so there's no way it could break the current language. In > fact you don't have to "reveal" this new type in the language > specification at all. It could just be a library type > NotQuiteRefany.T. > > You could then introduce separately, a la Rodney, > > TAGGED T <: REFANY; (* for all T *) > > (* but *not* TAGGED T <: NOTQUITEREFANY *) > > > >>> but maybe it doesn't break anything else. Although you do >>> in any case get LSB checks all over the place (in safe code!) where >>> the TAGGED U is revealed to be a TAGGED U. >>> >>> Note that, as we probably all know, the Modula-3 designers expressly >>> considered, and rejected, full variant records. >>> >> Are these the factors they based their decision on? >> >> (1) The ones in Pascal are insecure without a lot of run-time checking. >> >> (2) Objects and inheritance take care of much of the functionality. >> >> (3) The ones in Algol 68 involve copying entire records when >> construction and deconstructing unions of records. >> > > (1) and (2) at least. I'll quote: > > "[talk about runtime errors due to freeing still-used references] > > Another well-known runtime error is to assign to the tag of a variant > record in a way that subverts the type system. Distinguishing > subversive assignments from benign assignments in the language > definition is error-prone and arbitrary. The objects and classes > first introduced in Simula and adopted in Oberon and Object Pascal > are more general than variant records, and they are safe, so we > have discarded variant records and adopted objects. > > [talk about objects]" > > (See Cardelli et al., "The Modula-3 Type System" (c) 1989 ACM.) > > Mika > > >> What we're considering not is the case in which (2) provides >> excessive indirection and garbage-collector load, and in which >> the copying in (3) is really cheap. There are applications >> for which this feature could have major effects on efficiency. >> I have some I'd consider rewriting from C/C++ to Modula 3 >> if this feature were available. >> >> -- hendrik >> > .... > > From rodney.m.bates at cox.net Fri Apr 10 00:00:55 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Thu, 09 Apr 2009 17:00:55 -0500 Subject: [M3devel] small objects In-Reply-To: References: <200904090038.n390cNsg097270@camembert.async.caltech.edu> <49DD59DB.4050404@cox.net> <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> Message-ID: <49DE7017.1010902@cox.net> Without language changes, this could be useful. It does use two words instead of one, with always one or the other being wasted. But in my 11-to-1 example, it would give 11-to-2 savings--not to be sneezed at. One limitation it has is, to get the benefit, you have to stored the two-word record itself embedded wherever the pointer would have been, not out in the heap. So it's not a reference type and thus can't be opaque. No type unsafely here, but client code can not be prevented from breaking the abstraction. There are places in the M3 distribution where a non-reference type has a comment (* Treat as opaque *). Jay wrote: > Um, what do folks think of, like: > > struct > { > void* Type; > union > { > size_t Integer; > void* Pointer; > } Value; > } Variant; > > ? > You know -- something that is two pointers, one pointer for the type, > one for the value or integer? > void* Type would actually be a pointer to something actually defined > and elaborate. > > Obviously this is twice as large, not as small as it could be, but > much more general and portable. No need to determine how many of bits > can be the tag. > > And hope/assume for perf that such a small struct is passed in registers. > On x86/NT 4 and 8 byte structs I think are. > > Type could also be an integer, index into some table, with some > predefined values. > #define TYPE_INTEGER 0 > #define TYPE_FLOAT 1 > #define TYPE_DOUBLE 2 > #define TYPE_ADDRESS 3 > > more generally the union would have a float, and maybe a double on > 64bit platforms. > > OR, on 64bit platforms, you probably can, with some porting work, > dedicate a whole 8 bits or so to a type index, and still the thing in > one "word". How many bits of address space does any 64bit platform > these days or forseeable future actually implement? > > But 32 bits doesn't seem big enough to afford that, and still this is > a portability problem -- anything less than a full pointer. > > - Jay From rodney.m.bates at cox.net Thu Apr 9 23:50:45 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Thu, 09 Apr 2009 16:50:45 -0500 Subject: [M3devel] small objects In-Reply-To: <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> References: <200904090038.n390cNsg097270@camembert.async.caltech.edu> <49DD59DB.4050404@cox.net> <7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu> Message-ID: <49DE6DB5.7080807@cox.net> Tony Hosking wrote: > Sounds like you want something like: > > TAGGED REFANY FOR T > > where T must be a type that fits into BITS(REFANY)-1? Almost. But instead of a union of an arbitrary ordinal type with just REFANY, I want a union of just one ordinal type (TAG, a new language-defined subrange of INTEGER, with implementation-defined bounds) and an arbitrary traced reference or object type. I think just one ordinal type is adequate, but there are advantages to not having it restricted to REFANY, see below. Two tagged types constructed from different reference types are not the same type, have no subtype relation between them, and no assignability between them. This despite the fact that they will have overlapping value sets. There are other places in the language where this happens already. But RefType <: TAGGED RefType and TAG <: TAGGED RefType, so you can assign between a tagged type and either the reference type it is built from, or TAG. When going from the tagged type, these assignments require narrowing operations. Going to a tagged type is allowed by existing assignability rules, and the implementation can simply copy the bits at runtime. > > Branding could be used to prevent mixing otherwise structurally > equivalent TAGGED REFANY. Yes, some kind of branding is essential to allow otherwise structurally equivalent tagged types to be made unique. In my "safe" proposal, you can build a tagged type from a branded reference type, and it will inherit the uniqueness of the branded reference type. This simplifies the implementation, because BRANDED does not need to be extended to a non-reference type. Allowing a tagged type to be constructed from any reference type also means you can construct it from an opaque type if this is what you want, and it will inherit the opaqueness, as well as what's visible, from the opaque type. In unrevealed contexts, you can still narrow it to an integer and you can narrow it to the opaque type, then do whatever operations are visible in the opaque type. Example: TYPE Public = OBJECT METHODS m() END; TYPE Op <: Public; TYPE T = TAGGED Op; VAR VT: T := ... Here, without a revelation, you can do TYPECASE VT OF Op (o) => o.m() ... > > TAGGED BRANDED REFANY FOR T > > Where this breaks down is what are the subtyping rules, since I assume > you'd like to store these in a REFANY and dynamically test for the > appropriate tagged type: No, I do not want to store these in a variable of type REFANY or any other existing type. In fact, I want to forbid it. I want to store them only in a variable declared of a TAGGED type. To get the reference value out of a tagged type, do a NARROW or one of its equivalents and store the result in a REFANY. All the existing reference types and the allowable operations on them are unchanged. Only the narrowing operations make a runtime check of the tag bit. Similarly, for an integer value, narrow it and assign to an INTEGER variable. > > TAGGED REFANY FOR T <: REFANY > > But then how do we distinguish all the different TAGGED REFANY from > each other at run-time? All the tagged types are statically distinct and thus no runtime distinction is needed. The only new RT distinction is whether the value of a single tagged type is a member of TAG or of the underlying RefType. > > On 9 Apr 2009, at 12:13, Rodney M. Bates wrote: > >> Mika Nystrom wrote: >>> Hmm, ok, there's one big difference between what you're saying and >>> what Tony and I have been talking about. (I think your understanding >>> sounds pretty correct.) >>> >>> You want to do objects other than small integers. Like what? And why? >>> I was thinking the trick would apply only to one specific type of >>> integer. >>> >> >> Yes, I want a language mechanism that can be used by various >> modules to implement various abstract data types, each of which >> can perform the sometimes dramatic space optimization of putting >> values that are common and will fit directly in the word. >> One module I spoke of implements general sets of integers with >> dynamically variable and sometimes large range. This differs from >> the builtin SET OF.., which must have a static (and probably relatively >> small) base subrange. Thus the general, heap-allocated values contain >> open arrays of Word.T, treated as sets, or if you prefer, packed arrays >> of booleans, although I manipulate them with bit-twiddling operations >> from Word. >> There is another, static-sized, heap-allocated object in front of >> each array, >> containing biases on what bits correspond to what integers in the >> abstract set, etc. It all works fine now, but the usage pattern of >> some >> clients has a high percentage very small sets that would fit in a word, >> and there would be an 11-to-1 space savings if that could be done. >> BTW, there are also two different kinds of heap objects, one that >> represents a range set by just its bounds. So I am TYPECASEing >> these already. It would be very convenient if I could just add another >> alternative to the TYPECASE for in-word values. >> >> In another case, I need truly dynamically variable sized arrays of >> integers in [0..15], and the great majority are 7 elements or less, >> which would fit directly in the word, but I still the need full >> generality >> to be available, so it's open arrays all the time, with three additional >> words each. >> >> If you can pack a union of a pointer and an integer into a word and >> can separate them with runtime checks, then you can use the >> separated integer any way you want, with bit twiddling, type >> conversions, >> LOOPHOLE, or whatever. That is what I am trying to get, not just >> Smalltalk-like integers. >> Note that Smalltalk has zero static typing, so only one internal >> representation must do for the union of all possible values in >> the language. In Modula-3, it would be very inconsistent with >> the language's philosophy to be this restricted. >>> Hmm, so your idea is to statically determine what type the references >>> can have if they are non-references. So you are thinking to put >>> various >>> kinds of subranges into the "TAGGED" types. But you have to be able to >>> determine, statically, which subrange it is... am I understanding this >>> correctly? >>> >> >> From the language, all I want is to be able to dynamically determine >> whether it is a true pointer to a heap object or a value stored >> directly in the word, while preserving the safety principles and >> the semantics of everything already there. So I want some new >> types, different from any existing types, that statically are known >> to hold this kind of valueset union and can be converted/assigned >> to a variable of existing type that is statically known to be either a >> pointer or an integer (but not both), with a suitable runtime check. >> It is also necessary to have a way to do this without risking a runtime >> error, if your code doesn't know yet which kind of value it has. >> Various ADT modules can take it from there. >>> Mika >>> >>> "Rodney M. Bates" writes: >>> >>>> Tony Hosking wrote: >>>> >>>>> On 8 Apr 2009, at 11:49, Rodney M. Bates wrote: >>>>> >>>>> >>>>>> Mika Nystrom wrote: >>>>>> >>>>>>> Hendrik, I think Tony's and my arguments that you can't break any >>>>>>> existing code by allowing the squirreling away of integers into >>>>>>> REFANYs are pretty solid. Pre-existing code simply can't do >>>>>>> anything >>>>>>> useful with unrevealed REFANYs. >>>>>>> >>>>>> This is only true of _unrevealed opaque subtypes_ of REFANY, >>>>>> not of REFANY itself. There is lots of existing code that uses >>>>>> REFANY, >>>>>> and there, ISTYPE, NARROW, TYPECASE, and assigment can be and >>>>>> regularly are used on it. It is essential not to alter the >>>>>> semantics there. >>>>>> >>>>> Pre-existing code won't be able to do anything useful with tagged >>>>> REFANYs: >>>>> >>>>> Suppose we have >>>>> >>>>> VAR r: REFANY = SmallInteger.FromInt(0); >>>>> >>>>> then >>>>> >>>>> ISTYPE(r, REFANY) => TRUE >>>>> ISTYPE(r, T) => FALSE for any T # REFANY >>>>> >>>>> Similarly, for TYPECASE, r will only trigger the REFANY branch. >>>>> >>>>> NARROW(r, REFANY) => r >>>>> NARROW(r, T) => run-time error for any T #REFANY >>>>> >>>>> VAR x: REFANY => assignment succeeds >>>>> VAR x: T := r => run-time error for any T # REFANY (because of >>>>> implicit NARROW) >>>>> >>>> I think I am getting a bit lost in all the proposals, variations, >>>> counterproposals, etc., but >>>> >>> >from this argument I am inferring that your plan is that only >>> variables >>>> declared REFANY >>>> and not any proper subtype of REFANY can ever have a value with a >>>> tag bit set? Then >>>> the 4 narrowing operations, when and only when applied to an >>>> expression of static >>>> type REFANY, would change to make a runtime check for a tag bit and >>>> fail if it's set? >>>> It would take this to prevent a tagged value from getting into a >>>> variable declared a >>>> proper subtype of REFANY, which can be dereferenced. >>>> >>>> This would preclude making your abstract data type an opaque >>>> subtype of REFANY, >>>> and would mean all supposedly unrelated ADT modules that used the >>>> tag technique >>>> could be broken by client code that mixed up the REFANY values of >>>> one of them with >>>> those of another. I consider this a definite breach of Modula-3's >>>> otherwise bulletproof >>>> type safety. >>>>> It is impossible to dereference an expression statically typed as >>>>> REFANY, so there is no need for a "tagged" check on dereference. >>>>> Because a tagged REFANY cannot be assigned to anything other than >>>>> something typed REFANY, it can never propagate to a place where it >>>>> can be dereferenced. >>>>> >>>>> >>>>>> Aside from actual semantic changes, I agree with Tony that we should >>>>>> not burden any existing type with additional runtime work. Even >>>>>> though >>>>>> I expect small objects to support big performance gains in certain >>>>>> important cases, non-tagged references will still greatly >>>>>> predominate >>>>>> in most code. Create new type(s) for tagged references. >>>>>> >>>>> I'm not sure that we are seeing any semantic changes at all. And >>>>> with Mika's definition of SmallInteger.T as a "boxed" INTEGER >>>>> object (actually it would be a subrange for values that fit into >>>>> BITSIZE(Word.T)-1 bits), it is essentially transparent. It just >>>>> happens to be a run-time optimization that unboxes the INTEGER value. >>>>> >>>>> >>>>> I think I can implement the compiler and run-time support for this >>>>> very quickly. >>>>> >>>>> >>>>> >>> >>> > > From mika at async.caltech.edu Fri Apr 10 02:04:23 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 09 Apr 2009 17:04:23 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Thu, 09 Apr 2009 16:50:45 CDT." <49DE6DB5.7080807@cox.net> Message-ID: <200904100004.n3A04NlY051431@camembert.async.caltech.edu> Sorry to splice together two emails from you, but I feel I've already used up my m3devel quota this week: "Rodney M. Bates" writes: >> Are you sure? I want a type---some type---that can hold "any >> reference, even a tagged one", and I would rewrite most library >> code that today takes REFANY to take that instead. Why not? Why >> would I want to limit it to REFANY when it performs no operations >> that couldn't legally be performed on TAGGED REFANY. >> > >I believe my "safe" proposal would make this very simple, if I am >thinking of the kind of library code you are. > >I envision a container data structure that takes in things and returns >them without performing operations on them other than moving them around >and storing them, e.g. the ever belabored stack. The values going in >and out are declared REFANY, and the client passes in values of >some proper subtype of REFANY, which get assigned to the REFANY >parameters. When it gets them back, it narrows them to this type. > >In this pattern, just changing the declared type of the container values >from REFANY to TAGGED REFANY would do it. The library code's storage ... >> you'd like to store these in a REFANY and dynamically test for the >> appropriate tagged type: > >No, I do not want to store these in a variable of type REFANY or any >other existing type. >In fact, I want to forbid it. I think you are thinking of exactly the same kind of library code. TextRefTbl.T, RefList.T, etc. After the introduction of TAGGED REFANY, what use is there for REFANY? What piece of code can you think of where the cost of the 1-LSB check of TAGGED REFANY outweighs the convenience of being able to process objects of type TAGGED T (for all ref types T) as well as objects of type T? Mika From rodney.m.bates at cox.net Fri Apr 10 19:24:49 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Fri, 10 Apr 2009 12:24:49 -0500 Subject: [M3devel] small objects In-Reply-To: <200904100004.n3A04NlY051431@camembert.async.caltech.edu> References: <200904100004.n3A04NlY051431@camembert.async.caltech.edu> Message-ID: <49DF80E1.10709@cox.net> Mika Nystrom wrote: > Sorry to splice together two emails from you, but I feel I've already > used up my m3devel quota this week: > > "Rodney M. Bates" writes: > >>> Are you sure? I want a type---some type---that can hold "any >>> reference, even a tagged one", and I would rewrite most library >>> code that today takes REFANY to take that instead. Why not? Why >>> would I want to limit it to REFANY when it performs no operations >>> that couldn't legally be performed on TAGGED REFANY. >>> >>> >> I believe my "safe" proposal would make this very simple, if I am >> thinking of the kind of library code you are. >> >> I envision a container data structure that takes in things and returns >> them without performing operations on them other than moving them around >> and storing them, e.g. the ever belabored stack. The values going in >> and out are declared REFANY, and the client passes in values of >> some proper subtype of REFANY, which get assigned to the REFANY >> parameters. When it gets them back, it narrows them to this type. >> >> In this pattern, just changing the declared type of the container values >> > >from REFANY to TAGGED REFANY would do it. The library code's storage > ... > There are two very different kinds of uses of reference and tagged types. The one I speak of above is for the type of the elements inside a container data structure. In this case, it is the client that knows what type the value really is, and will declare it as such. The library ADT module should know as little as possible about it, so it will declare it as REFANY or TAGGED REFANY. Here, you want the most general type possible, just to make the abstraction more versatile. And TAGGED REFANY generalizes it from REFANY. But... > >>> you'd like to store these in a REFANY and dynamically test for the >>> appropriate tagged type: >>> >> No, I do not want to store these in a variable of type REFANY or any >> other existing type. >> In fact, I want to forbid it. >> > > I think you are thinking of exactly the same kind of library code. > TextRefTbl.T, RefList.T, etc. > > After the introduction of TAGGED REFANY, what use is there for > REFANY? What piece of code can you think of where the cost of the > 1-LSB check of TAGGED REFANY outweighs the convenience of being > able to process objects of type TAGGED T (for all ref types T) as > well as objects of type T? > The other use is for the abstract type itself. Forgetting tagged types for a moment, I have never seen an interface/module that uses REFANY for this. Instead, the modules declare their abstract type as some proper subtype of REFANY, usually an opaque type. It would be possible to use just REFANY here of course, but that would require an otherwise unnecessary RT check on the allocated type, every time an operation of the module is called. This is a much more expensive check than a tag check, as has been pointed out in this discussion. But worse, it would sacrifice the static checking that we now have that prevents, at compile time, clients from passing, say a Text.T to some procedure in Atom that expects an Atom.T. If these modules ever wanted to use a tagged type, but the only tagged type were REFANY, we would lose this static checking, because Text.T would have to become equal to Atom.T. In cases where your algorithms don't specifically need dynamic typing, static typing is always much better, because one run of the compiler on the source code will do it. Bugs checked only at runtime require a massive test suit to be coded and then regularly rerun to get even close to the same confidence they've been found. So when using tagged types as the ADT itself,, we need to be able to have a tagged version of whatever proper subtype of REFANY the abstraction needs, including an opaque subtype of REFANY or an opaque subtype of some Public subtype of REFANY. This is why I am adamant that we need to be able to build a tagged type from any traced or object type. And once you do this, keeping REFANY itself unchanged and allowing TAGGED REFANY as one case of a tagged type falls out of the system for free _and_ saves a lot of cases that would otherwise need a new RT check that can never fail, but the language can't know that, because the type system has lost the distinction. I really feel that the fad of all dynamic typing in languages is a huge mistake and that it will someday be recognized as such. In the meantime, we have a language that provides a very extensive set of statically-typed alternatives, while also allowing dynamic typing when you really need it. This is one of Modula-3's best principles. Let's don't erode the static alternatives unnecessarily. > Mika > > From wagner at elegosoft.com Fri Apr 10 20:07:31 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 10 Apr 2009 20:07:31 +0200 Subject: [M3devel] FW: cvsup In-Reply-To: References: <20090409170205.0D1CF60C150@birch.elegosoft.com> Message-ID: <20090410200731.nho013ykaowwc4s0@mail.elegosoft.com> Quoting Jay : > > This is the first time I've used cvs import. > Hopefully I don't mess it up much. > > This is just an initial import with no changes, no attempt to build it, etc. > I think that's the right approach. You should use the latest version from the DCVS repository; it should be much more compatible with the recent CM3. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mika at async.caltech.edu Fri Apr 10 20:35:10 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 10 Apr 2009 11:35:10 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Fri, 10 Apr 2009 12:24:49 CDT." <49DF80E1.10709@cox.net> Message-ID: <200904101835.n3AIZACW001487@camembert.async.caltech.edu> Ahhhh!!!!! Now I get it, Rodney! You're talking about using tagged types "within" Modula-3. I've just been asking for tagged types to do something "that's not Modula-3". I'm completely aware that passing REFANY around is not the "Modula-3 way", and had no intention of making it so. (That's why I keep saying that only lazy people do it, so it doesn't matter.) My desire for storing integers and pointers in the same machine word is not something I thought would ever be useful in Modula-3 itself. But now what you say makes sense to me... you want to build your ADTs with this. Then you do need the full M3 type system "above" your tagged reference. I agree with you on MOST of the following: >I really feel that the fad of all dynamic typing in languages is a huge >mistake and that it will someday be recognized as such. In the >meantime, we have a language that provides a very extensive set >of statically-typed alternatives, while also allowing dynamic typing >when you really need it. This is one of Modula-3's best principles. >Let's don't erode the static alternatives unnecessarily. I program, currently, mostly in Scheme and in Modula-3, (mostly M3) and I am constantly amazed by: 1. The way that Modula-3 programs often are correct the first time they are compiled, even if they haven't been carefully designed. Using the M3 type system can really make your code obviously correct. 2. The way that Scheme programs can sometimes abstract away all sorts of type irrelevancies. In M3 you'd have to have many versions of the same code, or at least many generic instances. This is especially true for "higher-higher order" types, where one type is made from another and that was made from another, etc. (Interpret "type" liberally, please. It's probably just some sort of lambda expression.) Now I agree that untyped languages are probably a fad, and they have set computing back by years or decades(?). Too easy to make mistakes. But there is something of value there, and my feeling is that the best way to take advantage of it is to *combine* the two worlds, rather than trying to come up with some sort of "super language" that incorporates the best of both worlds and somehow manages to step on no one's toes. I'm presenting this as an alternative to type inferencing schemes in environments such as ML. So my idea, my "vision" if you like, is that we embed untyped languages in Modula-3. The parts of the system that need performance or are more convenient to program in the "bondage and discipline" world of Algol get written in Modula-3, and the parts of the system that it is more convenient (all things considered) to program in a typeless environment can be programmed in Scheme (currently, other interpreted languages can be added later if this turns out to be a good idea). But it is clear that the typeless approach of REFANY (REALLYREFANY, including the tagged types) is necessary to implement this layer of the system---if you want to be able to pass data structures seamlessly between the two layers. Maybe that explains better where I'm coming from. I have no intention of using these types for Modula-3 programming :-) However, I do see your point. A facility provided is a facility used, so if there's a very compact way of storing data in pointers, other applications than the ones I have in mind will use them, too, and perhaps lead to an abuse of Modula-3. But I'm not sure if this isn't over the line of legislating programming *style*---if we go down that route, we can do it the Java way and ban UNSAFE as well, so people won't be tempted to program C in Modula-3. In any case, the particular feature that one can hide 31 bits of information in a REFANY (and only a REFANY) can't hurt you if you don't choose to avail yourself of it---in fact it's transparent to people who don't care about it. Ok, an added 2 instructions out of 1,000 on an ISTYPE or TYPECASE of r : REFANY, but come on, that's not really an argument! So I am supportive of making a new type hierarchy TAGGED T for any T. And yes I understand that now---once you have TAGGED T---it is trivial to add a TAGGED REFANY, which you can distinguish from REFANY. I think your arguments for the TAGGED hierarchy are very good. However, I still don't think you have made a good argument *against* being able to hide 31 bits of information in a REFANY. You don't have to use the facility if it doesn't meet your requirements! Please remember that what I've been proposing is not a language change at all but a request that the runtime system and compiler respect a couple of not-difficult-to-ensure properties, so that we may do some new tricks in UNSAFE code. Nothing more than that. Mika P.S. You didn't actually give any examples of code where you would, after *your* proposed change, still use REFANY instead of switching the code to TAGGED REFANY. You said that: >And TAGGED REFANY generalizes it from REFANY. i.e., container code would switch to TAGGED REFANY >The other use is for the abstract type itself. Forgetting tagged >types for a moment, I have never seen an interface/module that >uses REFANY for this. Instead, the modules declare their abstract >type as some proper subtype of REFANY, usually an opaque type. i.e., other code doesn't actually use REFANY! (For what it's worth, your experience here matches mine. Container types (may) use REFANY and ADTs (almost) never do.) So back to my question: where would you use REFANY???? If never, then why bother having the two roots? What you're saying is that after *my* proposed runtime change, *you* will be tempted to abuse REFANY for ADTs. I don't think this is a very good argument against my proposal (but it is a good argument for yours, which is not incompatible with mine but instead expands it). The only thing that makes your proposal slightly incompatible with mine is that you're insisting on having a new distinction between REFANY and TAGGED REFANY, which I am saying will never be used in practice. And both your experience with Modula-3 and mine seem to back up this assertion. "Rodney M. Bates" writes: >Mika Nystrom wrote: >> Sorry to splice together two emails from you, but I feel I've already >> used up my m3devel quota this week: >> >> "Rodney M. Bates" writes: >> >>>> Are you sure? I want a type---some type---that can hold "any >>>> reference, even a tagged one", and I would rewrite most library >>>> code that today takes REFANY to take that instead. Why not? Why >>>> would I want to limit it to REFANY when it performs no operations >>>> that couldn't legally be performed on TAGGED REFANY. >>>> >>>> >>> I believe my "safe" proposal would make this very simple, if I am >>> thinking of the kind of library code you are. >>> >>> I envision a container data structure that takes in things and returns >>> them without performing operations on them other than moving them around >>> and storing them, e.g. the ever belabored stack. The values going in >>> and out are declared REFANY, and the client passes in values of >>> some proper subtype of REFANY, which get assigned to the REFANY >>> parameters. When it gets them back, it narrows them to this type. >>> >>> In this pattern, just changing the declared type of the container values >>> >> >from REFANY to TAGGED REFANY would do it. The library code's storage >> ... >> >There are two very different kinds of uses of reference and >tagged types. The one I speak of above is for the type of the >elements inside a container data structure. In this case, it >is the client that knows what type the value really is, and will >declare it as such. The library ADT module should know as little >as possible about it, so it will declare it as REFANY or >TAGGED REFANY. Here, you want the most general type >possible, just to make the abstraction more versatile. >And TAGGED REFANY generalizes it from REFANY. > >But... >> > > >>>> you'd like to store these in a REFANY and dynamically test for the >>>> appropriate tagged type: >>>> >>> No, I do not want to store these in a variable of type REFANY or any >>> other existing type. >>> In fact, I want to forbid it. >>> >> >> I think you are thinking of exactly the same kind of library code. >> TextRefTbl.T, RefList.T, etc. >> >> After the introduction of TAGGED REFANY, what use is there for >> REFANY? What piece of code can you think of where the cost of the >> 1-LSB check of TAGGED REFANY outweighs the convenience of being >> able to process objects of type TAGGED T (for all ref types T) as >> well as objects of type T? >> >The other use is for the abstract type itself. Forgetting tagged >types for a moment, I have never seen an interface/module that >uses REFANY for this. Instead, the modules declare their abstract >type as some proper subtype of REFANY, usually an opaque type. > >It would be possible to use just REFANY here of course, but that would >require an otherwise unnecessary RT check on the allocated type, >every time an operation of the module is called. This is a much >more expensive check than a tag check, as has been pointed out >in this discussion. > >But worse, it would sacrifice the static checking that we now have >that prevents, at compile time, clients from passing, say a Text.T >to some procedure in Atom that expects an Atom.T. If these modules >ever wanted to use a tagged type, but the only tagged type were >REFANY, we would lose this static checking, because Text.T would >have to become equal to Atom.T. > >In cases where your algorithms don't specifically need dynamic >typing, static typing is always much better, because one run of >the compiler on the source code will do it. Bugs checked >only at runtime require a massive test suit to be coded and then >regularly rerun to get even close to the same confidence they've >been found. > >So when using tagged types as the ADT itself,, we need to be able >to have a tagged version of whatever proper subtype of REFANY >the abstraction needs, including an opaque subtype of REFANY >or an opaque subtype of some Public subtype of REFANY. This is >why I am adamant that we need to be able to build a tagged type >from any traced or object type. > >And once you do this, keeping REFANY itself unchanged and allowing >TAGGED REFANY as one case of a tagged type falls out of the system >for free _and_ saves a lot of cases that would otherwise need a new RT >check that can never fail, but the language can't know that, because >the type system has lost the distinction. > >I really feel that the fad of all dynamic typing in languages is a huge >mistake and that it will someday be recognized as such. In the >meantime, we have a language that provides a very extensive set >of statically-typed alternatives, while also allowing dynamic typing >when you really need it. This is one of Modula-3's best principles. >Let's don't erode the static alternatives unnecessarily. > >> Mika >> >> From mika at async.caltech.edu Fri Apr 10 21:02:07 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 10 Apr 2009 12:02:07 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Fri, 10 Apr 2009 12:24:49 CDT." <49DF80E1.10709@cox.net> Message-ID: <200904101902.n3AJ27UI002559@camembert.async.caltech.edu> Specific proposal. What Rodney said, *except* make REFANY the root of everything. Insert an untagged root with a new name. Rodney himself has said that the uses of REFANY he knows about would be changed to accept the TAGGED type, so I simply propose allowing REFANY to handle the TAGGED type by default, and insert a new root for the untagged types. The structure of the type hierarchy is exactly the same as in Rodney's proposal, but the different naming makes it more backward-compatible. ROOT <: UNTAGGEDREFANY T <: UNTAGGEDREFANY UNTAGGEDREFANY <: REFANY and finally. TAGGED T <: REFANY (* for all T *) The advantages with this proposal are that it does precisely what Rodney is asking for (typesafe ADTs), but it's compatible with Tony's runtime changes in the *current* M3 implementation and it won't require anyone to do a massive search and replace, replacing REFANY with "TAGGED REFANY" in every existing Modula-3 program. Supposed disadvantage: every TYPECASE, NARROW, etc., of REFANY will cost an extra LSB check. Those who feel strongly about that and for some reason *know* that they don't want to process TAGGED types (which may be the empty set), can modify their code to use UNTAGGEDREFANY instead of REFANY. Mika "Rodney M. Bates" writes: >Mika Nystrom wrote: >> Sorry to splice together two emails from you, but I feel I've already >> used up my m3devel quota this week: >> >> "Rodney M. Bates" writes: >> >>>> Are you sure? I want a type---some type---that can hold "any >>>> reference, even a tagged one", and I would rewrite most library >>>> code that today takes REFANY to take that instead. Why not? Why >>>> would I want to limit it to REFANY when it performs no operations >>>> that couldn't legally be performed on TAGGED REFANY. >>>> >>>> >>> I believe my "safe" proposal would make this very simple, if I am >>> thinking of the kind of library code you are. >>> >>> I envision a container data structure that takes in things and returns >>> them without performing operations on them other than moving them around >>> and storing them, e.g. the ever belabored stack. The values going in >>> and out are declared REFANY, and the client passes in values of >>> some proper subtype of REFANY, which get assigned to the REFANY >>> parameters. When it gets them back, it narrows them to this type. >>> >>> In this pattern, just changing the declared type of the container values >>> >> >from REFANY to TAGGED REFANY would do it. The library code's storage >> ... >> >There are two very different kinds of uses of reference and >tagged types. The one I speak of above is for the type of the >elements inside a container data structure. In this case, it >is the client that knows what type the value really is, and will >declare it as such. The library ADT module should know as little >as possible about it, so it will declare it as REFANY or >TAGGED REFANY. Here, you want the most general type >possible, just to make the abstraction more versatile. >And TAGGED REFANY generalizes it from REFANY. > >But... >> > > >>>> you'd like to store these in a REFANY and dynamically test for the >>>> appropriate tagged type: >>>> >>> No, I do not want to store these in a variable of type REFANY or any >>> other existing type. >>> In fact, I want to forbid it. >>> >> >> I think you are thinking of exactly the same kind of library code. >> TextRefTbl.T, RefList.T, etc. >> >> After the introduction of TAGGED REFANY, what use is there for >> REFANY? What piece of code can you think of where the cost of the >> 1-LSB check of TAGGED REFANY outweighs the convenience of being >> able to process objects of type TAGGED T (for all ref types T) as >> well as objects of type T? >> >The other use is for the abstract type itself. Forgetting tagged >types for a moment, I have never seen an interface/module that >uses REFANY for this. Instead, the modules declare their abstract >type as some proper subtype of REFANY, usually an opaque type. > >It would be possible to use just REFANY here of course, but that would >require an otherwise unnecessary RT check on the allocated type, >every time an operation of the module is called. This is a much >more expensive check than a tag check, as has been pointed out >in this discussion. > >But worse, it would sacrifice the static checking that we now have >that prevents, at compile time, clients from passing, say a Text.T >to some procedure in Atom that expects an Atom.T. If these modules >ever wanted to use a tagged type, but the only tagged type were >REFANY, we would lose this static checking, because Text.T would >have to become equal to Atom.T. > >In cases where your algorithms don't specifically need dynamic >typing, static typing is always much better, because one run of >the compiler on the source code will do it. Bugs checked >only at runtime require a massive test suit to be coded and then >regularly rerun to get even close to the same confidence they've >been found. > >So when using tagged types as the ADT itself,, we need to be able >to have a tagged version of whatever proper subtype of REFANY >the abstraction needs, including an opaque subtype of REFANY >or an opaque subtype of some Public subtype of REFANY. This is >why I am adamant that we need to be able to build a tagged type >from any traced or object type. > >And once you do this, keeping REFANY itself unchanged and allowing >TAGGED REFANY as one case of a tagged type falls out of the system >for free _and_ saves a lot of cases that would otherwise need a new RT >check that can never fail, but the language can't know that, because >the type system has lost the distinction. > >I really feel that the fad of all dynamic typing in languages is a huge >mistake and that it will someday be recognized as such. In the >meantime, we have a language that provides a very extensive set >of statically-typed alternatives, while also allowing dynamic typing >when you really need it. This is one of Modula-3's best principles. >Let's don't erode the static alternatives unnecessarily. > >> Mika >> >> From mika at async.caltech.edu Fri Apr 10 21:18:38 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 10 Apr 2009 12:18:38 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Fri, 10 Apr 2009 12:24:49 CDT." <49DF80E1.10709@cox.net> Message-ID: <200904101918.n3AJIcLj003231@camembert.async.caltech.edu> Sigh, I hate sending so many emails to a mailing list. Sorry about the inboxes I'm clogging of people with no interest in this. But I just realized something important, which I think may be decisive in deciding the fate of the name "REFANY" in the addition of new types. Rodney proposes TAGGED T <: TAGGED REFANY T <: REFANY <: TAGGED REFANY I propose TAGGED T <: REFANY T <: UNTAGGEDREFANY <: REFANY Both proposals are identical in the power of the language that results, because they differ merely in naming. Both proposals are also backward-compatible: all existing Modula-3 programs are unchanged by them. However, UNTAGGEDREFANY (mine), is *forward*-compatible as well as backward-compatible. Think about it. The TAGGED REFANY proposal will have the following effect: people will go through all the M3 libraries and replace every or almost every occurrence of REFANY with TAGGED REFANY. The resulting code will not compile with an older compiler! In my proposal, it is the user of the TAGGED types who is responsible for---in new code only!---deciding whether he wants his code to compile both on older and newer M3 systems. If he does, then he can add appropriate implementations for compilers that don't support the TAGGED types (which will be trivial since he has to have those anyway!) The burden of handling change is on the programmer of the special new feature rather than on everyone who has a container module. I'll try to refrain from posting any more messages on this topic now. Mika "Rodney M. Bates" writes: >Mika Nystrom wrote: >> Sorry to splice together two emails from you, but I feel I've already >> used up my m3devel quota this week: >> >> "Rodney M. Bates" writes: >> >>>> Are you sure? I want a type---some type---that can hold "any >>>> reference, even a tagged one", and I would rewrite most library >>>> code that today takes REFANY to take that instead. Why not? Why >>>> would I want to limit it to REFANY when it performs no operations >>>> that couldn't legally be performed on TAGGED REFANY. >>>> >>>> >>> I believe my "safe" proposal would make this very simple, if I am >>> thinking of the kind of library code you are. >>> >>> I envision a container data structure that takes in things and returns >>> them without performing operations on them other than moving them around >>> and storing them, e.g. the ever belabored stack. The values going in >>> and out are declared REFANY, and the client passes in values of >>> some proper subtype of REFANY, which get assigned to the REFANY >>> parameters. When it gets them back, it narrows them to this type. >>> >>> In this pattern, just changing the declared type of the container values >>> >> >from REFANY to TAGGED REFANY would do it. The library code's storage >> ... >> >There are two very different kinds of uses of reference and >tagged types. The one I speak of above is for the type of the >elements inside a container data structure. In this case, it >is the client that knows what type the value really is, and will >declare it as such. The library ADT module should know as little >as possible about it, so it will declare it as REFANY or >TAGGED REFANY. Here, you want the most general type >possible, just to make the abstraction more versatile. >And TAGGED REFANY generalizes it from REFANY. > >But... >> > > >>>> you'd like to store these in a REFANY and dynamically test for the >>>> appropriate tagged type: >>>> >>> No, I do not want to store these in a variable of type REFANY or any >>> other existing type. >>> In fact, I want to forbid it. >>> >> >> I think you are thinking of exactly the same kind of library code. >> TextRefTbl.T, RefList.T, etc. >> >> After the introduction of TAGGED REFANY, what use is there for >> REFANY? What piece of code can you think of where the cost of the >> 1-LSB check of TAGGED REFANY outweighs the convenience of being >> able to process objects of type TAGGED T (for all ref types T) as >> well as objects of type T? >> >The other use is for the abstract type itself. Forgetting tagged >types for a moment, I have never seen an interface/module that >uses REFANY for this. Instead, the modules declare their abstract >type as some proper subtype of REFANY, usually an opaque type. > >It would be possible to use just REFANY here of course, but that would >require an otherwise unnecessary RT check on the allocated type, >every time an operation of the module is called. This is a much >more expensive check than a tag check, as has been pointed out >in this discussion. > >But worse, it would sacrifice the static checking that we now have >that prevents, at compile time, clients from passing, say a Text.T >to some procedure in Atom that expects an Atom.T. If these modules >ever wanted to use a tagged type, but the only tagged type were >REFANY, we would lose this static checking, because Text.T would >have to become equal to Atom.T. > >In cases where your algorithms don't specifically need dynamic >typing, static typing is always much better, because one run of >the compiler on the source code will do it. Bugs checked >only at runtime require a massive test suit to be coded and then >regularly rerun to get even close to the same confidence they've >been found. > >So when using tagged types as the ADT itself,, we need to be able >to have a tagged version of whatever proper subtype of REFANY >the abstraction needs, including an opaque subtype of REFANY >or an opaque subtype of some Public subtype of REFANY. This is >why I am adamant that we need to be able to build a tagged type >from any traced or object type. > >And once you do this, keeping REFANY itself unchanged and allowing >TAGGED REFANY as one case of a tagged type falls out of the system >for free _and_ saves a lot of cases that would otherwise need a new RT >check that can never fail, but the language can't know that, because >the type system has lost the distinction. > >I really feel that the fad of all dynamic typing in languages is a huge >mistake and that it will someday be recognized as such. In the >meantime, we have a language that provides a very extensive set >of statically-typed alternatives, while also allowing dynamic typing >when you really need it. This is one of Modula-3's best principles. >Let's don't erode the static alternatives unnecessarily. > >> Mika >> >> From hosking at cs.purdue.edu Sat Apr 11 00:16:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Apr 2009 08:16:07 +1000 Subject: [M3devel] Fwd: Output from "cron" command References: <200904101323.n3ADNfb4028603@niagara.cs.purdue.edu> Message-ID: <4F3FB486-EE62-4E46-BD8A-8D914710E3BF@cs.purdue.edu> SOLgnu failed again. Begin forwarded message: > From: Tony Hosking > Date: 10 April 2009 23:23:41 GMT+10:00 > To: hosking at cs.purdue.edu > Subject: Output from "cron" command > > Your "cron" job on niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/cron.sh > > produced the following output: > > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-04-10-10-30-04 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara release-build" > > creating log file /tmp/build-cm3-20090410-063006-Rbai0T/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.04.10 06:30:06 -- checkout in progress. > [start checkout 2009.04.10 06:30:09] > cd /tmp/build-cm3-20090410-063006-Rbai0T/build > cvs return value: 0 > [end checkout 2009.04.10 06:50:44] > CHECKOUT_RETURN = 0 > -- > 2009.04.10 06:50:46 -- compile in progress. > [start compile 2009.04.10 06:50:47] > compile return value: 0 > [end compile 2009.04.10 08:11:42] > COMPILE_RETURN = 1 > *** COMPILE FAILED > removing build tree /tmp/build-cm3-20090410-063006-Rbai0T ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-04-10-12-13-48 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" > > creating log file /tmp/build-cm3-20090410-081351-rXaGeZ/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.04.10 08:13:51 -- checkout in progress. > [start checkout 2009.04.10 08:13:53] > cd /tmp/build-cm3-20090410-081351-rXaGeZ/build > cvs return value: 0 > [end checkout 2009.04.10 08:35:16] > CHECKOUT_RETURN = 0 > -- > 2009.04.10 08:35:18 -- compile in progress. > [start compile 2009.04.10 08:35:18] > compile return value: 0 > [end compile 2009.04.10 09:21:41] > COMPILE_RETURN = 0 > 2009.04.10 09:21:45 -- tests in progress. > [start run-tests 2009.04.10 09:21:45] > cd /tmp/build-cm3-20090410-081351-rXaGeZ/build > [end run-tests 2009.04.10 09:21:45] > TESTS_RETURN = 0 > 2009.04.10 09:21:45 -- checkout, compile and test run done. > > --- > > removing build tree /tmp/build-cm3-20090410-081351-rXaGeZ ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > done. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 11 00:20:28 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 10 Apr 2009 22:20:28 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <4F3FB486-EE62-4E46-BD8A-8D914710E3BF@cs.purdue.edu> References: <200904101323.n3ADNfb4028603@niagara.cs.purdue.edu> <4F3FB486-EE62-4E46-BD8A-8D914710E3BF@cs.purdue.edu> Message-ID: Yes, sorry, I made a few slightly bad changes. Like three. All fixed. sizeof short, schedulerposix, ugrp (ugrp not a problem on this platform). Let's wait again, sorry. The config file/cminstall thing I didn't do anything with (before or after). So if that's still broken for you, still needs attention. - Jay ________________________________ > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Sat, 11 Apr 2009 08:16:07 +1000 > Subject: [M3devel] Fwd: Output from "cron" command > > SOLgnu failed again. > > Begin forwarded message: > > From: Tony Hosking> > Date: 10 April 2009 23:23:41 GMT+10:00 > To: hosking at cs.purdue.edu > Subject: Output from "cron" command > > Your "cron" job on niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/cron.sh > > produced the following output: > > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-04-10-10-30-04 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara release-build" > > creating log file /tmp/build-cm3-20090410-063006-Rbai0T/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.04.10 06:30:06 -- checkout in progress. > [start checkout 2009.04.10 06:30:09] > cd /tmp/build-cm3-20090410-063006-Rbai0T/build > cvs return value: 0 > [end checkout 2009.04.10 06:50:44] > CHECKOUT_RETURN = 0 > -- > 2009.04.10 06:50:46 -- compile in progress. > [start compile 2009.04.10 06:50:47] > compile return value: 0 > [end compile 2009.04.10 08:11:42] > COMPILE_RETURN = 1 > *** COMPILE FAILED > removing build tree /tmp/build-cm3-20090410-063006-Rbai0T ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-04-10-12-13-48 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" > > creating log file /tmp/build-cm3-20090410-081351-rXaGeZ/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.04.10 08:13:51 -- checkout in progress. > [start checkout 2009.04.10 08:13:53] > cd /tmp/build-cm3-20090410-081351-rXaGeZ/build > cvs return value: 0 > [end checkout 2009.04.10 08:35:16] > CHECKOUT_RETURN = 0 > -- > 2009.04.10 08:35:18 -- compile in progress. > [start compile 2009.04.10 08:35:18] > compile return value: 0 > [end compile 2009.04.10 09:21:41] > COMPILE_RETURN = 0 > 2009.04.10 09:21:45 -- tests in progress. > [start run-tests 2009.04.10 09:21:45] > cd /tmp/build-cm3-20090410-081351-rXaGeZ/build > [end run-tests 2009.04.10 09:21:45] > TESTS_RETURN = 0 > 2009.04.10 09:21:45 -- checkout, compile and test run done. > > --- > > removing build tree /tmp/build-cm3-20090410-081351-rXaGeZ ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > done. > From jay.krell at cornell.edu Sat Apr 11 00:25:11 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 10 Apr 2009 22:25:11 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <4F3FB486-EE62-4E46-BD8A-8D914710E3BF@cs.purdue.edu> References: <200904101323.n3ADNfb4028603@niagara.cs.purdue.edu> <4F3FB486-EE62-4E46-BD8A-8D914710E3BF@cs.purdue.edu> Message-ID: [was slightly truncated] ---------------------------------------- > From: jay.krell at cornell.edu > The config file/cminstall thing I didn't do anything with (before or after). > So if that's still broken for you, still needs attention. > > > - Jay From hosking at cs.purdue.edu Sat Apr 11 00:25:32 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Apr 2009 08:25:32 +1000 Subject: [M3devel] small objects In-Reply-To: <200904101918.n3AJIcLj003231@camembert.async.caltech.edu> References: <200904101918.n3AJIcLj003231@camembert.async.caltech.edu> Message-ID: <305809AF-0615-4D4F-BCA9-D801991D76ED@cs.purdue.edu> Too many e-mails to digest lately. I take it that Mika's is now definitive. Let me think it through. On 11 Apr 2009, at 05:18, Mika Nystrom wrote: > > Sigh, I hate sending so many emails to a mailing list. Sorry about > the inboxes I'm clogging of people with no interest in this. > > But I just realized something important, which I think may be > decisive in deciding the fate of the name "REFANY" in the addition > of new types. > > Rodney proposes > > TAGGED T <: TAGGED REFANY > T <: REFANY <: TAGGED REFANY > > I propose > > TAGGED T <: REFANY > T <: UNTAGGEDREFANY <: REFANY > > Both proposals are identical in the power of the language that > results, because they differ merely in naming. > > Both proposals are also backward-compatible: all existing Modula-3 > programs are unchanged by them. > > However, UNTAGGEDREFANY (mine), is *forward*-compatible as well > as backward-compatible. > > Think about it. The TAGGED REFANY proposal will have the following > effect: people will go through all the M3 libraries and replace > every or almost every occurrence of REFANY with TAGGED REFANY. The > resulting code will not compile with an older compiler! > > In my proposal, it is the user of the TAGGED types who is responsible > for---in new code only!---deciding whether he wants his code to > compile both on older and newer M3 systems. If he does, then he > can add appropriate implementations for compilers that don't support > the TAGGED types (which will be trivial since he has to have those > anyway!) The burden of handling change is on the programmer of the > special new feature rather than on everyone who has a container > module. > > I'll try to refrain from posting any more messages on this topic now. > > Mika > > "Rodney M. Bates" writes: >> Mika Nystrom wrote: >>> Sorry to splice together two emails from you, but I feel I've >>> already >>> used up my m3devel quota this week: >>> >>> "Rodney M. Bates" writes: >>> >>>>> Are you sure? I want a type---some type---that can hold "any >>>>> reference, even a tagged one", and I would rewrite most library >>>>> code that today takes REFANY to take that instead. Why not? Why >>>>> would I want to limit it to REFANY when it performs no operations >>>>> that couldn't legally be performed on TAGGED REFANY. >>>>> >>>>> >>>> I believe my "safe" proposal would make this very simple, if I am >>>> thinking of the kind of library code you are. >>>> >>>> I envision a container data structure that takes in things and >>>> returns >>>> them without performing operations on them other than moving them >>>> around >>>> and storing them, e.g. the ever belabored stack. The values >>>> going in >>>> and out are declared REFANY, and the client passes in values of >>>> some proper subtype of REFANY, which get assigned to the REFANY >>>> parameters. When it gets them back, it narrows them to this type. >>>> >>>> In this pattern, just changing the declared type of the container >>>> values >>>> >>>> from REFANY to TAGGED REFANY would do it. The library code's >>>> storage >>> ... >>> >> There are two very different kinds of uses of reference and >> tagged types. The one I speak of above is for the type of the >> elements inside a container data structure. In this case, it >> is the client that knows what type the value really is, and will >> declare it as such. The library ADT module should know as little >> as possible about it, so it will declare it as REFANY or >> TAGGED REFANY. Here, you want the most general type >> possible, just to make the abstraction more versatile. >> And TAGGED REFANY generalizes it from REFANY. >> >> But... >>> >> >> >>>>> you'd like to store these in a REFANY and dynamically test for the >>>>> appropriate tagged type: >>>>> >>>> No, I do not want to store these in a variable of type REFANY or >>>> any >>>> other existing type. >>>> In fact, I want to forbid it. >>>> >>> >>> I think you are thinking of exactly the same kind of library code. >>> TextRefTbl.T, RefList.T, etc. >>> >>> After the introduction of TAGGED REFANY, what use is there for >>> REFANY? What piece of code can you think of where the cost of the >>> 1-LSB check of TAGGED REFANY outweighs the convenience of being >>> able to process objects of type TAGGED T (for all ref types T) as >>> well as objects of type T? >>> >> The other use is for the abstract type itself. Forgetting tagged >> types for a moment, I have never seen an interface/module that >> uses REFANY for this. Instead, the modules declare their abstract >> type as some proper subtype of REFANY, usually an opaque type. >> >> It would be possible to use just REFANY here of course, but that >> would >> require an otherwise unnecessary RT check on the allocated type, >> every time an operation of the module is called. This is a much >> more expensive check than a tag check, as has been pointed out >> in this discussion. >> >> But worse, it would sacrifice the static checking that we now have >> that prevents, at compile time, clients from passing, say a Text.T >> to some procedure in Atom that expects an Atom.T. If these modules >> ever wanted to use a tagged type, but the only tagged type were >> REFANY, we would lose this static checking, because Text.T would >> have to become equal to Atom.T. >> >> In cases where your algorithms don't specifically need dynamic >> typing, static typing is always much better, because one run of >> the compiler on the source code will do it. Bugs checked >> only at runtime require a massive test suit to be coded and then >> regularly rerun to get even close to the same confidence they've >> been found. >> >> So when using tagged types as the ADT itself,, we need to be able >> to have a tagged version of whatever proper subtype of REFANY >> the abstraction needs, including an opaque subtype of REFANY >> or an opaque subtype of some Public subtype of REFANY. This is >> why I am adamant that we need to be able to build a tagged type >> from any traced or object type. >> >> And once you do this, keeping REFANY itself unchanged and allowing >> TAGGED REFANY as one case of a tagged type falls out of the system >> for free _and_ saves a lot of cases that would otherwise need a new >> RT >> check that can never fail, but the language can't know that, because >> the type system has lost the distinction. >> >> I really feel that the fad of all dynamic typing in languages is a >> huge >> mistake and that it will someday be recognized as such. In the >> meantime, we have a language that provides a very extensive set >> of statically-typed alternatives, while also allowing dynamic typing >> when you really need it. This is one of Modula-3's best principles. >> Let's don't erode the static alternatives unnecessarily. >> >>> Mika >>> >>> From jay.krell at cornell.edu Sat Apr 11 00:24:28 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 10 Apr 2009 22:24:28 +0000 Subject: [M3devel] "cvsup compat"? (really, general source compat) Message-ID: The subject isn't really the whole subject. cvsup compat? I could make the cvsup source highly compatible with "all" Modula-3 distributions by giving it its own "SupUnix.i3", implemented mostly in C, using INTEGER more and LONGINT less. Even its own SchedulerPosix with Enable/DisableSwitching. It would just, like, IMPORT SupUnix as Unix, IMPORT SupScheduler as SchedulerPosix, leading to the overall source changes being small. Or I could adapt it to current cm3, not compatible with any other older versions or forks (ezm3, pm3, old cm3, etc.) Use LONGINT. Use some of the slightly copying wrappers (Ugrp, Unetdb). Thoughts? Maintaining full source compat in cm3 itself I think is not an option. But almost. At least stat should always return 64bit file sizes. Or at least a 53bit double..I doubt that helps though. Most of the rest of "problems" could be "fixed". Such as by restoring a little bit of header cloning -- more for Ugrp and Unetdb, not Ustat, and verify the correctness in the C code. (because Ustat already has a place to copy an idealized type to, whereas Ugrp and Unetdb don't, unless interfaces altered like I did.) And using INTEGER more and LONGINT less. Not just because older compilers don't support LONGINT, but because code that uses one is not compatible with interfaces that use the other, even on 64bit platforms where they are "the same". (like on 32bit platforms, in C, int* and long* are compatible). I'd have to do more research though, like on ino_t and dev_t. They are 64bits on Linux/AMD64, I don't know if they ever are on any 32bit platforms, in which case LONGINT comes back. (other point here is LONGINT or, really, my preference, INT64 and UINT64 should have been added to the language over 10 years ago, then these would have been smoothed out by now..oh well..or possibly INTEGER and LONGINT should be more source compatible, but I realize there are arguments against some of that -- you could make it so on 64bit, but then a bunch of code would be produced that only compiled on 64bit platforms.) I'll probably go ahead and adapt it to current cm3. The other option can be explored later independently. Could be that nothing but current cm3 matters much. - Jay From jay.krell at cornell.edu Sat Apr 11 00:27:17 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 10 Apr 2009 22:27:17 +0000 Subject: [M3devel] tinderbox summary log Message-ID: This is very minor. The tinderbox summary log doesn't show stuff like: "../src/thread/PTHREAD/ThreadPThread.m3", line 7: symbol redefined (DisableSwitching) 4402 "../src/thread/PTHREAD/ThreadPThread.m3", line 7: symbol redefined (EnableSwitching) 4403 2 errors encountered Or at least the first two lines. If it does find the last, fix is to always show a few lines of "context". But the full log works well enough, the errors occur near the end. Not a big deal. (One might say -- but don't make such errors..but hey, tinderbox is all about catching errors...) - Jay From wagner at elegosoft.com Sat Apr 11 10:46:40 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 11 Apr 2009 10:46:40 +0200 Subject: [M3devel] tinderbox summary log In-Reply-To: References: Message-ID: <20090411104640.7cm9u7utc40oscoc@mail.elegosoft.com> Quoting Jay : > > This is very minor. > > The tinderbox summary log doesn't show stuff like: > > "../src/thread/PTHREAD/ThreadPThread.m3", line 7: symbol > redefined (DisableSwitching) > 4402 "../src/thread/PTHREAD/ThreadPThread.m3", line 7: > symbol redefined (EnableSwitching) > 4403 2 errors encountered > > > Or at least the first two lines. > If it does find the last, fix is to always show a few lines of "context". > > But the full log works well enough, the errors occur near the end. > > Not a big deal. > (One might say -- but don't make such errors..but hey, tinderbox is > all about catching errors...) Anybody here who would like to work on improving and fixing our tinderbox installation on birch again? Michael Anderson has not too much time to spend for cm3, and Ronny, who made the last installation, doesn't work for us anymore. So if you like perl scripting, this would be a great opportunity ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 11 10:55:12 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 11 Apr 2009 10:55:12 +0200 Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN Message-ID: <20090411105512.92784fp7cc0o448k@mail.elegosoft.com> After trying to upgrade cm3 on my notebook to the latest version, I get lots of internal compiler errors.This is on % uname -a Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power Macintosh powerpc ... new source -> compiling RuntimeError.m3 ../src/runtime/common/RuntimeError.m3: In function 'RuntimeError__Tag': ../src/runtime/common/RuntimeError.m3:56: error: type mismatch in binary expression int_32 int_32 word_32 D.252 = D.251 * 4 ../src/runtime/common/RuntimeError.m3:56: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. ... Full log attached. Before you ask, it won't be easy to upgrade Darwin on this notebook, and I surely cannot do this within the next two weeks :-/ Any ideas? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 -------------- /Users/wagner/work/cm3/scripts/do-pkg.sh buildship sysutils m3bundle m3middle m3quake patternmatching cminstall /Users/wagner/work/cm3/scripts/pkgmap.sh -c "cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' " sysutils m3bundle m3middle m3quake patternmatching cminstall === package m3-libs/sysutils === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/sysutils/PPC_DARWIN .M3EXPORTS libsysutils.5.2.dylib libsysutils.5.dylib libsysutils.dylib libsysutils.a libsysutils.m3x .M3WEB ../PPC_DARWIN => /usr/local/cm3/pkg/sysutils/PPC_DARWIN TextTextSeqTbl.i3 TextTextSeqTbl.m3 ../src => /usr/local/cm3/pkg/sysutils/src EnvUtils.i3 EnvUtils.m3 FingerprintFmt.i3 FingerprintFmt.m3 FSUtils.i3 FSUtils.m3 SMsg.i3 SMsg.m3 MsgIF.m3 MsgIF.i3 MsgX.m3 MsgX.i3 ProcessEnv.i3 ProcessEnv.m3 System.i3 System.m3 PathRepr.i3 PathReprCommon.m3 TextUtils.i3 TextReadingUtils.m3 TextReadingUtils.i3 OSSpecials.i3 FastLex.i3 FastLex.m3 Confirmation.i3 Confirmation.m3 DirStack.i3 DirStack.m3 ConnectRdWr.m3 ConnectRdWr.i3 ../src/POSIX => /usr/local/cm3/pkg/sysutils/src/POSIX OSSpecialsPosix.m3 PathReprPosix.m3 SystemPosix.m3 FSUnix_cm3.m3 ../src/cm3 => /usr/local/cm3/pkg/sysutils/src/cm3 TextUtils.m3 ==> m3-libs/sysutils done === package m3-tools/m3bundle === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/m3bundle/PPC_DARWIN .M3EXPORTS .M3WEB ../src => /usr/local/cm3/pkg/m3bundle/src m3bundle.m3 . => /usr/local/cm3/bin m3bundle . => /usr/local/cm3/man/man1 m3bundle.1 ==> m3-tools/m3bundle done === package m3-sys/m3middle === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/m3middle/PPC_DARWIN .M3EXPORTS libm3middle.a libm3middle.m3x .M3WEB ../src/POSIX => /usr/local/cm3/pkg/m3middle/src/POSIX M3Process.m3 CoffTime.i3 CoffTime.m3 ../src => /usr/local/cm3/pkg/m3middle/src Target.i3 Target.m3 TargetMap.i3 TargetMap.m3 TInt.i3 TInt.m3 TWord.m3 TWord.i3 TFloat.i3 TFloat.m3 M3FP.i3 M3FP.m3 M3Buf.i3 M3Buf.m3 M3ID.i3 M3ID.m3 M3Timers.m3 M3Timers.i3 M3File.i3 M3File.m3 M3Process.i3 M3CG.i3 M3CG.m3 M3CG_Ops.i3 M3CG_Check.i3 M3CG_Check.m3 M3CG_Rd.m3 M3CG_Rd.i3 M3CG_Wr.i3 M3CG_Wr.m3 M3CG_Binary.i3 M3CG_Binary.m3 M3CG_BinRd.m3 M3CG_BinRd.i3 M3CG_BinWr.i3 M3CG_BinWr.m3 M3RT.i3 M3RT.m3 ==> m3-sys/m3middle done === package m3-sys/m3quake === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/m3quake/PPC_DARWIN .M3EXPORTS libm3quake.a libm3quake.m3x .M3WEB ../PPC_DARWIN => /usr/local/cm3/pkg/m3quake/PPC_DARWIN QVTbl.m3 QVTbl.i3 QVSeq.i3 QVSeq.m3 QVSeqRep.i3 ../src => /usr/local/cm3/pkg/m3quake/src Quake.i3 Quake.m3 QToken.i3 QToken.m3 QIdent.m3 QIdent.i3 QScanner.i3 QScanner.m3 QCode.i3 QCode.m3 QCompiler.m3 QCompiler.i3 QValue.m3 QValue.i3 QMachine.i3 QMachine.m3 QVal.i3 QVal.m3 MxConfig.i3 MxConfig.m3 ==> m3-sys/m3quake done === package m3-libs/patternmatching === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/patternmatching/PPC_DARWIN .M3EXPORTS libpatternmatching.5.2.dylib libpatternmatching.5.dylib libpatternmatching.dylib libpatternmatching.a libpatternmatching.m3x .M3WEB ../src/libglob => /usr/local/cm3/pkg/patternmatching/src/libglob fnmatch.c ../src => /usr/local/cm3/pkg/patternmatching/src RegEx.i3 RegEx.m3 Uglob.i3 Glob.i3 Glob.m3 GlobTree.i3 GlobTree.m3 ==> m3-libs/patternmatching done === package m3-sys/cminstall === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/cminstall/PPC_DARWIN .M3EXPORTS .M3WEB ../PPC_DARWIN => /usr/local/cm3/pkg/cminstall/PPC_DARWIN Setup.i3 Setup.m3 InstallTarget.i3 ../src => /usr/local/cm3/pkg/cminstall/src Msg.m3 Msg.i3 Text2.i3 Text2.m3 OS.i3 OS.m3 Registry.i3 Main.m3 OSPOSIX.m3 RegistryPOSIX.m3 . => /usr/local/cm3/pkg/cminstall/PPC_DARWIN cminstall ==> m3-sys/cminstall done /Users/wagner/work/cm3/scripts/do-pkg.sh buildship sysutils m3middle m3objfile m3linker m3back m3front m3quake cm3 /Users/wagner/work/cm3/scripts/pkgmap.sh -c "cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' " sysutils m3middle m3objfile m3linker m3back m3front m3quake cm3 === package m3-libs/sysutils === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/sysutils/PPC_DARWIN .M3EXPORTS libsysutils.5.2.dylib libsysutils.5.dylib libsysutils.dylib libsysutils.a libsysutils.m3x .M3WEB ../PPC_DARWIN => /usr/local/cm3/pkg/sysutils/PPC_DARWIN TextTextSeqTbl.i3 TextTextSeqTbl.m3 ../src => /usr/local/cm3/pkg/sysutils/src EnvUtils.i3 EnvUtils.m3 FingerprintFmt.i3 FingerprintFmt.m3 FSUtils.i3 FSUtils.m3 SMsg.i3 SMsg.m3 MsgIF.m3 MsgIF.i3 MsgX.m3 MsgX.i3 ProcessEnv.i3 ProcessEnv.m3 System.i3 System.m3 PathRepr.i3 PathReprCommon.m3 TextUtils.i3 TextReadingUtils.m3 TextReadingUtils.i3 OSSpecials.i3 FastLex.i3 FastLex.m3 Confirmation.i3 Confirmation.m3 DirStack.i3 DirStack.m3 ConnectRdWr.m3 ConnectRdWr.i3 ../src/POSIX => /usr/local/cm3/pkg/sysutils/src/POSIX OSSpecialsPosix.m3 PathReprPosix.m3 SystemPosix.m3 FSUnix_cm3.m3 ../src/cm3 => /usr/local/cm3/pkg/sysutils/src/cm3 TextUtils.m3 ==> m3-libs/sysutils done === package m3-sys/m3middle === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/m3middle/PPC_DARWIN .M3EXPORTS libm3middle.a libm3middle.m3x .M3WEB ../src/POSIX => /usr/local/cm3/pkg/m3middle/src/POSIX M3Process.m3 CoffTime.i3 CoffTime.m3 ../src => /usr/local/cm3/pkg/m3middle/src Target.i3 Target.m3 TargetMap.i3 TargetMap.m3 TInt.i3 TInt.m3 TWord.m3 TWord.i3 TFloat.i3 TFloat.m3 M3FP.i3 M3FP.m3 M3Buf.i3 M3Buf.m3 M3ID.i3 M3ID.m3 M3Timers.m3 M3Timers.i3 M3File.i3 M3File.m3 M3Process.i3 M3CG.i3 M3CG.m3 M3CG_Ops.i3 M3CG_Check.i3 M3CG_Check.m3 M3CG_Rd.m3 M3CG_Rd.i3 M3CG_Wr.i3 M3CG_Wr.m3 M3CG_Binary.i3 M3CG_Binary.m3 M3CG_BinRd.m3 M3CG_BinRd.i3 M3CG_BinWr.i3 M3CG_BinWr.m3 M3RT.i3 M3RT.m3 ==> m3-sys/m3middle done === package m3-sys/m3objfile === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/m3objfile/PPC_DARWIN .M3EXPORTS libm3objfile.a libm3objfile.m3x .M3WEB ../src => /usr/local/cm3/pkg/m3objfile/src Coff.i3 Coff.m3 M3ObjFile.i3 M3ObjFile.m3 MasmObjFile.i3 MasmObjFile.m3 NTObjFile.i3 NTObjFile.m3 ==> m3-sys/m3objfile done === package m3-sys/m3linker === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/m3linker/PPC_DARWIN .M3EXPORTS libm3link.a libm3link.m3x .M3WEB ../src => /usr/local/cm3/pkg/m3linker/src Mx.i3 Mx.m3 MxIn.i3 MxIn.m3 MxOut.i3 MxOut.m3 MxMerge.m3 MxMerge.i3 MxCheck.i3 MxCheck.m3 MxGen.i3 MxGen.m3 MxVS.m3 MxVS.i3 MxRep.i3 MxRep.m3 MxMap.i3 MxMap.m3 MxSet.m3 MxSet.i3 MxVSSet.i3 MxVSSet.m3 MxIO.i3 MxIO.m3 ==> m3-sys/m3linker done === package m3-sys/m3back === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/m3back/PPC_DARWIN .M3EXPORTS libm3back.a libm3back.m3x .M3WEB ../src => /usr/local/cm3/pkg/m3back/src M3x86.i3 M3x86.m3 M3x86Rep.i3 Wrx86.i3 Wrx86.m3 Stackx86.i3 Stackx86.m3 Codex86.i3 Codex86.m3 ==> m3-sys/m3back done === package m3-sys/m3front === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/m3front/PPC_DARWIN .M3EXPORTS libm3front.a libm3front.m3x .M3WEB ../src/types => /usr/local/cm3/pkg/m3front/src/types Type.i3 Type.m3 TypeRep.i3 ArrayType.i3 ArrayType.m3 Brand.i3 Brand.m3 EnumType.i3 EnumType.m3 NamedType.m3 NamedType.i3 ObjectType.i3 ObjectType.m3 OpaqueType.i3 OpaqueType.m3 OpenArrayType.i3 OpenArrayType.m3 PackedType.m3 PackedType.i3 ProcType.i3 ProcType.m3 RecordType.i3 RecordType.m3 RefType.i3 RefType.m3 SetType.m3 SetType.i3 SubrangeType.i3 SubrangeType.m3 TypeFP.i3 TypeFP.m3 TypeTbl.i3 TypeTbl.m3 UserProc.i3 UserProc.m3 ../src/builtinOps => /usr/local/cm3/pkg/m3front/src/builtinOps Abs.i3 Abs.m3 Adr.m3 Adr.i3 AdrSize.i3 AdrSize.m3 BitSize.i3 BitSize.m3 BuiltinOps.i3 BuiltinOps.m3 ByteSize.i3 ByteSize.m3 Cas.m3 Cas.i3 CasP.i3 CasP.m3 Ceiling.m3 Ceiling.i3 Dec.i3 Dec.m3 Dispose.m3 Dispose.i3 First.i3 First.m3 Floatt.i3 Floatt.m3 Floor.i3 Floor.m3 Inc.i3 Inc.m3 IsType.i3 IsType.m3 Last.m3 Last.i3 Loophole.i3 Loophole.m3 Max.m3 Max.i3 Min.i3 Min.m3 Narrow.m3 Narrow.i3 New.m3 New.i3 Number.i3 Number.m3 Ord.m3 Ord.i3 Round.m3 Round.i3 Subarray.i3 Subarray.m3 Trunc.i3 Trunc.m3 Typecode.m3 Typecode.i3 Val.i3 Val.m3 ../src/builtinWord => /usr/local/cm3/pkg/m3front/src/builtinWord WordAnd.m3 WordAnd.i3 WordDivide.i3 WordDivide.m3 WordExtract.i3 WordExtract.m3 WordGE.m3 WordGE.i3 WordGT.i3 WordGT.m3 WordInsert.m3 WordInsert.i3 WordLE.m3 WordLE.i3 WordLT.i3 WordLT.m3 WordMinus.m3 WordMinus.i3 WordMod.i3 WordMod.m3 WordModule.i3 WordModule.m3 WordNot.i3 WordNot.m3 WordOr.i3 WordOr.m3 WordPlus.i3 WordPlus.m3 WordRotate.i3 WordRotate.m3 WordShift.i3 WordShift.m3 WordTimes.i3 WordTimes.m3 WordXor.m3 WordXor.i3 ../src/builtinLong => /usr/local/cm3/pkg/m3front/src/builtinLong LongAnd.i3 LongAnd.m3 LongDivide.i3 LongDivide.m3 LongExtract.i3 LongExtract.m3 LongGE.i3 LongGE.m3 LongGT.m3 LongGT.i3 LongInsert.m3 LongInsert.i3 LongLE.i3 LongLE.m3 LongLT.i3 LongLT.m3 LongMinus.i3 LongMinus.m3 LongMod.i3 LongMod.m3 LongModule.i3 LongModule.m3 LongNot.i3 LongNot.m3 LongOr.m3 LongOr.i3 LongPlus.i3 LongPlus.m3 LongRotate.i3 LongRotate.m3 LongShift.i3 LongShift.m3 LongTimes.i3 LongTimes.m3 LongXor.i3 LongXor.m3 ../src/builtinInfo => /usr/local/cm3/pkg/m3front/src/builtinInfo InfoModule.i3 InfoModule.m3 InfoThisFile.m3 InfoThisFile.i3 InfoThisPath.i3 InfoThisPath.m3 InfoThisLine.i3 InfoThisLine.m3 InfoThisException.i3 InfoThisException.m3 ../src/builtinTypes => /usr/local/cm3/pkg/m3front/src/builtinTypes Addr.i3 Addr.m3 Bool.i3 Bool.m3 BuiltinTypes.m3 BuiltinTypes.i3 Charr.i3 Charr.m3 Card.i3 Card.m3 EReel.i3 EReel.m3 ErrType.i3 ErrType.m3 Int.i3 Int.m3 LInt.i3 LInt.m3 LReel.m3 LReel.i3 Mutex.i3 Mutex.m3 Null.i3 Null.m3 ObjectAdr.m3 ObjectAdr.i3 ObjectRef.m3 ObjectRef.i3 Reel.m3 Reel.i3 Reff.i3 Reff.m3 Textt.m3 Textt.i3 WCharr.i3 WCharr.m3 ../src/exprs => /usr/local/cm3/pkg/m3front/src/exprs Expr.i3 Expr.m3 ExprRep.i3 AddExpr.i3 AddExpr.m3 AddressExpr.i3 AddressExpr.m3 AndExpr.i3 AndExpr.m3 ArrayExpr.m3 ArrayExpr.i3 CallExpr.i3 CallExpr.m3 CastExpr.i3 CastExpr.m3 CheckExpr.i3 CheckExpr.m3 CompareExpr.i3 CompareExpr.m3 ConcatExpr.i3 ConcatExpr.m3 ConsExpr.i3 ConsExpr.m3 DerefExpr.i3 DerefExpr.m3 DivExpr.i3 DivExpr.m3 DivideExpr.i3 DivideExpr.m3 EnumExpr.m3 EnumExpr.i3 EqualExpr.i3 EqualExpr.m3 ExprParse.i3 ExprParse.m3 InExpr.m3 InExpr.i3 IntegerExpr.m3 IntegerExpr.i3 KeywordExpr.m3 KeywordExpr.i3 MethodExpr.m3 MethodExpr.i3 ModExpr.i3 ModExpr.m3 MultiplyExpr.m3 MultiplyExpr.i3 NamedExpr.m3 NamedExpr.i3 NarrowExpr.m3 NarrowExpr.i3 NegateExpr.m3 NegateExpr.i3 NilChkExpr.i3 NilChkExpr.m3 NotExpr.i3 NotExpr.m3 OrExpr.i3 OrExpr.m3 PlusExpr.i3 PlusExpr.m3 ProcExpr.i3 ProcExpr.m3 QualifyExpr.i3 QualifyExpr.m3 RangeExpr.m3 RangeExpr.i3 RecordExpr.m3 RecordExpr.i3 ReelExpr.m3 ReelExpr.i3 SetExpr.m3 SetExpr.i3 SubscriptExpr.i3 SubscriptExpr.m3 SubtractExpr.i3 SubtractExpr.m3 TextExpr.i3 TextExpr.m3 TypeExpr.i3 TypeExpr.m3 VarExpr.i3 VarExpr.m3 ../src/misc => /usr/local/cm3/pkg/m3front/src/misc M3.i3 M3.m3 M3Front.i3 M3Front.m3 M3Compiler.m3 M3Compiler.i3 M3Header.m3 M3Header.i3 M3String.m3 M3String.i3 M3WString.i3 M3WString.m3 Token.i3 Token.m3 Error.m3 Error.i3 Host.m3 Host.i3 Marker.m3 Marker.i3 Scanner.i3 Scanner.m3 Scope.i3 Scope.m3 Coverage.i3 Coverage.m3 ESet.i3 ESet.m3 ProcBody.i3 ProcBody.m3 CG.i3 CG.m3 RunTyme.i3 RunTyme.m3 TipeMap.i3 TipeMap.m3 TipeDesc.i3 TipeDesc.m3 Tracer.i3 Tracer.m3 WebInfo.i3 WebInfo.m3 ../src/stmts => /usr/local/cm3/pkg/m3front/src/stmts Stmt.i3 Stmt.m3 StmtRep.i3 AssertStmt.m3 AssertStmt.i3 AssignStmt.i3 AssignStmt.m3 BlockStmt.i3 BlockStmt.m3 CallStmt.i3 CallStmt.m3 CaseStmt.i3 CaseStmt.m3 DebugStmt.i3 DebugStmt.m3 EvalStmt.i3 EvalStmt.m3 ExitStmt.i3 ExitStmt.m3 ForStmt.i3 ForStmt.m3 IfStmt.i3 IfStmt.m3 LockStmt.m3 LockStmt.i3 LoopStmt.m3 LoopStmt.i3 RaiseStmt.m3 RaiseStmt.i3 RepeatStmt.m3 RepeatStmt.i3 ReturnStmt.i3 ReturnStmt.m3 TryFinStmt.m3 TryFinStmt.i3 TryStmt.i3 TryStmt.m3 TypeCaseStmt.m3 TypeCaseStmt.i3 WhileStmt.i3 WhileStmt.m3 WithStmt.m3 WithStmt.i3 ../src/values => /usr/local/cm3/pkg/m3front/src/values Module.i3 Module.m3 Value.i3 Value.m3 ValueRep.i3 Constant.i3 Constant.m3 Decl.m3 Decl.i3 EnumElt.i3 EnumElt.m3 Exceptionz.i3 Exceptionz.m3 External.i3 External.m3 Field.i3 Field.m3 Formal.i3 Formal.m3 Ident.i3 Ident.m3 Method.m3 Method.i3 Procedure.i3 Procedure.m3 Revelation.m3 Revelation.i3 Tipe.i3 Tipe.m3 Variable.i3 Variable.m3 ==> m3-sys/m3front done === package m3-sys/m3quake === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/m3quake/PPC_DARWIN .M3EXPORTS libm3quake.a libm3quake.m3x .M3WEB ../PPC_DARWIN => /usr/local/cm3/pkg/m3quake/PPC_DARWIN QVTbl.m3 QVTbl.i3 QVSeq.i3 QVSeq.m3 QVSeqRep.i3 ../src => /usr/local/cm3/pkg/m3quake/src Quake.i3 Quake.m3 QToken.i3 QToken.m3 QIdent.m3 QIdent.i3 QScanner.i3 QScanner.m3 QCode.i3 QCode.m3 QCompiler.m3 QCompiler.i3 QValue.m3 QValue.i3 QMachine.i3 QMachine.m3 QVal.i3 QVal.m3 MxConfig.i3 MxConfig.m3 ==> m3-sys/m3quake done === package m3-sys/cm3 === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides new source -> compiling Version.i3 new source -> compiling M3Backend.i3 new source -> compiling Arg.i3 new source -> compiling Utils.i3 new source -> compiling Msg.i3 new source -> compiling M3Backend.m3 new source -> compiling UtilsPosix.m3 new source -> compiling Arg.m3 new source -> compiling M3Path.i3 new source -> compiling M3Loc.i3 new source -> compiling M3Unit.i3 new source -> compiling Builder.i3 new source -> compiling M3Options.i3 new source -> compiling WebFile.i3 new source -> compiling Dirs.i3 new source -> compiling Builder.m3 new source -> compiling Dirs.m3 new source -> compiling M3Build.i3 new source -> compiling M3Build.m3 new source -> compiling M3Loc.m3 new source -> compiling M3Options.m3 new source -> compiling M3Path.m3 new source -> compiling M3Unit.m3 new source -> compiling Makefile.i3 new source -> compiling Makefile.m3 new source -> compiling Msg.m3 new source -> compiling Utils.m3 new source -> compiling WebFile.m3 new source -> compiling Main.m3 new exporters -> recompiling Utils.i3 -> linking cm3 --- shipping from PPC_DARWIN --- . => /usr/local/cm3/pkg/cm3/PPC_DARWIN .M3EXPORTS .M3WEB ../PPC_DARWIN => /usr/local/cm3/pkg/cm3/PPC_DARWIN Version.i3 ../src => /usr/local/cm3/pkg/cm3/src M3Backend.i3 M3Backend.m3 UtilsPosix.m3 Arg.i3 Arg.m3 Builder.m3 Builder.i3 Dirs.i3 Dirs.m3 M3Build.i3 M3Build.m3 M3Loc.i3 M3Loc.m3 M3Options.m3 M3Options.i3 M3Path.i3 M3Path.m3 M3Unit.i3 M3Unit.m3 Makefile.i3 Makefile.m3 Msg.m3 Msg.i3 Utils.i3 Utils.m3 WebFile.i3 WebFile.m3 Main.m3 . => /usr/local/cm3/pkg/cm3/PPC_DARWIN cm3 ==> m3-sys/cm3 done /Users/wagner/work/cm3/scripts/do-pkg.sh build m3cc /Users/wagner/work/cm3/scripts/pkgmap.sh -c "cm3 -build -override -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' " m3cc === package m3-sys/m3cc === +++ cm3 -build -override -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- cd . && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: configure-host | tee -a _m3.log cd . && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: configure-host | tee -a _m3.log make all-recursive Making all in tests Making all in . make[4]: Nothing to be done for `all-am'. Making all in devel make[4]: Nothing to be done for `all'. Making all in mpn make[4]: Nothing to be done for `all'. Making all in mpz make[4]: Nothing to be done for `all'. Making all in mpq make[4]: Nothing to be done for `all'. Making all in mpf make[4]: Nothing to be done for `all'. Making all in rand make[4]: Nothing to be done for `all'. Making all in misc make[4]: Nothing to be done for `all'. Making all in cxx make[4]: Nothing to be done for `all'. Making all in mpbsd make[4]: Nothing to be done for `all'. Making all in mpn make[3]: Nothing to be done for `all'. Making all in mpz make[3]: Nothing to be done for `all'. Making all in mpq make[3]: Nothing to be done for `all'. Making all in mpf make[3]: Nothing to be done for `all'. Making all in printf make[3]: Nothing to be done for `all'. Making all in scanf make[3]: Nothing to be done for `all'. Making all in cxx make[3]: Nothing to be done for `all'. Making all in mpbsd make[3]: Nothing to be done for `all'. Making all in demos Making all in calc make all-am make[5]: Nothing to be done for `all-am'. Making all in expr make[4]: Nothing to be done for `all'. make[4]: Nothing to be done for `all-am'. Making all in tune make[3]: Nothing to be done for `all'. Making all in doc make[3]: Nothing to be done for `all'. make[3]: Nothing to be done for `all-am'. sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./gcc/Makefile > ./gcc/Makefile.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./gcc/Makefile > ./gcc/Makefile.1 ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./gcc/Makefile > ./gcc/Makefile.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./gcc/Makefile > ./gcc/Makefile.1 ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile sed -e 's/^#define HAVE_ICONV 1$//' < ./gcc/Makefile > ./gcc/Makefile.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./gcc/Makefile > ./gcc/Makefile.1 ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile sed -e 's/^#define HAVE_ICONV_H 1$//' < ./gcc/Makefile > ./gcc/Makefile.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./gcc/Makefile > ./gcc/Makefile.1 ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h sed -e 's/^#define HAVE_ICONV 1$//' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h sed -e 's/^#define HAVE_ICONV_H 1$//' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./gcc/config.h > ./gcc/config.h.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./gcc/config.h > ./gcc/config.h.1 ../gcc/move-if-change ./gcc/config.h.1 ./gcc/config.h ../gcc/move-if-change ./gcc/config.h.1 ./gcc/config.h sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./gcc/config.h > ./gcc/config.h.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./gcc/config.h > ./gcc/config.h.1 ../gcc/move-if-change ./gcc/config.h.1 ./gcc/config.h ../gcc/move-if-change ./gcc/config.h.1 ./gcc/config.h sed -e 's/^#define HAVE_ICONV 1$//' < ./gcc/config.h > ./gcc/config.h.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./gcc/config.h > ./gcc/config.h.1 ../gcc/move-if-change ./gcc/config.h.1 ./gcc/config.h ../gcc/move-if-change ./gcc/config.h.1 ./gcc/config.h sed -e 's/^#define HAVE_ICONV_H 1$//' < ./gcc/config.h > ./gcc/config.h.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./gcc/config.h > ./gcc/config.h.1 ../gcc/move-if-change ./gcc/config.h.1 ./gcc/config.h ../gcc/move-if-change ./gcc/config.h.1 ./gcc/config.h sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./libcpp/Makefile > ./libcpp/Makefile.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./libcpp/Makefile > ./libcpp/Makefile.1 ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./libcpp/Makefile > ./libcpp/Makefile.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./libcpp/Makefile > ./libcpp/Makefile.1 ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile sed -e 's/^#define HAVE_ICONV 1$//' < ./libcpp/Makefile > ./libcpp/Makefile.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./libcpp/Makefile > ./libcpp/Makefile.1 ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile sed -e 's/^#define HAVE_ICONV_H 1$//' < ./libcpp/Makefile > ./libcpp/Makefile.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./libcpp/Makefile > ./libcpp/Makefile.1 ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./libcpp/config.h > ./libcpp/config.h.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./libcpp/config.h > ./libcpp/config.h.1 ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./libcpp/config.h > ./libcpp/config.h.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./libcpp/config.h > ./libcpp/config.h.1 ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h sed -e 's/^#define HAVE_ICONV 1$//' < ./libcpp/config.h > ./libcpp/config.h.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./libcpp/config.h > ./libcpp/config.h.1 ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h sed -e 's/^#define HAVE_ICONV_H 1$//' < ./libcpp/config.h > ./libcpp/config.h.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./libcpp/config.h > ./libcpp/config.h.1 ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./mpfr/Makefile > ./mpfr/Makefile.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./mpfr/Makefile > ./mpfr/Makefile.1 ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./mpfr/Makefile > ./mpfr/Makefile.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./mpfr/Makefile > ./mpfr/Makefile.1 ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile sed -e 's/^#define HAVE_ICONV 1$//' < ./mpfr/Makefile > ./mpfr/Makefile.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./mpfr/Makefile > ./mpfr/Makefile.1 ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile sed -e 's/^#define HAVE_ICONV_H 1$//' < ./mpfr/Makefile > ./mpfr/Makefile.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./mpfr/Makefile > ./mpfr/Makefile.1 ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile sed -e 's/^#define HAVE_ICONV 1$//' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile sed -e 's/^#define HAVE_ICONV_H 1$//' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile cd . && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: all-gmp all-mpfr all-build-libiberty all-libiberty all-libdecnumber | tee -a _m3.log cd . && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: all-gmp all-mpfr all-build-libiberty all-libiberty all-libdecnumber | tee -a _m3.log make all-recursive Making all in tests Making all in . make[4]: Nothing to be done for `all-am'. Making all in devel make[4]: Nothing to be done for `all'. Making all in mpn make[4]: Nothing to be done for `all'. Making all in mpz make[4]: Nothing to be done for `all'. Making all in mpq make[4]: Nothing to be done for `all'. Making all in mpf make[4]: Nothing to be done for `all'. Making all in rand make[4]: Nothing to be done for `all'. Making all in misc make[4]: Nothing to be done for `all'. Making all in cxx make[4]: Nothing to be done for `all'. Making all in mpbsd make[4]: Nothing to be done for `all'. Making all in mpn make[3]: Nothing to be done for `all'. Making all in mpz make[3]: Nothing to be done for `all'. Making all in mpq make[3]: Nothing to be done for `all'. Making all in mpf make[3]: Nothing to be done for `all'. Making all in printf make[3]: Nothing to be done for `all'. Making all in scanf make[3]: Nothing to be done for `all'. Making all in cxx make[3]: Nothing to be done for `all'. Making all in mpbsd make[3]: Nothing to be done for `all'. Making all in demos Making all in calc make all-am make[5]: Nothing to be done for `all-am'. Making all in expr make[4]: Nothing to be done for `all'. make[4]: Nothing to be done for `all-am'. Making all in tune make[3]: Nothing to be done for `all'. Making all in doc make[3]: Nothing to be done for `all'. make[3]: Nothing to be done for `all-am'. Making all in tests make[2]: Nothing to be done for `all'. make[2]: Nothing to be done for `all-am'. make[2]: Nothing to be done for `all'. make[2]: Nothing to be done for `all'. make[1]: Nothing to be done for `all'. cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a _m3.log cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a _m3.log cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a _m3.log cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a _m3.log make: `s-modes' is up to date. ==> m3-sys/m3cc done /Users/wagner/work/cm3/scripts/install-cm3-compiler.sh upgrade cp /usr/local/cm3/bin/cm3 /usr/local/cm3/bin/cm3-d5.7.0 cp_if: /usr/local/cm3/bin/cm3cg and /usr/local/cm3/bin/cm3cg-d5.7.0 identical cp /Users/wagner/work/cm3/m3-sys/cm3/PPC_DARWIN/cm3 /usr/local/cm3/bin/cm3-d5.8.0 cp /Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/cm3cg /usr/local/cm3/bin/cm3cg-d5.8.0 cp /usr/local/cm3/bin/cm3-d5.8.0 /usr/local/cm3/bin/cm3 cp /usr/local/cm3/bin/cm3cg-d5.8.0 /usr/local/cm3/bin/cm3cg /Users/wagner/work/cm3/scripts/do-cm3-core.sh realclean /Users/wagner/work/cm3/scripts/pkgmap.sh -k -c "rm -rf PPC_DARWIN" import-libs m3cc m3core libm3 patternmatching sysutils unittest m3middle m3objfile m3linker m3back m3staloneback m3front m3quake cm3 m3scanner m3tools m3cgcat m3cggen m3bundle mklib fix_nl libdump bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles tcl === package m3-win/import-libs === === package omitted on this platform === ==> m3-win/import-libs done === package m3-sys/m3cc === === package omitted on this platform === ==> m3-sys/m3cc done === package m3-libs/m3core === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/m3core done === package m3-libs/libm3 === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/libm3 done === package m3-libs/patternmatching === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/patternmatching done === package m3-libs/sysutils === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/sysutils done === package m3-libs/unittest === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/unittest done === package m3-sys/m3middle === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/m3middle done === package m3-sys/m3objfile === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/m3objfile done === package m3-sys/m3linker === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/m3linker done === package m3-sys/m3back === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/m3back done === package m3-sys/m3staloneback === === package omitted on this platform === ==> m3-sys/m3staloneback done === package m3-sys/m3front === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/m3front done === package m3-sys/m3quake === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/m3quake done === package m3-sys/cm3 === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/cm3 done === package m3-sys/m3scanner === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/m3scanner done === package m3-sys/m3tools === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/m3tools done === package m3-sys/m3cgcat === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/m3cgcat done === package m3-sys/m3cggen === +++ rm -rf PPC_DARWIN +++ ==> m3-sys/m3cggen done === package m3-tools/m3bundle === +++ rm -rf PPC_DARWIN +++ ==> m3-tools/m3bundle done === package m3-sys/mklib === === package omitted on this platform === ==> m3-sys/mklib done === package m3-sys/fix_nl === === package omitted on this platform === ==> m3-sys/fix_nl done === package m3-sys/libdump === === package omitted on this platform === ==> m3-sys/libdump done === package m3-libs/bitvector === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/bitvector done === package m3-libs/digraph === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/digraph done === package m3-libs/parseparams === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/parseparams done === package m3-libs/realgeometry === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/realgeometry done === package m3-libs/set === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/set done === package m3-libs/slisp === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/slisp done === package m3-libs/sortedtableextras === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/sortedtableextras done === package m3-libs/table-list === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/table-list done === package m3-libs/tempfiles === +++ rm -rf PPC_DARWIN +++ ==> m3-libs/tempfiles done === package m3-libs/tcl === === package omitted on this platform === ==> m3-libs/tcl done /Users/wagner/work/cm3/scripts/do-cm3-core.sh buildship /Users/wagner/work/cm3/scripts/pkgmap.sh -c "cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' " import-libs m3cc m3core libm3 patternmatching sysutils unittest m3middle m3objfile m3linker m3back m3staloneback m3front m3quake cm3 m3scanner m3tools m3cgcat m3cggen m3bundle mklib fix_nl libdump bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles tcl === package m3-win/import-libs === === package omitted on this platform === ==> m3-win/import-libs done === package m3-sys/m3cc === === package omitted on this platform === ==> m3-sys/m3cc done === package m3-libs/m3core === +++ cm3 -build -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' && cm3 -ship -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling WordRep.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 ../src/runtime/common/RuntimeError.m3: In function 'RuntimeError__Tag': ../src/runtime/common/RuntimeError.m3:56: error: type mismatch in binary expression int_32 int_32 word_32 D.252 = D.251 * 4 ../src/runtime/common/RuntimeError.m3:56: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 1024 m3cc (aka cm3cg) failed compiling: RuntimeError.mc new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling Scheduler.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling RTHeap.i3 new source -> compiling Cstdlib.i3 new source -> compiling LongRep.i3 new source -> compiling Long.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling Cstddef.i3 new source -> compiling Csetjmp.i3 new source -> compiling RTMachine.i3 new source -> compiling Uucontext.i3 new source -> compiling Usysdep.i3 new source -> compiling Cstdint.i3 new source -> compiling Utypes.i3 new source -> compiling Upthread.i3 new source -> compiling RTHeapRep.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 ../src/runtime/common/RTAllocator.m3: In function 'RTAllocator__CheckTypeFailed': ../src/runtime/common/RTAllocator.m3:181: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 1024 m3cc (aka cm3cg) failed compiling: RTAllocator.mc new source -> compiling RTAllocStats.i3 new source -> compiling Convert.i3 new source -> compiling TextClass.i3 new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 ../src/runtime/common/RTAllocStats.m3: In function 'RTAllocStats__EnableTrace': ../src/runtime/common/RTAllocStats.m3:40: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 1024 m3cc (aka cm3cg) failed compiling: RTAllocStats.mc new source -> compiling TextLiteral.i3 new source -> compiling RTHeap.m3 ../src/runtime/common/RTHeap.m3: In function 'RTHeap__GetDataAdr': ../src/runtime/common/RTHeap.m3:20: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 1024 m3cc (aka cm3cg) failed compiling: RTHeap.mc new source -> compiling RTHeapInfo.i3 new source -> compiling Cstring.i3 -------------- next part -------------- /Users/wagner/work/cm3/scripts/pkgmap.sh -c "cm3 -build -override -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' " m3core === package m3-libs/m3core === +++ cm3 -build -override -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' +++ --- building in PPC_DARWIN --- new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling WordRep.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 ../src/runtime/common/RuntimeError.m3: In function 'RuntimeError__Tag': ../src/runtime/common/RuntimeError.m3:56: error: type mismatch in binary expression int_32 int_32 word_32 D.252 = D.251 * 4 ../src/runtime/common/RuntimeError.m3:56: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling Scheduler.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling RTHeap.i3 new source -> compiling Cstdlib.i3 new source -> compiling LongRep.i3 new source -> compiling Long.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling Cstddef.i3 new source -> compiling Csetjmp.i3 new source -> compiling RTMachine.i3 new source -> compiling Uucontext.i3 new source -> compiling Usysdep.i3 new source -> compiling Cstdint.i3 new source -> compiling Utypes.i3 new source -> compiling Upthread.i3 new source -> compiling RTHeapRep.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 ../src/runtime/common/RTAllocator.m3: In function 'RTAllocator__CheckTypeFailed': ../src/runtime/common/RTAllocator.m3:181: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTAllocStats.i3 new source -> compiling Convert.i3 new source -> compiling TextClass.i3 new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 ../src/runtime/common/RTAllocStats.m3: In function 'RTAllocStats__EnableTrace': ../src/runtime/common/RTAllocStats.m3:40: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling TextLiteral.i3 new source -> compiling RTHeap.m3 ../src/runtime/common/RTHeap.m3: In function 'RTHeap__GetDataAdr': ../src/runtime/common/RTHeap.m3:20: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTHeapInfo.i3 new source -> compiling Cstring.i3 new source -> compiling Thread.i3 new source -> compiling RTPerfTool.i3 new source -> compiling RTParams.i3 new source -> compiling RTHeapInfo.m3 ../src/runtime/common/RTHeapInfo.m3: In function 'RTHeapInfo__Producer': ../src/runtime/common/RTHeapInfo.m3:22: error: type mismatch in binary expression int_32 int_32 word_32 D.343 = M3_AcxOUs_i.6 * 4 ../src/runtime/common/RTHeapInfo.m3:22: error: type mismatch in binary expression int_32 int_32 word_32 D.365 = M3_AcxOUs_i.17 * 4 ../src/runtime/common/RTHeapInfo.m3:22: error: type mismatch in binary expression int_32 int_32 word_32 D.385 = M3_AcxOUs_i.26 * 4 ../src/runtime/common/RTHeapInfo.m3:22: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTHeapMap.i3 new source -> compiling RTIO.i3 new source -> compiling RTTypeMap.i3 new source -> compiling RTMapOp.i3 new source -> compiling RTModule.i3 new source -> compiling RTHeapMap.m3 ../src/runtime/common/RTHeapMap.m3: In function 'RTHeapMap__WalkGlobals': ../src/runtime/common/RTHeapMap.m3:73: error: type mismatch in binary expression int_32 int_32 word_32 D.450 = M3_AcxOUs_i.43 * 4 ../src/runtime/common/RTHeapMap.m3:73: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTHeapRep.m3 new source -> compiling RTHeapStats.i3 new source -> compiling FloatMode.i3 new source -> compiling ThreadF.i3 new source -> compiling RTTypeSRC.i3 new source -> compiling RTCollector.i3 new source -> compiling RTHeapStats.m3 ../src/runtime/common/RTHeapStats.m3: In function 'RTHeapStats__ReportReachable': ../src/runtime/common/RTHeapStats.m3:75: error: type mismatch in shift expression int_32 word_32 int_32 D.624 = D.623 >> 20 ../src/runtime/common/RTHeapStats.m3:75: error: type mismatch in shift expression int_32 word_32 int_32 D.634 = D.633 >> 20 ../src/runtime/common/RTHeapStats.m3:75: error: type mismatch in binary expression int_32 int_32 word_32 D.666 = D.665 * 24 ../src/runtime/common/RTHeapStats.m3:75: error: type mismatch in binary expression int_32 int_32 word_32 D.679 = D.678 * 24 ../src/runtime/common/RTHeapStats.m3:75: error: type mismatch in binary expression int_32 int_32 word_32 D.692 = D.691 * 24 ../src/runtime/common/RTHeapStats.m3:75: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Time.i3 new source -> compiling RTLinker.i3 new source -> compiling RTProcess.i3 new source -> compiling RTHeapEvent.i3 new source -> compiling RTWeakRef.i3 new source -> compiling RTCollectorSRC.i3 new source -> compiling RTCollector.m3 ../src/runtime/common/RTCollector.m3: In function 'RTCollector__Disable': ../src/runtime/common/RTCollector.m3:42: internal compiler error: in verify_gimple_expr, at tree-cfg.c:3957 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTIO.m3 new source -> compiling RTLinkerX.i3 new source -> compiling RTSignal.i3 new source -> compiling RTDebug.i3 new source -> compiling RTLinker.m3 ../src/runtime/common/RTLinker.m3: In function 'RTModule__Get': ../src/runtime/common/RTLinker.m3:439: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTDebug.m3 ../src/runtime/common/RTDebug.m3: In function 'RTDebug__DefaultMsg': ../src/runtime/common/RTDebug.m3:36: error: type mismatch in binary expression int_32 int_32 word_32 D.349 = M3_AcxOUs_i.22 * 4 ../src/runtime/common/RTDebug.m3:36: error: type mismatch in binary expression int_32 int_32 word_32 D.377 = M3_AcxOUs_i.29 * 4 ../src/runtime/common/RTDebug.m3:36: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTError.i3 new source -> compiling RTError.m3 new source -> compiling M3toC.i3 new source -> compiling RTException.m3 new source -> compiling RTMapOp.m3 ../src/runtime/common/RTMapOp.m3: In function 'RTMapOp__GetInt': ../src/runtime/common/RTMapOp.m3:11: error: type mismatch in binary expression word_32 word_32 int_32 D.234 = iftmp.12 | M3_AcxOUs_n.15 ../src/runtime/common/RTMapOp.m3:11: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTMisc.m3 new source -> compiling RTPacking.i3 new source -> compiling RTPacking.m3 ../src/runtime/common/RTPacking.m3: In function 'RTPacking__SizeOf': ../src/runtime/common/RTPacking.m3:63: error: type mismatch in binary expression int_32 int_32 word_32 D.311 = M3_AcxOUs_i.10 * 4 ../src/runtime/common/RTPacking.m3:63: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTArgs.i3 new source -> compiling RTParams.m3 ../src/runtime/common/RTParams.m3: In function 'RTParams__Init': ../src/runtime/common/RTParams.m3:78: error: type mismatch in shift expression int_32 word_32 int_32 D.618 = D.617 >> 1 ../src/runtime/common/RTParams.m3:78: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTProcedure.m3 ../src/runtime/common/RTProcedure.m3: In function 'RTProcedureSRC__FromPC': ../src/runtime/common/RTProcedure.m3:57: error: type mismatch in binary expression int_32 int_32 word_32 D.377 = M3_AcxOUs_i.14 * 4 ../src/runtime/common/RTProcedure.m3:57: error: type mismatch in binary expression int_32 int_32 word_32 D.413 = M3_AcxOUs_best.34 * 4 ../src/runtime/common/RTProcedure.m3:57: error: type mismatch in binary expression int_32 int_32 word_32 D.443 = M3_AcxOUs_best.48 * 4 ../src/runtime/common/RTProcedure.m3:57: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTProcess.m3 new source -> compiling RTTipe.i3 new source -> compiling RTTipe.m3 ../src/runtime/common/RTTipe.m3: In function 'RTTipe__ReadOp': ../src/runtime/common/RTTipe.m3:106: error: type mismatch in binary expression int_32 int_32 word_32 D.792 = D.791 * 4 ../src/runtime/common/RTTipe.m3:106: error: type mismatch in binary expression int_32 int_32 word_32 D.899 = D.898 * 4 ../src/runtime/common/RTTipe.m3:106: error: type mismatch in binary expression int_32 int_32 word_32 D.986 = D.985 * 4 ../src/runtime/common/RTTipe.m3:106: error: type mismatch in binary expression int_32 int_32 word_32 D.1073 = D.1072 * 4 ../src/runtime/common/RTTipe.m3:106: error: type mismatch in binary expression int_32 int_32 word_32 D.1157 = D.1156 * 4 ../src/runtime/common/RTTipe.m3:106: error: type mismatch in binary expression int_32 int_32 word_32 D.1303 = D.1302 * 4 ../src/runtime/common/RTTipe.m3:106: error: type mismatch in binary expression int_32 int_32 word_32 D.1412 = D.1411 * 4 ../src/runtime/common/RTTipe.m3:106: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTType.m3 ../src/runtime/common/RTType.m3: In function 'RTType__Get': ../src/runtime/common/RTType.m3:71: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTTypeFP.i3 new source -> compiling RTTypeFP.m3 ../src/runtime/common/RTTypeFP.m3: In function 'RTTypeFP__FromFingerprint': ../src/runtime/common/RTTypeFP.m3:23: error: type mismatch in binary expression int_32 int_32 word_32 D.285 = M3_AcxOUs_x.17 * 4 ../src/runtime/common/RTTypeFP.m3:23: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTTypeMap.m3 ../src/runtime/common/RTTypeMap.m3: In function 'RTTypeMap__Walk': ../src/runtime/common/RTTypeMap.m3:51: error: type mismatch in binary expression word_32 int_32 word_32 D.657 = M3_DrLXJX_mask.111 & 65536 ../src/runtime/common/RTTypeMap.m3:51: error: type mismatch in binary expression word_32 word_32 int_32 D.695 = iftmp.124 & M3_DrLXJX_mask.128 ../src/runtime/common/RTTypeMap.m3:51: error: type mismatch in binary expression int_32 int_32 word_32 D.715 = D.714 * 4 ../src/runtime/common/RTTypeMap.m3:51: error: type mismatch in binary expression word_32 word_32 int_32 D.736 = iftmp.139 & M3_DrLXJX_mask.143 ../src/runtime/common/RTTypeMap.m3:51: error: type mismatch in binary expression int_32 int_32 word_32 D.790 = D.789 * 4 ../src/runtime/common/RTTypeMap.m3:51: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTutils.i3 new source -> compiling RTutils.m3 ../src/runtime/common/RTutils.m3: In function 'RTutils__Delta': ../src/runtime/common/RTutils.m3:78: error: type mismatch in binary expression int_32 int_32 word_32 D.687 = M3_AcxOUs_i.30 * 12 ../src/runtime/common/RTutils.m3:78: error: type mismatch in binary expression int_32 int_32 word_32 D.718 = M3_AcxOUs_i.36 * 12 ../src/runtime/common/RTutils.m3:78: error: type mismatch in binary expression int_32 int_32 word_32 D.749 = M3_AcxOUs_i.42 * 12 ../src/runtime/common/RTutils.m3:78: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTHeapDebug.i3 new source -> compiling WeakRef.i3 new source -> compiling RTHeapDebug.m3 ../src/runtime/common/RTHeapDebug.m3: In function 'RTHeapDebug__Free': ../src/runtime/common/RTHeapDebug.m3:48: error: type mismatch in binary expression int_32 int_32 word_32 D.348 = D.347 * 8 ../src/runtime/common/RTHeapDebug.m3:48: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTArgs.m3 ../src/runtime/POSIX/RTArgs.m3: In function 'RTArgs__GetArg': ../src/runtime/POSIX/RTArgs.m3:21: error: type mismatch in binary expression int_32 int_32 word_32 D.245 = D.244 * 4 ../src/runtime/POSIX/RTArgs.m3:21: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Uuio.i3 new source -> compiling Unix.i3 new source -> compiling Utime.i3 new source -> compiling RTOS.m3 new source -> compiling Uexec.i3 new source -> compiling RTPerfTool.m3 new source -> compiling Usignal.i3 new source -> compiling RTThread.i3 new source -> compiling RTThreadStk.m3 ../src/runtime/POSIX/RTThreadStk.m3: In function 'RTThread__GetStack': ../src/runtime/POSIX/RTThreadStk.m3:15: error: type mismatch in binary expression int_32 int_32 word_32 D.238 = D.237 * 12 ../src/runtime/POSIX/RTThreadStk.m3:15: error: type mismatch in binary expression int_32 int_32 word_32 D.271 = D.270 * 12 ../src/runtime/POSIX/RTThreadStk.m3:15: error: type mismatch in binary expression int_32 int_32 word_32 D.279 = D.278 * 12 ../src/runtime/POSIX/RTThreadStk.m3:15: error: type mismatch in binary expression int_32 int_32 word_32 D.307 = D.306 * 12 ../src/runtime/POSIX/RTThreadStk.m3:15: error: type mismatch in binary expression int_32 int_32 word_32 D.320 = D.319 * 12 ../src/runtime/POSIX/RTThreadStk.m3:15: error: type mismatch in binary expression int_32 int_32 word_32 D.326 = D.325 * 12 ../src/runtime/POSIX/RTThreadStk.m3:15: error: type mismatch in binary expression int_32 int_32 word_32 D.334 = D.333 * 12 ../src/runtime/POSIX/RTThreadStk.m3:15: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTSignalPrivate.i3 new source -> compiling RTSignalC.i3 new source -> compiling RTSignal.m3 new source -> compiling Umman.i3 new source -> compiling RTThread.m3 ../src/runtime/PPC_DARWIN/RTThread.m3: In function 'RTThread__NewStack': ../src/runtime/PPC_DARWIN/RTThread.m3:26: error: type mismatch in shift expression int_32 word_32 int_32 D.261 = D.260 >> 2 ../src/runtime/PPC_DARWIN/RTThread.m3:26: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTExFrame.i3 new source -> compiling RTExFrame.m3 ../src/runtime/ex_frame/RTExFrame.m3: In function 'RTExFrame_M3': ../src/runtime/ex_frame/RTExFrame.m3:279: internal compiler error: tree check: did not expect class 'type', have 'type' (pointer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling SchedulerPosix.i3 new source -> compiling MutexRep.i3 new source -> compiling ThreadEvent.i3 new source -> compiling ThreadPThread.i3 new source -> compiling Uerror.i3 new source -> compiling Usched.i3 new source -> compiling Cerrno.i3 new source -> compiling ThreadPThread.m3 ../src/thread/PTHREAD/ThreadPThread.m3: In function 'ThreadPThread__SetState': ../src/thread/PTHREAD/ThreadPThread.m3:98: error: type mismatch in binary expression int_32 int_32 word_32 D.954 = D.953 * 4 ../src/thread/PTHREAD/ThreadPThread.m3:98: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling WinBaseTypes.i3 new source -> compiling WinDef.i3 new source -> compiling WinDef.m3 ../src/win32/WinDef.m3: In function 'WinDef__MAKEWORD': ../src/win32/WinDef.m3:78: error: type mismatch in binary expression word_32 word_32 int_32 D.365 = iftmp.1 | D.364 ../src/win32/WinDef.m3:78: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling WinNT.i3 new source -> compiling WinNT.m3 ../src/win32/WinNT.m3: In function 'WinNT__BTYPE': ../src/win32/WinNT.m3:19: error: type mismatch in binary expression word_32 int_32 int_32 D.212 = D.211 & 15 ../src/win32/WinNT.m3:19: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Unetdb.i3 new source -> compiling Uutmp.i3 new source -> compiling Ugrp.i3 new source -> compiling Upwd.i3 new source -> compiling Uugid.i3 new source -> compiling Uprocess.i3 new source -> compiling Unix.m3 new source -> compiling Usocket.i3 new source -> compiling Uin.i3 new source -> compiling Ustat.i3 new source -> compiling Udir.i3 new source -> compiling Usignal.m3 new source -> compiling Uin.m3 new source -> compiling Text8CString.i3 new source -> compiling Text8.i3 new source -> compiling M3toC.m3 new source -> compiling Csignal.i3 new source -> compiling Cstdio.i3 new source -> compiling Cstdio.m3 ../src/C/PPC_DARWIN/Cstdio.m3: In function 'Cstdio_M3': ../src/C/PPC_DARWIN/Cstdio.m3:6: error: type mismatch in binary expression int_32 int_32 word_32 D.212 = M3_AcxOUs_i.2 * 4 ../src/C/PPC_DARWIN/Cstdio.m3:6: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Real.i3 new source -> compiling RealFloat.i3 new source -> compiling LongReal.i3 new source -> compiling LongFloat.i3 new source -> compiling Extended.i3 new source -> compiling ExtendedFloat.i3 new source -> compiling IEEESpecial.i3 new source -> compiling LongRealRep.i3 new source -> compiling RealRep.i3 new source -> compiling IEEESpecial.m3 new source -> compiling Real.m3 new source -> compiling LongReal.m3 new source -> compiling Extended.m3 new source -> compiling DragonInt.i3 new source -> compiling DragonInt.m3 ../src/float/Common/DragonInt.m3: In function 'DragonInt__New': ../src/float/Common/DragonInt.m3:126: error: type mismatch in binary expression word_32 int_32 int_32 D.722 = M3_AcxOUs_a.24 & 16777215 ../src/float/Common/DragonInt.m3:126: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling DragonT.i3 new source -> compiling DragonT.m3 new source -> compiling FPU.i3 new source -> compiling RealFloat.m3 ../src/float/IEEE/RealFloat.m3: In function 'RealFloat__ILogb': ../src/float/IEEE/RealFloat.m3:40: error: type mismatch in binary expression word_32 int_32 int_32 D.409 = M3_AcxOUs_v.14 & M3_AcxOUs_w.15 ../src/float/IEEE/RealFloat.m3:40: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling LongFloat.m3 ../src/float/IEEE/LongFloat.m3: In function 'LongFloat__ILogb': ../src/float/IEEE/LongFloat.m3:44: error: type mismatch in binary expression word_32 int_32 int_32 D.410 = M3_AcxOUs_v.18 & M3_AcxOUs_w.19 ../src/float/IEEE/LongFloat.m3:44: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling ExtendedFloat.m3 new source -> compiling FPU.m3 new source -> compiling FloatMode.m3 new source -> compiling Tick.i3 new source -> compiling Date.i3 new source -> compiling FmtTime.i3 new source -> compiling FmtTime.m3 ../src/time/Common/FmtTime.m3: In function 'FmtTime__DateLong': ../src/time/Common/FmtTime.m3:38: error: type mismatch in binary expression int_32 int_32 word_32 D.300 = D.299 * 4 ../src/time/Common/FmtTime.m3:38: error: type mismatch in binary expression int_32 int_32 word_32 D.326 = D.325 * 4 ../src/time/Common/FmtTime.m3:38: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling TickPortable.m3 new source -> compiling TimePosix.i3 new source -> compiling DateBsd.m3 new source -> compiling TimePosix.m3 new source -> compiling CConvert.i3 new source -> compiling CConvert.m3 ../src/convert/CConvert.m3: In function 'CConvert__Acquire': ../src/convert/CConvert.m3:15: internal compiler error: in verify_gimple_expr, at tree-cfg.c:3957 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Convert.m3 ../src/convert/Convert.m3: In function 'Convert__InternalFromLongFloat': ../src/convert/Convert.m3:337: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling String8.i3 new source -> compiling String8.m3 ../src/text/String8.m3: In function 'String8__Hash': ../src/text/String8.m3:30: error: type mismatch in binary expression word_32 word_32 int_32 D.299 = D.294 ^ D.298 ../src/text/String8.m3:30: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling String16.i3 new source -> compiling String16.m3 ../src/text/String16.m3: In function 'String16__Hash': ../src/text/String16.m3:45: error: type mismatch in binary expression word_32 word_32 int_32 D.374 = D.369 ^ D.373 ../src/text/String16.m3:45: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Text16.i3 new source -> compiling Text.m3 ../src/text/Text.m3: In function 'Text__EqualBuf': ../src/text/Text.m3:47: error: type mismatch in binary expression int_32 int_32 word_32 D.611 = D.610 * 2 ../src/text/Text.m3:47: error: type mismatch in binary expression int_32 int_32 word_32 D.618 = D.617 * 2 ../src/text/Text.m3:47: error: type mismatch in binary expression int_32 int_32 word_32 D.685 = D.684 * 2 ../src/text/Text.m3:47: error: type mismatch in binary expression int_32 int_32 word_32 D.690 = D.689 * 2 ../src/text/Text.m3:47: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling TextClass.m3 ../src/text/TextClass.m3: In function 'TextClass__GetChar': ../src/text/TextClass.m3:8: error: type mismatch in binary expression word_32 int_32 int_32 D.234 = D.233 & 255 ../src/text/TextClass.m3:8: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling TextLiteral.m3 ../src/text/TextLiteral.m3: In function 'RTHooks__TextLitGetChar': ../src/text/TextLiteral.m3:19: error: type mismatch in binary expression word_32 int_32 int_32 D.307 = D.306 & 255 ../src/text/TextLiteral.m3:19: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Text8Short.i3 new source -> compiling Text8.m3 ../src/text/Text8.m3: In function 'Text8__New': ../src/text/Text8.m3:20: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Text8Short.m3 ../src/text/Text8Short.m3: In function 'Text8Short__GetChars': ../src/text/Text8Short.m3:41: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Text8CString.m3 new source -> compiling Text16Short.i3 new source -> compiling Text16.m3 ../src/text/Text16.m3: In function 'Text16__New': ../src/text/Text16.m3:20: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Text16Short.m3 ../src/text/Text16Short.m3: In function 'Text16Short__New': ../src/text/Text16Short.m3:15: error: type mismatch in binary expression int_32 int_32 word_32 D.276 = D.275 * 2 ../src/text/Text16Short.m3:15: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling TextSub.i3 new source -> compiling TextCat.i3 new source -> compiling TextSub.m3 ../src/text/TextSub.m3: In function 'Text__Sub': ../src/text/TextSub.m3:65: internal compiler error: tree check: did not expect class 'type', have 'type' (integer_type) in m3cg_pop, at m3cg/parse.c:4337 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling TextCat.m3 ../src/text/TextCat.m3: In function 'RTHooks__MultiCat': ../src/text/TextCat.m3:39: error: type mismatch in binary expression int_32 int_32 word_32 D.488 = M3_AcxOUs_i.42 * 4 ../src/text/TextCat.m3:39: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling TextConv.i3 new source -> compiling TextConv.m3 ../src/text/TextConv.m3: In function 'TextConv__EncodeChar': ../src/text/TextConv.m3:46: error: type mismatch in shift expression int_32 word_32 int_32 D.497 = D.496 >> 6 ../src/text/TextConv.m3:46: error: type mismatch in binary expression word_32 int_32 int_32 D.510 = D.509 & 63 ../src/text/TextConv.m3:46: error: type mismatch in shift expression int_32 word_32 int_32 D.511 = D.510 >> 3 ../src/text/TextConv.m3:46: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Poly.i3 new source -> compiling Fingerprint.m3 ../src/fingerprint/Fingerprint.m3: In function 'Fingerprint__Fix32': ../src/fingerprint/Fingerprint.m3:93: error: type mismatch in binary expression word_32 word_32 int_32 D.407 = M3_AcxOUs_x.61 | -2147483648 ../src/fingerprint/Fingerprint.m3:93: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Poly.m3 ../src/fingerprint/Poly.m3: In function 'Poly__Sum': ../src/fingerprint/Poly.m3:45: error: type mismatch in binary expression word_32 int_32 int_32 D.381 = D.377 ^ D.380 ../src/fingerprint/Poly.m3:45: error: type mismatch in binary expression word_32 int_32 int_32 D.391 = D.386 ^ D.390 ../src/fingerprint/Poly.m3:45: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling PolyBasis.i3 new source -> compiling PolyBasis.m3 new source -> compiling Main.i3 new source -> compiling WeakRef.m3 new source -> compiling Word.m3 ../src/word/Word.m3 => ../src/word/GenWord.mg: In function 'Word__And': ../src/word/Word.m3 => ../src/word/GenWord.mg:19: error: type mismatch in binary expression word_32 int_32 int_32 D.381 = M3_AcxOUs_x.36 & M3_AcxOUs_y.37 ../src/word/Word.m3 => ../src/word/GenWord.mg:19: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Long.m3 ../src/word/Long.m3 => ../src/word/GenWord.mg: In function 'Long__And': ../src/word/Long.m3 => ../src/word/GenWord.mg:19: error: type mismatch in binary expression word_64 int_64 int_64 D.382 = M3_AGDpCO_x.36 & M3_AGDpCO_y.37 ../src/word/Long.m3 => ../src/word/GenWord.mg:19: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTLinkerC.c new source -> compiling RTOSmmap.c new source -> compiling RTSignalC.c new source -> compiling RTThreadC.c new source -> compiling RTMachineC.c new source -> compiling RTStackC.c new source -> compiling ThreadPThreadC.c new source -> compiling WinNTc.c new source -> compiling UtimeC.c new source -> compiling UnixC.c new source -> compiling Uexec.c new source -> compiling Unetdb.c new source -> compiling Umman.c new source -> compiling Ugrp.c new source -> compiling Uconstants.c new source -> compiling UstatC.c new source -> compiling Usocket.c new source -> compiling UdirC.c new source -> compiling CerrnoC.c new exporters -> recompiling RTHooks.i3 new exporters -> recompiling RTAllocCnts.i3 new exporters -> recompiling RTHeapRep.i3 new exporters -> recompiling RTCollectorSRC.i3 new exporters -> recompiling RTWeakRef.i3 new exporters -> recompiling RTException.i3 new exporters -> recompiling RTModule.i3 new exporters -> recompiling RTProcedureSRC.i3 new exporters -> recompiling RTTypeSRC.i3 new exporters -> recompiling RTOS.i3 new exporters -> recompiling RTThread.i3 new exporters -> recompiling RTSignalPrivate.i3 new exporters -> recompiling Thread.i3 new exporters -> recompiling Scheduler.i3 new exporters -> recompiling SchedulerPosix.i3 new exporters -> recompiling ThreadF.i3 new exporters -> recompiling Time.i3 new exporters -> recompiling Tick.i3 new exporters -> recompiling Date.i3 new exporters -> recompiling Text.i3 compilation failed => not building library "libm3core.a" Fatal Error: package build failed *** execution of cm3 -build -override -DROOT='/Users/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.8.0' -DCM3_VERSION_NUMBER='050800' -DCM3_LAST_CHANGED='2009-04-11' failed *** From wagner at elegosoft.com Sat Apr 11 11:26:11 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 11 Apr 2009 11:26:11 +0200 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <49DE5A8A.5070307@bellsouth.net> References: <49DE5A8A.5070307@bellsouth.net> Message-ID: <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> Quoting Martin Bishop : > A few days ago there was more talk of a proper "release" for CM3. I > think this is very important. I second that. I'll try to start the release engineering now, as nobody else seems to volunteer ;-) We have two options here though: we can either (a) agree on a code freeze (beginning at some date we need to agree upon) (b) create a release branch immediately Code freeze would mean that nobody commits any major new functionality any more, but all commits concentrate on fixing bugs in some set of release candiates. I'd rather avoid creating a branch too early, as that means more work by selecting and merging fixes from trunk to branch. So here my questions: o Do we all agree on a temporary code freeze? o When should we start? I.e. wha changes would you like to complete before we start the release process? Please let me know your opinions, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 11 13:44:18 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 11 Apr 2009 13:44:18 +0200 Subject: [M3devel] (D)DCVSup in DCCS/DCVS for download Message-ID: <20090411134418.cqc2yem2g44ogkkg@mail.elegosoft.com> Hi, I've put most of the source code of our more or less abandoned DCCS project into http://www.opencm3.net/uploaded-archives/dccs-public.tar.gz for download. It contains a complete and extended version of CVSup along with much other potentially useful M3 code. I was able to compile everything with a recent CM3 for target FreeBSD4. To build everything, cd to dccs-public/prod and type make all. Please note that the resulting executables for CVSup are named dcvsup and dcvsupd, but they should work without DCVS configuration, too. At least you should be able to use the source to get get standard CVSup to compile. Hope this helps, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Sat Apr 11 13:44:41 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 11 Apr 2009 07:44:41 -0400 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> Message-ID: <20090411114441.GA22262@topoi.pooq.com> On Sat, Apr 11, 2009 at 11:26:11AM +0200, Olaf Wagner wrote: > o When should we start? I.e. wha changes would you like to complete > before we start the release process? The change to the ButtonVBT I brought up earlier. But if I continue not having time to get to it, you'd better release rather than watining indefinitely. I'd also like to make some progress in creating the monotone archive. But that's probably not relevant to the release process. It had perhaps better be thought of as (conceptually, at least) something for after the release. -- hendrik From jay.krell at cornell.edu Sat Apr 11 14:03:39 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 11 Apr 2009 12:03:39 +0000 Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN In-Reply-To: <20090411105512.92784fp7cc0o448k@mail.elegosoft.com> References: <20090411105512.92784fp7cc0o448k@mail.elegosoft.com> Message-ID: I do test on 10.4 fairly often, at least do-cm3-std buildship and/or make-dist, I even lately don't always skip gcc, I can report recent results soon. I've got a few PPC iBooks/PowerBooks and might yet try 10.2 or 3 or 5. It sounds like 7.9.0 is 10.3? Do my archives work for you, but then a locally build cm3cg doesn't? What does config.guess say? Can you try removing all the stuff I put in? cd somewhere configure -disable-bootstrap -disable-multilibs make If desperate I can send you a 10.4 machine and you can send me your 10.3, but it's not likely worth the shipping. - Jay > Date: Sat, 11 Apr 2009 10:55:12 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN > > After trying to upgrade cm3 on my notebook to the latest version, > I get lots of internal compiler errors.This is on > > % uname -a > Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 > 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power > Macintosh powerpc > > ... > new source -> compiling RuntimeError.m3 > ../src/runtime/common/RuntimeError.m3: In function 'RuntimeError__Tag': > ../src/runtime/common/RuntimeError.m3:56: error: type mismatch in > binary expression > int_32 > > int_32 > > word_32 > > D.252 = D.251 * 4 > ../src/runtime/common/RuntimeError.m3:56: internal compiler error: > verify_gimple failed > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > ... > > Full log attached. > > Before you ask, it won't be easy to upgrade Darwin on this notebook, > and I surely cannot do this within the next two weeks :-/ > > Any ideas? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Apr 11 14:19:37 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 11 Apr 2009 12:19:37 +0000 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <20090411114441.GA22262@topoi.pooq.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> Message-ID: > > o When should we start? I.e. wha changes would you like to complete > > before we start the release process? I'd like to see the formsvbt crash debugged and fixed, unless I'm the only one seeing it. I only see it on Solaris and PPC_DARWIN but haven't tried "everything". I'll try to get this. I'd also like to see: FreeBSD/x86 switched to the new Unix/*.i3 files. I'll do this. Maybe also I386_DARWIN, AMD64_DARWIN, but I don't have the hardware. $ORIGIN/LD_LIBRARY_PATH resolved a bit further, probably very little work (I'll do this). Basically just 1) put buildlocal back how it was 2) push it across more platforms e.g. I think FreeBSD/x86 is the main one missing, but I'll get to it. cvsup building and in "std" (I'll do this, probably very little left here really. -- beyond this, not required for release -- Maybe more AMD64 releases, e.g. NetBSD and Solaris. (If I get to it). (could be "mingw64" is good enough to try AMD64_NT now). Maybe update gmp/mpfr to fix the "maintainer" problem. (not likely by me) Maybe more new/resuscitated platforms..HPPA64_HPUX, IA64_*, *_VMS, ALPHA_*, ARM_*, *_IRIX, *_AIX, MIPS64_*.... but these take back seat to important fixes in existing platforms. Fix NT386 to use setjmp3 instead of setjmp so exceptions don't skip C __finally blocks. I've just been very lazy here, should demonstrate the behavior with a test case, then fix it.. Maybe fix cm3cg so other -g options besides -gstabs works, like plain -g, -ggdb, on at least one platform -gstabs isn't supported, leaving nothing, because others cause internal compiler errors, like on HPPA64_HPUX. Oh, and NT386GNU probably switched back to Win32 threads. Otherwise one of the test cases hangs and it doesn't look easy to figure out. I'll do this shortly if I remember. But I also wouldn't mind if this platform isn't officially released either (unless someone else wants to support it). Debug why many NT386MINGNU gui apps crash..but also probably just don't release this platform and ok asis. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Apr 11 14:21:38 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 11 Apr 2009 14:21:38 +0200 Subject: [M3devel] (D)DCVSup in DCCS/DCVS for download In-Reply-To: <20090411134418.cqc2yem2g44ogkkg@mail.elegosoft.com> References: <20090411134418.cqc2yem2g44ogkkg@mail.elegosoft.com> Message-ID: <20090411142138.mvnqsfqdus8wk8ko@mail.elegosoft.com> That still does not work on AMD64_LINUX yet. Even after changing dcvs/cvsup/quake/cvsup.quake to recognize Jay's new config files with if defined("INITIAL_REACTOR_EDITOR") or defined("CM3SetInstallRoot") M3_VARIANT = "CM3" I get several errors in FileAttr.m3 and dev_t_linux/DevT.m3. It seems there are some 64 bit issues. I've got to stop M3 work for today, though; perhaps Jay will look further into compiling CVSup for Linux today... Olaf Quoting Olaf Wagner : > Hi, > > I've put most of the source code of our more or less abandoned > DCCS project into > > http://www.opencm3.net/uploaded-archives/dccs-public.tar.gz > > for download. > > It contains a complete and extended version of CVSup along with > much other potentially useful M3 code. > > I was able to compile everything with a recent CM3 for target > FreeBSD4. > > To build everything, cd to dccs-public/prod and type make all. > Please note that the resulting executables for CVSup are named > dcvsup and dcvsupd, but they should work without DCVS configuration, > too. At least you should be able to use the source to get get standard > CVSup to compile. > > Hope this helps, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Sat Apr 11 16:27:02 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 11 Apr 2009 10:27:02 -0400 Subject: [M3devel] m3 CVS? In-Reply-To: References: <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> <20090325144505.GA16526@topoi.pooq.com> <20090325225421.GB17118@topoi.pooq.com> <20090330131918.GA6921@topoi.pooq.com> <20090331133910.flci659jockgo04c@mail.elegosoft.com> <20090331135610.GA9539@topoi.pooq.com> <20090331161908.3pferzf9c08oso40@mail.elegosoft.com> Message-ID: <20090411142702.GA22586@topoi.pooq.com> On Tue, Mar 31, 2009 at 10:41:42PM +0000, Jay wrote: > > Also, presumably you can copy the entire CVS repository with little CPU use and then do the monotone work locally. I doubt it is all that large, can tell you later.. (ssh in and du /usr/cvs) > > > > - Jay OK. What's the recommended way of copying the CVS repository? Downloading a .tgz file? Or figuring out how to get cvsup up first? (the more tools I have to build before I can test feasibility, the less likely I am to get there. cvsup doesn't seem to be available in Debian; perhaps that's because Modula 3 isn't either) I seem to have two ways to try to build the monotone repository. (1) use monotone's rcs_imnport command (2) use the cvs_sync branch, generate a new monotone from that branch, and see what it does. I'd have to try both so see what's feasible. Each seems to have limitations. rcs_import seems to want to have access to the cvs files instead of network access to CVS. -- hendrik > > > > Date: Tue, 31 Mar 2009 16:19:08 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > CC: manderson at elego.de > > Subject: Re: [M3devel] m3 CVS? > > > > Quoting hendrik at topoi.pooq.com: > > > > > On Tue, Mar 31, 2009 at 01:39:10PM +0200, Olaf Wagner wrote: > > >> Quoting hendrik at topoi.pooq.com: > > >> > > >> >Is CVS back up yet? Completely? I've been delaying trying the > > >> >monotone conversion because it would be nice to have only one set > > >> >of problems to look into. > > >> > > >> CVS is up and no history should be lost, but tinderbox is still not > > >> working and several archives are missing. Michael is working on it > > >> (but he's got some other tasks, too). > > > > > > So the current source is available, but not the tools to investigate > > > their status on-line. And the other archives? What are they? Are they > > > more source code? Should they be subject to revision control too? Are > > > they ancient prehistory that should be grafted into the revision tree > > > except that it may not be technically feasible? > > > > Mostly all the old installation archives and snapshots are still missing. > > I'm not sure what's the status of the re-installation of tinderbox. > > > > > Ah. I have too many questions. > > > > > > By the way, rumours are that monotone's cvs pull command is quite > > > demanding on the cvs server, but that sync operation isn't bad at all > > > after that. Getting really old versions of files requires CVS to chain > > > back through a lot of reverse differences. And I don't know if it > > > caches any of that in case it is asked to cough up another really old > > > version. > > > > > > If there are any scheduling considerations I'd like to hear them. I > > > don't know if I'll flatten your system, but if I do there are probably > > > better and worse times to do it. (I may saturate ny DSL link first, but > > > you never know until you try it.) > > > > > > By the way, what's the total size of Modula 3's CVS archive? > > > > I've got no access from here (can only check later tonight); please > > ask Michael Anderson directly for administrative topics. > > > > Olaf > > > > PS: I don't think you can bring the server down a one external CVS > > client; the syncing will just take a long time. Unless lots of parallel > > requests are started... > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > From neels at elego.de Sat Apr 11 23:20:24 2009 From: neels at elego.de (Neels J Hofmeyr) Date: Sat, 11 Apr 2009 23:20:24 +0200 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> Message-ID: <49E10998.5010205@elego.de> I have no opinion since I'm not active in the code. ~Neels Olaf Wagner wrote: > Quoting Martin Bishop : > >> A few days ago there was more talk of a proper "release" for CM3. I >> think this is very important. > > I second that. > > I'll try to start the release engineering now, as nobody else seems > to volunteer ;-) > > We have two options here though: we can either > > (a) agree on a code freeze (beginning at some date we need to agree upon) > (b) create a release branch immediately > > Code freeze would mean that nobody commits any major new functionality > any more, but all commits concentrate on fixing bugs in some set of > release candiates. > > I'd rather avoid creating a branch too early, as that means more work > by selecting and merging fixes from trunk to branch. So here my questions: > > o Do we all agree on a temporary code freeze? > o When should we start? I.e. wha changes would you like to complete > before we start the release process? > > Please let me know your opinions, > > Olaf -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From jay.krell at cornell.edu Sun Apr 12 05:00:39 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 12 Apr 2009 03:00:39 +0000 Subject: [M3devel] readdir/malloc Message-ID: cvsup source says: (*****************************************************************************) (* FIXME - The following procedures work around a bug in SRC Modula-3 thru version 3.6, at least. The FS.Iterator operations call the Unix opendir, readdir, and closedir functions, which in turn usually call malloc. This is done without any mutual exclusion, and malloc is normally not thread-safe. I have observed memory corruption and have traced it to this cause. As a work-around, these wrappers disable thread switching while the offending functions are executing. *) (*****************************************************************************) This is already fixed wrt opendir/closedir in cm3. But readdir? True? I guess I'll be pessimistic and assume it is true. - Jay From jay.krell at cornell.edu Sun Apr 12 13:32:07 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 12 Apr 2009 11:32:07 +0000 Subject: [M3devel] cvsup Message-ID: cvsup builds and starts up on a few platforms now, including Cygwin/x86, Linux/x86, Linux/AMD64 (birch), Macosx/PowerPC, FreeBSD/x86. I can verify more later.. I expect there might be problems on Macosx/x86 and AMD64. And FreeBSD/x86 might not work until I commit the change to use Unix/common. That is -- these are the only platforms not using Unix/common. Some platforms store extra "flags" with files -- Darwin and *BSD. Historically cvsup only get/sets those on FreeBSD. I extended that to the others, though didn't build NetBSD/OpenBSD. (nor have I tested any of the functionality at all..) The source should be refactored some in this regard, the "FreeBSD" directory split into "FreeBSD" and "flags" or something. But I don't like moving files since history might not track well. (I also chose "m3-tools" arbitrarily..) It might not even have to be refactored -- instead of the static platform checks, the code can check of the #defines in Ustat are zero or not, and UstatC.c can provide empty chflags/fchflags functions instead of none at all. It's a tricky area though in terms of what is best, providing no functions, vs. providing functions that do nothing and succeed, vs. providing functions that do nothing and fail, vs. providing a more explicit way to query if the functionality is provided, as well as deciding between build-time vs. run-time checks (we don't have anything like autoconf in our system, for better and worse). Now hopefully we can switch to svn or monotone and cvsup won't matter to us. :) (Well, I never use it in any case. I know it is big in FreeBSD-land.) - Jay From jay.krell at cornell.edu Sun Apr 12 13:34:49 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 12 Apr 2009 11:34:49 +0000 Subject: [M3devel] FW: cvsup Message-ID: [truncated again..] cvsup builds and starts up on a few platforms now, including Cygwin/x86, Linux/x86, Linux/AMD64 (birch), Macosx/PowerPC, FreeBSD/x86. I can verify more later.. I expect there might be problems on Macosx/x86 and AMD64. And FreeBSD/x86 might not work until I commit the change to use Unix/common. That is -- these are the only platforms not using Unix/common. Some platforms store extra "flags" with files -- Darwin and *BSD. see man chflags and man 2 chflags. Historically cvsup only get/sets those on FreeBSD. I extended that to the others, though didn't build NetBSD/OpenBSD. (nor have I tested any of the functionality at all..) The source should be refactored some in this regard, the "FreeBSD" directory split into "FreeBSD" and "flags" or something. But I don't like moving files since history might not track well. (I also chose "m3-tools" arbitrarily..) It might not even have to be refactored -- instead of the static platform checks, the code can check of the #defines in Ustat are zero or not, and UstatC.c can provide empty chflags/fchflags functions instead of none at all. It's a tricky area though in terms of what is best, providing no functions, vs. providing functions that do nothing and succeed, vs. providing functions that do nothing and fail, vs. providing a more explicit way to query if the functionality is provided, as well as deciding between build-time vs. run-time checks (we don't have anything like autoconf in our system, for better and worse). Now hopefully we can switch to svn or monotone and cvsup won't matter to us. :) (Well, I never use it in any case. I know it is big in FreeBSD-land.) - Jay From jay.krell at cornell.edu Sun Apr 12 13:40:45 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 12 Apr 2009 11:40:45 +0000 Subject: [M3devel] (D)DCVSup in DCCS/DCVS for download In-Reply-To: <20090411134418.cqc2yem2g44ogkkg@mail.elegosoft.com> References: <20090411134418.cqc2yem2g44ogkkg@mail.elegosoft.com> Message-ID: Yes, this helped, thank you. FreeBSD4 is unusual in that it has more complete and compatible (and platform specific) m3core/unix. - Jay ---------------------------------------- > Date: Sat, 11 Apr 2009 13:44:18 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] (D)DCVSup in DCCS/DCVS for download > > Hi, > > I've put most of the source code of our more or less abandoned > DCCS project into > > http://www.opencm3.net/uploaded-archives/dccs-public.tar.gz > > for download. > > It contains a complete and extended version of CVSup along with > much other potentially useful M3 code. > > I was able to compile everything with a recent CM3 for target > FreeBSD4. > > To build everything, cd to dccs-public/prod and type make all. > Please note that the resulting executables for CVSup are named > dcvsup and dcvsupd, but they should work without DCVS configuration, > too. At least you should be able to use the source to get get standard > CVSup to compile. > > Hope this helps, > > Olaf > -- From jay.krell at cornell.edu Sun Apr 12 14:07:44 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 12 Apr 2009 12:07:44 +0000 Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN In-Reply-To: <20090411105512.92784fp7cc0o448k@mail.elegosoft.com> References: <20090411105512.92784fp7cc0o448k@mail.elegosoft.com> Message-ID: My machine calls itself: jbook15:~ jay$ uname -a Darwin jbook15.local 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc That is 10.4.something. It works ok. cm3cg built as recently as 4/10.. - Jay ________________________________ > From: jay > To: wagner; m3devel > Subject: RE: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN > Date: Sat, 11 Apr 2009 12:03:39 +0000> > > I do test on 10.4 fairly often... > It sounds like 7.9.0 is 10.3? > > > - Jay > >> Date: Sat, 11 Apr 2009 10:55:12 +0200 >> From: wagner@ >> To: m3devel@ >> Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN >> >> After trying to upgrade cm3 on my notebook to the latest version, >> I get lots of internal compiler errors.This is on >> >> % uname -a >> Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 >> 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power >> Macintosh powerpc >> >> ... From jay.krell at cornell.edu Sun Apr 12 21:45:44 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 12 Apr 2009 19:45:44 +0000 Subject: [M3devel] cvsup and "flags" Message-ID: Um, these "flags" that cvsup is willing to traffic: 1) They are the same between machines that support them? Maybe, maybe not, I can check. 2) They are actually interesting? Given that many operating systems (e.g. Linux, Solaris) don't support them? They seem a little dubious. I suppose most cvsup users have both client and server on FreeBSD and if the FreeBSD source itself needs these flags on source controled files, it is useful. Even storing an executable bit in cvs seems not portable..but that is a different set of flags. (NTFS ACL should be reasonable superset, but then, FAT?) - Jay From mika at async.caltech.edu Sun Apr 12 22:05:49 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 12 Apr 2009 13:05:49 -0700 Subject: [M3devel] quick question for the Modula-3 ether... LONGFLOAT?? Message-ID: <200904122005.n3CK5omN035622@camembert.async.caltech.edu> Does anyone out there have any idea why a lot of bits of Modula-3 refer to something called "LONGFLOAT" or "LongFloat". I just checked Wirth, and Modula-2 used "REAL" as well so it doesn't seem like LONGREAL would ever have been called "LONGFLOAT". Is LONGFLOAT/LongFloat of any significance or is it OK to search-and-replace it away with LONGREAL/LongReal everywhere? (I'm talking about things like the emacs macro package as well as all over m3tk...) Mika From jay.krell at cornell.edu Mon Apr 13 00:01:35 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 12 Apr 2009 22:01:35 +0000 Subject: [M3devel] quick question for the Modula-3 ether... LONGFLOAT?? In-Reply-To: <200904122005.n3CK5omN035622@camembert.async.caltech.edu> References: <200904122005.n3CK5omN035622@camembert.async.caltech.edu> Message-ID: 1) I'm sure it is a natural term to all the other programmers, easy mistake to make. 2) There in fact this natural need to come up with alternate names. You know, if you read the compiler and runtime source, you see things called Type and/or Tipe, not just Type, because Type (or at least TYPE) is already a reserved word if you write "metacode" dealing with types, you can't use that name. In that vein there are some public m3core modules for dealing with floats/reals/whatever and they might use names like this. - Jay > To: m3devel at elegosoft.com > Date: Sun, 12 Apr 2009 13:05:49 -0700 > From: mika at async.caltech.edu > Subject: [M3devel] quick question for the Modula-3 ether... LONGFLOAT?? > > > Does anyone out there have any idea why a lot of bits of Modula-3 > refer to something called "LONGFLOAT" or "LongFloat". I just checked > Wirth, and Modula-2 used "REAL" as well so it doesn't seem like > LONGREAL would ever have been called "LONGFLOAT". > > Is LONGFLOAT/LongFloat of any significance or is it OK to > search-and-replace it away with LONGREAL/LongReal everywhere? > > (I'm talking about things like the emacs macro package as well as > all over m3tk...) > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Apr 13 00:22:23 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 12 Apr 2009 15:22:23 -0700 Subject: [M3devel] quick question for the Modula-3 ether... LONGFLOAT?? In-Reply-To: Your message of "Sun, 12 Apr 2009 22:01:35 -0000." Message-ID: <200904122222.n3CMMNTc041696@camembert.async.caltech.edu> It seems a bit more common a term than I would have thought from someone's making a mistake. I am talking about things like this. In the stubgen sources, there are two interfaces: Value.i3 and Type.i3. Not the only place I've seen it in Modula-3. Value.i3 has: TYPE T <: ROOT; (* Ordinal | Float | LongFloat | Extended | ArrayOrRecord | Set | Text | Null *) Ordinal = T OBJECT ord: INTEGER END; (* ORD(the value) *) Float = T OBJECT val: REAL END; (* XXX *) LongFloat = T OBJECT val: LONGREAL END; (* XXX *) Extended = T OBJECT val: EXTENDED END; ... Type.i3 has: TYPE T <: OBJECT name: Qid; visited := FALSE; brandsOK := TRUE END; (* Ordinal | Real | LongReal | Extended | Reference | Array | Packed | Record | Set | Procedure *) Ordinal = T BRANDED OBJECT END; (* Enumeration | Subrange *) (* ... *) Real = T BRANDED OBJECT END; (* YYY *) LongReal = T BRANDED OBJECT END; (* YYY *) Extended = T BRANDED OBJECT END; ... Is there a reason or is this just inconsistent crud from before the glaciers came thru? Mika Jay writes: >--_eaf98d33-2bbc-4e5b-8afc-bc1f32079c51_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >1) I'm sure it is a natural term to all the other programmers=2C easy mista= >ke to make. > >=20 > >2) There in fact this natural need to come up with alternate names. > >You know=2C if you read the compiler and runtime source=2C you see things c= >alled Type and/or Tipe=2C not just Type=2C because Type (or at least TYPE) = >is already a reserved word if you write "metacode" dealing with types=2C yo= >u can't use that name. > >=20 > >In that vein there are some public m3core modules for dealing with floats/r= >eals/whatever and they might use names like this. > >=20 > > - Jay > > >=20 >> To: m3devel at elegosoft.com >> Date: Sun=2C 12 Apr 2009 13:05:49 -0700 >> From: mika at async.caltech.edu >> Subject: [M3devel] quick question for the Modula-3 ether... LONGFLOAT?? >>=20 >>=20 >> Does anyone out there have any idea why a lot of bits of Modula-3 >> refer to something called "LONGFLOAT" or "LongFloat". I just checked >> Wirth=2C and Modula-2 used "REAL" as well so it doesn't seem like >> LONGREAL would ever have been called "LONGFLOAT". >>=20 >> Is LONGFLOAT/LongFloat of any significance or is it OK to >> search-and-replace it away with LONGREAL/LongReal everywhere? >>=20 >> (I'm talking about things like the emacs macro package as well as >> all over m3tk...) >>=20 >> Mika > >--_eaf98d33-2bbc-4e5b-8afc-bc1f32079c51_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >1) I'm sure it is a natural term to all the =3Bother programmers=2C eas= >y mistake to make.
> =3B
>2) There in fact this =3Bnatural need to come up with alternate names.<= >BR> >You know=2C if you read the compiler =3Band runtime source=2C you see t= >hings called Type and/or Tipe=2C not just Type=2C because Type (or at least= > TYPE) is already a reserved word if you write =3B"metacode" dealing wi= >th types=2C you can't use that name.
> =3B
>In that =3Bvein there are some =3Bpublic m3core modules for dealing= > with floats/reals/whatever and they =3Bmight use names like this.
> =3B
> =3B- Jay


 =3B
>=3B To: m3devel at elegosoft.com
&g= >t=3B Date: Sun=2C 12 Apr 2009 13:05:49 -0700
>=3B From: mika at async.cal= >tech.edu
>=3B Subject: [M3devel] quick question for the Modula-3 ether= >... LONGFLOAT??
>=3B
>=3B
>=3B Does anyone out there have = >any idea why a lot of bits of Modula-3
>=3B refer to something called = >"LONGFLOAT" or "LongFloat". I just checked
>=3B Wirth=2C and Modula-2 = >used "REAL" as well so it doesn't seem like
>=3B LONGREAL would ever h= >ave been called "LONGFLOAT".
>=3B
>=3B Is LONGFLOAT/LongFloat of= > any significance or is it OK to
>=3B search-and-replace it away with = >LONGREAL/LongReal everywhere?
>=3B
>=3B (I'm talking about thing= >s like the emacs macro package as well as
>=3B all over m3tk...)
&g= >t=3B
>=3B Mika
>= > >--_eaf98d33-2bbc-4e5b-8afc-bc1f32079c51_-- From jay.krell at cornell.edu Mon Apr 13 02:00:40 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 13 Apr 2009 00:00:40 +0000 Subject: [M3devel] quick question for the Modula-3 ether... LONGFLOAT?? In-Reply-To: <200904122222.n3CMMNTc041696@camembert.async.caltech.edu> References: Your message of "Sun, 12 Apr 2009 22:01:35 -0000." <200904122222.n3CMMNTc041696@camembert.async.caltech.edu> Message-ID: Here is the stuff I was talking about: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/float/Common/ This stuff is "standard" and in the green book. Surprising that both names occur here, float and real. You can see your example sort of proves my point. Imagine if there was no case sensitivity. Or if you aren't keen on identifiers varying only in case. The below needs to setup a parallel set of names for "wrapper types", or WrapperModule.T. Changing "Float" to "Real" or vice versa can help. Though, now that I'm saying it, it feels a bit sleazy. Maybe better to invent a prefix or suffix. IntegerValue, RealValue, etc. (That reminds me, I've seen "reel" used in a similar fashion.) You know, using homonyms -- ea vs. ee, y for long i, etc. tipe, type runtime, runtyme - Jay > To: jay.krell at cornell.edu > Date: Sun, 12 Apr 2009 15:22:23 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] quick question for the Modula-3 ether... LONGFLOAT?? > > > It seems a bit more common a term than I would have thought from > someone's making a mistake. > > I am talking about things like this. In the stubgen sources, there are > two interfaces: Value.i3 and Type.i3. > > Not the only place I've seen it in Modula-3. > > Value.i3 has: > > TYPE > T <: ROOT; > (* Ordinal | Float | LongFloat | Extended | ArrayOrRecord | Set | > Text | Null *) > > Ordinal = T OBJECT ord: INTEGER END; > (* ORD(the value) *) > > Float = T OBJECT val: REAL END; (* XXX *) > > LongFloat = T OBJECT val: LONGREAL END; (* XXX *) > > Extended = T OBJECT val: EXTENDED END; > > ... > > Type.i3 has: > > TYPE > T <: OBJECT name: Qid; visited := FALSE; brandsOK := TRUE END; > > (* Ordinal | Real | LongReal | Extended | Reference | Array > | Packed | Record | Set | Procedure *) > > Ordinal = T BRANDED OBJECT END; (* Enumeration | Subrange *) > > (* ... *) > > Real = T BRANDED OBJECT END; (* YYY *) > > LongReal = T BRANDED OBJECT END; (* YYY *) > > Extended = T BRANDED OBJECT END; > > ... > > Is there a reason or is this just inconsistent crud from before the > glaciers came thru? > > Mika > > > Jay writes: > >--_eaf98d33-2bbc-4e5b-8afc-bc1f32079c51_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >1) I'm sure it is a natural term to all the other programmers=2C easy mista= > >ke to make. > > > >=20 > > > >2) There in fact this natural need to come up with alternate names. > > > >You know=2C if you read the compiler and runtime source=2C you see things c= > >alled Type and/or Tipe=2C not just Type=2C because Type (or at least TYPE) = > >is already a reserved word if you write "metacode" dealing with types=2C yo= > >u can't use that name. > > > >=20 > > > >In that vein there are some public m3core modules for dealing with floats/r= > >eals/whatever and they might use names like this. > > > >=20 > > > > - Jay > > > > > >=20 > >> To: m3devel at elegosoft.com > >> Date: Sun=2C 12 Apr 2009 13:05:49 -0700 > >> From: mika at async.caltech.edu > >> Subject: [M3devel] quick question for the Modula-3 ether... LONGFLOAT?? > >>=20 > >>=20 > >> Does anyone out there have any idea why a lot of bits of Modula-3 > >> refer to something called "LONGFLOAT" or "LongFloat". I just checked > >> Wirth=2C and Modula-2 used "REAL" as well so it doesn't seem like > >> LONGREAL would ever have been called "LONGFLOAT". > >>=20 > >> Is LONGFLOAT/LongFloat of any significance or is it OK to > >> search-and-replace it away with LONGREAL/LongReal everywhere? > >>=20 > >> (I'm talking about things like the emacs macro package as well as > >> all over m3tk...) > >>=20 > >> Mika > > > >--_eaf98d33-2bbc-4e5b-8afc-bc1f32079c51_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >1) I'm sure it is a natural term to all the =3Bother programmers=2C eas= > >y mistake to make.
> > =3B
> >2) There in fact this =3Bnatural need to come up with alternate names.<= > >BR> > >You know=2C if you read the compiler =3Band runtime source=2C you see t= > >hings called Type and/or Tipe=2C not just Type=2C because Type (or at least= > > TYPE) is already a reserved word if you write =3B"metacode" dealing wi= > >th types=2C you can't use that name.
> > =3B
> >In that =3Bvein there are some =3Bpublic m3core modules for dealing= > > with floats/reals/whatever and they =3Bmight use names like this.
> > =3B
> > =3B- Jay


 =3B
>=3B To: m3devel at elegosoft.com
&g= > >t=3B Date: Sun=2C 12 Apr 2009 13:05:49 -0700
>=3B From: mika at async.cal= > >tech.edu
>=3B Subject: [M3devel] quick question for the Modula-3 ether= > >... LONGFLOAT??
>=3B
>=3B
>=3B Does anyone out there have = > >any idea why a lot of bits of Modula-3
>=3B refer to something called = > >"LONGFLOAT" or "LongFloat". I just checked
>=3B Wirth=2C and Modula-2 = > >used "REAL" as well so it doesn't seem like
>=3B LONGREAL would ever h= > >ave been called "LONGFLOAT".
>=3B
>=3B Is LONGFLOAT/LongFloat of= > > any significance or is it OK to
>=3B search-and-replace it away with = > >LONGREAL/LongReal everywhere?
>=3B
>=3B (I'm talking about thing= > >s like the emacs macro package as well as
>=3B all over m3tk...)
&g= > >t=3B
>=3B Mika
> >= > > > >--_eaf98d33-2bbc-4e5b-8afc-bc1f32079c51_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.m.bates at cox.net Mon Apr 13 04:12:34 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Sun, 12 Apr 2009 21:12:34 -0500 Subject: [M3devel] small objects In-Reply-To: <200904101918.n3AJIcLj003231@camembert.async.caltech.edu> References: <200904101918.n3AJIcLj003231@camembert.async.caltech.edu> Message-ID: <49E29F92.7000808@cox.net> Mika Nystrom wrote: > Sigh, I hate sending so many emails to a mailing list. Sorry about > the inboxes I'm clogging of people with no interest in this. > > But I just realized something important, which I think may be > decisive in deciding the fate of the name "REFANY" in the addition > of new types. > > Rodney proposes > > TAGGED T <: TAGGED REFANY > No. I am specifically proposing that TAGGED T and TAGGED U have _no_ subtype relation, when T #U. Putting the tagged types into their own hierarchy creates a big complicated subtype mess, with both two hierarchies on the one hand and subtype cross-links between them on the other hand. I also really calls for a new, complex structural type equality rule that is very out of sync with the existing type equality rule. > T <: REFANY <: TAGGED REFANY > > I propose > > TAGGED T <: REFANY > T <: UNTAGGEDREFANY <: REFANY > > Both proposals are identical in the power of the language that > results, because they differ merely in naming. > > Both proposals are also backward-compatible: all existing Modula-3 > programs are unchanged by them. > > However, UNTAGGEDREFANY (mine), is *forward*-compatible as well > as backward-compatible. > > Think about it. The TAGGED REFANY proposal will have the following > effect: people will go through all the M3 libraries and replace > every or almost every occurrence of REFANY with TAGGED REFANY. The > resulting code will not compile with an older compiler! > > In my proposal, it is the user of the TAGGED types who is responsible > for---in new code only!---deciding whether he wants his code to > compile both on older and newer M3 systems. If he does, then he > can add appropriate implementations for compilers that don't support > the TAGGED types (which will be trivial since he has to have those > anyway!) The burden of handling change is on the programmer of the > special new feature rather than on everyone who has a container > module. > Well, I do see how this certain class of uses of REFANY could have their meaning changed in this way, with no required editing of source code. But it reminds me of the joke that real programmers don't fix their code, they just patch the compiler. Despite my strong belief in the ability to have portable code, I think it is a terrible thing to have the same code have fundamentally different semantics when compiled by different compilers, even if you can cite a large class of uses for which this semantic change happens to be handy. For portable container data structures between pre/post tagged Modula-3, declare a type in one place and change it in that one place: TYPE MostGeneralContainerElement = REFANY. or TYPE MostGeneralContainerElement = TAGGED REFANY. Then have all the containter ADTs equate their element type to this. It is also a glaring inconsistency to have all reference types other than REFANY to be untagged by default and made tagged by an explicit TAGGED, while REFANY defaults the other way around. > I'll try to refrain from posting any more messages on this topic now. > > Mika > > "Rodney M. Bates" writes: > >> Mika Nystrom wrote: >> >>> Sorry to splice together two emails from you, but I feel I've already >>> used up my m3devel quota this week: >>> >>> "Rodney M. Bates" writes: >>> >>> >>>>> Are you sure? I want a type---some type---that can hold "any >>>>> reference, even a tagged one", and I would rewrite most library >>>>> code that today takes REFANY to take that instead. Why not? Why >>>>> would I want to limit it to REFANY when it performs no operations >>>>> that couldn't legally be performed on TAGGED REFANY. >>>>> >>>>> >>>>> >>>> I believe my "safe" proposal would make this very simple, if I am >>>> thinking of the kind of library code you are. >>>> >>>> I envision a container data structure that takes in things and returns >>>> them without performing operations on them other than moving them around >>>> and storing them, e.g. the ever belabored stack. The values going in >>>> and out are declared REFANY, and the client passes in values of >>>> some proper subtype of REFANY, which get assigned to the REFANY >>>> parameters. When it gets them back, it narrows them to this type. >>>> >>>> In this pattern, just changing the declared type of the container values >>>> >>>> >>> >from REFANY to TAGGED REFANY would do it. The library code's storage >>> ... >>> >>> >> There are two very different kinds of uses of reference and >> tagged types. The one I speak of above is for the type of the >> elements inside a container data structure. In this case, it >> is the client that knows what type the value really is, and will >> declare it as such. The library ADT module should know as little >> as possible about it, so it will declare it as REFANY or >> TAGGED REFANY. Here, you want the most general type >> possible, just to make the abstraction more versatile. >> And TAGGED REFANY generalizes it from REFANY. >> >> But... >> >>> >>> >> >>>>> you'd like to store these in a REFANY and dynamically test for the >>>>> appropriate tagged type: >>>>> >>>>> >>>> No, I do not want to store these in a variable of type REFANY or any >>>> other existing type. >>>> In fact, I want to forbid it. >>>> >>>> >>> I think you are thinking of exactly the same kind of library code. >>> TextRefTbl.T, RefList.T, etc. >>> >>> After the introduction of TAGGED REFANY, what use is there for >>> REFANY? What piece of code can you think of where the cost of the >>> 1-LSB check of TAGGED REFANY outweighs the convenience of being >>> able to process objects of type TAGGED T (for all ref types T) as >>> well as objects of type T? >>> >>> >> The other use is for the abstract type itself. Forgetting tagged >> types for a moment, I have never seen an interface/module that >> uses REFANY for this. Instead, the modules declare their abstract >> type as some proper subtype of REFANY, usually an opaque type. >> >> It would be possible to use just REFANY here of course, but that would >> require an otherwise unnecessary RT check on the allocated type, >> every time an operation of the module is called. This is a much >> more expensive check than a tag check, as has been pointed out >> in this discussion. >> >> But worse, it would sacrifice the static checking that we now have >> that prevents, at compile time, clients from passing, say a Text.T >> to some procedure in Atom that expects an Atom.T. If these modules >> ever wanted to use a tagged type, but the only tagged type were >> REFANY, we would lose this static checking, because Text.T would >> have to become equal to Atom.T. >> >> In cases where your algorithms don't specifically need dynamic >> typing, static typing is always much better, because one run of >> the compiler on the source code will do it. Bugs checked >> only at runtime require a massive test suit to be coded and then >> regularly rerun to get even close to the same confidence they've >> been found. >> >> So when using tagged types as the ADT itself,, we need to be able >> to have a tagged version of whatever proper subtype of REFANY >> the abstraction needs, including an opaque subtype of REFANY >> or an opaque subtype of some Public subtype of REFANY. This is >> why I am adamant that we need to be able to build a tagged type >> > >from any traced or object type. > >> And once you do this, keeping REFANY itself unchanged and allowing >> TAGGED REFANY as one case of a tagged type falls out of the system >> for free _and_ saves a lot of cases that would otherwise need a new RT >> check that can never fail, but the language can't know that, because >> the type system has lost the distinction. >> >> I really feel that the fad of all dynamic typing in languages is a huge >> mistake and that it will someday be recognized as such. In the >> meantime, we have a language that provides a very extensive set >> of statically-typed alternatives, while also allowing dynamic typing >> when you really need it. This is one of Modula-3's best principles. >> Let's don't erode the static alternatives unnecessarily. >> >> >>> Mika >>> >>> >>> > > From rodney.m.bates at cox.net Mon Apr 13 04:12:29 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Sun, 12 Apr 2009 21:12:29 -0500 Subject: [M3devel] small objects In-Reply-To: <200904101902.n3AJ27UI002559@camembert.async.caltech.edu> References: <200904101902.n3AJ27UI002559@camembert.async.caltech.edu> Message-ID: <49E29F8D.9040103@cox.net> Mika Nystrom wrote: > Specific proposal. > > What Rodney said, *except* make REFANY the root of everything. > Insert an untagged root with a new name. > > Rodney himself has said that the uses of REFANY he knows about would > be changed to accept the TAGGED type, No, not all of them. Just those that are the element type of general-purpose container data types. > so I simply propose allowing > REFANY to handle the TAGGED type by default, and insert a new root > for the untagged types. The structure of the type hierarchy is > exactly the same as in Rodney's proposal, but the different naming > makes it more backward-compatible. > > ROOT <: UNTAGGEDREFANY > T <: UNTAGGEDREFANY > > UNTAGGEDREFANY <: REFANY > > and finally. > > TAGGED T <: REFANY (* for all T *) > > The advantages with this proposal are that it does precisely what > Rodney is asking for (typesafe ADTs), but it's compatible with > Tony's runtime changes in the *current* M3 implementation and it > won't require anyone to do a massive search and replace, replacing > REFANY with "TAGGED REFANY" in every existing Modula-3 program. > > Supposed disadvantage: every TYPECASE, NARROW, etc., of REFANY will > cost an extra LSB check. Those who feel strongly about that and > for some reason *know* that they don't want to process TAGGED types > (which may be the empty set), can modify their code to use > UNTAGGEDREFANY instead of REFANY. > I am still not sure we are communicating. I am proposing that _only_ the tagged types, i.e., those constructed by TAGGED T, for T a traced or object type, can have a LSB nonzero. So TYPECASE and friends will not have an LSB check when applied to T, only when applied to TAGGED T. > Mika > > "Rodney M. Bates" writes: > >> Mika Nystrom wrote: >> >>> Sorry to splice together two emails from you, but I feel I've already >>> used up my m3devel quota this week: >>> >>> "Rodney M. Bates" writes: >>> >>> >>>>> Are you sure? I want a type---some type---that can hold "any >>>>> reference, even a tagged one", and I would rewrite most library >>>>> code that today takes REFANY to take that instead. Why not? Why >>>>> would I want to limit it to REFANY when it performs no operations >>>>> that couldn't legally be performed on TAGGED REFANY. >>>>> >>>>> >>>>> >>>> I believe my "safe" proposal would make this very simple, if I am >>>> thinking of the kind of library code you are. >>>> >>>> I envision a container data structure that takes in things and returns >>>> them without performing operations on them other than moving them around >>>> and storing them, e.g. the ever belabored stack. The values going in >>>> and out are declared REFANY, and the client passes in values of >>>> some proper subtype of REFANY, which get assigned to the REFANY >>>> parameters. When it gets them back, it narrows them to this type. >>>> >>>> In this pattern, just changing the declared type of the container values >>>> >>>> >>> >from REFANY to TAGGED REFANY would do it. The library code's storage >>> ... >>> >>> >> There are two very different kinds of uses of reference and >> tagged types. The one I speak of above is for the type of the >> elements inside a container data structure. In this case, it >> is the client that knows what type the value really is, and will >> declare it as such. The library ADT module should know as little >> as possible about it, so it will declare it as REFANY or >> TAGGED REFANY. Here, you want the most general type >> possible, just to make the abstraction more versatile. >> And TAGGED REFANY generalizes it from REFANY. >> >> But... >> >>> >>> >> >>>>> you'd like to store these in a REFANY and dynamically test for the >>>>> appropriate tagged type: >>>>> >>>>> >>>> No, I do not want to store these in a variable of type REFANY or any >>>> other existing type. >>>> In fact, I want to forbid it. >>>> >>>> >>> I think you are thinking of exactly the same kind of library code. >>> TextRefTbl.T, RefList.T, etc. >>> >>> After the introduction of TAGGED REFANY, what use is there for >>> REFANY? What piece of code can you think of where the cost of the >>> 1-LSB check of TAGGED REFANY outweighs the convenience of being >>> able to process objects of type TAGGED T (for all ref types T) as >>> well as objects of type T? >>> >>> >> The other use is for the abstract type itself. Forgetting tagged >> types for a moment, I have never seen an interface/module that >> uses REFANY for this. Instead, the modules declare their abstract >> type as some proper subtype of REFANY, usually an opaque type. >> >> It would be possible to use just REFANY here of course, but that would >> require an otherwise unnecessary RT check on the allocated type, >> every time an operation of the module is called. This is a much >> more expensive check than a tag check, as has been pointed out >> in this discussion. >> >> But worse, it would sacrifice the static checking that we now have >> that prevents, at compile time, clients from passing, say a Text.T >> to some procedure in Atom that expects an Atom.T. If these modules >> ever wanted to use a tagged type, but the only tagged type were >> REFANY, we would lose this static checking, because Text.T would >> have to become equal to Atom.T. >> >> In cases where your algorithms don't specifically need dynamic >> typing, static typing is always much better, because one run of >> the compiler on the source code will do it. Bugs checked >> only at runtime require a massive test suit to be coded and then >> regularly rerun to get even close to the same confidence they've >> been found. >> >> So when using tagged types as the ADT itself,, we need to be able >> to have a tagged version of whatever proper subtype of REFANY >> the abstraction needs, including an opaque subtype of REFANY >> or an opaque subtype of some Public subtype of REFANY. This is >> why I am adamant that we need to be able to build a tagged type >> > >from any traced or object type. > >> And once you do this, keeping REFANY itself unchanged and allowing >> TAGGED REFANY as one case of a tagged type falls out of the system >> for free _and_ saves a lot of cases that would otherwise need a new RT >> check that can never fail, but the language can't know that, because >> the type system has lost the distinction. >> >> I really feel that the fad of all dynamic typing in languages is a huge >> mistake and that it will someday be recognized as such. In the >> meantime, we have a language that provides a very extensive set >> of statically-typed alternatives, while also allowing dynamic typing >> when you really need it. This is one of Modula-3's best principles. >> Let's don't erode the static alternatives unnecessarily. >> >> >>> Mika >>> >>> >>> > > From jay.krell at cornell.edu Mon Apr 13 11:46:22 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 13 Apr 2009 09:46:22 +0000 Subject: [M3devel] pieces of TARGET? Message-ID: We have: TARGET= NT386, LINUXLIBC6, AMD64_DARWIN, etc. OS_TYPE= Win32 or POSIX I added HOST, HOST_OS_TYPE, etc. We should also have TARGET_ARCHITECTURE=X86,AMD64,SPARC32,SPARC64,PPC32,PPC64,MIP32,MIP64,etc. probably defined be whatever preceded the first underscore in new consistently named targets (X86 or I386?) Because already have WORD_SIZE, can probably refine this to just: X86,AMD64,SPARC,PPC,MIPS, no general need for "32" and "64" variants. (I hesitate to point out that neither ALPHA nor IA64 imply WORD_SIZE=64. NT on Alpha had 32bit and 64bit variants, HP-UX on IA64 ditto for usermode). Maybe even can drop AMD64 from this list. TARGET_OS or TARGET_KERNEL or somesuch=NT,LINUX,SOLARIS,DARWIN,CYGWIN, etc. probably defined to be whatever follows the lone underscore in new consistently named targets, with a single underscore Leaving unspecified what to do about ARM and its competing calling conventions and C runtimes Then we can check, for example, if TARGET_OS == "FREEBSD" and get all architectures at once. There isn't a huge need for this, but some. Besides, TARGET_ENDIAN= BIG or LITTLE should probably be exposed. You know, if you look at the lists of platforms, both in Target.m3 and the various m3makefiles, sometimes they can be shortened. Sometimes all that is needed is the "OS" (e.g. the time/date stuff) or the endian or architecture(the float stuff). I realize there aren't tons of these lists, so it's not a huge deal. Let me know if any objections are strong opinions on nailing some of the details. My biggest objection is there is always a lag from the time compiler changes are in, until you can/should depend on them. Building newer code with older compiler and such. It makes it such that it seems sometimes not worth changing anything. Thanks, - Jay From wagner at elegosoft.com Mon Apr 13 12:51:48 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 13 Apr 2009 12:51:48 +0200 Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN In-Reply-To: References: <20090411105512.92784fp7cc0o448k@mail.elegosoft.com> Message-ID: <20090413125148.vxbxs7ftessckwko@mail.elegosoft.com> Quoting Jay : > > My machine calls itself: > > jbook15:~ jay$ uname -a > Darwin jbook15.local 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 > 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh > powerpc > > That is 10.4.something. It works ok. cm3cg built as recently as 4/10.. So it seems OK for newer MacOS X releases. I worked around it here by continuning to use an older backend, which seems OK for now. Doing a realclean and a complete rebuild, I got syntax errors with some pattern substitution in a Makefile, and the build stopped. I'll try a newer backend compiled on another machine, too. Olaf > - Jay > > > ________________________________ >> From: jay >> To: wagner; m3devel >> Subject: RE: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN >> Date: Sat, 11 Apr 2009 12:03:39 +0000> >> >> I do test on 10.4 fairly often... > >> It sounds like 7.9.0 is 10.3? >> >> >> - Jay >> >>> Date: Sat, 11 Apr 2009 10:55:12 +0200 >>> From: wagner@ >>> To: m3devel@ >>> Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN >>> >>> After trying to upgrade cm3 on my notebook to the latest version, >>> I get lots of internal compiler errors.This is on >>> >>> % uname -a >>> Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 >>> 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power >>> Macintosh powerpc >>> >>> ... -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 13 12:56:40 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 13 Apr 2009 12:56:40 +0200 Subject: [M3devel] cvsup and "flags" In-Reply-To: References: Message-ID: <20090413125640.58q2uf7spw0w844o@mail.elegosoft.com> Quoting Jay : > > Um, these "flags" that cvsup is willing to traffic: > > 1) They are the same between machines that support them? > Maybe, maybe not, I can check. > > 2) They are actually interesting? Given that many operating > systems (e.g. Linux, Solaris) don't support them? Yes, they are interesting and important, since they are in use at many sites. They're not portable as far as I know though. The system immutable flag is used by many FreeBSD installations to further protect from accidental and unauthorized changes. > They seem a little dubious. > I suppose most cvsup users have both client and server on FreeBSD > and if the FreeBSD source itself needs these flags on source > controled files, it is useful. > > Even storing an executable bit in cvs seems not portable..but that > is a different set of flags. (NTFS ACL should be reasonable > superset, but then, FAT?) POSIX file access control lists should be portable to a certain degree. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 13 12:58:30 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 13 Apr 2009 10:58:30 +0000 Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN In-Reply-To: <20090413125148.vxbxs7ftessckwko@mail.elegosoft.com> References: <20090411105512.92784fp7cc0o448k@mail.elegosoft.com> <20090413125148.vxbxs7ftessckwko@mail.elegosoft.com> Message-ID: > I got syntax errors with > some pattern substitution in a Makefile, and the build stopped. make vs. gmake? - Jay ---------------------------------------- > Date: Mon, 13 Apr 2009 12:51:48 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN > > Quoting Jay : > >> >> My machine calls itself: >> >> jbook15:~ jay$ uname -a >> Darwin jbook15.local 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 >> 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh >> powerpc >> >> That is 10.4.something. It works ok. cm3cg built as recently as 4/10.. > > So it seems OK for newer MacOS X releases. I worked around it here by > continuning to use an older backend, which seems OK for now. > Doing a realclean and a complete rebuild, I got syntax errors with > some pattern substitution in a Makefile, and the build stopped. > > I'll try a newer backend compiled on another machine, too. > > Olaf > >> - Jay >> >> >> ________________________________ >>> From: jay >>> To: wagner; m3devel >>> Subject: RE: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN >>> Date: Sat, 11 Apr 2009 12:03:39 +0000> >>> >>> I do test on 10.4 fairly often... >> >>> It sounds like 7.9.0 is 10.3? >>> >>> >>> - Jay >>> >>>> Date: Sat, 11 Apr 2009 10:55:12 +0200 >>>> From: wagner@ >>>> To: m3devel@ >>>> Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN >>>> >>>> After trying to upgrade cm3 on my notebook to the latest version, >>>> I get lots of internal compiler errors.This is on >>>> >>>> % uname -a >>>> Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 >>>> 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power >>>> Macintosh powerpc >>>> >>>> ... > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 13 13:04:58 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 13 Apr 2009 11:04:58 +0000 Subject: [M3devel] cvsup and "flags" In-Reply-To: <20090413125640.58q2uf7spw0w844o@mail.elegosoft.com> References: <20090413125640.58q2uf7spw0w844o@mail.elegosoft.com> Message-ID: It's a little different to say "these flags are useful" vs. "I should be able to store these flags in source control". Not entirely different, but somewhat. If you need them in source control, then you need your source control system to bother with system-dependent possibly esoteric features. On the other hand, if nobody every catered to good system-dependent aspects, a lot of things would be a lot worse. I only skimmed the cvsup source a little, but I think it traffics in plain integers. It would be smarter to traffic in the "name" of the flag, and the "OS name" it originated from..and maybe allow some "required" vs. "optional" bit. That way, if Darwin and FreeBSD both had the flag "FOO", it hopefully/probably means the same on each, but could be "translated" into the proper integer. And if user deemed flag "FOO" important than cvsup could error for updates to a system that doesn't support it. Maybe it already does do these things though. Some people use "source control" for keep track of and backup their "system configuration" or perhaps their entire "system install". Whereas most people just store a bunch of text files. There can be quite a difference -- e.g. support for hardlinks, symlinks, owner user, owner group, etc.. Folks just storing textual source files tend to have lighter requirements. (which reminds me -- can you clear the executable bit on the vast majority of non-directories in the tree, like outside of scripts/*.sh and scripts/*.py) - Jay ---------------------------------------- > Date: Mon, 13 Apr 2009 12:56:40 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] cvsup and "flags" > > Quoting Jay : > >> >> Um, these "flags" that cvsup is willing to traffic: >> >> 1) They are the same between machines that support them? >> Maybe, maybe not, I can check. >> >> 2) They are actually interesting? Given that many operating >> systems (e.g. Linux, Solaris) don't support them? > > Yes, they are interesting and important, since they are in use > at many sites. They're not portable as far as I know though. > > The system immutable flag is used by many FreeBSD installations to > further protect from accidental and unauthorized changes. > >> They seem a little dubious. >> I suppose most cvsup users have both client and server on FreeBSD >> and if the FreeBSD source itself needs these flags on source >> controled files, it is useful. >> >> Even storing an executable bit in cvs seems not portable..but that >> is a different set of flags. (NTFS ACL should be reasonable >> superset, but then, FAT?) > > POSIX file access control lists should be portable to a certain degree. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 13 13:07:20 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 13 Apr 2009 13:07:20 +0200 Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN In-Reply-To: References: <20090411105512.92784fp7cc0o448k@mail.elegosoft.com> <20090413125148.vxbxs7ftessckwko@mail.elegosoft.com> Message-ID: <20090413130720.aziv5e0fggwgccw0@mail.elegosoft.com> Quoting Jay : > >> I got syntax errors with >> some pattern substitution in a Makefile, and the build stopped. > > make vs. gmake? Maybe (log attached). But shouldn't configure be able to figure this out by itself? GNU make is /usr/bin/gnumake on this system (Fink packages). Olaf > - Jay > > > > ---------------------------------------- >> Date: Mon, 13 Apr 2009 12:51:48 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN >> >> Quoting Jay : >> >>> >>> My machine calls itself: >>> >>> jbook15:~ jay$ uname -a >>> Darwin jbook15.local 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 >>> 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh >>> powerpc >>> >>> That is 10.4.something. It works ok. cm3cg built as recently as 4/10.. >> >> So it seems OK for newer MacOS X releases. I worked around it here by >> continuning to use an older backend, which seems OK for now. >> Doing a realclean and a complete rebuild, I got syntax errors with >> some pattern substitution in a Makefile, and the build stopped. >> >> I'll try a newer backend compiled on another machine, too. >> >> Olaf >> >>> - Jay >>> >>> >>> ________________________________ >>>> From: jay >>>> To: wagner; m3devel >>>> Subject: RE: [M3devel] Internal compiler errors after upgrade on >>>> PPC_DARWIN >>>> Date: Sat, 11 Apr 2009 12:03:39 +0000> >>>> >>>> I do test on 10.4 fairly often... >>> >>>> It sounds like 7.9.0 is 10.3? >>>> >>>> >>>> - Jay >>>> >>>>> Date: Sat, 11 Apr 2009 10:55:12 +0200 >>>>> From: wagner@ >>>>> To: m3devel@ >>>>> Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN >>>>> >>>>> After trying to upgrade cm3 on my notebook to the latest version, >>>>> I get lots of internal compiler errors.This is on >>>>> >>>>> % uname -a >>>>> Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 >>>>> 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power >>>>> Macintosh powerpc >>>>> >>>>> ... >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 -------------- --- building in PPC_DARWIN --- ignoring ../src/m3overrides cd . && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: configure-host | tee -a _m3.log cd . && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: configure-host | tee -a _m3.log make all-recursive Making all in tests Making all in . make[4]: Nothing to be done for `all-am'. Making all in devel make[4]: Nothing to be done for `all'. Making all in mpn make[4]: Nothing to be done for `all'. Making all in mpz make[4]: Nothing to be done for `all'. Making all in mpq make[4]: Nothing to be done for `all'. Making all in mpf make[4]: Nothing to be done for `all'. Making all in rand make[4]: Nothing to be done for `all'. Making all in misc make[4]: Nothing to be done for `all'. Making all in cxx make[4]: Nothing to be done for `all'. Making all in mpbsd make[4]: Nothing to be done for `all'. Making all in mpn make[3]: Nothing to be done for `all'. Making all in mpz make[3]: Nothing to be done for `all'. Making all in mpq make[3]: Nothing to be done for `all'. Making all in mpf make[3]: Nothing to be done for `all'. Making all in printf make[3]: Nothing to be done for `all'. Making all in scanf make[3]: Nothing to be done for `all'. Making all in cxx make[3]: Nothing to be done for `all'. Making all in mpbsd make[3]: Nothing to be done for `all'. Making all in demos Making all in calc make all-am make[5]: Nothing to be done for `all-am'. Making all in expr make[4]: Nothing to be done for `all'. make[4]: Nothing to be done for `all-am'. Making all in tune make[3]: Nothing to be done for `all'. Making all in doc make[3]: Nothing to be done for `all'. make[3]: Nothing to be done for `all-am'. sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./gcc/Makefile > ./gcc/Makefile.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./gcc/Makefile > ./gcc/Makefile.1 ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./gcc/Makefile > ./gcc/Makefile.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./gcc/Makefile > ./gcc/Makefile.1 ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile sed -e 's/^#define HAVE_ICONV 1$//' < ./gcc/Makefile > ./gcc/Makefile.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./gcc/Makefile > ./gcc/Makefile.1 ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile sed -e 's/^#define HAVE_ICONV_H 1$//' < ./gcc/Makefile > ./gcc/Makefile.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./gcc/Makefile > ./gcc/Makefile.1 ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile ../gcc/move-if-change ./gcc/Makefile.1 ./gcc/Makefile sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h sed -e 's/^#define HAVE_ICONV 1$//' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h sed -e 's/^#define HAVE_ICONV_H 1$//' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./gcc/auto-host.h > ./gcc/auto-host.h.1 ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h ../gcc/move-if-change ./gcc/auto-host.h.1 ./gcc/auto-host.h sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./libcpp/Makefile > ./libcpp/Makefile.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./libcpp/Makefile > ./libcpp/Makefile.1 ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./libcpp/Makefile > ./libcpp/Makefile.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./libcpp/Makefile > ./libcpp/Makefile.1 ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile sed -e 's/^#define HAVE_ICONV 1$//' < ./libcpp/Makefile > ./libcpp/Makefile.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./libcpp/Makefile > ./libcpp/Makefile.1 ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile sed -e 's/^#define HAVE_ICONV_H 1$//' < ./libcpp/Makefile > ./libcpp/Makefile.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./libcpp/Makefile > ./libcpp/Makefile.1 ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile ../gcc/move-if-change ./libcpp/Makefile.1 ./libcpp/Makefile sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./libcpp/config.h > ./libcpp/config.h.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./libcpp/config.h > ./libcpp/config.h.1 ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./libcpp/config.h > ./libcpp/config.h.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./libcpp/config.h > ./libcpp/config.h.1 ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h sed -e 's/^#define HAVE_ICONV 1$//' < ./libcpp/config.h > ./libcpp/config.h.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./libcpp/config.h > ./libcpp/config.h.1 ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h sed -e 's/^#define HAVE_ICONV_H 1$//' < ./libcpp/config.h > ./libcpp/config.h.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./libcpp/config.h > ./libcpp/config.h.1 ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h ../gcc/move-if-change ./libcpp/config.h.1 ./libcpp/config.h sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./mpfr/Makefile > ./mpfr/Makefile.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./mpfr/Makefile > ./mpfr/Makefile.1 ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./mpfr/Makefile > ./mpfr/Makefile.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./mpfr/Makefile > ./mpfr/Makefile.1 ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile sed -e 's/^#define HAVE_ICONV 1$//' < ./mpfr/Makefile > ./mpfr/Makefile.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./mpfr/Makefile > ./mpfr/Makefile.1 ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile sed -e 's/^#define HAVE_ICONV_H 1$//' < ./mpfr/Makefile > ./mpfr/Makefile.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./mpfr/Makefile > ./mpfr/Makefile.1 ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile ../gcc/move-if-change ./mpfr/Makefile.1 ./mpfr/Makefile sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 sed -e 's/^LIBICONV =.+$/LIBICONV =/' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 sed -e 's/^LIBICONV_DEP =.+$/LIBICONV_DEP =/' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile sed -e 's/^#define HAVE_ICONV 1$//' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 sed -e 's/^#define HAVE_ICONV 1$//' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile sed -e 's/^#define HAVE_ICONV_H 1$//' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 sed -e 's/^#define HAVE_ICONV_H 1$//' < ./mpfr/tests/Makefile > ./mpfr/tests/Makefile.1 ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile ../gcc/move-if-change ./mpfr/tests/Makefile.1 ./mpfr/tests/Makefile cd . && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: all-gmp all-mpfr all-build-libiberty all-libiberty all-libdecnumber | tee -a _m3.log cd . && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: all-gmp all-mpfr all-build-libiberty all-libiberty all-libdecnumber | tee -a _m3.log make all-recursive Making all in tests Making all in . make[4]: Nothing to be done for `all-am'. Making all in devel make[4]: Nothing to be done for `all'. Making all in mpn make[4]: Nothing to be done for `all'. Making all in mpz make[4]: Nothing to be done for `all'. Making all in mpq make[4]: Nothing to be done for `all'. Making all in mpf make[4]: Nothing to be done for `all'. Making all in rand make[4]: Nothing to be done for `all'. Making all in misc make[4]: Nothing to be done for `all'. Making all in cxx make[4]: Nothing to be done for `all'. Making all in mpbsd make[4]: Nothing to be done for `all'. Making all in mpn make[3]: Nothing to be done for `all'. Making all in mpz make[3]: Nothing to be done for `all'. Making all in mpq make[3]: Nothing to be done for `all'. Making all in mpf make[3]: Nothing to be done for `all'. Making all in printf make[3]: Nothing to be done for `all'. Making all in scanf make[3]: Nothing to be done for `all'. Making all in cxx make[3]: Nothing to be done for `all'. Making all in mpbsd make[3]: Nothing to be done for `all'. Making all in demos Making all in calc make all-am make[5]: Nothing to be done for `all-am'. Making all in expr make[4]: Nothing to be done for `all'. make[4]: Nothing to be done for `all-am'. Making all in tune make[3]: Nothing to be done for `all'. Making all in doc make[3]: Nothing to be done for `all'. make[3]: Nothing to be done for `all-am'. Making all in tests make[2]: Nothing to be done for `all'. make[2]: Nothing to be done for `all-am'. make[2]: Nothing to be done for `all'. make[2]: Nothing to be done for `all'. make[1]: Nothing to be done for `all'. cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a _m3.log cd . && cd libcpp && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a _m3.log Makefile:191: *** Insufficient number of arguments (2) to function `patsubst'. Stop. cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a _m3.log cd . && cd gcc && make CC="gcc" CFLAGS="-O2 -g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a _m3.log Makefile:4437: *** Insufficient number of arguments (2) to function `patsubst'. Stop. "/Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile", line 463: quake runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2 --procedure-- -line- -file--- cp_if -- postcp 463 /Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile include_dir 529 /Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile 4 /Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args Fatal Error: package build failed From wagner at elegosoft.com Mon Apr 13 13:12:00 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 13 Apr 2009 13:12:00 +0200 Subject: [M3devel] cvsup and "flags" In-Reply-To: References: <20090413125640.58q2uf7spw0w844o@mail.elegosoft.com> Message-ID: <20090413131200.aai00p9vk44cgc00@mail.elegosoft.com> Well, yes, that's all correct, but CVSup is not only a CVS mirroring tool, as its name suggest, but also a general efficient file replication tool (which can be used to replicate whole systems). We should try to keep all of its functionality (improvements possible, of course). Olaf Quoting Jay : > > It's a little different to say "these flags are useful" vs. > "I should be able to store these flags in source control". > Not entirely different, but somewhat. > > > If you need them in source control, then you need your source control > system to bother with system-dependent possibly esoteric features. > On the other hand, if nobody every catered to good system-dependent > aspects, a lot of things would be a lot worse. > > > I only skimmed the cvsup source a little, but I think it traffics > in plain integers. It would be smarter to traffic in the "name" > of the flag, and the "OS name" it originated from..and maybe allow > some "required" vs. "optional" bit. That way, if Darwin and FreeBSD > both had the flag "FOO", it hopefully/probably means the same on each, > but could be "translated" into the proper integer. And if user deemed > flag "FOO" important than cvsup could error for updates to a system > that doesn't support it. Maybe it already does do these things though. > > > Some people use "source control" for keep track of and backup > their "system configuration" or perhaps their entire "system install". > Whereas most people just store a bunch of text files. > There can be quite a difference -- e.g. support for hardlinks, symlinks, > owner user, owner group, etc.. > > > Folks just storing textual source files tend to have lighter requirements. > (which reminds me -- can you clear the executable bit on the vast > majority of non-directories in the tree, like outside of > scripts/*.sh and scripts/*.py) > > > - Jay > > > ---------------------------------------- >> Date: Mon, 13 Apr 2009 12:56:40 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] cvsup and "flags" >> >> Quoting Jay : >> >>> >>> Um, these "flags" that cvsup is willing to traffic: >>> >>> 1) They are the same between machines that support them? >>> Maybe, maybe not, I can check. >>> >>> 2) They are actually interesting? Given that many operating >>> systems (e.g. Linux, Solaris) don't support them? >> >> Yes, they are interesting and important, since they are in use >> at many sites. They're not portable as far as I know though. >> >> The system immutable flag is used by many FreeBSD installations to >> further protect from accidental and unauthorized changes. >> >>> They seem a little dubious. >>> I suppose most cvsup users have both client and server on FreeBSD >>> and if the FreeBSD source itself needs these flags on source >>> controled files, it is useful. >>> >>> Even storing an executable bit in cvs seems not portable..but that >>> is a different set of flags. (NTFS ACL should be reasonable >>> superset, but then, FAT?) >> >> POSIX file access control lists should be portable to a certain degree. >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Mon Apr 13 13:34:13 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 13 Apr 2009 13:34:13 +0200 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> Message-ID: <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> Well, that's a quite long list; but many things are bug fixes anyway, and wouldn't be affected by a code freeze, while others are already finished (as integrating CVSup, as I understand). The only thing we should not do is introduce new platforms while trying to get the system stable. We should concentrate on installation support and bug fixing. I'd suggest to start the release process in about two weeks at the start of May. That should give everybody enough time to either finish their ongoing work that shall make it into the release or decide to postpone it ;-) Any objections? Olaf Quoting Jay : > > > > o When should we start? I.e. wha changes would you like to complete > > > before we start the release process? > > > > > I'd like to see the formsvbt crash debugged and fixed, unless I'm > the only one seeing it. > > I only see it on Solaris and PPC_DARWIN but haven't tried "everything". > > I'll try to get this. > > > > > > I'd also like to see: > > > > > > FreeBSD/x86 switched to the new Unix/*.i3 files. I'll do this. > > Maybe also I386_DARWIN, AMD64_DARWIN, but I don't have the hardware. > > > > > > $ORIGIN/LD_LIBRARY_PATH resolved a bit further, probably very > little work (I'll do this). > > Basically just 1) put buildlocal back how it was 2) push it across > more platforms e.g. I think FreeBSD/x86 is the main one missing, > but I'll get to it. > > > > > > cvsup building and in "std" (I'll do this, probably very little > left here really. > > > > > > -- beyond this, not required for release -- > > > > > > Maybe more AMD64 releases, e.g. NetBSD and Solaris. (If I get to it). > > (could be "mingw64" is good enough to try AMD64_NT now). > > > > > > Maybe update gmp/mpfr to fix the "maintainer" problem. (not likely by me) > > > > > > Maybe more new/resuscitated platforms..HPPA64_HPUX, IA64_*, *_VMS, > ALPHA_*, ARM_*, *_IRIX, *_AIX, MIPS64_*.... but these take back > seat to important fixes in existing platforms. > > > > > > Fix NT386 to use setjmp3 instead of setjmp so exceptions don't > skip C __finally blocks. I've just been very lazy here, should > demonstrate the behavior with a test case, then fix it.. > > > > > > Maybe fix cm3cg so other -g options besides -gstabs works, like > plain -g, -ggdb, on at least one platform -gstabs isn't supported, > leaving nothing, because others cause internal compiler errors, like > on HPPA64_HPUX. > > > > > > Oh, and NT386GNU probably switched back to Win32 threads. > Otherwise one of the test cases hangs and it doesn't look easy to > figure out. I'll do this shortly if I remember. > > But I also wouldn't mind if this platform isn't officially released > either (unless someone else wants to support it). > > > > > > Debug why many NT386MINGNU gui apps crash..but also probably just > don't release this platform and ok asis. > > > > > > - 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 hendrik at topoi.pooq.com Mon Apr 13 17:08:54 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 13 Apr 2009 11:08:54 -0400 Subject: [M3devel] FW: cvsup In-Reply-To: References: Message-ID: <20090413150854.GA32577@topoi.pooq.com> On Sun, Apr 12, 2009 at 11:34:49AM +0000, Jay wrote: > > [truncated again..] > > cvsup builds and starts up on a few platforms now, > including Cygwin/x86, Linux/x86, Linux/AMD64 (birch), > Macosx/PowerPC, FreeBSD/x86. I can verify more later.. > > > I expect there might be problems on Macosx/x86 and AMD64. > And FreeBSD/x86 might not work until I commit the change to use Unix/common. > That is -- these are the only platforms not using Unix/common. > > > Some platforms store extra "flags" with files -- Darwin and *BSD. > see man chflags and man 2 chflags. > Historically cvsup only get/sets those on FreeBSD. > I extended that to the others, though didn't build NetBSD/OpenBSD. > (nor have I tested any of the functionality at all..) > The source should be refactored some in this regard, the "FreeBSD" > directory split into "FreeBSD" and "flags" or something. But > I don't like moving files since history might not track well. > (I also chose "m3-tools" arbitrarily..) > > > It might not even have to be refactored -- instead of the static platform checks, the code can check of the #defines in Ustat are zero or not, and UstatC.c can provide empty chflags/fchflags functions instead of none at all. It's a tricky area though in terms of what is best, providing no functions, vs. providing functions that do nothing and succeed, vs. providing functions that do nothing and fail, vs. providing a more explicit way to query if the functionality is provided, as well as deciding between build-time vs. run-time checks (we don't have anything like autoconf in our system, for better and worse). > > > Now hopefully we can switch to svn or monotone and cvsup won't matter to us. :) > (Well, I never use it in any case. I know it is big in FreeBSD-land.) Yes, monotone... I'm trying to organise putting together the monotone repository, and it seems that the first thing to do is to get a local copy of the existing modula 3 CVS repository to experiment on. There are at least two ways to go about putting the monotone repository together, on of them seems to requre me to have a local copy of the repository. I suspect I need to get cvsup running to make this local copy of the CVS. Where should I get cvsup? (It doesn't seem to be distributed as a Debian package; perhaps that's because Modula 3 ins't either?) Did you make changes to cvsup to get it to work on current versions of Modula 3? If so I should probably get the changed version. Or else maybe someone could make a .tgz file out of the entire cm3 CVS and I could download and work with that? -- hendrik From hendrik at topoi.pooq.com Mon Apr 13 21:20:06 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 13 Apr 2009 15:20:06 -0400 Subject: [M3devel] FW: cvsup In-Reply-To: <20090413150854.GA32577@topoi.pooq.com> References: <20090413150854.GA32577@topoi.pooq.com> Message-ID: <20090413192006.GA660@topoi.pooq.com> On Mon, Apr 13, 2009 at 11:08:54AM -0400, hendrik at topoi.pooq.com wrote: > On Sun, Apr 12, 2009 at 11:34:49AM +0000, Jay wrote: > > > > Now hopefully we can switch to svn or monotone and cvsup won't matter to us. :) > > (Well, I never use it in any case. I know it is big in FreeBSD-land.) > > Yes, monotone... I'm trying to organise putting together the monotone > repository, and it seems that the first thing to do is to get a local > copy of the existing modula 3 CVS repository to experiment on. There > are at least two ways to go about putting the monotone repository > together, on of them seems to requre me to have a local copy of the > repository. > > I suspect I need to get cvsup running to make this local copy of the > CVS. Where should I get cvsup? (It doesn't seem to be distributed as a > Debian package; perhaps that's because Modula 3 ins't either?) Did you > make changes to cvsup to get it to work on current versions of Modula 3? > If so I should probably get the changed version. I should definitely get the changed version, to avoid wasting time. I just tried downloading and installing cvsup-snap-16.1h.tar.gz on an x86 Debian system. It seems to run into trouble because it duplicates code in cm3 itself: hendrik at lovesong:~/dv/cvsup/cvsup-snap-16.1h$ make make[1]: Entering directory `/farhome/hendrik/dv/cvsup/cvsup-snap-16.1h' --- building in LINUXLIBC6 --- ===> suptcp make[2]: Entering directory `/farhome/hendrik/dv/cvsup/cvsup-snap-16.1h/suptcp' cm3 --- building in LINUXLIBC6 --- Fatal Error: duplicate unit: /usr/local/cm3/pkg/tcp/src/POSIX/SockOpt.i3 ../src/POSIX/SockOpt.i3 -- hendrik > > Or else maybe someone could make a .tgz file out of the entire cm3 CVS > and I could download and work with that? > > -- hendrik From wagner at elegosoft.com Mon Apr 13 21:58:44 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 13 Apr 2009 21:58:44 +0200 Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN In-Reply-To: <20090413130720.aziv5e0fggwgccw0@mail.elegosoft.com> References: <20090411105512.92784fp7cc0o448k@mail.elegosoft.com> <20090413125148.vxbxs7ftessckwko@mail.elegosoft.com> <20090413130720.aziv5e0fggwgccw0@mail.elegosoft.com> Message-ID: <20090413215844.i3cr5vkecks48004@mail.elegosoft.com> FYI: installing the latest version of GNU make and autoconf manually fixed the problem. m3cc builds after realclean and works perfectly. Olaf Quoting Olaf Wagner : > Quoting Jay : > >> >>> I got syntax errors with >>> some pattern substitution in a Makefile, and the build stopped. >> >> make vs. gmake? > > Maybe (log attached). But shouldn't configure be able to figure this > out by itself? GNU make is /usr/bin/gnumake on this system (Fink > packages). > > Olaf > >> - Jay >> >> >> >> ---------------------------------------- >>> Date: Mon, 13 Apr 2009 12:51:48 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN >>> >>> Quoting Jay : >>> >>>> >>>> My machine calls itself: >>>> >>>> jbook15:~ jay$ uname -a >>>> Darwin jbook15.local 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 >>>> 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh >>>> powerpc >>>> >>>> That is 10.4.something. It works ok. cm3cg built as recently as 4/10.. >>> >>> So it seems OK for newer MacOS X releases. I worked around it here by >>> continuning to use an older backend, which seems OK for now. >>> Doing a realclean and a complete rebuild, I got syntax errors with >>> some pattern substitution in a Makefile, and the build stopped. >>> >>> I'll try a newer backend compiled on another machine, too. >>> >>> Olaf >>> >>>> - Jay >>>> >>>> >>>> ________________________________ >>>>> From: jay >>>>> To: wagner; m3devel >>>>> Subject: RE: [M3devel] Internal compiler errors after upgrade on >>>>> PPC_DARWIN >>>>> Date: Sat, 11 Apr 2009 12:03:39 +0000> >>>>> >>>>> I do test on 10.4 fairly often... >>>> >>>>> It sounds like 7.9.0 is 10.3? >>>>> >>>>> >>>>> - Jay >>>>> >>>>>> Date: Sat, 11 Apr 2009 10:55:12 +0200 >>>>>> From: wagner@ >>>>>> To: m3devel@ >>>>>> Subject: [M3devel] Internal compiler errors after upgrade on PPC_DARWIN >>>>>> >>>>>> After trying to upgrade cm3 on my notebook to the latest version, >>>>>> I get lots of internal compiler errors.This is on >>>>>> >>>>>> % uname -a >>>>>> Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 >>>>>> 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power >>>>>> Macintosh powerpc >>>>>> >>>>>> ... >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 rodney.m.bates at cox.net Mon Apr 13 23:24:06 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 13 Apr 2009 16:24:06 -0500 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> Message-ID: <49E3AD76.1080108@cox.net> Any opinions about the TEXT branch? Anybody tried it? To summarize: - I have tested it extensively on LINUXLIBC6, with a large random test program and two successive rebuilds of CM3. - It makes no changes in data structure, neither to static declarations nor to invariants. Thus it creates no compatibility problems with existing pickles, etc. - It slows down concatenation, but more than makes it up in other string accessing operations, if the numbers of concatenations and accessing operations are equal. - It cuts down on tree depth and even more or recursion depth (which implies needed stack space.) - This effect is dramatic when strings are built by "linear" concatenations, i.e., strictly left-to-right, or vice versa. Gains are moderate when concatenations are random. - It allocates a lot more storage, but abandons a lot more garbage, retaining somewhat more space when lots of old strings are retained along with newly-built ones. It probably retains less when operand strings of concatenations are not kept, but I haven't measured that. - Strategies are partial rebalancing of concatenation trees, flattening of short concatenations, elimination of a lot of tail-recursion, and recursing on the shorter side. Olaf Wagner wrote: > Well, that's a quite long list; but many things are bug fixes anyway, > and wouldn't be affected by a code freeze, while others are already > finished (as integrating CVSup, as I understand). > > The only thing we should not do is introduce new platforms while > trying to get the system stable. We should concentrate on installation > support and bug fixing. > > I'd suggest to start the release process in about two weeks at the > start of May. That should give everybody enough time to either finish > their ongoing work that shall make it into the release or decide to > postpone it ;-) > > Any objections? > > Olaf > > Quoting Jay : > >> >> > > o When should we start? I.e. wha changes would you like to complete >> > > before we start the release process? >> >> >> >> >> I'd like to see the formsvbt crash debugged and fixed, unless I'm >> the only one seeing it. >> >> I only see it on Solaris and PPC_DARWIN but haven't tried "everything". >> >> I'll try to get this. >> >> >> >> >> >> I'd also like to see: >> >> >> >> >> >> FreeBSD/x86 switched to the new Unix/*.i3 files. I'll do this. >> >> Maybe also I386_DARWIN, AMD64_DARWIN, but I don't have the hardware. >> >> >> >> >> >> $ORIGIN/LD_LIBRARY_PATH resolved a bit further, probably very >> little work (I'll do this). >> >> Basically just 1) put buildlocal back how it was 2) push it across >> more platforms e.g. I think FreeBSD/x86 is the main one missing, >> but I'll get to it. >> >> >> >> >> >> cvsup building and in "std" (I'll do this, probably very little >> left here really. >> >> >> >> >> >> -- beyond this, not required for release -- >> >> >> >> >> >> Maybe more AMD64 releases, e.g. NetBSD and Solaris. (If I get to it). >> >> (could be "mingw64" is good enough to try AMD64_NT now). >> >> >> >> >> >> Maybe update gmp/mpfr to fix the "maintainer" problem. (not likely >> by me) >> >> >> >> >> >> Maybe more new/resuscitated platforms..HPPA64_HPUX, IA64_*, *_VMS, >> ALPHA_*, ARM_*, *_IRIX, *_AIX, MIPS64_*.... but these take back >> seat to important fixes in existing platforms. >> >> >> >> >> >> Fix NT386 to use setjmp3 instead of setjmp so exceptions don't >> skip C __finally blocks. I've just been very lazy here, should >> demonstrate the behavior with a test case, then fix it.. >> >> >> >> >> >> Maybe fix cm3cg so other -g options besides -gstabs works, like >> plain -g, -ggdb, on at least one platform -gstabs isn't supported, >> leaving nothing, because others cause internal compiler errors, like >> on HPPA64_HPUX. >> >> >> >> >> >> Oh, and NT386GNU probably switched back to Win32 threads. >> Otherwise one of the test cases hangs and it doesn't look easy to >> figure out. I'll do this shortly if I remember. >> >> But I also wouldn't mind if this platform isn't officially released >> either (unless someone else wants to support it). >> >> >> >> >> >> Debug why many NT386MINGNU gui apps crash..but also probably just >> don't release this platform and ok asis. >> >> >> >> >> >> - Jay >> > > > From rcoleburn at scires.com Mon Apr 13 23:51:21 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 13 Apr 2009 17:51:21 -0400 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <49E3AD76.1080108@cox.net> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> Message-ID: <49E37ADC.1E75.00D7.1@scires.com> Rodney, sorry but I haven't tried your changes. If your test program is available, I would be glad to compile and run it on Windows to obtain results for that platform. Just let me know how to obtain/install your TEXT changes and the test program. I am ok with Olaf's suggestion of starting the release process in May. Again, I will be glad to help on Windows platforms. If necessary, I can also test cygwin on Windows. If we need to test/build/release on HPUX, I have an old v10 system I can pull out of storage (note that v10 is an older version of HPUX and not current). Regards, Randy Coleburn >>> "Rodney M. Bates" 4/13/2009 5:24 PM >>> Any opinions about the TEXT branch? Anybody tried it? To summarize: - I have tested it extensively on LINUXLIBC6, with a large random test program and two successive rebuilds of CM3. - It makes no changes in data structure, neither to static declarations nor to invariants. Thus it creates no compatibility problems with existing pickles, etc. - It slows down concatenation, but more than makes it up in other string accessing operations, if the numbers of concatenations and accessing operations are equal. - It cuts down on tree depth and even more or recursion depth (which implies needed stack space.) - This effect is dramatic when strings are built by "linear" concatenations, i.e., strictly left-to-right, or vice versa. Gains are moderate when concatenations are random. - It allocates a lot more storage, but abandons a lot more garbage, retaining somewhat more space when lots of old strings are retained along with newly-built ones. It probably retains less when operand strings of concatenations are not kept, but I haven't measured that. - Strategies are partial rebalancing of concatenation trees, flattening of short concatenations, elimination of a lot of tail-recursion, and recursing on the shorter side. Olaf Wagner wrote: > Well, that's a quite long list; but many things are bug fixes anyway, > and wouldn't be affected by a code freeze, while others are already > finished (as integrating CVSup, as I understand). > > The only thing we should not do is introduce new platforms while > trying to get the system stable. We should concentrate on installation > support and bug fixing. > > I'd suggest to start the release process in about two weeks at the > start of May. That should give everybody enough time to either finish > their ongoing work that shall make it into the release or decide to > postpone it ;-) > > Any objections? > > Olaf > > Quoting Jay : > >> >> > > o When should we start? I.e. wha changes would you like to complete >> > > before we start the release process? >> >> >> >> >> I'd like to see the formsvbt crash debugged and fixed, unless I'm >> the only one seeing it. >> >> I only see it on Solaris and PPC_DARWIN but haven't tried "everything". >> >> I'll try to get this. >> >> >> >> >> >> I'd also like to see: >> >> >> >> >> >> FreeBSD/x86 switched to the new Unix/*.i3 files. I'll do this. >> >> Maybe also I386_DARWIN, AMD64_DARWIN, but I don't have the hardware. >> >> >> >> >> >> $ORIGIN/LD_LIBRARY_PATH resolved a bit further, probably very >> little work (I'll do this). >> >> Basically just 1) put buildlocal back how it was 2) push it across >> more platforms e.g. I think FreeBSD/x86 is the main one missing, >> but I'll get to it. >> >> >> >> >> >> cvsup building and in "std" (I'll do this, probably very little >> left here really. >> >> >> >> >> >> -- beyond this, not required for release -- >> >> >> >> >> >> Maybe more AMD64 releases, e.g. NetBSD and Solaris. (If I get to it). >> >> (could be "mingw64" is good enough to try AMD64_NT now). >> >> >> >> >> >> Maybe update gmp/mpfr to fix the "maintainer" problem. (not likely >> by me) >> >> >> >> >> >> Maybe more new/resuscitated platforms..HPPA64_HPUX, IA64_*, *_VMS, >> ALPHA_*, ARM_*, *_IRIX, *_AIX, MIPS64_*.... but these take back >> seat to important fixes in existing platforms. >> >> >> >> >> >> Fix NT386 to use setjmp3 instead of setjmp so exceptions don't >> skip C __finally blocks. I've just been very lazy here, should >> demonstrate the behavior with a test case, then fix it.. >> >> >> >> >> >> Maybe fix cm3cg so other -g options besides -gstabs works, like >> plain -g, -ggdb, on at least one platform -gstabs isn't supported, >> leaving nothing, because others cause internal compiler errors, like >> on HPPA64_HPUX. >> >> >> >> >> >> Oh, and NT386GNU probably switched back to Win32 threads. >> Otherwise one of the test cases hangs and it doesn't look easy to >> figure out. I'll do this shortly if I remember. >> >> But I also wouldn't mind if this platform isn't officially released >> either (unless someone else wants to support it). >> >> >> >> >> >> Debug why many NT386MINGNU gui apps crash..but also probably just >> don't release this platform and ok asis. >> >> >> >> >> >> - 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 wagner at elegosoft.com Mon Apr 13 23:49:13 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 13 Apr 2009 23:49:13 +0200 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <49E3AD76.1080108@cox.net> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> Message-ID: <20090413234913.28trgcepwk488sc8@mail.elegosoft.com> Quoting "Rodney M. Bates" : > Any opinions about the TEXT branch? Anybody tried it? To summarize: > > - I have tested it extensively on LINUXLIBC6, with a large random > test program and two successive rebuilds of CM3. > > - It makes no changes in data structure, neither to static declarations > nor to invariants. Thus it creates no compatibility problems with existing > pickles, etc. > > - It slows down concatenation, but more than makes it up in other > string accessing operations, if the numbers of concatenations and > accessing operations are equal. > > - It cuts down on tree depth and even more or recursion depth > (which implies needed stack space.) > > - This effect is dramatic when strings are built by "linear" concatenations, > i.e., strictly left-to-right, or vice versa. Gains are moderate when > concatenations are random. > > - It allocates a lot more storage, but abandons a lot more garbage, > retaining somewhat more space when lots of old strings are retained > along with newly-built ones. It probably retains less when operand > strings of concatenations are not kept, but I haven't measured that. > > - Strategies are partial rebalancing of concatenation trees, flattening > of short concatenations, elimination of a lot of tail-recursion, and > recursing on the shorter side. I would tend to give it a try, i.e. include it in the release candiates, but I'd like to have some data about the impacts on real applications, let's say the cm3 compiler itself, the caltech parser generator, and cvsup. How do these perform for a small set of sample data? I won't have the time to do these tests though, so I'll trust the opinion of others regarding the inclusion in the next release. Olaf > Olaf Wagner wrote: >> Well, that's a quite long list; but many things are bug fixes anyway, >> and wouldn't be affected by a code freeze, while others are already >> finished (as integrating CVSup, as I understand). >> >> The only thing we should not do is introduce new platforms while >> trying to get the system stable. We should concentrate on installation >> support and bug fixing. >> >> I'd suggest to start the release process in about two weeks at the >> start of May. That should give everybody enough time to either finish >> their ongoing work that shall make it into the release or decide to >> postpone it ;-) >> >> Any objections? >> >> Olaf >> >> Quoting Jay : >> >>> >>> > > o When should we start? I.e. wha changes would you like to complete >>> > > before we start the release process? >>> >>> >>> >>> >>> I'd like to see the formsvbt crash debugged and fixed, unless I'm >>> the only one seeing it. >>> >>> I only see it on Solaris and PPC_DARWIN but haven't tried "everything". >>> >>> I'll try to get this. >>> >>> >>> >>> >>> >>> I'd also like to see: >>> >>> >>> >>> >>> >>> FreeBSD/x86 switched to the new Unix/*.i3 files. I'll do this. >>> >>> Maybe also I386_DARWIN, AMD64_DARWIN, but I don't have the hardware. >>> >>> >>> >>> >>> >>> $ORIGIN/LD_LIBRARY_PATH resolved a bit further, probably very >>> little work (I'll do this). >>> >>> Basically just 1) put buildlocal back how it was 2) push it >>> across more platforms e.g. I think FreeBSD/x86 is the main one >>> missing, but I'll get to it. >>> >>> >>> >>> >>> >>> cvsup building and in "std" (I'll do this, probably very little >>> left here really. >>> >>> >>> >>> >>> >>> -- beyond this, not required for release -- >>> >>> >>> >>> >>> >>> Maybe more AMD64 releases, e.g. NetBSD and Solaris. (If I get to it). >>> >>> (could be "mingw64" is good enough to try AMD64_NT now). >>> >>> >>> >>> >>> >>> Maybe update gmp/mpfr to fix the "maintainer" problem. (not likely by me) >>> >>> >>> >>> >>> >>> Maybe more new/resuscitated platforms..HPPA64_HPUX, IA64_*, >>> *_VMS, ALPHA_*, ARM_*, *_IRIX, *_AIX, MIPS64_*.... but these take >>> back seat to important fixes in existing platforms. >>> >>> >>> >>> >>> >>> Fix NT386 to use setjmp3 instead of setjmp so exceptions don't >>> skip C __finally blocks. I've just been very lazy here, should >>> demonstrate the behavior with a test case, then fix it.. >>> >>> >>> >>> >>> >>> Maybe fix cm3cg so other -g options besides -gstabs works, like >>> plain -g, -ggdb, on at least one platform -gstabs isn't supported, >>> leaving nothing, because others cause internal compiler errors, >>> like on HPPA64_HPUX. >>> >>> >>> >>> >>> >>> Oh, and NT386GNU probably switched back to Win32 threads. >>> Otherwise one of the test cases hangs and it doesn't look easy to >>> figure out. I'll do this shortly if I remember. >>> >>> But I also wouldn't mind if this platform isn't officially >>> released either (unless someone else wants to support it). >>> >>> >>> >>> >>> >>> Debug why many NT386MINGNU gui apps crash..but also probably just >>> don't release this platform and ok asis. >>> >>> >>> >>> >>> >>> - 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 Mon Apr 13 23:51:31 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 13 Apr 2009 16:51:31 -0500 Subject: [M3devel] small objects] Message-ID: <49E3B3E3.8090400@cox.net> Mika Nystrom wrote: > Ahhhh!!!!! Now I get it, Rodney! > > You're talking about using tagged types "within" Modula-3. > > I've just been asking for tagged types to do something "that's not > Modula-3". I'm completely aware that passing REFANY around is not > the "Modula-3 way", and had no intention of making it so. (That's > why I keep saying that only lazy people do it, so it doesn't matter.) > > My desire for storing integers and pointers in the same machine word > is not something I thought would ever be useful in Modula-3 itself. > But now what you say makes sense to me... you want to build your > ADTs with this. Then you do need the full M3 type system "above" > your tagged reference. > > I agree with you on MOST of the following: > > >> I really feel that the fad of all dynamic typing in languages is a huge >> mistake and that it will someday be recognized as such. In the >> meantime, we have a language that provides a very extensive set >> of statically-typed alternatives, while also allowing dynamic typing >> when you really need it. This is one of Modula-3's best principles. >> Let's don't erode the static alternatives unnecessarily. >> > > I program, currently, mostly in Scheme and in Modula-3, (mostly M3) > and I am constantly amazed by: > > 1. The way that Modula-3 programs often are correct the first time > they are compiled, even if they haven't been carefully designed. > Using the M3 type system can really make your code obviously correct. > > 2. The way that Scheme programs can sometimes abstract away all sorts > of type irrelevancies. In M3 you'd have to have many versions of the > same code, or at least many generic instances. This is especially > true for "higher-higher order" types, where one type is made from > another and that was made from another, etc. (Interpret "type" > liberally, please. It's probably just some sort of lambda expression.) > > Now I agree that untyped languages are probably a fad, and they have > set computing back by years or decades(?). Too easy to make mistakes. > But there is something of value there, and my feeling is that the best > way to take advantage of it is to *combine* the two worlds, rather than > trying to come up with some sort of "super language" that incorporates > the best of both worlds and somehow manages to step on no one's toes. > I'm presenting this as an alternative to type inferencing schemes in > environments such as ML. > > So my idea, my "vision" if you like, is that we embed untyped > languages in Modula-3. The parts of the system that need performance > or are more convenient to program in the "bondage and discipline" > world of Algol get written in Modula-3, and the parts of the system > that it is more convenient (all things considered) to program in a > typeless environment can be programmed in Scheme (currently, other > interpreted languages can be added later if this turns out to be a > good idea). But it is clear that the typeless approach of REFANY > (REALLYREFANY, including the tagged types) is necessary to implement > this layer of the system---if you want to be able to pass data > structures seamlessly between the two layers. > > Maybe that explains better where I'm coming from. I have no intention > of using these types for Modula-3 programming :-) > > However, I do see your point. A facility provided is a facility > used, so if there's a very compact way of storing data in pointers, > other applications than the ones I have in mind will use them, too, > and perhaps lead to an abuse of Modula-3. But I'm not sure if this > isn't over the line of legislating programming *style*---if we go > down that route, we can do it the Java way and ban UNSAFE as well, > so people won't be tempted to program C in Modula-3. In any case, > the particular feature that one can hide 31 bits of information in > a REFANY (and only a REFANY) can't hurt you if you don't choose to > avail yourself of it---in fact it's transparent to people who don't > care about it. Ok, an added 2 instructions out of 1,000 on an > ISTYPE or TYPECASE of r : REFANY, but come on, that's not really > an argument! > > So I am supportive of making a new type hierarchy TAGGED T for any > No, not a tagged hierarchy. That was an earlier idea I toyed with that I considered a tar pit. The reference types remain in the existing hierarchy, but the tagged types have no subtype relation to each other. > T. And yes I understand that now---once you have TAGGED T---it is > trivial to add a TAGGED REFANY, which you can distinguish from > REFANY. I think your arguments for the TAGGED hierarchy are very > good. > > However, I still don't think you have made a good argument *against* > being able to hide 31 bits of information in a REFANY. You don't > have to use the facility if it doesn't meet your requirements! > > Please remember that what I've been proposing is not a language > change at all but a request that the runtime system and compiler > respect a couple of not-difficult-to-ensure properties, so that we > may do some new tricks in UNSAFE code. Nothing more than that. > > Mika > > P.S. You didn't actually give any examples of code where you > would, after *your* proposed change, still use REFANY instead of > switching the code to TAGGED REFANY. I brought up container data structures as one important group, but they are not the universe of uses of REFANY. As an example, I have a good sized module that builds a tree--not a general tree determined by input, but exactly one, hard-coded specific tree. It's needed to boostrap the general tree-building code. The tree is rather large, and hard coding all the node constructor calls was very tedious and boring. I wrote some node constructor procedures with the intent of minimizing the keystrokes in the calls on them. One way I did this was to make the child parameters have type REFANY, with meaningful values being either TEXT or previously-built tree nodes of a few possible different types. The constructors then TYPECASE on them. REFANY is the narrowest possible type that can take this set of options. This has nothing to do with any abstract data type and is not intended for any general-purpose use by various other code. In fact, it has a very specific and limited purpose. > You said that: > > >> And TAGGED REFANY generalizes it from REFANY. >> > > i.e., container code would switch to TAGGED REFANY > > >> The other use is for the abstract type itself. Forgetting tagged >> types for a moment, I have never seen an interface/module that >> uses REFANY for this. Instead, the modules declare their abstract >> type as some proper subtype of REFANY, usually an opaque type. >> > > i.e., other code doesn't actually use REFANY! > > (For what it's worth, your experience here matches mine. Container > types (may) use REFANY and ADTs (almost) never do.) > > So back to my question: where would you use REFANY???? If never, > then why bother having the two roots? > > What you're saying is that after *my* proposed runtime change, *you* > will be tempted to abuse REFANY for ADTs. I don't think this is a > very good argument against my proposal (but it is a good argument > for yours, which is not incompatible with mine but instead expands it). > The only thing that makes your proposal slightly incompatible with > mine is that you're insisting on having a new distinction between > REFANY and TAGGED REFANY, which I am saying will never be used in > practice. And both your experience with Modula-3 and mine seem to > back up this assertion. > > > "Rodney M. Bates" writes: > >> Mika Nystrom wrote: >> >>> Sorry to splice together two emails from you, but I feel I've already >>> used up my m3devel quota this week: >>> >>> "Rodney M. Bates" writes: >>> >>> >>>>> Are you sure? I want a type---some type---that can hold "any >>>>> reference, even a tagged one", and I would rewrite most library >>>>> code that today takes REFANY to take that instead. Why not? Why >>>>> would I want to limit it to REFANY when it performs no operations >>>>> that couldn't legally be performed on TAGGED REFANY. >>>>> >>>>> >>>>> >>>> I believe my "safe" proposal would make this very simple, if I am >>>> thinking of the kind of library code you are. >>>> >>>> I envision a container data structure that takes in things and returns >>>> them without performing operations on them other than moving them around >>>> and storing them, e.g. the ever belabored stack. The values going in >>>> and out are declared REFANY, and the client passes in values of >>>> some proper subtype of REFANY, which get assigned to the REFANY >>>> parameters. When it gets them back, it narrows them to this type. >>>> >>>> In this pattern, just changing the declared type of the container values >>>> >>>> >>> >from REFANY to TAGGED REFANY would do it. The library code's storage >>> ... >>> >>> >> There are two very different kinds of uses of reference and >> tagged types. The one I speak of above is for the type of the >> elements inside a container data structure. In this case, it >> is the client that knows what type the value really is, and will >> declare it as such. The library ADT module should know as little >> as possible about it, so it will declare it as REFANY or >> TAGGED REFANY. Here, you want the most general type >> possible, just to make the abstraction more versatile. >> And TAGGED REFANY generalizes it from REFANY. >> >> But... >> >>> >>> >> >>>>> you'd like to store these in a REFANY and dynamically test for the >>>>> appropriate tagged type: >>>>> >>>>> >>>> No, I do not want to store these in a variable of type REFANY or any >>>> other existing type. >>>> In fact, I want to forbid it. >>>> >>>> >>> I think you are thinking of exactly the same kind of library code. >>> TextRefTbl.T, RefList.T, etc. >>> >>> After the introduction of TAGGED REFANY, what use is there for >>> REFANY? What piece of code can you think of where the cost of the >>> 1-LSB check of TAGGED REFANY outweighs the convenience of being >>> able to process objects of type TAGGED T (for all ref types T) as >>> well as objects of type T? >>> >>> >> The other use is for the abstract type itself. Forgetting tagged >> types for a moment, I have never seen an interface/module that >> uses REFANY for this. Instead, the modules declare their abstract >> type as some proper subtype of REFANY, usually an opaque type. >> >> It would be possible to use just REFANY here of course, but that would >> require an otherwise unnecessary RT check on the allocated type, >> every time an operation of the module is called. This is a much >> more expensive check than a tag check, as has been pointed out >> in this discussion. >> >> But worse, it would sacrifice the static checking that we now have >> that prevents, at compile time, clients from passing, say a Text.T >> to some procedure in Atom that expects an Atom.T. If these modules >> ever wanted to use a tagged type, but the only tagged type were >> REFANY, we would lose this static checking, because Text.T would >> have to become equal to Atom.T. >> >> In cases where your algorithms don't specifically need dynamic >> typing, static typing is always much better, because one run of >> the compiler on the source code will do it. Bugs checked >> only at runtime require a massive test suit to be coded and then >> regularly rerun to get even close to the same confidence they've >> been found. >> >> So when using tagged types as the ADT itself,, we need to be able >> to have a tagged version of whatever proper subtype of REFANY >> the abstraction needs, including an opaque subtype of REFANY >> or an opaque subtype of some Public subtype of REFANY. This is >> why I am adamant that we need to be able to build a tagged type >> > >from any traced or object type. > >> And once you do this, keeping REFANY itself unchanged and allowing >> TAGGED REFANY as one case of a tagged type falls out of the system >> for free _and_ saves a lot of cases that would otherwise need a new RT >> check that can never fail, but the language can't know that, because >> the type system has lost the distinction. >> >> I really feel that the fad of all dynamic typing in languages is a huge >> mistake and that it will someday be recognized as such. In the >> meantime, we have a language that provides a very extensive set >> of statically-typed alternatives, while also allowing dynamic typing >> when you really need it. This is one of Modula-3's best principles. >> Let's don't erode the static alternatives unnecessarily. >> >> >>> Mika >>> >>> >>> > > From jay.krell at cornell.edu Tue Apr 14 02:37:42 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 14 Apr 2009 00:37:42 +0000 Subject: [M3devel] FW: cvsup In-Reply-To: <20090413192006.GA660@topoi.pooq.com> References: <20090413150854.GA32577@topoi.pooq.com> <20090413192006.GA660@topoi.pooq.com> Message-ID: I think you can ssh into birch and tar cfz /usr/cvs/cm3 or such. If you want/need cvsup, yes please try current cm3 source. It at least builds and the changes weren't really significant. Yes they had their own copy of TCP. Olaf's does too, but his used "override" to avoid the duplicate. I just don't use the duplicate. It looks like the mainline and cvsup were mostly in sync, though mainline has 64bit big endian bug fixes ("one is int not INTEGER"). I should double check that though. I think there is a bit of a language problem in Modula3. I can have: INTERFACE A; PROCEDURE F; INTERFACE B; PROCEDURE F; and IMPORT both A and B from a third module, since I can refer to A.F and B.F, but I cannot IMPORT A from B's implementation or vice versa. The implementation of F is ambiguous. A possible solution is to let the implementation put the interface name ahead of the function. MODULE B IMPORTS A; PROCEDURE B.F() = BEGIN END B.F; and all uses of F within B must say B.F or A.F. - Jay ---------------------------------------- > Date: Mon, 13 Apr 2009 15:20:06 -0400 > From: hendrik > To: m3devel > Subject: Re: [M3devel] FW: cvsup > From rodney.m.bates at cox.net Tue Apr 14 04:33:48 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 13 Apr 2009 21:33:48 -0500 Subject: [M3devel] FW: cvsup In-Reply-To: References: <20090413150854.GA32577@topoi.pooq.com> <20090413192006.GA660@topoi.pooq.com> Message-ID: <49E3F60C.3070808@cox.net> Jay wrote: > I think you can ssh into birch and tar cfz /usr/cvs/cm3 or such. > > > If you want/need cvsup, yes please try current cm3 source. > It at least builds and the changes weren't really significant. > Yes they had their own copy of TCP. > Olaf's does too, but his used "override" to avoid the duplicate. > I just don't use the duplicate. > It looks like the mainline and cvsup were mostly in sync, > though mainline has 64bit big endian bug fixes ("one is int not INTEGER"). > I should double check that though. > > > I think there is a bit of a language problem in Modula3. > I can have: > > > INTERFACE A; > PROCEDURE F; > > > INTERFACE B; > PROCEDURE F; > > > and IMPORT both A and B from a third module, since I can refer to A.F and B.F, > > but I cannot IMPORT A from B's implementation or vice versa. > The implementation of F is ambiguous. > Sure you can. > > > A possible solution is to let the implementation put the > interface name ahead of the function. > > MODULE B IMPORTS A; > In module B, you can refer to A.F. If you want the F in B, its name is just unqualified F. MODULE B is short for MODULE B EXPORTS B (see 2.5.3, 1st paragraph), and one consequence of exporting B is that everything declared in interface B is available without qualification in the module that does the export . See 2.5.3, 2nd paragraph. What you can't do is have the same module export both A and B. That would make F an illegal redeclaration. See 2.5.3, 4th paragraph. > > PROCEDURE B.F() = BEGIN END B.F; > > > and all uses of F within B must say B.F or A.F. > > > - Jay > > > ---------------------------------------- > >> Date: Mon, 13 Apr 2009 15:20:06 -0400 >> From: hendrik >> To: m3devel >> Subject: Re: [M3devel] FW: cvsup >> >> From hosking at cs.purdue.edu Tue Apr 14 05:43:45 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 14 Apr 2009 13:43:45 +1000 Subject: [M3devel] FW: cvsup In-Reply-To: References: <20090413150854.GA32577@topoi.pooq.com> <20090413192006.GA660@topoi.pooq.com> Message-ID: <7F0E7523-EC64-44C5-932B-48EA3F3B05A6@cs.purdue.edu> ssh + rsync! On 14 Apr 2009, at 10:37, Jay wrote: > > I think you can ssh into birch and tar cfz /usr/cvs/cm3 or such. > > > If you want/need cvsup, yes please try current cm3 source. > It at least builds and the changes weren't really significant. > Yes they had their own copy of TCP. > Olaf's does too, but his used "override" to avoid the duplicate. > I just don't use the duplicate. > It looks like the mainline and cvsup were mostly in sync, > though mainline has 64bit big endian bug fixes ("one is int not > INTEGER"). > I should double check that though. > > > I think there is a bit of a language problem in Modula3. > I can have: > > > INTERFACE A; > PROCEDURE F; > > > INTERFACE B; > PROCEDURE F; > > > and IMPORT both A and B from a third module, since I can refer to > A.F and B.F, > > but I cannot IMPORT A from B's implementation or vice versa. > The implementation of F is ambiguous. > > > A possible solution is to let the implementation put the > interface name ahead of the function. > > MODULE B IMPORTS A; > > PROCEDURE B.F() = BEGIN END B.F; > > > and all uses of F within B must say B.F or A.F. > > > - Jay > > > ---------------------------------------- >> Date: Mon, 13 Apr 2009 15:20:06 -0400 >> From: hendrik >> To: m3devel >> Subject: Re: [M3devel] FW: cvsup >> From wagner at elegosoft.com Tue Apr 14 12:02:17 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 14 Apr 2009 12:02:17 +0200 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <49E37ADC.1E75.00D7.1@scires.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> <49E37ADC.1E75.00D7.1@scires.com> Message-ID: <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> If anybody could test Rodney's TEXT changes and provide some information on the impacts on our applications, that would help a lot. I also wasn't able to read and understand all the mails about small objects. (Guessing, I'd say I'd need another day for that :-) Can anybody summarize? Has a conclusion been reached and what will be done/implemented? Is this relevant for the next release, or will it take longer? Olaf Quoting Randy Coleburn : > Rodney, sorry but I haven't tried your changes. If your test > program is available, I would be glad to compile and run it on > Windows to obtain results for that platform. Just let me know how > to obtain/install your TEXT changes and the test program. > > I am ok with Olaf's suggestion of starting the release process in May. > > Again, I will be glad to help on Windows platforms. If necessary, I > can also test cygwin on Windows. > > If we need to test/build/release on HPUX, I have an old v10 system I > can pull out of storage (note that v10 is an older version of HPUX > and not current). > > Regards, > Randy Coleburn > >>>> "Rodney M. Bates" 4/13/2009 5:24 PM >>> > Any opinions about the TEXT branch? Anybody tried it? To summarize: > > - I have tested it extensively on LINUXLIBC6, with a large random > test program and two successive rebuilds of CM3. > > - It makes no changes in data structure, neither to static declarations > nor to invariants. Thus it creates no compatibility problems with > existing > pickles, etc. > > - It slows down concatenation, but more than makes it up in other > string accessing operations, if the numbers of concatenations and > accessing operations are equal. > > - It cuts down on tree depth and even more or recursion depth > (which implies needed stack space.) > > - This effect is dramatic when strings are built by "linear" concatenations, > i.e., strictly left-to-right, or vice versa. Gains are moderate when > concatenations are random. > > - It allocates a lot more storage, but abandons a lot more garbage, > retaining somewhat more space when lots of old strings are retained > along with newly-built ones. It probably retains less when operand > strings of concatenations are not kept, but I haven't measured that. > > - Strategies are partial rebalancing of concatenation trees, flattening > of short concatenations, elimination of a lot of tail-recursion, and > recursing on the shorter side. > > > > Olaf Wagner wrote: >> Well, that's a quite long list; but many things are bug fixes anyway, >> and wouldn't be affected by a code freeze, while others are already >> finished (as integrating CVSup, as I understand). >> >> The only thing we should not do is introduce new platforms while >> trying to get the system stable. We should concentrate on installation >> support and bug fixing. >> >> I'd suggest to start the release process in about two weeks at the >> start of May. That should give everybody enough time to either finish >> their ongoing work that shall make it into the release or decide to >> postpone it ;-) >> >> Any objections? >> >> Olaf >> >> Quoting Jay : >> >>> >>> > > o When should we start? I.e. wha changes would you like to complete >>> > > before we start the release process? >>> >>> >>> >>> >>> I'd like to see the formsvbt crash debugged and fixed, unless I'm >>> the only one seeing it. >>> >>> I only see it on Solaris and PPC_DARWIN but haven't tried "everything". >>> >>> I'll try to get this. >>> >>> >>> >>> >>> >>> I'd also like to see: >>> >>> >>> >>> >>> >>> FreeBSD/x86 switched to the new Unix/*.i3 files. I'll do this. >>> >>> Maybe also I386_DARWIN, AMD64_DARWIN, but I don't have the hardware. >>> >>> >>> >>> >>> >>> $ORIGIN/LD_LIBRARY_PATH resolved a bit further, probably very >>> little work (I'll do this). >>> >>> Basically just 1) put buildlocal back how it was 2) push it across >>> more platforms e.g. I think FreeBSD/x86 is the main one missing, >>> but I'll get to it. >>> >>> >>> >>> >>> >>> cvsup building and in "std" (I'll do this, probably very little >>> left here really. >>> >>> >>> >>> >>> >>> -- beyond this, not required for release -- >>> >>> >>> >>> >>> >>> Maybe more AMD64 releases, e.g. NetBSD and Solaris. (If I get to it). >>> >>> (could be "mingw64" is good enough to try AMD64_NT now). >>> >>> >>> >>> >>> >>> Maybe update gmp/mpfr to fix the "maintainer" problem. (not likely >>> by me) >>> >>> >>> >>> >>> >>> Maybe more new/resuscitated platforms..HPPA64_HPUX, IA64_*, *_VMS, >>> ALPHA_*, ARM_*, *_IRIX, *_AIX, MIPS64_*.... but these take back >>> seat to important fixes in existing platforms. >>> >>> >>> >>> >>> >>> Fix NT386 to use setjmp3 instead of setjmp so exceptions don't >>> skip C __finally blocks. I've just been very lazy here, should >>> demonstrate the behavior with a test case, then fix it.. >>> >>> >>> >>> >>> >>> Maybe fix cm3cg so other -g options besides -gstabs works, like >>> plain -g, -ggdb, on at least one platform -gstabs isn't supported, >>> leaving nothing, because others cause internal compiler errors, like >>> on HPPA64_HPUX. >>> >>> >>> >>> >>> >>> Oh, and NT386GNU probably switched back to Win32 threads. >>> Otherwise one of the test cases hangs and it doesn't look easy to >>> figure out. I'll do this shortly if I remember. >>> >>> But I also wouldn't mind if this platform isn't officially released >>> either (unless someone else wants to support it). >>> >>> >>> >>> >>> >>> Debug why many NT386MINGNU gui apps crash..but also probably just >>> don't release this platform and ok asis. >>> >>> >>> >>> >>> >>> - 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. > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Tue Apr 14 15:04:33 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 14 Apr 2009 09:04:33 -0400 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> <49E37ADC.1E75.00D7.1@scires.com> <20090414120217.io1ufanh340k0wo8@mail.elegosoft.com> Message-ID: <20090414130433.GA2968@topoi.pooq.com> On Tue, Apr 14, 2009 at 12:02:17PM +0200, Olaf Wagner wrote: > If anybody could test Rodney's TEXT changes and provide some > information on the impacts on our applications, that would help a lot. > > I also wasn't able to read and understand all the mails about small objects. > (Guessing, I'd say I'd need another day for that :-) > Can anybody summarize? > Has a conclusion been reached and what will be done/implemented? > Is this relevant for the next release, or will it take longer? Deciding that the garbage collector should test for the low-order bit of pointers and leave them alone if the bit is set could probably dop done immediately, and would make it possible for users to build unsafe code to do the small-objects stuff. This could go in the next release if the garbage-collector change wom't upset anything. There's still some discussion about just what form the final language feature should take. I don't know if that will be finished in time for the release. -- hendrik From rodney.m.bates at cox.net Tue Apr 14 14:21:07 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Tue, 14 Apr 2009 07:21:07 -0500 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <49E37ADC.1E75.00D7.1@scires.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> <20090411114441.GA22262@topoi.pooq.com> <20090413133413.npelc6h3wwgoc4o4@mail.elegosoft.com> <49E3AD76.1080108@cox.net> <49E37ADC.1E75.00D7.1@scires.com> Message-ID: <49E47FB3.2070102@cox.net> Randy Coleburn wrote: > Rodney, sorry but I haven't tried your changes. If your test program > is available, I would be glad to compile and run it on Windows to > obtain results for that platform. Just let me know how to > obtain/install your TEXT changes and the test program. It's in a branch named: devel_m3core_text_newtext_branch It's all part of m3core, which you have to rebuild and ship. The test program source code is in m3-libs/m3core/tests/newtext/src of the branch, along with a README file. > > I am ok with Olaf's suggestion of starting the release process in May. > > Again, I will be glad to help on Windows platforms. If necessary, I > can also test cygwin on Windows. > > If we need to test/build/release on HPUX, I have an old v10 system I > can pull out of storage (note that v10 is an older version of HPUX and > not current). > > Regards, > Randy Coleburn > > >>> "Rodney M. Bates" 4/13/2009 5:24 PM >>> > Any opinions about the TEXT branch? Anybody tried it? To summarize: > > - I have tested it extensively on LINUXLIBC6, with a large random > test program and two successive rebuilds of CM3. > > - It makes no changes in data structure, neither to static declarations > nor to invariants. Thus it creates no compatibility problems with > existing > pickles, etc. > > - It slows down concatenation, but more than makes it up in other > string accessing operations, if the numbers of concatenations and > accessing operations are equal. > > - It cuts down on tree depth and even more or recursion depth > (which implies needed stack space.) > > - This effect is dramatic when strings are built by "linear" > concatenations, > i.e., strictly left-to-right, or vice versa. Gains are moderate when > concatenations are random. > > - It allocates a lot more storage, but abandons a lot more garbage, > retaining somewhat more space when lots of old strings are retained > along with newly-built ones. It probably retains less when operand > strings of concatenations are not kept, but I haven't measured that. > > - Strategies are partial rebalancing of concatenation trees, flattening > of short concatenations, elimination of a lot of tail-recursion, and > recursing on the shorter side. > > > > Olaf Wagner wrote: > > Well, that's a quite long list; but many things are bug fixes anyway, > > and wouldn't be affected by a code freeze, while others are already > > finished (as integrating CVSup, as I understand). > > > > The only thing we should not do is introduce new platforms while > > trying to get the system stable. We should concentrate on installation > > support and bug fixing. > > > > I'd suggest to start the release process in about two weeks at the > > start of May. That should give everybody enough time to either finish > > their ongoing work that shall make it into the release or decide to > > postpone it ;-) > > > > Any objections? > > > > Olaf > > > > Quoting Jay : > > > >> > >> > > o When should we start? I.e. wha changes would you like to > complete > >> > > before we start the release process? > >> > >> > >> > >> > >> I'd like to see the formsvbt crash debugged and fixed, unless I'm > >> the only one seeing it. > >> > >> I only see it on Solaris and PPC_DARWIN but haven't tried > "everything". > >> > >> I'll try to get this. > >> > >> > >> > >> > >> > >> I'd also like to see: > >> > >> > >> > >> > >> > >> FreeBSD/x86 switched to the new Unix/*.i3 files. I'll do this. > >> > >> Maybe also I386_DARWIN, AMD64_DARWIN, but I don't have the > hardware. > >> > >> > >> > >> > >> > >> $ORIGIN/LD_LIBRARY_PATH resolved a bit further, probably very > >> little work (I'll do this). > >> > >> Basically just 1) put buildlocal back how it was 2) push it across > >> more platforms e.g. I think FreeBSD/x86 is the main one missing, > >> but I'll get to it. > >> > >> > >> > >> > >> > >> cvsup building and in "std" (I'll do this, probably very little > >> left here really. > >> > >> > >> > >> > >> > >> -- beyond this, not required for release -- > >> > >> > >> > >> > >> > >> Maybe more AMD64 releases, e.g. NetBSD and Solaris. (If I get to it). > >> > >> (could be "mingw64" is good enough to try AMD64_NT now). > >> > >> > >> > >> > >> > >> Maybe update gmp/mpfr to fix the "maintainer" problem. (not likely > >> by me) > >> > >> > >> > >> > >> > >> Maybe more new/resuscitated platforms..HPPA64_HPUX, IA64_*, *_VMS, > >> ALPHA_*, ARM_*, *_IRIX, *_AIX, MIPS64_*.... but these take back > >> seat to important fixes in existing platforms. > >> > >> > >> > >> > >> > >> Fix NT386 to use setjmp3 instead of setjmp so exceptions don't > >> skip C __finally blocks. I've just been very lazy here, should > >> demonstrate the behavior with a test case, then fix it.. > >> > >> > >> > >> > >> > >> Maybe fix cm3cg so other -g options besides -gstabs works, like > >> plain -g, -ggdb, on at least one platform -gstabs isn't supported, > >> leaving nothing, because others cause internal compiler errors, like > >> on HPPA64_HPUX. > >> > >> > >> > >> > >> > >> Oh, and NT386GNU probably switched back to Win32 threads. > >> Otherwise one of the test cases hangs and it doesn't look easy to > >> figure out. I'll do this shortly if I remember. > >> > >> But I also wouldn't mind if this platform isn't officially released > >> either (unless someone else wants to support it). > >> > >> > >> > >> > >> > >> Debug why many NT386MINGNU gui apps crash..but also probably just > >> don't release this platform and ok asis. > >> > >> > >> > >> > >> > >> - Jay > >> > > > > > > > > From jay.krell at cornell.edu Tue Apr 14 17:29:11 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 14 Apr 2009 15:29:11 +0000 Subject: [M3devel] $ORIGIN/../lib vs. $ORIGIN/../../../lib? Message-ID: $ORIGIN/../lib vs. $ORIGIN/../../../lib? It doesn't appear simple to know which of these runpaths to use. It depends on if the file is exported to bin or just "regular". It would be nice to just use one of these and not concatenate them. Usually "libraries" are in pkg and "executables" are not. But cm3 is an exception, can be ignored in general anything "standalone" can be ignored vorun is an exception. cmpfp is an exception. Also standalone. Is that it? Ignore cm3, change the others to go to bin, and use that rule then? cvsup and cvsupd where also exceptions but I went ahead and changed them. m3back is an exception, but isn't really ever used. uniq is an exception. But it is build static. There, is you know, the notion of an executable that is only meant to be run by code, not humans directly (e.g. cm3cg, cc1, etc.). These can be located outside of $PATH. I guess I can do this with "non local" information or parameter passing? I assume it is too painful right now to add a parameter to the quake link function. or maybe not -- go ahead and add a parameter to m3_link and make_lib, giving the installed path of the file? proc make_lib(lib, options, objects, imported_libs, shared, installed_path) is proc m3_link(prog, options, objects, imported_libs, shared, installed_path) is ? This would affect all configuration files. Several alternatives..that might be too large: Stop shippping any shared libraries or executables to pkg, just bin and lib? Or, reverse the sense of the file vs. symlink? Or make them hardlinks -- not great, since runpath would be wrong for one of them. Relink-upon-install still seems reasonable -- it knows the destination path. Is "../../../lib" moving too far around? How about the notion of confirming the layout, using: $ORIGIN/../pkg/m3core/target/../../.. $ORIGIN/../../../pkg/m3core/target/../../.. Does that feel safer? And not too inefficient? This way generally the ../../../ doesn't hold, unless "pkg/m3core/target" exists. - Jay From mika at async.caltech.edu Tue Apr 14 18:56:34 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 14 Apr 2009 09:56:34 -0700 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: Your message of "Tue, 14 Apr 2009 09:04:33 EDT." <20090414130433.GA2968@topoi.pooq.com> Message-ID: <200904141656.n3EGuYuZ061174@camembert.async.caltech.edu> I agree with what Hendrik says, but what about TYPECASE, ISTYPE, NARROW? Those are necessary to make it possible to pass "pointers" with the low-order bit set outside of unsafe code. My feeling is that if Tony can make the necessary changes, it could be done immediately, and the language issues can be pushed to the future. But admittedly I'm biased because of the application I'm working on. I need to get a recent CM3 up to test the TEXTs.... are they the default now? Mika hendrik at topoi.pooq.com writes: >On Tue, Apr 14, 2009 at 12:02:17PM +0200, Olaf Wagner wrote: >> If anybody could test Rodney's TEXT changes and provide some >> information on the impacts on our applications, that would help a lot. >> >> I also wasn't able to read and understand all the mails about small objects. >> (Guessing, I'd say I'd need another day for that :-) >> Can anybody summarize? >> Has a conclusion been reached and what will be done/implemented? >> Is this relevant for the next release, or will it take longer? > >Deciding that the garbage collector should test for the low-order bit of >pointers and leave them alone if the bit is set could probably dop done >immediately, and would make it possible for users to build unsafe code >to do the small-objects stuff. This could go in the next release if >the garbage-collector change wom't upset anything. > >There's still some discussion about just what form the final language >feature should take. I don't know if that will be finished in time for >the release. > >-- hendrik > From hendrik at topoi.pooq.com Tue Apr 14 18:59:57 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 14 Apr 2009 12:59:57 -0400 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <200904141656.n3EGuYuZ061174@camembert.async.caltech.edu> References: <20090414130433.GA2968@topoi.pooq.com> <200904141656.n3EGuYuZ061174@camembert.async.caltech.edu> Message-ID: <20090414165957.GA3460@topoi.pooq.com> On Tue, Apr 14, 2009 at 09:56:34AM -0700, Mika Nystrom wrote: > > I agree with what Hendrik says, but what about TYPECASE, ISTYPE, > NARROW? Those are necessary to make it possible to pass "pointers" > with the low-order bit set outside of unsafe code. Actually, it's possible to hack this inside unsafe code. So the language chenges are not absolutely essential. But if we have the right langauge changes, agreed, it would be pleasant not to have teo rewrite our code when the language changes finally freeze. -- hendrik From hendrik at topoi.pooq.com Tue Apr 14 19:11:33 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 14 Apr 2009 13:11:33 -0400 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> References: <49DE5A8A.5070307@bellsouth.net> <20090411112611.xynpb1f688o4gsw0@mail.elegosoft.com> Message-ID: <20090414171133.GB3460@topoi.pooq.com> On Sat, Apr 11, 2009 at 11:26:11AM +0200, Olaf Wagner wrote: > > I'd rather avoid creating a branch too early, as that means more work > by selecting and merging fixes from trunk to branch. So here my questions: > > o Do we all agree on a temporary code freeze? > o When should we start? I.e. wha changes would you like to complete > before we start the release process? One thing that's essential is to debug the documentation -- specifically, the installation instructions, the various README files, and so forth. A naive user. competent in the ways of computers, but not yet in the ways of Modula 3, should be able to follow the instructions and succeed. Now I've done Modula 3 installations from snapshots before. So I'm no longer the naive user you want from this. If we can find a few colunteers who have never done such installations before, it would be useful to have them try to install, log the results, and come up with a list of obscuritues in the docs. (right down to difficulties in finding the docs!) But I have never compiled and installed the entire system from CVS. I've just downloaded the source from CVS, using the helpful instructions on http://modula3.elegosoft.com/cm3/, so I can report on how this goes, and there there are problems. First problem: the instructions don't say that cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 create a new dubdirectory of the current directory called cm3, and put everything in there. In particular, if there's already a directory called cm3, the downloaded source code will be plunked right on top of whatever was there. This may be obvious to experienced cvs users, but cvs is no longer the standard version control system, and we shouln't expect familiarity. -- hendrik From hendrik at topoi.pooq.com Wed Apr 15 04:54:32 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 14 Apr 2009 22:54:32 -0400 Subject: [M3devel] cvsup and TEXT In-Reply-To: References: <20090413150854.GA32577@topoi.pooq.com> <20090413192006.GA660@topoi.pooq.com> <20090414021311.GB1549@topoi.pooq.com> Message-ID: <20090415025432.GA3881@topoi.pooq.com> On Tue, Apr 14, 2009 at 03:00:48AM +0000, Jay wrote: > > > birch's full domain name > > > > .elegosoft.com > > aka m3.elegosoft.com > > aka modula3.elegosoft.com > > > > > Maybe it's time to change all this. > > > Could be. > > > > > So I should just remove the duplicate from the m3makefile, and maybe > > from the src directory? > > > Just cvs upd -dAP in cm3/m3-tools/cvsup. > > The current commited code should work. > > > > Specifically: remove the suptcp directory, change import(suptcp) to > tcp, any occurences of IMPORT SupFoo AS Foo changed to just IMPORT > Foo, where Foo is roughly in the set TCP, ConnFD, ConnRW, and similer > for SupErrno vs. CErrno, but don't take my word for it, try the > current source. There are more changes than that, such as adapt for > non-const errno values, fixes for big endian 64bit system (a rare > thing, I realize)... Anyway, I checked out cm3 from cvs and spent a while (that's another story) getting a lot of it built and shipped. I'm not quite sure if you're enumerating the things I still have to do, or the things that already have been done on the mainline CVS version. Most of the Sup things seem to be gone already, except suptcp and suplib are still there. Or maybe I haven't looked in the right places yet. I ran ..//scripts/do-pkg.sh buildship cvsup in the source tree as obtained from CVS, without changes, and got no complaints about suptcp (but maybe they were masked by other problems, in which case I'll get around to them soon). Instead I got a complaint that seems to have nothing at all to do with sup: Fatal Error: duplicate unit: ../suplib/src/text_cm3/CText.m3 ../suplib/src/text_pm3/CText.m3 Would this be related to the TEXT changes that are going on? -- hendrik From jay.krell at cornell.edu Wed Apr 15 12:59:59 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 15 Apr 2009 10:59:59 +0000 Subject: [M3devel] cvsup In-Reply-To: <20090415025432.GA3881@topoi.pooq.com> References: <20090413150854.GA32577@topoi.pooq.com> <20090413192006.GA660@topoi.pooq.com> <20090414021311.GB1549@topoi.pooq.com> <20090415025432.GA3881@topoi.pooq.com> Message-ID: Again, the current source builds. The stuff I listed is some of what I did, what you would have to do if you started with the snapshop. I shouldn't have mentioned it. I did not make "do-pkg cvsup" and such work however. Or test it. But it might work, like do-pkg suplib && do-pkg cvsup/server && do-pkg cvsup/client. The error indicates you don't have current source maybe. Or, whatever, the pm3 vs. cm3 check isn't working. I' think I'll just make unconditional. The text changes do not change the interface or even the underlying data structures/pickes (future changes will conceivable change the underlying structures). Only small bugfixes are even in the mainline. suplib is fine and needed. It is specific to cvsup and a bunch of code unique to it. Just suptcp is dead now. cd $CVSROOT/m3-tools cvs -z3 upd cvsup cd cvsup/suplib cm3 cm3 -ship cd ../server cm3 cm3 -ship (optional) cd ../client cm3 cm3 -ship (optional) (client and server can be built in either order; suplib must be built before either) - Jay From hendrik at topoi.pooq.com Wed Apr 15 15:39:53 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 15 Apr 2009 09:39:53 -0400 Subject: [M3devel] cvsup In-Reply-To: References: <20090413150854.GA32577@topoi.pooq.com> <20090413192006.GA660@topoi.pooq.com> <20090414021311.GB1549@topoi.pooq.com> <20090415025432.GA3881@topoi.pooq.com> Message-ID: <20090415133953.GB5233@topoi.pooq.com> On Wed, Apr 15, 2009 at 10:59:59AM +0000, Jay wrote: > > Again, the current source builds. > The stuff I listed is some of what I did, what > you would have to do if you started with the snapshop. > I shouldn't have mentioned it. > > > I did not make "do-pkg cvsup" and such work however. Or test it. > But it might work, like do-pkg suplib && do-pkg cvsup/server && do-pkg cvsup/client. > The error indicates you don't have current source maybe. Well, I just checked the entire cm3 out from cvs yesterday (or was it the evening before? No earlier, anyway.). > Or, whatever, the pm3 vs. cm3 check isn't working. Perhaps this is the problem. What is the pm3 vs cm3 check? > I' think I'll just make unconditional. > The text changes do not change the interface or even the > underlying data structures/pickes (future changes will conceivable > change the underlying structures). Only small bugfixes > are even in the mainline. So I should see where the extraneous interfece comes from and try to get rid of it. > > > suplib is fine and needed. It is specific to cvsup and a bunch > of code unique to it. > Just suptcp is dead now. > > > cd $CVSROOT/m3-tools > cvs -z3 upd cvsup > cd cvsup/suplib > cm3 > cm3 -ship > cd ../server > cm3 > cm3 -ship (optional) > cd ../client > cm3 > cm3 -ship (optional) Will try this first. -- hendrik > > > (client and server can be built in either order; suplib must be built before either) > > > - Jay From jay.krell at cornell.edu Wed Apr 15 16:12:34 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 15 Apr 2009 14:12:34 +0000 Subject: [M3devel] fewer wrappers/more C? (or a wash?) Message-ID: This "rewrites" ThreadPThread.InitMutex and ThreadPThread.InitCondition in C. They are only a few lines either way. Thereby removing all uses of initMu from Modula-3 and enabling removing the "bridging" of it between Modula-3 and C. Better? I'm not sure. No real difference? Maybe. Likewise can be done for CreateT's allocation/initialization of cond_t. And then MemAlloc/MemFree would be moved. Ultimately this is the route toward - writing most/all of ThreadPThread.c in C - removing most/all bridging I'm aware it should handle out of memory. - Jay Index: ThreadPThread.i3 =================================================================== RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThread.i3,v retrieving revision 1.14 diff -u -r1.14 ThreadPThread.i3 --- ThreadPThread.i3 30 Mar 2009 21:52:15 -0000 1.14 +++ ThreadPThread.i3 15 Apr 2009 14:03:58 -0000 @@ -137,20 +137,10 @@ pthread_mutex_t = ADDRESS; pthread_cond_t = ADDRESS; - -(*CONST*) VAR sizeof_pthread_mutex_t:int; - (*CONST*) VAR sizeof_pthread_cond_t:int; -PROCEDURE pthread_mutex_init(mutex: pthread_mutex_t; attr:ADDRESS:=NIL):int; - -(* This wrapper has some OS-specific bug workarounds. *) - -PROCEDURE pthread_mutex_destroy(mutex: pthread_mutex_t):int; - - PROCEDURE pthread_mutex_lock(mutex: pthread_mutex_t):int; @@ -170,4 +160,12 @@ (*---------------------------------------------------------------------------*) + +PROCEDURE InitMutex (MutexRoot: REFANY; VAR pthread_mutex: pthread_mutex_t); + + +PROCEDURE InitCondition (ConditionRoot: REFANY; VAR pthread_mutex: pthread_mutex_t); + +(*---------------------------------------------------------------------------*) + END ThreadPThread. Index: ThreadPThread.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThread.m3,v retrieving revision 1.101 diff -u -r1.101 ThreadPThread.m3 --- ThreadPThread.m3 30 Mar 2009 21:59:31 -0000 1.101 +++ ThreadPThread.m3 15 Apr 2009 14:03:58 -0000 @@ -155,35 +155,13 @@ m.release (); END Release; -PROCEDURE CleanMutex (r: REFANY) = - VAR m := NARROW(r, Mutex); - BEGIN - WITH r = pthread_mutex_destroy (m.mutex) DO END; - MemFree(m.mutex); - END CleanMutex; - -PROCEDURE InitMutex (m: Mutex) = - VAR mutex: pthread_mutex_t; - BEGIN - TRY - WITH r = pthread_mutex_lock_init() DO END; - IF m.mutex # NIL THEN RETURN END; - mutex := MemAlloc(sizeof_pthread_mutex_t); - WITH r = pthread_mutex_init(mutex) DO END; - m.mutex := mutex; - FINALLY - WITH r = pthread_mutex_unlock_init() DO END; - END; - RTHeapRep.RegisterFinalCleanup (m, CleanMutex); - END InitMutex; - PROCEDURE LockMutex (m: Mutex) = VAR self := Self(); BEGIN IF self = NIL THEN Die(ThisLine(), "LockMutex called from a non-Modula-3 thread"); END; - IF m.mutex = NIL THEN InitMutex(m) END; + IF m.mutex = NIL THEN InitMutex(m, m.mutex) END; IF perfOn THEN PerfChanged(self.id, State.locking) END; WITH r = pthread_mutex_lock(m.mutex) DO IF r # 0 THEN @@ -211,34 +189,12 @@ (*---------------------------------------- Condition variables and Alerts ---*) -PROCEDURE CleanCondition (r: REFANY) = - VAR c := NARROW(r, Condition); - BEGIN - WITH r = pthread_mutex_destroy (c.mutex) DO END; - MemFree(c.mutex); - END CleanCondition; - -PROCEDURE InitCondition (c: Condition) = - VAR mutex: pthread_mutex_t; - BEGIN - TRY - WITH r = pthread_mutex_lock_init() DO END; - IF c.mutex # NIL THEN RETURN END; - mutex := MemAlloc(sizeof_pthread_mutex_t); - WITH r = pthread_mutex_init(mutex) DO END; - c.mutex := mutex; - FINALLY - WITH r = pthread_mutex_unlock_init() DO END; - END; - RTHeapRep.RegisterFinalCleanup (c, CleanCondition); - END InitCondition; - PROCEDURE XWait (self: T; m: Mutex; c: Condition; alertable: BOOLEAN) RAISES {Alerted} = (* LL = m *) VAR next, prev: T; BEGIN - IF c.mutex = NIL THEN InitCondition(c) END; + IF c.mutex = NIL THEN InitCondition(c, c.mutex) END; TRY @@ -325,7 +281,7 @@ PROCEDURE Signal (c: Condition) = BEGIN - IF c.mutex = NIL THEN InitCondition(c) END; + IF c.mutex = NIL THEN InitCondition(c, c.mutex) END; WITH r = pthread_mutex_lock(c.mutex) DO END; IF c.waiters # NIL THEN DequeueHead(c) END; WITH r = pthread_mutex_unlock(c.mutex) DO END; @@ -333,7 +289,7 @@ PROCEDURE Broadcast (c: Condition) = BEGIN - IF c.mutex = NIL THEN InitCondition(c) END; + IF c.mutex = NIL THEN InitCondition(c, c.mutex) END; WITH r = pthread_mutex_lock(c.mutex) DO END; WHILE c.waiters # NIL DO DequeueHead(c) END; WITH r = pthread_mutex_unlock(c.mutex) DO END; Index: ThreadPThreadC.c =================================================================== RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThreadC.c,v retrieving revision 1.19 diff -u -r1.19 ThreadPThreadC.c --- ThreadPThreadC.c 30 Mar 2009 21:52:15 -0000 1.19 +++ ThreadPThreadC.c 15 Apr 2009 14:03:58 -0000 @@ -250,16 +250,12 @@ MUTEX(active) /* global lock for list of active threads */ MUTEX(slot) /* global lock for thread slot table */ -MUTEX(init) /* global lock for initializers */ MUTEX(perf) MUTEX(heap) CONDITION_VARIABLE(heap) THREAD_LOCAL(activations) EXTERN_CONST -int ThreadPThread__sizeof_pthread_mutex_t = sizeof(pthread_mutex_t); - -EXTERN_CONST int ThreadPThread__sizeof_pthread_cond_t = sizeof(pthread_cond_t); int @@ -271,17 +267,83 @@ pthread_mutex_destroy() intermittently returns EBUSY even when there are no threads accessing the mutex. */ int e; - do - { - e = pthread_mutex_destroy(mutex); - } - while (e == EBUSY); + while ((e = pthread_mutex_destroy(mutex)) == EBUSY) { } return e; #else return pthread_mutex_destroy(mutex); #endif } +void RTHeapRep__RegisterFinalCleanup (char* Root, void (*clean)(char*)); + +/* This should be known at compile-time, but I don't know the Modula-3 object model. */ +size_t M3MutexToPthreadMutex; +size_t M3ConditionToPthreadMutex; + +#define MemAlloc ThreadPThread__MemAlloc +#define MemFree ThreadPThread__MemFree + +void* MemAlloc (size_t size); +void MemFree (void* a); + +static void Common_CleanMutex(char* Root, size_t Offset) +{ + pthread_mutex_t** inout_Mutex = (pthread_mutex_t**)(Root + Offset); + pthread_mutex_t* Mutex = *inout_Mutex; + *inout_Mutex = NULL; + if (Mutex != NULL) + { + ThreadPThread__pthread_mutex_destroy(Mutex); + MemFree(Mutex); + } +} + +static void CleanCondition(char* Root) +{ + Common_CleanMutex(Root, M3ConditionToPthreadMutex); +} + +static void CleanMutex(char* Root) +{ + Common_CleanMutex(Root, M3MutexToPthreadMutex); +} + +static void Common_InitMutex(char* Root, pthread_mutex_t** inout_Mutex, size_t* inout_Offset, void (*Clean)(char*)) +{ + static pthread_mutex_t initMu = PTHREAD_MUTEX_INITIALIZER; /* global lock for initializers */ + size_t Offset = *inout_Offset; + + if (Offset == 0) + *inout_Offset = (((char*)inout_Mutex) - Root); + else + assert(Offset == (((char*)inout_Mutex) - Root)); + assert((char*)inout_Mutex>= Root); + + pthread_mutex_lock(&initMu); + if (*inout_Mutex == NULL) + { + pthread_mutex_t* Mutex = (pthread_mutex_t*)calloc(1, sizeof(*Mutex)); + if (Mutex) + { + pthread_mutex_init(Mutex, NULL); + *inout_Mutex = Mutex; + } + } + pthread_mutex_unlock(&initMu); + + RTHeapRep__RegisterFinalCleanup (Root, Clean); +} + +void ThreadPThread__InitMutex(char* Root, pthread_mutex_t** Mutex) +{ + Common_InitMutex(Root, Mutex, &M3MutexToPthreadMutex, CleanMutex); +} + +void ThreadPThread__InitCondition (char* Root, pthread_mutex_t** Mutex) +{ + Common_InitMutex(Root, Mutex, &M3ConditionToPthreadMutex, CleanCondition); +} + #ifdef __cplusplus } /* extern "C" */ #endif -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ThreadPThreadC.c URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ThreadPThread.m3 URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt URL: From jay.krell at cornell.edu Wed Apr 15 16:09:33 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 15 Apr 2009 14:09:33 +0000 Subject: [M3devel] cvsup In-Reply-To: <20090415133953.GB5233@topoi.pooq.com> References: <20090413150854.GA32577@topoi.pooq.com> <20090413192006.GA660@topoi.pooq.com> <20090414021311.GB1549@topoi.pooq.com> <20090415025432.GA3881@topoi.pooq.com> <20090415133953.GB5233@topoi.pooq.com> Message-ID: cm3/m3-tools/cvsup/quake/cvsup.quake I made it unconditional after your mail. There is code that is PM3 or CM3 or SRC specific and tries to pick the right one by sniffing the compiler. or Windows, easy to find it: cd \dev2\cm3\m3-tools\cvsup findstr /s PM3 * or dir /s/b/a-d | findstr /i cm3 dir /s/b/a-d | findstr /i pm3 It should all be easy to find. But again, it should just work from current cvs. - Jay From hendrik at topoi.pooq.com Wed Apr 15 19:25:29 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 15 Apr 2009 13:25:29 -0400 Subject: [M3devel] cvsup In-Reply-To: References: <20090413150854.GA32577@topoi.pooq.com> <20090413192006.GA660@topoi.pooq.com> <20090414021311.GB1549@topoi.pooq.com> <20090415025432.GA3881@topoi.pooq.com> <20090415133953.GB5233@topoi.pooq.com> Message-ID: <20090415172529.GA5566@topoi.pooq.com> On Wed, Apr 15, 2009 at 02:09:33PM +0000, Jay wrote: > > cm3/m3-tools/cvsup/quake/cvsup.quake > I made it unconditional after your mail. Maybe that's why it works now. And cvsup runs and I now have over a gigabyte of Modula 3 .v files. Next to figure out what monotone wants me to do with them. -- hendrik From hosking at cs.purdue.edu Fri Apr 17 04:54:13 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 17 Apr 2009 12:54:13 +1000 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <200904141656.n3EGuYuZ061174@camembert.async.caltech.edu> References: <200904141656.n3EGuYuZ061174@camembert.async.caltech.edu> Message-ID: <0DEE58D2-97B2-4BE3-A5F9-4FAFC326EC68@cs.purdue.edu> Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 15 Apr 2009, at 02:56, Mika Nystrom wrote: > > I agree with what Hendrik says, but what about TYPECASE, ISTYPE, > NARROW? Those are necessary to make it possible to pass "pointers" > with the low-order bit set outside of unsafe code. > > My feeling is that if Tony can make the necessary changes, it could > be done immediately, and the language issues can be pushed to the > future. But admittedly I'm biased because of the application I'm > working on. I can take care of this next week. > I need to get a recent CM3 up to test the TEXTs.... are they the > default now? > > Mika > > hendrik at topoi.pooq.com writes: >> On Tue, Apr 14, 2009 at 12:02:17PM +0200, Olaf Wagner wrote: >>> If anybody could test Rodney's TEXT changes and provide some >>> information on the impacts on our applications, that would help a >>> lot. >>> >>> I also wasn't able to read and understand all the mails about >>> small objects. >>> (Guessing, I'd say I'd need another day for that :-) >>> Can anybody summarize? >>> Has a conclusion been reached and what will be done/implemented? >>> Is this relevant for the next release, or will it take longer? >> >> Deciding that the garbage collector should test for the low-order >> bit of >> pointers and leave them alone if the bit is set could probably dop >> done >> immediately, and would make it possible for users to build unsafe >> code >> to do the small-objects stuff. This could go in the next release if >> the garbage-collector change wom't upset anything. >> >> There's still some discussion about just what form the final language >> feature should take. I don't know if that will be finished in time >> for >> the release. >> >> -- hendrik >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 17 14:57:10 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 17 Apr 2009 22:57:10 +1000 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: References: Message-ID: I am a little concerned about passing REFANY directly to C code as there is no guarantee that REFANY and C pointers will always be compatible. ADDRESS can more safely be assumed compatible. On 16 Apr 2009, at 00:12, Jay wrote: > > This "rewrites" ThreadPThread.InitMutex and > ThreadPThread.InitCondition in C. > They are only a few lines either way. > Thereby removing all uses of initMu from Modula-3 and enabling > removing > the "bridging" of it between Modula-3 and C. > > > Better? I'm not sure. > No real difference? Maybe. > > > Likewise can be done for CreateT's allocation/initialization of > cond_t. > And then MemAlloc/MemFree would be moved. > > > Ultimately this is the route toward > - writing most/all of ThreadPThread.c in C > - removing most/all bridging > > > I'm aware it should handle out of memory. > > > - Jay > > > Index: ThreadPThread.i3 > =================================================================== > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ > ThreadPThread.i3,v > retrieving revision 1.14 > diff -u -r1.14 ThreadPThread.i3 > --- ThreadPThread.i3 30 Mar 2009 21:52:15 -0000 1.14 > +++ ThreadPThread.i3 15 Apr 2009 14:03:58 -0000 > @@ -137,20 +137,10 @@ > pthread_mutex_t = ADDRESS; > pthread_cond_t = ADDRESS; > > - > -(*CONST*) VAR sizeof_pthread_mutex_t:int; > - > > (*CONST*) VAR sizeof_pthread_cond_t:int; > > > -PROCEDURE pthread_mutex_init(mutex: pthread_mutex_t; > attr:ADDRESS:=NIL):int; > - > -(* This wrapper has some OS-specific bug workarounds. *) > - > -PROCEDURE pthread_mutex_destroy(mutex: pthread_mutex_t):int; > - > - > PROCEDURE pthread_mutex_lock(mutex: pthread_mutex_t):int; > > > @@ -170,4 +160,12 @@ > > (*---------------------------------------------------------------------------*) > > + > +PROCEDURE InitMutex (MutexRoot: REFANY; VAR pthread_mutex: > pthread_mutex_t); > + > + > +PROCEDURE InitCondition (ConditionRoot: REFANY; VAR pthread_mutex: > pthread_mutex_t); > + > + > (*---------------------------------------------------------------------------*) > + > END ThreadPThread. > Index: ThreadPThread.m3 > =================================================================== > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ > ThreadPThread.m3,v > retrieving revision 1.101 > diff -u -r1.101 ThreadPThread.m3 > --- ThreadPThread.m3 30 Mar 2009 21:59:31 -0000 1.101 > +++ ThreadPThread.m3 15 Apr 2009 14:03:58 -0000 > @@ -155,35 +155,13 @@ > m.release (); > END Release; > > -PROCEDURE CleanMutex (r: REFANY) = > - VAR m := NARROW(r, Mutex); > - BEGIN > - WITH r = pthread_mutex_destroy (m.mutex) DO END; > - MemFree(m.mutex); > - END CleanMutex; > - > -PROCEDURE InitMutex (m: Mutex) = > - VAR mutex: pthread_mutex_t; > - BEGIN > - TRY > - WITH r = pthread_mutex_lock_init() DO END; > - IF m.mutex # NIL THEN RETURN END; > - mutex := MemAlloc(sizeof_pthread_mutex_t); > - WITH r = pthread_mutex_init(mutex) DO END; > - m.mutex := mutex; > - FINALLY > - WITH r = pthread_mutex_unlock_init() DO END; > - END; > - RTHeapRep.RegisterFinalCleanup (m, CleanMutex); > - END InitMutex; > - > PROCEDURE LockMutex (m: Mutex) = > VAR self := Self(); > BEGIN > IF self = NIL THEN > Die(ThisLine(), "LockMutex called from a non-Modula-3 thread"); > END; > - IF m.mutex = NIL THEN InitMutex(m) END; > + IF m.mutex = NIL THEN InitMutex(m, m.mutex) END; > IF perfOn THEN PerfChanged(self.id, State.locking) END; > WITH r = pthread_mutex_lock(m.mutex) DO > IF r # 0 THEN > @@ -211,34 +189,12 @@ > > (*---------------------------------------- Condition variables and > Alerts ---*) > > -PROCEDURE CleanCondition (r: REFANY) = > - VAR c := NARROW(r, Condition); > - BEGIN > - WITH r = pthread_mutex_destroy (c.mutex) DO END; > - MemFree(c.mutex); > - END CleanCondition; > - > -PROCEDURE InitCondition (c: Condition) = > - VAR mutex: pthread_mutex_t; > - BEGIN > - TRY > - WITH r = pthread_mutex_lock_init() DO END; > - IF c.mutex # NIL THEN RETURN END; > - mutex := MemAlloc(sizeof_pthread_mutex_t); > - WITH r = pthread_mutex_init(mutex) DO END; > - c.mutex := mutex; > - FINALLY > - WITH r = pthread_mutex_unlock_init() DO END; > - END; > - RTHeapRep.RegisterFinalCleanup (c, CleanCondition); > - END InitCondition; > - > PROCEDURE XWait (self: T; m: Mutex; c: Condition; alertable: BOOLEAN) > RAISES {Alerted} = > (* LL = m *) > VAR next, prev: T; > BEGIN > - IF c.mutex = NIL THEN InitCondition(c) END; > + IF c.mutex = NIL THEN InitCondition(c, c.mutex) END; > TRY > > > @@ -325,7 +281,7 @@ > > PROCEDURE Signal (c: Condition) = > BEGIN > - IF c.mutex = NIL THEN InitCondition(c) END; > + IF c.mutex = NIL THEN InitCondition(c, c.mutex) END; > WITH r = pthread_mutex_lock(c.mutex) DO END; > IF c.waiters # NIL THEN DequeueHead(c) END; > WITH r = pthread_mutex_unlock(c.mutex) DO END; > @@ -333,7 +289,7 @@ > > PROCEDURE Broadcast (c: Condition) = > BEGIN > - IF c.mutex = NIL THEN InitCondition(c) END; > + IF c.mutex = NIL THEN InitCondition(c, c.mutex) END; > WITH r = pthread_mutex_lock(c.mutex) DO END; > WHILE c.waiters # NIL DO DequeueHead(c) END; > WITH r = pthread_mutex_unlock(c.mutex) DO END; > Index: ThreadPThreadC.c > =================================================================== > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ > ThreadPThreadC.c,v > retrieving revision 1.19 > diff -u -r1.19 ThreadPThreadC.c > --- ThreadPThreadC.c 30 Mar 2009 21:52:15 -0000 1.19 > +++ ThreadPThreadC.c 15 Apr 2009 14:03:58 -0000 > @@ -250,16 +250,12 @@ > > MUTEX(active) /* global lock for list of active threads */ > MUTEX(slot) /* global lock for thread slot table */ > -MUTEX(init) /* global lock for initializers */ > MUTEX(perf) > MUTEX(heap) > CONDITION_VARIABLE(heap) > THREAD_LOCAL(activations) > > EXTERN_CONST > -int ThreadPThread__sizeof_pthread_mutex_t = sizeof(pthread_mutex_t); > - > -EXTERN_CONST > int ThreadPThread__sizeof_pthread_cond_t = sizeof(pthread_cond_t); > > int > @@ -271,17 +267,83 @@ > pthread_mutex_destroy() intermittently returns > EBUSY even when there are no threads accessing the mutex. */ > int e; > - do > - { > - e = pthread_mutex_destroy(mutex); > - } > - while (e == EBUSY); > + while ((e = pthread_mutex_destroy(mutex)) == EBUSY) { } > return e; > #else > return pthread_mutex_destroy(mutex); > #endif > } > > +void RTHeapRep__RegisterFinalCleanup (char* Root, void (*clean) > (char*)); > + > +/* This should be known at compile-time, but I don't know the > Modula-3 object model. */ > +size_t M3MutexToPthreadMutex; > +size_t M3ConditionToPthreadMutex; > + > +#define MemAlloc ThreadPThread__MemAlloc > +#define MemFree ThreadPThread__MemFree > + > +void* MemAlloc (size_t size); > +void MemFree (void* a); > + > +static void Common_CleanMutex(char* Root, size_t Offset) > +{ > + pthread_mutex_t** inout_Mutex = (pthread_mutex_t**)(Root + > Offset); > + pthread_mutex_t* Mutex = *inout_Mutex; > + *inout_Mutex = NULL; > + if (Mutex != NULL) > + { > + ThreadPThread__pthread_mutex_destroy(Mutex); > + MemFree(Mutex); > + } > +} > + > +static void CleanCondition(char* Root) > +{ > + Common_CleanMutex(Root, M3ConditionToPthreadMutex); > +} > + > +static void CleanMutex(char* Root) > +{ > + Common_CleanMutex(Root, M3MutexToPthreadMutex); > +} > + > +static void Common_InitMutex(char* Root, pthread_mutex_t** > inout_Mutex, size_t* inout_Offset, void (*Clean)(char*)) > +{ > + static pthread_mutex_t initMu = PTHREAD_MUTEX_INITIALIZER; /* > global lock for initializers */ > + size_t Offset = *inout_Offset; > + > + if (Offset == 0) > + *inout_Offset = (((char*)inout_Mutex) - Root); > + else > + assert(Offset == (((char*)inout_Mutex) - Root)); > + assert((char*)inout_Mutex>= Root); > + > + pthread_mutex_lock(&initMu); > + if (*inout_Mutex == NULL) > + { > + pthread_mutex_t* Mutex = (pthread_mutex_t*)calloc(1, > sizeof(*Mutex)); > + if (Mutex) > + { > + pthread_mutex_init(Mutex, NULL); > + *inout_Mutex = Mutex; > + } > + } > + pthread_mutex_unlock(&initMu); > + > + RTHeapRep__RegisterFinalCleanup (Root, Clean); > +} > + > +void ThreadPThread__InitMutex(char* Root, pthread_mutex_t** Mutex) > +{ > + Common_InitMutex(Root, Mutex, &M3MutexToPthreadMutex, > CleanMutex); > +} > + > +void ThreadPThread__InitCondition (char* Root, pthread_mutex_t** > Mutex) > +{ > + Common_InitMutex(Root, Mutex, &M3ConditionToPthreadMutex, > CleanCondition); > +} > + > #ifdef __cplusplus > } /* extern "C" */ > #endif > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Apr 17 23:48:44 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 17 Apr 2009 21:48:44 +0000 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: References: Message-ID: Ok. And the rest/overall? Usually I'm very certain my "more C code" changes are for the better. In this case it might be a wash. REFANY might have some tag bits set? ADDRESS really is/must-be a direct pointer that us C programmers are familiar with? UNTRACED REF T would have to be a plain old pointer too right? - Jay ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: fewer wrappers/more C? (or a wash?) > Date: Fri, 17 Apr 2009 22:57:10 +1000 > > I am a little concerned about passing REFANY directly to C code as there is no guarantee that REFANY and C pointers will always be compatible. ADDRESS can more safely be assumed compatible. > > On 16 Apr 2009, at 00:12, Jay wrote: > > > This "rewrites" ThreadPThread.InitMutex and ThreadPThread.InitCondition in C. > They are only a few lines either way. > Thereby removing all uses of initMu from Modula-3 and enabling removing > the "bridging" of it between Modula-3 and C. > > > Better? I'm not sure. > No real difference? Maybe. > > > Likewise can be done for CreateT's allocation/initialization of cond_t. > And then MemAlloc/MemFree would be moved. > > > Ultimately this is the route toward > - writing most/all of ThreadPThread.c in C > - removing most/all bridging > > > I'm aware it should handle out of memory. > > > - Jay > > > Index: ThreadPThread.i3 > =================================================================== > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThread.i3,v > retrieving revision 1.14 > diff -u -r1.14 ThreadPThread.i3 > --- ThreadPThread.i3 30 Mar 2009 21:52:15 -0000 1.14 > +++ ThreadPThread.i3 15 Apr 2009 14:03:58 -0000 > @@ -137,20 +137,10 @@ > pthread_mutex_t = ADDRESS; > pthread_cond_t = ADDRESS; > > - > -(*CONST*) VAR sizeof_pthread_mutex_t:int; > - > > (*CONST*) VAR sizeof_pthread_cond_t:int; > > > -PROCEDURE pthread_mutex_init(mutex: pthread_mutex_t; attr:ADDRESS:=NIL):int; > - > -(* This wrapper has some OS-specific bug workarounds. *) > - > -PROCEDURE pthread_mutex_destroy(mutex: pthread_mutex_t):int; > - > - > PROCEDURE pthread_mutex_lock(mutex: pthread_mutex_t):int; > > > @@ -170,4 +160,12 @@ > > (*---------------------------------------------------------------------------*) > > + > +PROCEDURE InitMutex (MutexRoot: REFANY; VAR pthread_mutex: pthread_mutex_t); > + > + > +PROCEDURE InitCondition (ConditionRoot: REFANY; VAR pthread_mutex: pthread_mutex_t); > + > +(*---------------------------------------------------------------------------*) > + > END ThreadPThread. > Index: ThreadPThread.m3 > =================================================================== > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThread.m3,v > retrieving revision 1.101 > diff -u -r1.101 ThreadPThread.m3 > --- ThreadPThread.m3 30 Mar 2009 21:59:31 -0000 1.101 > +++ ThreadPThread.m3 15 Apr 2009 14:03:58 -0000 > @@ -155,35 +155,13 @@ > m.release (); > END Release; > > -PROCEDURE CleanMutex (r: REFANY) = > - VAR m := NARROW(r, Mutex); > - BEGIN > - WITH r = pthread_mutex_destroy (m.mutex) DO END; > - MemFree(m.mutex); > - END CleanMutex; > - > -PROCEDURE InitMutex (m: Mutex) = > - VAR mutex: pthread_mutex_t; > - BEGIN > - TRY > - WITH r = pthread_mutex_lock_init() DO END; > - IF m.mutex # NIL THEN RETURN END; > - mutex := MemAlloc(sizeof_pthread_mutex_t); > - WITH r = pthread_mutex_init(mutex) DO END; > - m.mutex := mutex; > - FINALLY > - WITH r = pthread_mutex_unlock_init() DO END; > - END; > - RTHeapRep.RegisterFinalCleanup (m, CleanMutex); > - END InitMutex; > - > PROCEDURE LockMutex (m: Mutex) = > VAR self := Self(); > BEGIN > IF self = NIL THEN > Die(ThisLine(), "LockMutex called from a non-Modula-3 thread"); > END; > - IF m.mutex = NIL THEN InitMutex(m) END; > + IF m.mutex = NIL THEN InitMutex(m, m.mutex) END; > IF perfOn THEN PerfChanged(self.id, State.locking) END; > WITH r = pthread_mutex_lock(m.mutex) DO > IF r # 0 THEN > @@ -211,34 +189,12 @@ > > (*---------------------------------------- Condition variables and Alerts ---*) > > -PROCEDURE CleanCondition (r: REFANY) = > - VAR c := NARROW(r, Condition); > - BEGIN > - WITH r = pthread_mutex_destroy (c.mutex) DO END; > - MemFree(c.mutex); > - END CleanCondition; > - > -PROCEDURE InitCondition (c: Condition) = > - VAR mutex: pthread_mutex_t; > - BEGIN > - TRY > - WITH r = pthread_mutex_lock_init() DO END; > - IF c.mutex # NIL THEN RETURN END; > - mutex := MemAlloc(sizeof_pthread_mutex_t); > - WITH r = pthread_mutex_init(mutex) DO END; > - c.mutex := mutex; > - FINALLY > - WITH r = pthread_mutex_unlock_init() DO END; > - END; > - RTHeapRep.RegisterFinalCleanup (c, CleanCondition); > - END InitCondition; > - > PROCEDURE XWait (self: T; m: Mutex; c: Condition; alertable: BOOLEAN) > RAISES {Alerted} = > (* LL = m *) > VAR next, prev: T; > BEGIN > - IF c.mutex = NIL THEN InitCondition(c) END; > + IF c.mutex = NIL THEN InitCondition(c, c.mutex) END; > TRY > > > @@ -325,7 +281,7 @@ > > PROCEDURE Signal (c: Condition) = > BEGIN > - IF c.mutex = NIL THEN InitCondition(c) END; > + IF c.mutex = NIL THEN InitCondition(c, c.mutex) END; > WITH r = pthread_mutex_lock(c.mutex) DO END; > IF c.waiters # NIL THEN DequeueHead(c) END; > WITH r = pthread_mutex_unlock(c.mutex) DO END; > @@ -333,7 +289,7 @@ > > PROCEDURE Broadcast (c: Condition) = > BEGIN > - IF c.mutex = NIL THEN InitCondition(c) END; > + IF c.mutex = NIL THEN InitCondition(c, c.mutex) END; > WITH r = pthread_mutex_lock(c.mutex) DO END; > WHILE c.waiters # NIL DO DequeueHead(c) END; > WITH r = pthread_mutex_unlock(c.mutex) DO END; > Index: ThreadPThreadC.c > =================================================================== > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThreadC.c,v > retrieving revision 1.19 > diff -u -r1.19 ThreadPThreadC.c > --- ThreadPThreadC.c 30 Mar 2009 21:52:15 -0000 1.19 > +++ ThreadPThreadC.c 15 Apr 2009 14:03:58 -0000 > @@ -250,16 +250,12 @@ > > MUTEX(active) /* global lock for list of active threads */ > MUTEX(slot) /* global lock for thread slot table */ > -MUTEX(init) /* global lock for initializers */ > MUTEX(perf) > MUTEX(heap) > CONDITION_VARIABLE(heap) > THREAD_LOCAL(activations) > > EXTERN_CONST > -int ThreadPThread__sizeof_pthread_mutex_t = sizeof(pthread_mutex_t); > - > -EXTERN_CONST > int ThreadPThread__sizeof_pthread_cond_t = sizeof(pthread_cond_t); > > int > @@ -271,17 +267,83 @@ > pthread_mutex_destroy() intermittently returns > EBUSY even when there are no threads accessing the mutex. */ > int e; > - do > - { > - e = pthread_mutex_destroy(mutex); > - } > - while (e == EBUSY); > + while ((e = pthread_mutex_destroy(mutex)) == EBUSY) { } > return e; > #else > return pthread_mutex_destroy(mutex); > #endif > } > > +void RTHeapRep__RegisterFinalCleanup (char* Root, void (*clean)(char*)); > + > +/* This should be known at compile-time, but I don't know the Modula-3 object model. */ > +size_t M3MutexToPthreadMutex; > +size_t M3ConditionToPthreadMutex; > + > +#define MemAlloc ThreadPThread__MemAlloc > +#define MemFree ThreadPThread__MemFree > + > +void* MemAlloc (size_t size); > +void MemFree (void* a); > + > +static void Common_CleanMutex(char* Root, size_t Offset) > +{ > + pthread_mutex_t** inout_Mutex = (pthread_mutex_t**)(Root + Offset); > + pthread_mutex_t* Mutex = *inout_Mutex; > + *inout_Mutex = NULL; > + if (Mutex != NULL) > + { > + ThreadPThread__pthread_mutex_destroy(Mutex); > + MemFree(Mutex); > + } > +} > + > +static void CleanCondition(char* Root) > +{ > + Common_CleanMutex(Root, M3ConditionToPthreadMutex); > +} > + > +static void CleanMutex(char* Root) > +{ > + Common_CleanMutex(Root, M3MutexToPthreadMutex); > +} > + > +static void Common_InitMutex(char* Root, pthread_mutex_t** inout_Mutex, size_t* inout_Offset, void (*Clean)(char*)) > +{ > + static pthread_mutex_t initMu = PTHREAD_MUTEX_INITIALIZER; /* global lock for initializers */ > + size_t Offset = *inout_Offset; > + > + if (Offset == 0) > + *inout_Offset = (((char*)inout_Mutex) - Root); > + else > + assert(Offset == (((char*)inout_Mutex) - Root)); > + assert((char*)inout_Mutex>= Root); > + > + pthread_mutex_lock(&initMu); > + if (*inout_Mutex == NULL) > + { > + pthread_mutex_t* Mutex = (pthread_mutex_t*)calloc(1, sizeof(*Mutex)); > + if (Mutex) > + { > + pthread_mutex_init(Mutex, NULL); > + *inout_Mutex = Mutex; > + } > + } > + pthread_mutex_unlock(&initMu); > + > + RTHeapRep__RegisterFinalCleanup (Root, Clean); > +} > + > +void ThreadPThread__InitMutex(char* Root, pthread_mutex_t** Mutex) > +{ > + Common_InitMutex(Root, Mutex, &M3MutexToPthreadMutex, CleanMutex); > +} > + > +void ThreadPThread__InitCondition (char* Root, pthread_mutex_t** Mutex) > +{ > + Common_InitMutex(Root, Mutex, &M3ConditionToPthreadMutex, CleanCondition); > +} > + > #ifdef __cplusplus > } /* extern "C" */ > #endif > > From hendrik at topoi.pooq.com Sat Apr 18 00:02:58 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 17 Apr 2009 18:02:58 -0400 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <0DEE58D2-97B2-4BE3-A5F9-4FAFC326EC68@cs.purdue.edu> References: <200904141656.n3EGuYuZ061174@camembert.async.caltech.edu> <0DEE58D2-97B2-4BE3-A5F9-4FAFC326EC68@cs.purdue.edu> Message-ID: <20090417220257.GB15700@topoi.pooq.com> On Fri, Apr 17, 2009 at 12:54:13PM +1000, Tony Hosking wrote: > > On 15 Apr 2009, at 02:56, Mika Nystrom wrote: > > > > >I agree with what Hendrik says, but what about TYPECASE, ISTYPE, > >NARROW? Those are necessary to make it possible to pass "pointers" > >with the low-order bit set outside of unsafe code. > > > >My feeling is that if Tony can make the necessary changes, it could should > >be done immediately, and the language issues can be pushed to the > >future. But admittedly I'm biased because of the application I'm > >working on. > > I can take care of this next week. I'm in favour of trying it out before freezing the feature. That means going ahead now with an implementation, and reconsidering it in a few months. Perhaps marking it experimental with an appropriate warning message. A few months is little enough time to use it that it won't be traumatic if code that uses the new features has to be partially rewritten. -- hendrik From rcoleburn at scires.com Sat Apr 18 01:07:02 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 17 Apr 2009 19:07:02 -0400 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <20090417220257.GB15700@topoi.pooq.com> References: <200904141656.n3EGuYuZ061174@camembert.async.caltech.edu> <0DEE58D2-97B2-4BE3-A5F9-4FAFC326EC68@cs.purdue.edu> <20090417220257.GB15700@topoi.pooq.com> Message-ID: <49E8D325.1E75.00D7.1@scires.com> There have been a lot of messages flying back and forth on this idea of adding some sort of tagged ref. I'm afraid I've gotten lost on what exactly is being proposed. Can someone please succinctly state the proposal again along with the reasoning behind why it should be done--what does this change enable us to do that we couldn't do before? Based on the messages, I'm not sure that Mika, Tony, Rodney, et al are all saying the same thing. Also, not sure I clued into the significance of the LSB value. Regards, Randy >>> 4/17/2009 6:02 PM >>> On Fri, Apr 17, 2009 at 12:54:13PM +1000, Tony Hosking wrote: > > On 15 Apr 2009, at 02:56, Mika Nystrom wrote: > > > > >I agree with what Hendrik says, but what about TYPECASE, ISTYPE, > >NARROW? Those are necessary to make it possible to pass "pointers" > >with the low-order bit set outside of unsafe code. > > > >My feeling is that if Tony can make the necessary changes, it could should > >be done immediately, and the language issues can be pushed to the > >future. But admittedly I'm biased because of the application I'm > >working on. > > I can take care of this next week. I'm in favour of trying it out before freezing the feature. That means going ahead now with an implementation, and reconsidering it in a few months. Perhaps marking it experimental with an appropriate warning message. A few months is little enough time to use it that it won't be traumatic if code that uses the new features has to be partially rewritten. -- hendrik CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Apr 19 04:58:37 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 18 Apr 2009 19:58:37 -0700 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: Your message of "Fri, 17 Apr 2009 19:07:02 EDT." <49E8D325.1E75.00D7.1@scires.com> Message-ID: <200904190258.n3J2wcfG066701@camembert.async.caltech.edu> Randy, I think Tony and I are on the same page. I've proposed that the runtime and compiler be modified as necessary to allow values of type REFANY to hold, instead of an actual memory reference, an arbitrary (wordsize-1)-bit integer. The necessary changes would only guarantee that the type safety of Modula-3 could not be subverted within any type of safe code by any manipulations involving these new REFANY values. The necessary modifications are pretty limited: a tag check for uses of ISTYPE, NARROW, TYPECASE, and TYPECODE on values known only to be REFANY. Rodney has proposed adding a type constructor (I think that's the right terminology) to permit tagged values as above to be held in variables of type other than REFANY. And our disagreement at this point I think is only on whether REFANY itself should then be allowed to hold the tagged values, as it wouldn't strictly speaking be necessary, but I contend there are good "software engineering" reasons for permitting it. There are several applications for this idea. Think of it as using all those unused values of a reference. My application is to do small integers (a la Smalltalk); Rodney wants to do efficient data structures that can either be small (max 31 bits) or pointers to something bigger. In the former case they wouldn't involve memory allocation or garbage collection. Mika "Randy Coleburn" writes: >This is a MIME message. If you are reading this text, you may want to >consider changing to a mail reader or gateway that understands how to >properly handle MIME multipart messages. > >--=__Part456DE886.0__= >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: quoted-printable > >There have been a lot of messages flying back and forth on this idea of = >adding some sort of tagged ref. I'm afraid I've gotten lost on what = >exactly is being proposed. >=20 >Can someone please succinctly state the proposal again along with the = >reasoning behind why it should be done--what does this change enable us to = >do that we couldn't do before? Based on the messages, I'm not sure that = >Mika, Tony, Rodney, et al are all saying the same thing. >=20 >Also, not sure I clued into the significance of the LSB value. >=20 >Regards, >Randy > >>>> 4/17/2009 6:02 PM >>> >On Fri, Apr 17, 2009 at 12:54:13PM +1000, Tony Hosking wrote: >>=20 >> On 15 Apr 2009, at 02:56, Mika Nystrom wrote: >>=20 >> > >> >I agree with what Hendrik says, but what about TYPECASE, ISTYPE, >> >NARROW? Those are necessary to make it possible to pass "pointers" >> >with the low-order bit set outside of unsafe code. >> > >> >My feeling is that if Tony can make the necessary changes, it could > should >> >be done immediately, and the language issues can be pushed to the >> >future. But admittedly I'm biased because of the application I'm >> >working on. >>=20 >> I can take care of this next week. > >I'm in favour of trying it out before freezing the feature. That=20 >means going ahead now with an implementation, and reconsidering it=20 >in a few months. Perhaps marking it experimental with an appropriate=20 >warning message. A few months is little enough time to use it that it=20 >won't be traumatic if code that uses the new features has to be=20 >partially rewritten. > >-- hendrik > > >CONFIDENTIALITY NOTICE: This email and any attachments are intended = >solely for the use of the named recipient(s). This e-mail may contain = >confidential and/or proprietary information of Scientific Research = >Corporation. If you are not a named recipient, you are prohibited from = >making any use of the information in the email and attachments. If you = >believe you have received this email in error, please notify the sender = >immediately and permanently delete the email, any attachments, and all = >copies thereof from any drives or storage media and destroy any printouts = >of the email or attachments. > >EXPORT COMPLIANCE NOTICE: This email and any attachments may contain = >technical data subject to U.S export restrictions under the International = >Traffic in Arms Regulations (ITAR) or the Export Administration Regulations= > (EAR). Export or transfer of this technical data and/or related = >information to any foreign person(s) or entity(ies), either within the = >U.S. or outside of the U.S., may require export authorization by the = >appropriate U.S. Government agency prior to export or transfer. In = >addition, technical data may not be exported or transferred to certain = >countries or specified designated nationals identified by U.S. embargo = >controls without prior export authorization. By accepting this email and = >any attachments, all recipients confirm that they understand and will = >comply with all applicable ITAR, EAR and embargo compliance requirements. > > >--=__Part456DE886.0__= >Content-Type: text/html; charset=US-ASCII >Content-Transfer-Encoding: quoted-printable >Content-Description: HTML > > >"> > > >
There have been a lot of messages flying back and forth on this idea = >of adding some sort of tagged ref.  I'm afraid I've gotten lost on = >what exactly is being proposed.
>
 
>
Can someone please succinctly state the proposal again along with the = >reasoning behind why it should be done--what does this change enable us to = >do that we couldn't do before?  Based on the messages, I'm not sure = >that Mika, Tony, Rodney, et al are all saying the same thing.
>
 
>
Also, not sure I clued into the significance of the LSB value.
>
 
>
Regards,
>
Randy

>>> <hendrik at topoi.pooq.com> 4/17/2009 = >6:02 PM >>>
On Fri, Apr 17, 2009 at 12:54:13PM +1000, Tony = >Hosking wrote:
>
> On 15 Apr 2009, at 02:56, Mika Nystrom = >wrote:
>
> >
> >I agree with what Hendrik says, = >but what about TYPECASE, ISTYPE,
> >NARROW?  Those are = >necessary to make it possible to pass "pointers"
> >with the = >low-order bit set outside of unsafe code.
> >
> >My = >feeling is that if Tony can make the necessary changes, it could
 &= >nbsp;           &nbs= >p;            &= >nbsp;           &nbs= >p;            &= >nbsp;            = >should
> >be done immediately, and the language issues can be = >pushed to the
> >future.  But admittedly I'm biased because = >of the application I'm
> >working on.
>
> I can take = >care of this next week.

I'm in favour of trying it out before = >freezing the feature.  That
means going ahead now with an = >implementation, and reconsidering it
in a few months.  Perhaps = >marking it experimental with an appropriate
warning message.  A = >few months is little enough time to use it that it
won't be traumatic = >if code that uses the new features has to be
partially rewritten.
R>-- hendrik

> >--=__Part456DE886.0__=-- From hendrik at topoi.pooq.com Mon Apr 20 03:21:29 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 19 Apr 2009 21:21:29 -0400 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: References: Message-ID: <20090420012129.GA22387@topoi.pooq.com> On Fri, Apr 17, 2009 at 10:57:10PM +1000, Tony Hosking wrote: > I am a little concerned about passing REFANY directly to C code as > there is no guarantee that REFANY and C pointers will always be > compatible. ADDRESS can more safely be assumed compatible. Indeed, I once read the X toolkit specs, and it was rife with small integers being packed into pointers. Apparently the toolkit resolved it not by a tag bit, but by its magnitude. There was some constant somewhere that identified which numbers were small enough to be considered not-pointers. This was a discrimination without a tag bit. Similar concept to what we're planning for the future of REFANY, but different implementation. I don't know how they figured out which pointer values were safe to treat as integers. -- hendrik From rodney.m.bates at cox.net Mon Apr 20 04:37:37 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Sun, 19 Apr 2009 21:37:37 -0500 Subject: [M3devel] HEADS UP: Release engineering, was: Re: CM3 Release In-Reply-To: <49E8D325.1E75.00D7.1@scires.com> References: <200904141656.n3EGuYuZ061174@camembert.async.caltech.edu> <0DEE58D2-97B2-4BE3-A5F9-4FAFC326EC68@cs.purdue.edu> <20090417220257.GB15700@topoi.pooq.com> <49E8D325.1E75.00D7.1@scires.com> Message-ID: <49EBDFF1.2070902@cox.net> Randy Coleburn wrote: > There have been a lot of messages flying back and forth on this idea > of adding some sort of tagged ref. I'm afraid I've gotten lost on > what exactly is being proposed. > > Can someone please succinctly state the proposal again along with the > reasoning behind why it should be done--what does this change enable > us to do that we couldn't do before? The idea is to be able to have a "pointer", but certain values of the pointer actually have the desired data right in the "pointer" itself instead of located in a separate object in the heap. If the actual value is relatively small but common, this can save a _lot_ of overhead. I have an abstract data type module that implements sets of integers that are bounded only by the range of INTEGER, in which, for small sets that actually can fit in one word minus one bit, this technique would save memory words 11-to-one. On a 64-bit machine, the savings measured in bytes would be even bigger, and the likelihood the savings would happen would also be greater. Smalltalk implementations have used this idea. In Smalltalk, there is no static typing at all, so all variables have the same universal type, which, at runtime, can hold any value of any type and be changed with every assignment. For some common values such as false, true, and relatively small integers, the value is stored right in the variable. Otherwise, the variable is a pointer to a heap object. The heap object tells what class it belongs to and has other information about the value. Since heap objects are always aligned at least modulo 2, it follows that a heap pointer always has a zero in the lsb. So a one in the lsb can be used as a flag that says the value is right in the variable. Of course, it will have been shifted left by at least a bit in that case. How Smalltalk makes this look abstractly in the language is another story and a bit tricky. Even with a static typing system in Modula-3, the reference types still have at least 2 lsb's that are always zero in a 32-bit system, where heap objects will always be aligned modulo 4. So the idea is to arrange things so that at least the lsb can be used as a tag to indicate that a value is actually stored in the variable rather than in the heap. We seem to be calling these "tagged" values, and also "small objects". With unsafe code, such values can be created and accessed by bit-twiddling. However, the garbage collector as it stands would undoubtedly be confused by improperly aligned reference type values, when they occur in fields/elements inside heap objects. The GC can presumably be easily fixed to tolerate them. But then, other operations in the language would also be broken. The code for NARROW, ISTYPE, TYPECASE, and assignments that implicitly narrow a value would undoubtedly crash if they got a misaligned value of a supposedly reference type. So such values would have to never be given to these four operations. That undermines the language's principle that the writers of unsafe code can, if they coded everything correctly, ensure that all other (safe) code can't suffer events that are not explainable by the rules of the language. So we really should do a language fix, if we are to do this. > Based on the messages, I'm not sure that Mika, Tony, Rodney, et al are > all saying the same thing. > > Also, not sure I clued into the significance of the LSB value. See above. > > Regards, > Randy > > >>> 4/17/2009 6:02 PM >>> > On Fri, Apr 17, 2009 at 12:54:13PM +1000, Tony Hosking wrote: > > > > On 15 Apr 2009, at 02:56, Mika Nystrom wrote: > > > > > > > >I agree with what Hendrik says, but what about TYPECASE, ISTYPE, > > >NARROW? Those are necessary to make it possible to pass "pointers" > > >with the low-order bit set outside of unsafe code. > > > > > >My feeling is that if Tony can make the necessary changes, it could > should > > >be done immediately, and the language issues can be pushed to the > > >future. But admittedly I'm biased because of the application I'm > > >working on. > > > > I can take care of this next week. > > I'm in favour of trying it out before freezing the feature. That > means going ahead now with an implementation, and reconsidering it > in a few months. Perhaps marking it experimental with an appropriate > warning message. A few months is little enough time to use it that it > won't be traumatic if code that uses the new features has to be > partially rewritten. > > -- hendrik > From rodney.m.bates at cox.net Mon Apr 20 04:45:49 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Sun, 19 Apr 2009 21:45:49 -0500 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: <20090420012129.GA22387@topoi.pooq.com> References: <20090420012129.GA22387@topoi.pooq.com> Message-ID: <49EBE1DD.6080809@cox.net> hendrik at topoi.pooq.com wrote: > On Fri, Apr 17, 2009 at 10:57:10PM +1000, Tony Hosking wrote: > >> I am a little concerned about passing REFANY directly to C code as >> there is no guarantee that REFANY and C pointers will always be >> compatible. ADDRESS can more safely be assumed compatible. >> > > Indeed, I once read the X toolkit specs, and it was rife with small > integers being packed into pointers. Apparently the toolkit resolved > it not by a tag bit, but by its magnitude. There was some constant > somewhere that identified which numbers were small enough to be > considered not-pointers. > > This was a discrimination without a tag bit. Similar concept to what > we're planning for the future of REFANY, but different implementation. > > I don't know how they figured out which pointer values were safe to > treat as integers. > In my more elaborate "safe" proposal, at least, the language itself does not specify anything about what the bit-encodings of tagged types are. It's an implementors' option, and the language can support whatever the implementors choose. This could be used to match the X toolkit's encoding. However, using the lsb takes advantage of the fact that heap objects must always be aligned and thus the lsb is already always zero, when it's really a heap pointer. That seems like by far the most efficient encoding. > -- hendrik > > > From jay.krell at cornell.edu Mon Apr 20 05:31:27 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 20 Apr 2009 03:31:27 +0000 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: <49EBE1DD.6080809@cox.net> References: <20090420012129.GA22387@topoi.pooq.com> <49EBE1DD.6080809@cox.net> Message-ID: Um..you know..if you just use ADDRESS instead of REFANY, doesn't that get you what you need, with no language/compiler/runtime changes? Can't you check the low bit of the address and only if it is zero, assign it to a REFANY, and that party (NARROW/ISTYPE/etc.) on the REFANY? Otherwise LOOPHOLE the ADDRESS to an INTEGER and shift it right by one? There is danger here no matter what. Who says heap pointers need any alignment? On most machines they are aligned, but on most machines (x86, AMD64) they don't need to be. x86/AMD64 may have an option for triggering "alignment exceptions" in the hardware, but I don't think any OS ever enables it. And I doubt that any application can. On Windows when dealing with "resources" (strings, bitmaps, etc., same notion as Apple), anything under 64K is considered a small integer. This gives you a system where resources can be efficiently identified by small integers, and you need to coordinate with all contributors of resources to a particular file, or less efficiently but more flexibily use strings and less/no coordination is needed. It's a nice compromise. Very little code relies on the alignment of pointers. It is a "special purpose" kind of thing. Very little code makes these "policy" decisions either. On most machines, the pointer NULL is made invalid at the hardware level by making the first page inaccessible. On most machines, a page is at least 4K. On many machines it is larger, or even variably sized. Going further and always reserving the first 64K of address space is not a big waste. It's not physical memory, it's "just" address space. (It does cost something, but not much; it costs you some reduced capacity) There is danger here no matter what but also a lot of efficiency to be gained in some scenarios. On most machines you can probably take more than 1 bit. On NT the heap allocator aligns to "two pointers", so that gives you 3 (32bit) or 4 (64bit) bits. But that's just for typical code. Modula-3 usually allocates with mmap/sbrk/VirtualAlloc, giving it at least 4K alignment, probably in reality something larger like 64K. It is the under its control to subdivide that as it sees fit. So you could arbitrarily decree that all Modula-3 objects are aligned at say 32 bytes and have 5 tag bits. It's just that at some point you start wasting space. Allocating a bunch of 10 byte objects with 32 byte alignment wastes a lot of space. But allocating a bunch of 32 or 64 or 96 etc., byte objects with 32 byte alignment wastes nothing.. On NT as well, historically, the address space was split in two. (It still is split, but details vary). The upper bit was zero for usermode, one for kernelmode. Therefore, historically, another avenue this proposal could take is to use the high bit for a tag bit. Assuming nobody is writing drivers in kernel mode. However, this 2gig/2gig split can be constraining on usermode (and kernelmode..). So there is an option at boot-time to make it 3gig/1gig -- 3gig user mode, 1 gig usermode. However that breaks any code that uses the high bit as a tag bit. Therefore executables (.exes, not .dlls) have a flag in them to indicate if they are "large address aware". If they are not, even if you boot /3gig, you still, I guess, won't ever see addresses over 2gig. If you are using tag bits, it then becomes that the upper two bits are: 00: definitely usermode 01: ambiguous 10: definitely kernelmode (can be used as a 30 bit integer) 11: definitely kernelmode (can be used as a 30 bit integer) However if you run a "large address aware" 32bit executable on a 64bit system, you get all 4gig as usermode. The kernelmode addresses are even higher than 4gig and you can't even encode them in a 32bit usermode address, which is fine. It becomes that all addresses are usermode. (This is a little mind-bending at first). Using a small struct with a type tag (possibly an entire pointer) and a separate data word also seems very viable. Very portable, very safe. Just that it grows the representation. - Jay ---------------------------------------- > Date: Sun, 19 Apr 2009 21:45:49 -0500 > From: rodney.m.bates at cox.net > To: m3devel at elegosoft.com > Subject: Re: [M3devel] fewer wrappers/more C? (or a wash?) > > hendrik at topoi.pooq.com wrote: >> On Fri, Apr 17, 2009 at 10:57:10PM +1000, Tony Hosking wrote: >> >>> I am a little concerned about passing REFANY directly to C code as >>> there is no guarantee that REFANY and C pointers will always be >>> compatible. ADDRESS can more safely be assumed compatible. >>> >> >> Indeed, I once read the X toolkit specs, and it was rife with small >> integers being packed into pointers. Apparently the toolkit resolved >> it not by a tag bit, but by its magnitude. There was some constant >> somewhere that identified which numbers were small enough to be >> considered not-pointers. >> >> This was a discrimination without a tag bit. Similar concept to what >> we're planning for the future of REFANY, but different implementation. >> >> I don't know how they figured out which pointer values were safe to >> treat as integers. >> > In my more elaborate "safe" proposal, at least, the language itself > does not specify anything about what the bit-encodings of tagged > types are. It's an implementors' option, and the language > can support whatever the implementors choose. > > This could be used to match the X toolkit's encoding. However, > using the lsb takes advantage of the fact that heap objects must > always be aligned and thus the lsb is already always zero, when > it's really a heap pointer. That seems like by far the most efficient > encoding. >> -- hendrik >> >> >> > From hosking at cs.purdue.edu Mon Apr 20 05:34:15 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 20 Apr 2009 13:34:15 +1000 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: References: <20090420012129.GA22387@topoi.pooq.com> <49EBE1DD.6080809@cox.net> Message-ID: <3130252C-D715-4C35-8F20-5D6BAB71B523@cs.purdue.edu> The proposal that Mika and I have converged on doesn't require language changes. And it works with ISTYPE, etc. Confusing REFANY with ADDRESS is a swamp. On 20 Apr 2009, at 13:31, Jay wrote: > > > Um..you know..if you just use ADDRESS instead of REFANY, doesn't > that get you what you need, with no language/compiler/runtime changes? > > Can't you check the low bit of the address and only if it is zero, > assign it to a REFANY, and that party (NARROW/ISTYPE/etc.) on the > REFANY? Otherwise LOOPHOLE the ADDRESS to an INTEGER and shift it > right by one? > > > > > There is danger here no matter what. > > > Who says heap pointers need any alignment? > > > On most machines they are aligned, but on most machines (x86, AMD64) > they don't need to be. x86/AMD64 may have an option for triggering > "alignment exceptions" in the hardware, but I don't think any OS > ever enables it. And I doubt that any application can. > > > On Windows when dealing with "resources" (strings, bitmaps, etc., > same notion as Apple), anything under 64K is considered a small > integer. > This gives you a system where resources can be efficiently > identified by small integers, and you need to coordinate with all > contributors of resources to a particular file, or less efficiently > but more flexibily use strings and less/no coordination is needed. > It's a nice compromise. > > > Very little code relies on the alignment of pointers. > It is a "special purpose" kind of thing. > > > Very little code makes these "policy" decisions either. > > > On most machines, the pointer NULL is made invalid at the hardware > level by making the first page inaccessible. On most machines, a > page is at least 4K. On many machines it is larger, or even variably > sized. > Going further and always reserving the first 64K of address space is > not a big waste. > It's not physical memory, it's "just" address space. (It does cost > something, but not much; it costs you some reduced capacity) > > > There is danger here no matter what but also a lot of efficiency to > be gained in some scenarios. > > > On most machines you can probably take more than 1 bit. > > > On NT the heap allocator aligns to "two pointers", so that gives you > 3 (32bit) or 4 (64bit) bits. But that's just for typical code. > Modula-3 usually allocates with mmap/sbrk/VirtualAlloc, giving it at > least 4K alignment, probably in reality something larger like 64K. > It is the under its control to subdivide that as it sees fit. > So you could arbitrarily decree that all Modula-3 objects are > aligned at say 32 bytes and have 5 tag bits. It's just that at some > point you start wasting space. Allocating a bunch of 10 byte objects > with 32 byte alignment wastes a lot of space. But allocating a bunch > of 32 or 64 or 96 etc., byte objects with 32 byte alignment wastes > nothing.. > > > On NT as well, historically, the address space was split in two. > (It still is split, but details vary). > The upper bit was zero for usermode, one for kernelmode. > Therefore, historically, another avenue this proposal could take is > to use the high bit for a tag bit. Assuming nobody is writing > drivers in kernel mode. > > > However, this 2gig/2gig split can be constraining on usermode (and > kernelmode..). > So there is an option at boot-time to make it 3gig/1gig -- 3gig user > mode, 1 gig usermode. > However that breaks any code that uses the high bit as a tag bit. > Therefore executables (.exes, not .dlls) have a flag in them to > indicate if they are "large address aware". If they are not, even if > you boot /3gig, you still, I guess, won't ever see addresses over > 2gig. > If you are using tag bits, it then becomes that the upper two bits > are: > 00: definitely usermode > 01: ambiguous > 10: definitely kernelmode (can be used as a 30 bit integer) > 11: definitely kernelmode (can be used as a 30 bit integer) > > > However if you run a "large address aware" 32bit executable on a > 64bit system, you get all 4gig as usermode. The kernelmode addresses > are even higher than 4gig and you can't even encode them in a 32bit > usermode address, which is fine. It becomes that all addresses are > usermode. (This is a little mind-bending at first). > > > Using a small struct with a type tag (possibly an entire pointer) > and a separate data word also seems very viable. Very portable, very > safe. Just that it grows the representation. > > > - Jay > > > > ---------------------------------------- >> Date: Sun, 19 Apr 2009 21:45:49 -0500 >> From: rodney.m.bates at cox.net >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] fewer wrappers/more C? (or a wash?) >> >> hendrik at topoi.pooq.com wrote: >>> On Fri, Apr 17, 2009 at 10:57:10PM +1000, Tony Hosking wrote: >>> >>>> I am a little concerned about passing REFANY directly to C code as >>>> there is no guarantee that REFANY and C pointers will always be >>>> compatible. ADDRESS can more safely be assumed compatible. >>>> >>> >>> Indeed, I once read the X toolkit specs, and it was rife with small >>> integers being packed into pointers. Apparently the toolkit resolved >>> it not by a tag bit, but by its magnitude. There was some constant >>> somewhere that identified which numbers were small enough to be >>> considered not-pointers. >>> >>> This was a discrimination without a tag bit. Similar concept to what >>> we're planning for the future of REFANY, but different >>> implementation. >>> >>> I don't know how they figured out which pointer values were safe to >>> treat as integers. >>> >> In my more elaborate "safe" proposal, at least, the language itself >> does not specify anything about what the bit-encodings of tagged >> types are. It's an implementors' option, and the language >> can support whatever the implementors choose. >> >> This could be used to match the X toolkit's encoding. However, >> using the lsb takes advantage of the fact that heap objects must >> always be aligned and thus the lsb is already always zero, when >> it's really a heap pointer. That seems like by far the most efficient >> encoding. >>> -- hendrik >>> >>> >>> >> From jay.krell at cornell.edu Mon Apr 20 05:36:38 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 20 Apr 2009 03:36:38 +0000 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: References: <20090420012129.GA22387@topoi.pooq.com> <49EBE1DD.6080809@cox.net> Message-ID: > Assuming nobody is writing drivers in kernel mode. I meant, "in Modula-3". Even so, the runtime could discover the tag bits at initialization time. Or more efficiently, the runtime could be built twice. But the variations available make the high bit or bits as a tag not really viable. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: rodney.m.bates at cox.net; m3devel at elegosoft.com > Date: Mon, 20 Apr 2009 03:31:27 +0000 > Subject: Re: [M3devel] fewer wrappers/more C? (or a wash?) > > > > Um..you know..if you just use ADDRESS instead of REFANY, doesn't that get you what you need, with no language/compiler/runtime changes? > > Can't you check the low bit of the address and only if it is zero, assign it to a REFANY, and that party (NARROW/ISTYPE/etc.) on the REFANY? Otherwise LOOPHOLE the ADDRESS to an INTEGER and shift it right by one? > > > > > There is danger here no matter what. > > > Who says heap pointers need any alignment? > > > On most machines they are aligned, but on most machines (x86, AMD64) they don't need to be. x86/AMD64 may have an option for triggering "alignment exceptions" in the hardware, but I don't think any OS ever enables it. And I doubt that any application can. > > > On Windows when dealing with "resources" (strings, bitmaps, etc., same notion as Apple), anything under 64K is considered a small integer. > This gives you a system where resources can be efficiently identified by small integers, and you need to coordinate with all contributors of resources to a particular file, or less efficiently but more flexibily use strings and less/no coordination is needed. It's a nice compromise. > > > Very little code relies on the alignment of pointers. > It is a "special purpose" kind of thing. > > > Very little code makes these "policy" decisions either. > > > On most machines, the pointer NULL is made invalid at the hardware level by making the first page inaccessible. On most machines, a page is at least 4K. On many machines it is larger, or even variably sized. > Going further and always reserving the first 64K of address space is not a big waste. > It's not physical memory, it's "just" address space. (It does cost something, but not much; it costs you some reduced capacity) > > > There is danger here no matter what but also a lot of efficiency to be gained in some scenarios. > > > On most machines you can probably take more than 1 bit. > > > On NT the heap allocator aligns to "two pointers", so that gives you 3 (32bit) or 4 (64bit) bits. But that's just for typical code. Modula-3 usually allocates with mmap/sbrk/VirtualAlloc, giving it at least 4K alignment, probably in reality something larger like 64K. It is the under its control to subdivide that as it sees fit. > So you could arbitrarily decree that all Modula-3 objects are aligned at say 32 bytes and have 5 tag bits. It's just that at some point you start wasting space. Allocating a bunch of 10 byte objects with 32 byte alignment wastes a lot of space. But allocating a bunch of 32 or 64 or 96 etc., byte objects with 32 byte alignment wastes nothing.. > > > On NT as well, historically, the address space was split in two. > (It still is split, but details vary). > The upper bit was zero for usermode, one for kernelmode. > Therefore, historically, another avenue this proposal could take is to use the high bit for a tag bit. Assuming nobody is writing drivers in kernel mode. > > > However, this 2gig/2gig split can be constraining on usermode (and kernelmode..). > So there is an option at boot-time to make it 3gig/1gig -- 3gig user mode, 1 gig usermode. > However that breaks any code that uses the high bit as a tag bit. > Therefore executables (.exes, not .dlls) have a flag in them to indicate if they are "large address aware". If they are not, even if you boot /3gig, you still, I guess, won't ever see addresses over 2gig. > If you are using tag bits, it then becomes that the upper two bits are: > 00: definitely usermode > 01: ambiguous > 10: definitely kernelmode (can be used as a 30 bit integer) > 11: definitely kernelmode (can be used as a 30 bit integer) > > > However if you run a "large address aware" 32bit executable on a 64bit system, you get all 4gig as usermode. The kernelmode addresses are even higher than 4gig and you can't even encode them in a 32bit usermode address, which is fine. It becomes that all addresses are usermode. (This is a little mind-bending at first). > > > Using a small struct with a type tag (possibly an entire pointer) and a separate data word also seems very viable. Very portable, very safe. Just that it grows the representation. > > > - Jay > > > > ---------------------------------------- >> Date: Sun, 19 Apr 2009 21:45:49 -0500 >> From: rodney.m.bates at cox.net >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] fewer wrappers/more C? (or a wash?) >> >> hendrik at topoi.pooq.com wrote: >>> On Fri, Apr 17, 2009 at 10:57:10PM +1000, Tony Hosking wrote: >>> >>>> I am a little concerned about passing REFANY directly to C code as >>>> there is no guarantee that REFANY and C pointers will always be >>>> compatible. ADDRESS can more safely be assumed compatible. >>>> >>> >>> Indeed, I once read the X toolkit specs, and it was rife with small >>> integers being packed into pointers. Apparently the toolkit resolved >>> it not by a tag bit, but by its magnitude. There was some constant >>> somewhere that identified which numbers were small enough to be >>> considered not-pointers. >>> >>> This was a discrimination without a tag bit. Similar concept to what >>> we're planning for the future of REFANY, but different implementation. >>> >>> I don't know how they figured out which pointer values were safe to >>> treat as integers. >>> >> In my more elaborate "safe" proposal, at least, the language itself >> does not specify anything about what the bit-encodings of tagged >> types are. It's an implementors' option, and the language >> can support whatever the implementors choose. >> >> This could be used to match the X toolkit's encoding. However, >> using the lsb takes advantage of the fact that heap objects must >> always be aligned and thus the lsb is already always zero, when >> it's really a heap pointer. That seems like by far the most efficient >> encoding. >>> -- hendrik >>> >>> >>> >> From jay.krell at cornell.edu Mon Apr 20 05:46:30 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 20 Apr 2009 03:46:30 +0000 Subject: [M3devel] explanation of CheckLoadTracedRef? Message-ID: - What does CheckLoadTracedRef and co. do? - Can the compiler be smarter? Easily/effectively? I'm just reading code to understand the object model.. and I see like this: b.F1(1); (* line 60 *) b.F2(2); .stabn 68,0,60,LM17-LFBB2 (",60," means line 60) LM17: movl _MM_Main+584, %esi testl %esi, %esi je L13 testb $64, -2(%esi) je L13 movl %esi, (%esp) call _RTHooks__CheckLoadTracedRef L13: movl (%esi), %eax movl (%eax), %ebx movl $1, 4(%esp) movl %esi, (%esp) call *%ebx .stabn 68,0,61,LM18-LFBB2 (",61," means line 61) LM18: movl _MM_Main+584, %ebx testl %ebx, %ebx je L14 testb $64, -2(%ebx) je L14 movl %ebx, (%esp) call _RTHooks__CheckLoadTracedRef L14: movl (%ebx), %eax movl 4(%eax), %esi movl $2, 4(%esp) movl %ebx, (%esp) call *%esi Does one really need to "check" pointers so often? You know, like twice in a row? Granted, there is a call in between. I understand, that one call could have done "anything". Ok, here is another case cm3 -O, cm3cg -O3, no intervening function call, still two checks: T3 = OBJECT a: INTEGER; END; c := NEW(T3); RTIO.PutInt(c.a + c.a); .stabn 68,0,63,LM20-LFBB2 LM20: movl _MM_Main+588, %esi testl %esi, %esi je L15 testb $64, -2(%esi) je L15 movl %esi, (%esp) call _RTHooks__CheckLoadTracedRef L15: movl _MM_Main+588, %ebx testl %ebx, %ebx je L16 testb $64, -2(%ebx) je L16 movl %ebx, (%esp) call _RTHooks__CheckLoadTracedRef L16: movl $0, 4(%esp) movl 4(%ebx), %eax addl 4(%esi), %eax movl %eax, (%esp) call _RTIO__PutInt I'm of two minds on optimizing though. Do it. Don't it. I don't like debugging optimize code. Nor do I want to waste time having the compiler make the code less debuggable. But when I look at the code and how bad the code quality is, and that it could be substantially better without sacrificing debuging... This example is somewhat contrived, but the code seems like 33% waste. Eventually that much bloat is going to cost in terms of I/O in the assembly, linker, paging it in at runtime, and even a little extra to run it. "Now that I understand things somewhat better.." How bad/unportable was it the previous way, the VM-synchronized way? Can the checks only be generated for calls to extern functions? When I write C wrappers, am I missing checks? (I can check, maybe the checks are generated). Are they missing sometimes with regard to X Windows? I think I understand just barely some of what is going on. That writes through pointers need to be checked. Because objects can move around. But moving objects doesn't update the references, but instead marks pages as different? (In the VM-synchronized world, moving an object would mark its original page invalid, triggering a page fault upon subsequent access, which is handled by referencing the new location and maybe updating the old pointer). ??? Something like that ??? - Jay From jay.krell at cornell.edu Mon Apr 20 05:48:00 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 20 Apr 2009 03:48:00 +0000 Subject: [M3devel] explanation of CheckLoadTracedRef? Message-ID: - What does CheckLoadTracedRef and co. do? - Can the compiler be smarter? Easily/effectively? I'm just reading code to understand the object model.. and I see like this: b.F1(1); (* line 60 *) b.F2(2); .stabn 68,0,60,LM17-LFBB2 (",60," means line 60) LM17: movl _MM_Main+584, %esi testl %esi, %esi je L13 testb $64, -2(%esi) je L13 movl %esi, (%esp) call _RTHooks__CheckLoadTracedRef L13: movl (%esi), %eax movl (%eax), %ebx movl $1, 4(%esp) movl %esi, (%esp) call *%ebx .stabn 68,0,61,LM18-LFBB2 (",61," means line 61) LM18: movl _MM_Main+584, %ebx testl %ebx, %ebx je L14 testb $64, -2(%ebx) je L14 movl %ebx, (%esp) call _RTHooks__CheckLoadTracedRef L14: movl (%ebx), %eax movl 4(%eax), %esi movl $2, 4(%esp) movl %ebx, (%esp) call *%esi Does one really need to "check" pointers so often? You know, like twice in a row? Granted, there is a call in between. I understand, that one call could have done "anything". Ok, here is another case cm3 -O, cm3cg -O3, no intervening function call, still two checks: T3 = OBJECT a: INTEGER; END; c := NEW(T3); RTIO.PutInt(c.a + c.a); .stabn 68,0,63,LM20-LFBB2 LM20: movl _MM_Main+588, %esi testl %esi, %esi je L15 testb $64, -2(%esi) je L15 movl %esi, (%esp) call _RTHooks__CheckLoadTracedRef L15: movl _MM_Main+588, %ebx testl %ebx, %ebx je L16 testb $64, -2(%ebx) je L16 movl %ebx, (%esp) call _RTHooks__CheckLoadTracedRef L16: movl $0, 4(%esp) movl 4(%ebx), %eax addl 4(%esi), %eax movl %eax, (%esp) call _RTIO__PutInt I'm of two minds on optimizing though. Do it. Don't it. I don't like debugging optimize code. Nor do I want to waste time having the compiler make the code less debuggable. But when I look at the code and how bad the code quality is, and that it could be substantially better without sacrificing debuging... This example is somewhat contrived, but the code seems like 33% waste. Eventually that much bloat is going to cost in terms of I/O in the assembly, linker, paging it in at runtime, and even a little extra to run it. "Now that I understand things somewhat better.." How bad/unportable was it the previous way, the VM-synchronized way? Can the checks only be generated for calls to extern functions? When I write C wrappers, am I missing checks? (I can check, maybe the checks are generated). Are they missing sometimes with regard to X Windows? I think I understand just barely some of what is going on. That writes through pointers need to be checked. Because objects can move around. But moving objects doesn't update the references, but instead marks pages as different? (In the VM-synchronized world, moving an object would mark its original page invalid, triggering a page fault upon subsequent access, which is handled by referencing the new location and maybe updating the old pointer). ??? Something like that ??? - Jay From jay.krell at cornell.edu Mon Apr 20 05:47:09 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 20 Apr 2009 03:47:09 +0000 Subject: [M3devel] explanation of CheckLoadTracedRef? Message-ID: - What does CheckLoadTracedRef and co. do? - Can the compiler be smarter? Easily/effectively? I'm just reading code to understand the object model.. and I see like this: b.F1(1); (* line 60 *) b.F2(2); .stabn 68,0,60,LM17-LFBB2 (",60," means line 60) LM17: movl _MM_Main+584, %esi testl %esi, %esi je L13 testb $64, -2(%esi) je L13 movl %esi, (%esp) call _RTHooks__CheckLoadTracedRef L13: movl (%esi), %eax movl (%eax), %ebx movl $1, 4(%esp) movl %esi, (%esp) call *%ebx .stabn 68,0,61,LM18-LFBB2 (",61," means line 61) LM18: movl _MM_Main+584, %ebx testl %ebx, %ebx je L14 testb $64, -2(%ebx) je L14 movl %ebx, (%esp) call _RTHooks__CheckLoadTracedRef L14: movl (%ebx), %eax movl 4(%eax), %esi movl $2, 4(%esp) movl %ebx, (%esp) call *%esi Does one really need to "check" pointers so often? You know, like twice in a row? Granted, there is a call in between. I understand, that one call could have done "anything". Ok, here is another case cm3 -O, cm3cg -O3, no intervening function call, still two checks: T3 = OBJECT a: INTEGER; END; c := NEW(T3); RTIO.PutInt(c.a + c.a); .stabn 68,0,63,LM20-LFBB2 LM20: movl _MM_Main+588, %esi testl %esi, %esi je L15 testb $64, -2(%esi) je L15 movl %esi, (%esp) call _RTHooks__CheckLoadTracedRef L15: movl _MM_Main+588, %ebx testl %ebx, %ebx je L16 testb $64, -2(%ebx) je L16 movl %ebx, (%esp) call _RTHooks__CheckLoadTracedRef L16: movl $0, 4(%esp) movl 4(%ebx), %eax addl 4(%esi), %eax movl %eax, (%esp) call _RTIO__PutInt I'm of two minds on optimizing though. Do it. Don't it. I don't like debugging optimize code. Nor do I want to waste time having the compiler make the code less debuggable. But when I look at the code and how bad the code quality is, and that it could be substantially better without sacrificing debuging... This example is somewhat contrived, but the code seems like 33% waste. Eventually that much bloat is going to cost in terms of I/O in the assembly, linker, paging it in at runtime, and even a little extra to run it. "Now that I understand things somewhat better.." How bad/unportable was it the previous way, the VM-synchronized way? Can the checks only be generated for calls to extern functions? When I write C wrappers, am I missing checks? (I can check, maybe the checks are generated). Are they missing sometimes with regard to X Windows? I think I understand just barely some of what is going on. That writes through pointers need to be checked. Because objects can move around. But moving objects doesn't update the references, but instead marks pages as different? (In the VM-synchronized world, moving an object would mark its original page invalid, triggering a page fault upon subsequent access, which is handled by referencing the new location and maybe updating the old pointer). ??? Something like that ??? - Jay From hosking at cs.purdue.edu Mon Apr 20 06:55:13 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 20 Apr 2009 14:55:13 +1000 Subject: [M3devel] explanation of CheckLoadTracedRef? In-Reply-To: References: Message-ID: On 20 Apr 2009, at 13:47, Jay wrote: > > > - What does CheckLoadTracedRef and co. do? It makes sure that when loading a reference from the heap we make sure that reference is black (i.e., not gray). The invariant is that mutator threads should never be exposed to pointers to old space while the incrememtal collector is executing. > - Can the compiler be smarter? It's tricky. We'd like to eliminate two checks on the same field. So long as we can ensure that no GC flip occurs between the first check and the second then yes. If not then we must keep both checks. > Easily/effectively? > I'm just reading code to understand the object model.. > and I see like this: > b.F1(1); (* line 60 *) > b.F2(2); > > > > .stabn 68,0,60,LM17-LFBB2 (",60," means line 60) > LM17: > movl _MM_Main+584, %esi > testl %esi, %esi > je L13 > testb $64, -2(%esi) > je L13 > movl %esi, (%esp) > call _RTHooks__CheckLoadTracedRef > L13: > movl (%esi), %eax > movl (%eax), %ebx > movl $1, 4(%esp) > movl %esi, (%esp) > call *%ebx > .stabn 68,0,61,LM18-LFBB2 (",61," means line 61) > LM18: > movl _MM_Main+584, %ebx > testl %ebx, %ebx > je L14 > testb $64, -2(%ebx) > je L14 > movl %ebx, (%esp) > call _RTHooks__CheckLoadTracedRef > L14: > movl (%ebx), %eax > movl 4(%eax), %esi > movl $2, 4(%esp) > movl %ebx, (%esp) > call *%esi > > > Does one really need to "check" pointers so often? > You know, like twice in a row? > Granted, there is a call in between. > I understand, that one call could have done "anything". > > > Ok, here is another case cm3 -O, cm3cg -O3, no intervening function > call, still two checks: > > > T3 = OBJECT > a: INTEGER; > END; > > > c := NEW(T3); > > > RTIO.PutInt(c.a + c.a); > > > .stabn 68,0,63,LM20-LFBB2 > LM20: > movl _MM_Main+588, %esi > testl %esi, %esi > je L15 > testb $64, -2(%esi) > je L15 > movl %esi, (%esp) > call _RTHooks__CheckLoadTracedRef > L15: > movl _MM_Main+588, %ebx > testl %ebx, %ebx > je L16 > testb $64, -2(%ebx) > je L16 > movl %ebx, (%esp) > call _RTHooks__CheckLoadTracedRef > L16: > movl $0, 4(%esp) > movl 4(%ebx), %eax > addl 4(%esi), %eax > movl %eax, (%esp) > call _RTIO__PutInt > > > I'm of two minds on optimizing though. > Do it. Don't it. > > I don't like debugging optimize code. > Nor do I want to waste time having the compiler make the code less > debuggable. > But when I look at the code and how bad the code quality is, and > that it could be substantially > better without sacrificing debuging... > > > This example is somewhat contrived, but the code seems like 33% waste. > Eventually that much bloat is going to cost in terms of I/O in the > assembly, linker, > paging it in at runtime, and even a little extra to run it. It would be useful to see what the overhead actually is. You can do this by changing Host.doIncGC to FALSE instead of TRUE in m3front. There is a flag that will do this: -NoIncGC. I forget how we actually pass those flags to the front-end from m3build. I think something like: M3Option("-NoIncGC") > "Now that I understand things somewhat better.." > How bad/unportable was it the previous way, the VM-synchronized way? Not compatible with system threading. > Can the checks only be generated for calls to extern functions? Huh? Not pertinent. > When I write C wrappers, am I missing checks? > (I can check, maybe the checks are generated). > Are they missing sometimes with regard to X Windows? You should *never* access a field in the heap in C code! All accesses to traced fields in the heap must take place in Modula-3. Otherwise things will break! C wrappers should not do anything other than forward calls to C library calls. They should not perform heap accesses. > I think I understand just barely some of what is going on. > That writes through pointers need to be checked. Yes, writes of references to traced fields in the heap need the checks too for generational GC. > Because objects can move around. > But moving objects doesn't update the references, but instead > marks pages as different? (In the VM-synchronized world, > moving an object would mark its original page invalid, triggering > a page fault upon subsequent access, which is handled by referencing > the new location and maybe updating the old pointer). I think you are confusing incremental and incremental GC. > > > > ??? Something like that ??? > > > - Jay From jay.krell at cornell.edu Mon Apr 20 10:47:21 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 20 Apr 2009 08:47:21 +0000 Subject: [M3devel] crummy ThreadWin32.m3 implementation? Message-ID: Um, ThreadWin32.m3 looks pretty crummy -- all LockMutex calls bottleneck on one giant lock. .v0 and .v1 aren't bad this way. - Jay From jay.krell at cornell.edu Mon Apr 20 11:11:17 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 20 Apr 2009 09:11:17 +0000 Subject: [M3devel] crummy ThreadWin32.m3 implementation? In-Reply-To: References: Message-ID: Searching the web...finds this which seems very relevant: http://birrell.org/andrew/papers/ImplementingCVs.pdf - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 20 Apr 2009 08:47:21 +0000 > Subject: [M3devel] crummy ThreadWin32.m3 implementation? > > > Um, ThreadWin32.m3 looks pretty crummy -- all LockMutex calls bottleneck on one giant lock. .v0 and .v1 aren't bad this way. > > > - Jay From rodney.m.bates at cox.net Mon Apr 20 15:35:02 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 20 Apr 2009 08:35:02 -0500 Subject: [M3devel] Resummary of tagged reference proposals Message-ID: <49EC7A06.5040403@cox.net> I am going to try to resummarize the various proposals, as their description has now gotten rather scattered around in all the discussion. --------------------------------------------------------------------- Mika's proposal (I'll call it the "minimalist" propsal): Mika, please correct me if I misrepresent what you are proposing. There are no language changes at all, only changes in implementation. The implementation of the existing type REFANY, and no other type, allows it to have values whose lsb is nonzero. ISTYPE, NARROW, TYPECASE, and narrowing assignments, when and only when applied to REFANY, have their generated code fixed so it checks the lsb, and, if it is nonzero, consider the runtime type check to have failed, in whichever way such a failure is already handled. The only effect is to liberalize the rules unsafe code must follow to avoid undermining the safety of safe code. Only unsafe code can create or detect these misaligned values. Today, it must never return them in a variable of any reference type, lest the four narrowing operations unexpectedly crash. In the proposal, unsafe code would be able to return such values in variables of type REFANY, but not any other type. Already, the only things safe code can do with values of REFANY are copy them around (which would happily work on misaligned values) and narrow them. With the implementation of the narrowing operations changed, misaligned values can never escape from REFANY variables. In safe code, there is no way to detect whether a value of type REFANY is misaligned. Doing it by elimination, trying to narrow to any proper subtype of REFANY, is impractical, as there are an unbounded number of REF types to eliminate. If there is more than one abstract data type that uses this mechanism, client code can not be prevented from mixing up values from the different abstractions. (Perhaps this could be fixed by a language change allowing BRANDED REFANY?) --------------------------------------------------------------------- My (Rodney's) "safe" proposal: There is a new type named TAGABLE. It is a subrange of INTEGER, whose bounds are implementation-defined. These can be queried by the existing FIRST and LAST functions. Similar to CARDINAL, it has all the properties of a subrange type but is not the same type as the corresponding subrange. There is a new type constructor TAGGED. If T is any traced or object type, including branded and opaque types, then TAGGED T is a new type whose value set is the union of the value sets of T and TAGABLE. Moreover, TAGABLE <: TAGGED T T <: TAGGED T. IF T # U, then TAGGED T and TAGGED U are not the same type and have no subtype or assignability relation to each other. The semantics of ISTYPE, NARROW, TYPECASE, and assignability of a type to a type are generalized so that their to-be-narrowed operand can have a tagged type, and if it does, their to-be-narrowed-to type can be TAGABLE. Comments: Making TAGGED T have no relation to TAGGED U avoids a lot of really complicated type equality and subtype rules. The former would be a drastic departure from the current state of Modula-3. It is up to the implementation to decide the bit representation of tagged types, including how values of TAGABLE will be distinguished from reference values. Though the language would not require it, most likely a word the same size as a pointer will be used. Using the lsb as the tag bit is an efficient encoding, because in any currently conceivable machine, it will be zero for all pointers to heap objects. There is no reason pickles would have to use the same representation as compiler-generated code. The implementation should define the bounds of TAGABLE to be whatever it can fit in its representation, after removing the values that are true pointers. If the lsb is used as a tag, this will no doubt be a 31-bit integer on a 32-bit machine and 63-bit integer on a 64-bit machine. The language wouldn't even specify whether it is signed, although somehow unsigned seems nice to me. If it is unsigned and the suggested encodings are used, TAGABLE would have the same bounds as CARDINAL, but it really should be a separate type, so as not to overconstrain the implementation. If T is branded, then the effects of branding will propagate to TAGGED T, thus allowing independent abstract data types to ensure each one's values can't be mixed up with the other's. This will statically detect misuses by client code. However, TAGGED T is not a branded type. If T is an opaque type, then TAGGED T can be used to combine the space efficiency of tagging with the ability of an opaque type to reveal some but not all of its properties. To use this, client code will have to narrow a value first, since access to methods/fields could not have a definable meaning for a value in TAGABLE. On the other hand, T could be an opaque subtype of REFANY, thus revealing almost nothing about TAGGED T to clients. This would give tagged types the existing ability of ensuring statically, that the code in a revealed context will never get TAGGED REFANY, thus avoiding extra runtime type checks. From rodney.m.bates at cox.net Mon Apr 20 16:06:12 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 20 Apr 2009 09:06:12 -0500 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: References: <20090420012129.GA22387@topoi.pooq.com> <49EBE1DD.6080809@cox.net> Message-ID: <49EC8154.20909@cox.net> Jay wrote: > > Um..you know..if you just use ADDRESS instead of REFANY, doesn't that get you what you need, with no language/compiler/runtime changes? > > Can't you check the low bit of the address and only if it is zero, assign it to a REFANY, and that party (NARROW/ISTYPE/etc.) on the REFANY? Otherwise LOOPHOLE the ADDRESS to an INTEGER and shift it right by one? > > > > > There is danger here no matter what. > > > Who says heap pointers need any alignment? > They need alignment for the conjunction of the following two reasons: 1. Some heap objects have to be aligned because they contain a field or element that must be aligned. Examples are an open array of INTEGER and a linked-list node that contains a pointer. And, 2. It is impractically overcomplicated to build a heap allocator/garbage collector that handles a mix of aligned and unaligned heap objects. Even if one did so, there would probably be no benefit, or maybe memory use might even get worse, on account of increased fragmentation. So heap managers give all objects the strictest alignment any object could require. > > > On most machines they are aligned, but on most machines (x86, AMD64) they don't need to be. x86/AMD64 may have an option for triggering "alignment exceptions" in the hardware, but I don't think any OS ever enables it. And I doubt that any application can. > > > On Windows when dealing with "resources" (strings, bitmaps, etc., same notion as Apple), anything under 64K is considered a small integer. > This gives you a system where resources can be efficiently identified by small integers, and you need to coordinate with all contributors of resources to a particular file, or less efficiently but more flexibily use strings and less/no coordination is needed. It's a nice compromise. > > > Very little code relies on the alignment of pointers. > It is a "special purpose" kind of thing. > > > Very little code makes these "policy" decisions either. > > > On most machines, the pointer NULL is made invalid at the hardware level by making the first page inaccessible. On most machines, a page is at least 4K. On many machines it is larger, or even variably sized. > Going further and always reserving the first 64K of address space is not a big waste. > It's not physical memory, it's "just" address space. (It does cost something, but not much; it costs you some reduced capacity) > > > There is danger here no matter what but also a lot of efficiency to be gained in some scenarios. > > > On most machines you can probably take more than 1 bit. > > > On NT the heap allocator aligns to "two pointers", so that gives you 3 (32bit) or 4 (64bit) bits. But that's just for typical code. Modula-3 usually allocates with mmap/sbrk/VirtualAlloc, giving it at least 4K alignment, probably in reality something larger like 64K. It is the under its control to subdivide that as it sees fit. > So you could arbitrarily decree that all Modula-3 objects are aligned at say 32 bytes and have 5 tag bits. It's just that at some point you start wasting space. Allocating a bunch of 10 byte objects with 32 byte alignment wastes a lot of space. But allocating a bunch of 32 or 64 or 96 etc., byte objects with 32 byte alignment wastes nothing.. > > > On NT as well, historically, the address space was split in two. > (It still is split, but details vary). > The upper bit was zero for usermode, one for kernelmode. > Therefore, historically, another avenue this proposal could take is to use the high bit for a tag bit. Assuming nobody is writing drivers in kernel mode. > > > However, this 2gig/2gig split can be constraining on usermode (and kernelmode..). > So there is an option at boot-time to make it 3gig/1gig -- 3gig user mode, 1 gig usermode. > However that breaks any code that uses the high bit as a tag bit. > Therefore executables (.exes, not .dlls) have a flag in them to indicate if they are "large address aware". If they are not, even if you boot /3gig, you still, I guess, won't ever see addresses over 2gig. > If you are using tag bits, it then becomes that the upper two bits are: > 00: definitely usermode > 01: ambiguous > 10: definitely kernelmode (can be used as a 30 bit integer) > 11: definitely kernelmode (can be used as a 30 bit integer) > > > However if you run a "large address aware" 32bit executable on a 64bit system, you get all 4gig as usermode. The kernelmode addresses are even higher than 4gig and you can't even encode them in a 32bit usermode address, which is fine. It becomes that all addresses are usermode. (This is a little mind-bending at first). > > > Using a small struct with a type tag (possibly an entire pointer) and a separate data word also seems very viable. Very portable, very safe. Just that it grows the representation. > > > - Jay > > > > ---------------------------------------- > >> Date: Sun, 19 Apr 2009 21:45:49 -0500 >> From: rodney.m.bates at cox.net >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] fewer wrappers/more C? (or a wash?) >> >> hendrik at topoi.pooq.com wrote: >> >>> On Fri, Apr 17, 2009 at 10:57:10PM +1000, Tony Hosking wrote: >>> >>> >>>> I am a little concerned about passing REFANY directly to C code as >>>> there is no guarantee that REFANY and C pointers will always be >>>> compatible. ADDRESS can more safely be assumed compatible. >>>> >>>> >>> Indeed, I once read the X toolkit specs, and it was rife with small >>> integers being packed into pointers. Apparently the toolkit resolved >>> it not by a tag bit, but by its magnitude. There was some constant >>> somewhere that identified which numbers were small enough to be >>> considered not-pointers. >>> >>> This was a discrimination without a tag bit. Similar concept to what >>> we're planning for the future of REFANY, but different implementation. >>> >>> I don't know how they figured out which pointer values were safe to >>> treat as integers. >>> >>> >> In my more elaborate "safe" proposal, at least, the language itself >> does not specify anything about what the bit-encodings of tagged >> types are. It's an implementors' option, and the language >> can support whatever the implementors choose. >> >> This could be used to match the X toolkit's encoding. However, >> using the lsb takes advantage of the fact that heap objects must >> always be aligned and thus the lsb is already always zero, when >> it's really a heap pointer. That seems like by far the most efficient >> encoding. >> >>> -- hendrik >>> >>> >>> >>> From hendrik at topoi.pooq.com Mon Apr 20 16:53:20 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 20 Apr 2009 10:53:20 -0400 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: <49EBE1DD.6080809@cox.net> References: <20090420012129.GA22387@topoi.pooq.com> <49EBE1DD.6080809@cox.net> Message-ID: <20090420145320.GA23397@topoi.pooq.com> On Sun, Apr 19, 2009 at 09:45:49PM -0500, Rodney M. Bates wrote: > hendrik at topoi.pooq.com wrote: > >On Fri, Apr 17, 2009 at 10:57:10PM +1000, Tony Hosking wrote: > > > >>I am a little concerned about passing REFANY directly to C code as > >>there is no guarantee that REFANY and C pointers will always be > >>compatible. ADDRESS can more safely be assumed compatible. > >> > > > >Indeed, I once read the X toolkit specs, and it was rife with small > >integers being packed into pointers. Apparently the toolkit resolved > >it not by a tag bit, but by its magnitude. There was some constant > >somewhere that identified which numbers were small enough to be > >considered not-pointers. > > > >This was a discrimination without a tag bit. Similar concept to what > >we're planning for the future of REFANY, but different implementation. > > > >I don't know how they figured out which pointer values were safe to > >treat as integers. > > > In my more elaborate "safe" proposal, at least, the language itself > does not specify anything about what the bit-encodings of tagged > types are. It's an implementors' option, and the language > can support whatever the implementors choose. > > This could be used to match the X toolkit's encoding. However, > using the lsb takes advantage of the fact that heap objects must > always be aligned and thus the lsb is already always zero, when > it's really a heap pointer. That seems like by far the most efficient > encoding. The X toolkit was set up to be called from C, and the small integers were just parameters to a C function, or else pointers, whatever was more convenient. They had a specific range of small integers (which was machine-dependent as far as I can tell), and the whole convention seems to have been set up for coding convenience. I don't know how the limit on "small" inetgers was decided. The LSB trick is what I would recommend for us. I was just reinforcing the hopelessless of assuming we can make REFANY match C conventions. I suspect there are too many different ones. -- hendrik From jay.krell at cornell.edu Mon Apr 20 16:51:52 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 20 Apr 2009 14:51:52 +0000 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: <49EC8154.20909@cox.net> References: <20090420012129.GA22387@topoi.pooq.com> <49EBE1DD.6080809@cox.net> <49EC8154.20909@cox.net> Message-ID: > 1. Some heap objects have to be aligned because they contain a field or > element > that must be aligned. Examples are an open array of INTEGER and a > linked-list node that contains a pointer. And, And on every system there exist fields/elements that really require alignment? The following works fine for me..x86 tends to be very lax on requiring any alignment. #include int main() { unsigned char a[20]; unsigned i; for (i = 0 ; i < 20 ; ++i) a[i] = (unsigned char)i; for (i = 0 ; i < 8 ; ++i) printf("%x\n", *(unsigned*)&a[i]); for (i = 0 ; i < 8 ; ++i) printf("%f\n", *(double*)&a[i]); return 0; } I think we only care about Modula-3 heap allocated pointers, so what folks do in their C code doesn't matter. We can even introduce and depend upon higher alignment than the hardware requires or the underlying allocator provides. I realize that SPARC, MIPS, maybe Alpha, ARM?, IA64, and probably others, do have hardware-enforced alignment requirements. (Having debugged some of them.) I'm mostly just causing trouble. The proposals are all somewhat dangerous, but in reality they are ok, and can buy significant efficiencies in certain applications. Alignment is normal, even on x86. Btw, presumably on a 64 bit system, you can get a 32bit float in one of these things. - Jay From hendrik at topoi.pooq.com Mon Apr 20 16:57:48 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 20 Apr 2009 10:57:48 -0400 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: References: <20090420012129.GA22387@topoi.pooq.com> <49EBE1DD.6080809@cox.net> Message-ID: <20090420145748.GB23397@topoi.pooq.com> On Mon, Apr 20, 2009 at 03:36:38AM +0000, Jay wrote: > > > Assuming nobody is writing drivers in kernel mode. > > I meant, "in Modula-3". Hasn't an operating system been written in Modula 3? But not NT, I guess. -- hendrik From jay.krell at cornell.edu Mon Apr 20 17:06:41 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 20 Apr 2009 15:06:41 +0000 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: <20090420145748.GB23397@topoi.pooq.com> References: <20090420012129.GA22387@topoi.pooq.com> <49EBE1DD.6080809@cox.net> <20090420145748.GB23397@topoi.pooq.com> Message-ID: Yes, SPIN. - Jay ---------------------------------------- > Date: Mon, 20 Apr 2009 10:57:48 -0400 > From: hendrik@ >>> Assuming nobody is writing drivers in kernel mode. >> >> I meant, "in Modula-3". > > Hasn't an operating system been written in Modula 3? > But not NT, I guess. > > -- hendrik From mika at async.caltech.edu Mon Apr 20 17:31:32 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 20 Apr 2009 08:31:32 -0700 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: Your message of "Mon, 20 Apr 2009 14:51:52 -0000." Message-ID: <200904201531.n3KFVWLl065496@camembert.async.caltech.edu> I just wanted to point out that the discussion about X pointers is introducing a large red herring into the discussion about tagged REFANYs. The tagged REFANY idea just depends on Modula-3's own heap allocator's returning aligned addresses. If they're not aligned, you can't tag the REFANY. If they are, you can, because the only thing ever held by a REFANY is a Modula-3-heap-allocated address, NIL, or a tagged value. X pointers should clearly be passed as ADDRESS, not as REFANY. Completely different issue. Mika Jay writes: > >> 1. Some heap objects have to be aligned because they contain a field or >> element >> that must be aligned. Examples are an open array of INTEGER and a >> linked-list node that contains a pointer. And, > > >And on every system there exist fields/elements that really require alignment? > > >The following works fine for me..x86 tends to be very lax on requiring any alignment. > > >#include > > >int main() >{ >unsigned char a[20]; >unsigned i; > > >for (i = 0 ; i < 20 ; ++i) > a[i] = (unsigned char)i; > > >for (i = 0 ; i < 8 ; ++i) > printf("%x\n", *(unsigned*)&a[i]); > >for (i = 0 ; i < 8 ; ++i) > printf("%f\n", *(double*)&a[i]); > >return 0; >} > > >I think we only care about Modula-3 heap allocated pointers, so what >folks do in their C code doesn't matter. >We can even introduce and depend upon higher alignment than the hardware requires >or the underlying allocator provides. > > >I realize that SPARC, MIPS, maybe Alpha, ARM?, IA64, and probably others, >do have hardware-enforced alignment requirements. >(Having debugged some of them.) > > >I'm mostly just causing trouble. >The proposals are all somewhat dangerous, but in reality they are ok, >and can buy significant efficiencies in certain applications. >Alignment is normal, even on x86. > > >Btw, presumably on a 64 bit system, you can get a 32bit float in one of these things. > > > > - Jay From hosking at cs.purdue.edu Mon Apr 20 23:53:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Apr 2009 07:53:57 +1000 Subject: [M3devel] crummy ThreadWin32.m3 implementation? In-Reply-To: References: Message-ID: <14FDB4AD-26AA-43B0-BD25-925C596452EF@cs.purdue.edu> Also, note that win32 now supports CVs directly! No need for semaphores. On 20 Apr 2009, at 19:11, Jay wrote: > > Searching the web...finds this which seems very relevant: > > http://birrell.org/andrew/papers/ImplementingCVs.pdf > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Mon, 20 Apr 2009 08:47:21 +0000 >> Subject: [M3devel] crummy ThreadWin32.m3 implementation? >> >> >> Um, ThreadWin32.m3 looks pretty crummy -- all LockMutex calls >> bottleneck on one giant lock. .v0 and .v1 aren't bad this way. >> >> >> - Jay From hosking at cs.purdue.edu Tue Apr 21 03:53:05 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Apr 2009 11:53:05 +1000 Subject: [M3devel] Latest ThreadPThread Message-ID: <8510055B-CBC6-4A02-BAFA-B26AF9A827EC@cs.purdue.edu> Jay, I have some questions about why you have moved the Activation declaration to C code. I'm not sure what this gains, and I have strong reasons for wanting to keep it in Modula-3. I'd like to revert these most recent changes if possible, unless you can say why you want to retain them. Perhaps you have a good reason, but I remain to be convinced. -- Tony Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Apr 21 03:58:31 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Apr 2009 11:58:31 +1000 Subject: [M3devel] Latest ThreadPThread In-Reply-To: <8510055B-CBC6-4A02-BAFA-B26AF9A827EC@cs.purdue.edu> References: <8510055B-CBC6-4A02-BAFA-B26AF9A827EC@cs.purdue.edu> Message-ID: Jay, I am curious why you are using atomic operations for INC and DEC of inCritical (on WIN32/WIN64). In general, they are protected by an appropriate lock, so I don't know what the need is. Are you trying to move towards lock-free implementations of some of the thread primitives? 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 21 Apr 2009, at 11:53, Tony Hosking wrote: > Jay, > > I have some questions about why you have moved the Activation > declaration to C code. I'm not sure what this gains, and I have > strong reasons for wanting to keep it in Modula-3. I'd like to > revert these most recent changes if possible, unless you can say why > you want to retain them. Perhaps you have a good reason, but I > remain to be convinced. > > -- Tony > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Apr 21 04:51:18 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Apr 2009 12:51:18 +1000 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <49EC7A06.5040403@cox.net> References: <49EC7A06.5040403@cox.net> Message-ID: I note that Mika's proposal is no less safe than Rodney's. On 20 Apr 2009, at 23:35, Rodney M. Bates wrote: > I am going to try to resummarize the various proposals, as their > description has now gotten rather scattered around in all the > discussion. > --------------------------------------------------------------------- > Mika's proposal (I'll call it the "minimalist" propsal): > > Mika, please correct me if I misrepresent what you are proposing. > > There are no language changes at all, only changes in implementation. > The implementation of the existing type REFANY, and no other type, > allows it to have values whose lsb is nonzero. ISTYPE, NARROW, > TYPECASE, and narrowing assignments, when and only when applied to > REFANY, have their generated code fixed so it checks the lsb, and, if > it is nonzero, consider the runtime type check to have failed, in > whichever way such a failure is already handled. > > The only effect is to liberalize the rules unsafe code must follow to > avoid undermining the safety of safe code. Only unsafe code can > create or detect these misaligned values. Today, it must never return > them in a variable of any reference type, lest the four narrowing > operations unexpectedly crash. In the proposal, unsafe code would be > able to return such values in variables of type REFANY, but not any > other type. > > Already, the only things safe code can do with values of REFANY are > copy them around (which would happily work on misaligned values) and > narrow them. With the implementation of the narrowing operations > changed, misaligned values can never escape from REFANY variables. > > In safe code, there is no way to detect whether a value of type REFANY > is misaligned. Doing it by elimination, trying to narrow to any > proper subtype of REFANY, is impractical, as there are an unbounded > number of REF types to eliminate. > > If there is more than one abstract data type that uses this mechanism, > client code can not be prevented from mixing up values from the > different abstractions. (Perhaps this could be fixed by a language > change allowing BRANDED REFANY?) > > --------------------------------------------------------------------- > My (Rodney's) "safe" proposal: > > There is a new type named TAGABLE. It is a subrange of INTEGER, whose > bounds are implementation-defined. These can be queried by the > existing FIRST and LAST functions. Similar to CARDINAL, it has all > the properties of a subrange type but is not the same type as the > corresponding subrange. > > There is a new type constructor TAGGED. If T is any traced or object > type, including branded and opaque types, then TAGGED T is a new type > whose value set is the union of the value sets of T and TAGABLE. > Moreover, > > TAGABLE <: TAGGED T > T <: TAGGED T. > > IF T # U, then TAGGED T and TAGGED U are not the same type and have no > subtype or assignability relation to each other. > > The semantics of ISTYPE, NARROW, TYPECASE, and assignability of a type > to a type are generalized so that their to-be-narrowed operand can > have a tagged type, and if it does, their to-be-narrowed-to type can > be TAGABLE. > > Comments: > > Making TAGGED T have no relation to TAGGED U avoids a lot of really > complicated type equality and subtype rules. The former would be a > drastic departure from the current state of Modula-3. > > It is up to the implementation to decide the bit representation of > tagged types, including how values of TAGABLE will be distinguished > from reference values. Though the language would not require it, most > likely a word the same size as a pointer will be used. Using the lsb > as the tag bit is an efficient encoding, because in any currently > conceivable machine, it will be zero for all pointers to heap objects. > There is no reason pickles would have to use the same representation > as compiler-generated code. > > The implementation should define the bounds of TAGABLE to be whatever > it can fit in its representation, after removing the values that are > true pointers. If the lsb is used as a tag, this will no doubt be a > 31-bit integer on a 32-bit machine and 63-bit integer on a 64-bit > machine. The language wouldn't even specify whether it is signed, > although somehow unsigned seems nice to me. If it is unsigned and the > suggested encodings are used, TAGABLE would have the same bounds as > CARDINAL, but it really should be a separate type, so as not to > overconstrain the implementation. > > If T is branded, then the effects of branding will propagate to TAGGED > T, thus allowing independent abstract data types to ensure each one's > values can't be mixed up with the other's. This will statically > detect misuses by client code. However, TAGGED T is not a branded > type. > > If T is an opaque type, then TAGGED T can be used to combine the space > efficiency of tagging with the ability of an opaque type to reveal > some but not all of its properties. To use this, client code will > have to narrow a value first, since access to methods/fields could not > have a definable meaning for a value in TAGABLE. > > On the other hand, T could be an opaque subtype of REFANY, thus > revealing almost nothing about TAGGED T to clients. This would give > tagged types the existing ability of ensuring statically, that the > code in a revealed context will never get TAGGED REFANY, thus avoiding > extra runtime type checks. From hosking at cs.purdue.edu Tue Apr 21 05:59:35 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Apr 2009 13:59:35 +1000 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <49EC7A06.5040403@cox.net> References: <49EC7A06.5040403@cox.net> Message-ID: On 20 Apr 2009, at 23:35, Rodney M. Bates wrote: > I am going to try to resummarize the various proposals, as their > description has now gotten rather scattered around in all the > discussion. > --------------------------------------------------------------------- > Mika's proposal (I'll call it the "minimalist" propsal): > > Mika, please correct me if I misrepresent what you are proposing. > > There are no language changes at all, only changes in implementation. > The implementation of the existing type REFANY, and no other type, > allows it to have values whose lsb is nonzero. ISTYPE, NARROW, > TYPECASE, and narrowing assignments, when and only when applied to > REFANY, have their generated code fixed so it checks the lsb, and, if > it is nonzero, consider the runtime type check to have failed, in > whichever way such a failure is already handled. > > The only effect is to liberalize the rules unsafe code must follow to > avoid undermining the safety of safe code. Only unsafe code can > create or detect these misaligned values. Today, it must never return > them in a variable of any reference type, lest the four narrowing > operations unexpectedly crash. In the proposal, unsafe code would be > able to return such values in variables of type REFANY, but not any > other type. I don't see why we can't have safe creation of the misaligned values as per Mika's interface. > Already, the only things safe code can do with values of REFANY are > copy them around (which would happily work on misaligned values) and > narrow them. With the implementation of the narrowing operations > changed, misaligned values can never escape from REFANY variables. > > In safe code, there is no way to detect whether a value of type REFANY > is misaligned. Doing it by elimination, trying to narrow to any > proper subtype of REFANY, is impractical, as there are an unbounded > number of REF types to eliminate. An alternative would be to loosen the language spec to allow TYPECODE(REFANY) and use this typecode for tagged references. Then one can explicitly test for it without elimination of alternatives. > If there is more than one abstract data type that uses this mechanism, > client code can not be prevented from mixing up values from the > different abstractions. (Perhaps this could be fixed by a language > change allowing BRANDED REFANY?) Indeed. > --------------------------------------------------------------------- > My (Rodney's) "safe" proposal: > > There is a new type named TAGABLE. It is a subrange of INTEGER, whose > bounds are implementation-defined. These can be queried by the > existing FIRST and LAST functions. Similar to CARDINAL, it has all > the properties of a subrange type but is not the same type as the > corresponding subrange. > > There is a new type constructor TAGGED. If T is any traced or object > type, including branded and opaque types, then TAGGED T is a new type > whose value set is the union of the value sets of T and TAGABLE. > Moreover, > > TAGABLE <: TAGGED T > T <: TAGGED T. > > IF T # U, then TAGGED T and TAGGED U are not the same type and have no > subtype or assignability relation to each other. > > The semantics of ISTYPE, NARROW, TYPECASE, and assignability of a type > to a type are generalized so that their to-be-narrowed operand can > have a tagged type, and if it does, their to-be-narrowed-to type can > be TAGABLE. Hmm. It seems there is a nasty loophole in your spec. Consider: TYPE T = BRANDED OBJECT END TYPE U = BRANDED OBJECT END These are unrelated types. Now, the rules let me take: t: TAGGED T and obtain: i: TAGABLE := NARROW(t, TAGABLE); But TAGABLE <: TAGGED U so I can do: u: TAGGED U := t; Is that your intention? > > > Comments: > > Making TAGGED T have no relation to TAGGED U avoids a lot of really > complicated type equality and subtype rules. The former would be a > drastic departure from the current state of Modula-3. > > It is up to the implementation to decide the bit representation of > tagged types, including how values of TAGABLE will be distinguished > from reference values. Though the language would not require it, most > likely a word the same size as a pointer will be used. Using the lsb > as the tag bit is an efficient encoding, because in any currently > conceivable machine, it will be zero for all pointers to heap objects. > There is no reason pickles would have to use the same representation > as compiler-generated code. > > The implementation should define the bounds of TAGABLE to be whatever > it can fit in its representation, after removing the values that are > true pointers. If the lsb is used as a tag, this will no doubt be a > 31-bit integer on a 32-bit machine and 63-bit integer on a 64-bit > machine. The language wouldn't even specify whether it is signed, > although somehow unsigned seems nice to me. If it is unsigned and the > suggested encodings are used, TAGABLE would have the same bounds as > CARDINAL, but it really should be a separate type, so as not to > overconstrain the implementation. > > If T is branded, then the effects of branding will propagate to TAGGED > T, thus allowing independent abstract data types to ensure each one's > values can't be mixed up with the other's. This will statically > detect misuses by client code. However, TAGGED T is not a branded > type. > > If T is an opaque type, then TAGGED T can be used to combine the space > efficiency of tagging with the ability of an opaque type to reveal > some but not all of its properties. To use this, client code will > have to narrow a value first, since access to methods/fields could not > have a definable meaning for a value in TAGABLE. > > On the other hand, T could be an opaque subtype of REFANY, thus > revealing almost nothing about TAGGED T to clients. This would give > tagged types the existing ability of ensuring statically, that the > code in a revealed context will never get TAGGED REFANY, thus avoiding > extra runtime type checks. From jay.krell at cornell.edu Tue Apr 21 06:14:43 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 21 Apr 2009 04:14:43 +0000 Subject: [M3devel] crummy ThreadWin32.m3 implementation? In-Reply-To: <14FDB4AD-26AA-43B0-BD25-925C596452EF@cs.purdue.edu> References: <14FDB4AD-26AA-43B0-BD25-925C596452EF@cs.purdue.edu> Message-ID: Only if you drop support for pre-Vista versions. - Jay > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 21 Apr 2009 07:53:57 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? > > Also, note that win32 now supports CVs directly! No need for > semaphores. > > On 20 Apr 2009, at 19:11, Jay wrote: > > > > > Searching the web...finds this which seems very relevant: > > > > http://birrell.org/andrew/papers/ImplementingCVs.pdf > > > > - Jay > > > > > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: m3devel at elegosoft.com > >> Date: Mon, 20 Apr 2009 08:47:21 +0000 > >> Subject: [M3devel] crummy ThreadWin32.m3 implementation? > >> > >> > >> Um, ThreadWin32.m3 looks pretty crummy -- all LockMutex calls > >> bottleneck on one giant lock. .v0 and .v1 aren't bad this way. > >> > >> > >> - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 21 06:13:23 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 21 Apr 2009 04:13:23 +0000 Subject: [M3devel] Latest ThreadPThread In-Reply-To: <8510055B-CBC6-4A02-BAFA-B26AF9A827EC@cs.purdue.edu> References: <8510055B-CBC6-4A02-BAFA-B26AF9A827EC@cs.purdue.edu> Message-ID: Question is whether or not it is interesting to have fewer of those very thin pthread wrappers or not. This has fewer of them. Not clearly worthwhile. I can it put back later. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 21 Apr 2009 11:53:05 +1000 CC: m3devel at elegosoft.com Subject: [M3devel] Latest ThreadPThread Jay, I have some questions about why you have moved the Activation declaration to C code. I'm not sure what this gains, and I have strong reasons for wanting to keep it in Modula-3. I'd like to revert these most recent changes if possible, unless you can say why you want to retain them. Perhaps you have a good reason, but I remain to be convinced. -- Tony Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Apr 21 06:33:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Apr 2009 14:33:29 +1000 Subject: [M3devel] crummy ThreadWin32.m3 implementation? In-Reply-To: References: <14FDB4AD-26AA-43B0-BD25-925C596452EF@cs.purdue.edu> Message-ID: <3577783C-1892-435E-95E3-5E967C9BA638@cs.purdue.edu> Might not be such a bad thing ;-) On 21 Apr 2009, at 14:14, Jay wrote: > Only if you drop support for pre-Vista versions. > > - Jay > > > > > From: hosking at cs.purdue.edu > > To: jay.krell at cornell.edu > > Date: Tue, 21 Apr 2009 07:53:57 +1000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? > > > > Also, note that win32 now supports CVs directly! No need for > > semaphores. > > > > On 20 Apr 2009, at 19:11, Jay wrote: > > > > > > > > Searching the web...finds this which seems very relevant: > > > > > > http://birrell.org/andrew/papers/ImplementingCVs.pdf > > > > > > - Jay > > > > > > > > > > > > ---------------------------------------- > > >> From: jay.krell at cornell.edu > > >> To: m3devel at elegosoft.com > > >> Date: Mon, 20 Apr 2009 08:47:21 +0000 > > >> Subject: [M3devel] crummy ThreadWin32.m3 implementation? > > >> > > >> > > >> Um, ThreadWin32.m3 looks pretty crummy -- all LockMutex calls > > >> bottleneck on one giant lock. .v0 and .v1 aren't bad this way. > > >> > > >> > > >> - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 21 06:41:55 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 21 Apr 2009 04:41:55 +0000 Subject: [M3devel] crummy ThreadWin32.m3 implementation? In-Reply-To: <3577783C-1892-435E-95E3-5E967C9BA638@cs.purdue.edu> References: <14FDB4AD-26AA-43B0-BD25-925C596452EF@cs.purdue.edu> <3577783C-1892-435E-95E3-5E967C9BA638@cs.purdue.edu> Message-ID: I'm not keen on it. Checking the version and having two implementation switched between at initialization would be ok though -- actually using function pointers like so: void DoSomething_v2(void) { } void DoSomething_v1(void) { } void DoSomething_init(void) { if (... ) DoSomething = DoSomething_v1; else DoSomething = DoSomething_v2; DoSomething(); } void (*DoSomething)(void) = DoSomething_init; Something more if switching multiple pointers though -- switching a pointer to a struct of function pointers. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 21 Apr 2009 14:33:29 +1000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? Might not be such a bad thing ;-) On 21 Apr 2009, at 14:14, Jay wrote: Only if you drop support for pre-Vista versions. - Jay > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 21 Apr 2009 07:53:57 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? > > Also, note that win32 now supports CVs directly! No need for > semaphores. > > On 20 Apr 2009, at 19:11, Jay wrote: > > > > > Searching the web...finds this which seems very relevant: > > > > http://birrell.org/andrew/papers/ImplementingCVs.pdf > > > > - Jay > > > > > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: m3devel at elegosoft.com > >> Date: Mon, 20 Apr 2009 08:47:21 +0000 > >> Subject: [M3devel] crummy ThreadWin32.m3 implementation? > >> > >> > >> Um, ThreadWin32.m3 looks pretty crummy -- all LockMutex calls > >> bottleneck on one giant lock. .v0 and .v1 aren't bad this way. > >> > >> > >> - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 21 06:44:33 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 21 Apr 2009 04:44:33 +0000 Subject: [M3devel] Latest ThreadPThread In-Reply-To: References: <8510055B-CBC6-4A02-BAFA-B26AF9A827EC@cs.purdue.edu> Message-ID: The Interlocked doesn't have a strong reason. It's fairly cheap at least. There are places in the Modula-3 code with comments about inc/dec taking one instruction, which these would but otherwise I'm skeptical.. - Jay From: hosking at cs.purdue.edu To: hosking at cs.purdue.edu Date: Tue, 21 Apr 2009 11:58:31 +1000 CC: m3devel at elegosoft.com; jay.krell at cornell.edu Subject: Re: [M3devel] Latest ThreadPThread Jay, I am curious why you are using atomic operations for INC and DEC of inCritical (on WIN32/WIN64). In general, they are protected by an appropriate lock, so I don't know what the need is. Are you trying to move towards lock-free implementations of some of the thread primitives? 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 21 Apr 2009, at 11:53, Tony Hosking wrote: Jay, I have some questions about why you have moved the Activation declaration to C code. I'm not sure what this gains, and I have strong reasons for wanting to keep it in Modula-3. I'd like to revert these most recent changes if possible, unless you can say why you want to retain them. Perhaps you have a good reason, but I remain to be convinced. -- Tony Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Apr 21 07:05:48 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Apr 2009 15:05:48 +1000 Subject: [M3devel] Latest ThreadPThread In-Reply-To: References: <8510055B-CBC6-4A02-BAFA-B26AF9A827EC@cs.purdue.edu> Message-ID: On 21 Apr 2009, at 14:44, Jay wrote: > The Interlocked doesn't have a strong reason. > It's fairly cheap at least. It's many cycles (~50x depending on hardware) more expensive than an unlocked INC/DEC. > There are places in the Modula-3 code with comments about inc/dec > taking one instruction, > which these would but otherwise I'm skeptical.. I'm pretty sure that is only in the user-level threading model, where thread switches only occur on delivery of a signal to the process. I am unaware of any OS/hardware that will deliver a thread switch signal in the middle of INC/DEC. So, effectively, for user level threads INC/ DEC can be assumed atomic. That's what the comments are meant to imply. Outside ThreadPosix, all other uses of INC/DEC manipulate state that is already protected appropriately by a lock so should be thread safe. > > > > - Jay > > > > From: hosking at cs.purdue.edu > To: hosking at cs.purdue.edu > Date: Tue, 21 Apr 2009 11:58:31 +1000 > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] Latest ThreadPThread > > Jay, I am curious why you are using atomic operations for INC and > DEC of inCritical (on WIN32/WIN64). In general, they are protected > by an appropriate lock, so I don't know what the need is. Are you > trying to move towards lock-free implementations of some of the > thread primitives? > > 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 21 Apr 2009, at 11:53, Tony Hosking wrote: > > Jay, > > I have some questions about why you have moved the Activation > declaration to C code. I'm not sure what this gains, and I have > strong reasons for wanting to keep it in Modula-3. I'd like to > revert these most recent changes if possible, unless you can say why > you want to retain them. Perhaps you have a good reason, but I > remain to be convinced. > > -- Tony > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 21 11:37:21 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 21 Apr 2009 09:37:21 +0000 Subject: [M3devel] explanation of CheckLoadTracedRef? In-Reply-To: References: Message-ID: > > How bad/unportable was it the previous way, the VM-synchronized way? > > Not compatible with system threading. Really? NT386 wasn't VM-synchronized back in 3.6, 4.1, etc.? Or only with great cost? I have to admit, those old import .libs, kernel32.lib, etc. I didn't realize what was in them when I deleted them. I thought they were just regular import .libs. I think I got luckly in that the overlap between me deleting them and you removing VM-synchronized GC was small or zero. > You should *never* access a field in the heap in C code! All > accesses to traced fields in the heap must take place in Modula-3. > Otherwise things will break! C wrappers should not do anything other > than forward calls to C library calls. They should not perform heap > accesses. Ok, that makes sense. Important "out" is the accessing stack is always ok. But this is a requirement I didn't keep in mind. Now, luckily, the C wrappers are all relatively thin and not difficult to re-review in their entirety. But, take for example "open". The first parameter to it is bound to be in the heap. But probably it is untraced or somehow ok, since it does come from a module used primarily for C interop. And, the line between C wrappers and the "C library" that they forward to does not exist. If I, say, pass a VAR to a VAR..no check is made? Important to declare extern/C functions as taking UNTRACED REF and not VAR? > I think you are confusing incremental and incremental GC. You assume I understand more than I do (I assume you have a typo. :)) "generational" -- the concept that most objects die young. (aka most objects could have been allocated on the stack...) But does that imply detailed implementation choices, or is just like a "guiding principle"? I guess it implies the heap is split into at least two generations, old and young. Though I guess in reality there is a range of young, less young, lesser young, least young, etc. And that has objects age, they should be moved from young to old heaps, and references to them either updated right away, or "caught" upon use and updated then...something like that. "incremental" -- don't pause the world.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Apr 21 14:18:00 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 21 Apr 2009 08:18:00 -0400 Subject: [M3devel] fewer wrappers/more C? (or a wash?) In-Reply-To: <200904201531.n3KFVWLl065496@camembert.async.caltech.edu> References: <200904201531.n3KFVWLl065496@camembert.async.caltech.edu> Message-ID: <20090421121800.GA25465@topoi.pooq.com> On Mon, Apr 20, 2009 at 08:31:32AM -0700, Mika Nystrom wrote: > > I just wanted to point out that the discussion about X pointers > is introducing a large red herring into the discussion about tagged REFANYs. > > The tagged REFANY idea just depends on Modula-3's own heap allocator's > returning aligned addresses. If they're not aligned, you can't tag > the REFANY. If they are, you can, because the only thing ever held by > a REFANY is a Modula-3-heap-allocated address, NIL, or a tagged value. > > X pointers should clearly be passed as ADDRESS, not as REFANY. Completely > different issue. Because Modula 3's reference data structures are subject to the Modula 3 garbage collector, and C's are not. And further, C's addresses don't have to be aligned; neither do ADDRESSes. -- hendrik From hendrik at topoi.pooq.com Tue Apr 21 14:26:48 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 21 Apr 2009 08:26:48 -0400 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <49EC7A06.5040403@cox.net> References: <49EC7A06.5040403@cox.net> Message-ID: <20090421122648.GB25465@topoi.pooq.com> On Mon, Apr 20, 2009 at 08:35:02AM -0500, Rodney M. Bates wrote: > > --------------------------------------------------------------------- > My (Rodney's) "safe" proposal: > > There is a new type named TAGABLE. It is a subrange of INTEGER, whose Please spell it TAGGABLE. TAG doubles its last consonant when adding suffixes: TAGGED, TAGGING. -- hendrik From jay.krell at cornell.edu Tue Apr 21 14:46:22 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 21 Apr 2009 12:46:22 +0000 Subject: [M3devel] crummy ThreadWin32.m3 implementation? In-Reply-To: References: <14FDB4AD-26AA-43B0-BD25-925C596452EF@cs.purdue.edu> <3577783C-1892-435E-95E3-5E967C9BA638@cs.purdue.edu> Message-ID: did more "research" (search the web..) It sounds like: if fairness not critical, and pre NT 4.0 compat is needed, there are options where mutex/lock=criticalsection If fairness is important, and NT 4.0 can be used, and perf can be degraded, then mutex/lock=kernel mutex, and use the SignalAndWait function They never seem to use a global lock like ours. Should we maybe adopt Boost's code? e.g.: http://svn.boost.org/trac/boost/browser/trunk/boost/thread/win32/mutex.hpp http://svn.boost.org/trac/boost/browser/trunk/boost/thread/win32/condition_variable.hpp I don't know, it all seems kind of unforunate. Perhaps there should be two types of locks, one that can be associated with a conditionvariable (kernel mutex), one that cannot (criticalsection)? I guess our implementation is quite simple and solves "all the problems" by throwing scalability right out -- lots of independent threads acquiring lots of independent locks will all interfere somewhat with each other, but not a ton. The "giant" lock protects too much data, but not for long durations. It might be interesting to see what cygwin does..but I notice..pthread is a superset, e.g. timedwait, trylock, etc. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 21 Apr 2009 04:41:55 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? I'm not keen on it. Checking the version and having two implementation switched between at initialization would be ok though -- actually using function pointers like so: void DoSomething_v2(void) { } void DoSomething_v1(void) { } void DoSomething_init(void) { if (... ) DoSomething = DoSomething_v1; else DoSomething = DoSomething_v2; DoSomething(); } void (*DoSomething)(void) = DoSomething_init; Something more if switching multiple pointers though -- switching a pointer to a struct of function pointers. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 21 Apr 2009 14:33:29 +1000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? Might not be such a bad thing ;-) On 21 Apr 2009, at 14:14, Jay wrote: Only if you drop support for pre-Vista versions. - Jay > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 21 Apr 2009 07:53:57 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? > > Also, note that win32 now supports CVs directly! No need for > semaphores. > > On 20 Apr 2009, at 19:11, Jay wrote: > > > > > Searching the web...finds this which seems very relevant: > > > > http://birrell.org/andrew/papers/ImplementingCVs.pdf > > > > - Jay > > > > > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: m3devel at elegosoft.com > >> Date: Mon, 20 Apr 2009 08:47:21 +0000 > >> Subject: [M3devel] crummy ThreadWin32.m3 implementation? > >> > >> > >> Um, ThreadWin32.m3 looks pretty crummy -- all LockMutex calls > >> bottleneck on one giant lock. .v0 and .v1 aren't bad this way. > >> > >> > >> - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 21 14:47:16 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 21 Apr 2009 12:47:16 +0000 Subject: [M3devel] crummy ThreadWin32.m3 implementation? In-Reply-To: References: <14FDB4AD-26AA-43B0-BD25-925C596452EF@cs.purdue.edu> <3577783C-1892-435E-95E3-5E967C9BA638@cs.purdue.edu> Message-ID: did more "research" (search the web..) It sounds like: if fairness not critical, and pre NT 4.0 compat is needed, there are options where mutex/lock=criticalsection If fairness is important, and NT 4.0 can be used, and perf can be degraded, then mutex/lock=kernel mutex, and use the SignalAndWait function They never seem to use a global lock like ours. Should we maybe adopt Boost's code? e.g.: http://svn.boost.org/trac/boost/browser/trunk/boost/thread/win32/mutex.hpp http://svn.boost.org/trac/boost/browser/trunk/boost/thread/win32/condition_variable.hpp I don't know, it all seems kind of unforunate. Perhaps there should be two types of locks, one that can be associated with a conditionvariable (kernel mutex), one that cannot (criticalsection)? I guess our implementation is quite simple and solves "all the problems" by throwing scalability right out -- lots of independent threads acquiring lots of independent locks will all interfere somewhat with each other, but not a ton. The "giant" lock protects too much data, but not for long durations. It might be interesting to see what cygwin does..but I notice..pthread is a superset, e.g. timedwait, trylock, etc. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 21 Apr 2009 04:41:55 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? I'm not keen on it. Checking the version and having two implementation switched between at initialization would be ok though -- actually using function pointers like so: void DoSomething_v2(void) { } void DoSomething_v1(void) { } void DoSomething_init(void) { if (... ) DoSomething = DoSomething_v1; else DoSomething = DoSomething_v2; DoSomething(); } void (*DoSomething)(void) = DoSomething_init; Something more if switching multiple pointers though -- switching a pointer to a struct of function pointers. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 21 Apr 2009 14:33:29 +1000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? Might not be such a bad thing ;-) On 21 Apr 2009, at 14:14, Jay wrote: Only if you drop support for pre-Vista versions. - Jay > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 21 Apr 2009 07:53:57 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? > > Also, note that win32 now supports CVs directly! No need for > semaphores. > > On 20 Apr 2009, at 19:11, Jay wrote: > > > > > Searching the web...finds this which seems very relevant: > > > > http://birrell.org/andrew/papers/ImplementingCVs.pdf > > > > - Jay > > > > > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: m3devel at elegosoft.com > >> Date: Mon, 20 Apr 2009 08:47:21 +0000 > >> Subject: [M3devel] crummy ThreadWin32.m3 implementation? > >> > >> > >> Um, ThreadWin32.m3 looks pretty crummy -- all LockMutex calls > >> bottleneck on one giant lock. .v0 and .v1 aren't bad this way. > >> > >> > >> - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carson at taltos.org Tue Apr 21 20:29:28 2009 From: carson at taltos.org (Carson Gaspar) Date: Tue, 21 Apr 2009 11:29:28 -0700 Subject: [M3devel] Latest ThreadPThread In-Reply-To: References: <8510055B-CBC6-4A02-BAFA-B26AF9A827EC@cs.purdue.edu> Message-ID: <49EE1088.6030006@taltos.org> Tony Hosking wrote: > I'm pretty sure that is only in the user-level threading model, where > thread switches only occur on delivery of a signal to the process. I am > unaware of any OS/hardware that will deliver a thread switch signal in > the middle of INC/DEC. So, effectively, for user level threads INC/DEC > can be assumed atomic. That's what the comments are meant to imply. > Outside ThreadPosix, all other uses of INC/DEC manipulate state that is > already protected appropriately by a lock so should be thread safe. I'm not sure what you mean by INC/DEC... but if it involves changing a value in memory (as opposed to a register), then it is _not_ atomic and _must_ use a lock. The most common mistake I've seen is a variable modified in a signal handler and in the main code, especially SIGCHLD. "nchildren++" is _not_ signal or thread safe. If you're talking about purely register instructions, please ignore me ;-) -- Carson From mika at async.caltech.edu Tue Apr 21 23:41:49 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 21 Apr 2009 14:41:49 -0700 Subject: [M3devel] an old, recurring issue: mapping runtime errors to exceptions? Message-ID: <200904212141.n3LLfnZ4030631@camembert.async.caltech.edu> Hello Modula-3ers, I know this is a question that comes up from time to time, and I am aware of Greg Nelson's short article in "Threads" about why Modula-3 doesn't map runtime errors to exceptions, but the Green Book does allude to mapping runtime errors to exceptions, and I know that the SPIN OS did that. How hard would this be to support in CM3? Attached is a transcript of an interactive session with my current Scheme environment. I think it ought to be obvious why I ask about exceptions. In Modula-3, from safe code, only checked runtime errors can occur. Checked runtime errors cannot violate invariants of the runtime system, so it ought to be safe to convert them to exceptions that can be caught, and then permit the program to continue. I realize this isn't *always* what you want to do, but in an interactive environment, making the system dump core on runtime errors sort of spoils the whole experience. In this application, there are many places where you may want to raise an exception that hasn't been declared. In a non-interactive environment, it is probably best to go for the core dump, but in an interactive environment, it seems to me it ought to just return control to the read-eval-print loop.... Mika LITHP ITH LITHENING. > (define wr (scheme-procedure-stubs-call '(TextWr . New) '())) wr > wr > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) "hello!" > (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) "" > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) "hello!hello!hello!hello!hello!" > (scheme-procedure-stubs-call '(TextWr . ToText) (list '()) '()) *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x80c69c8 = LockMutex + 0x28 in /usr/ports/lang/ezm3/work/ezm3-1.0/libs/m3core/src/thread/POSIX/ThreadPosix.m3 *** use option @M3stackdump to get a stack trace Abort From rcoleburn at scires.com Wed Apr 22 00:22:28 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 21 Apr 2009 18:22:28 -0400 Subject: [M3devel] an old, recurring issue: mapping runtime errors to exceptions? In-Reply-To: <200904212141.n3LLfnZ4030631@camembert.async.caltech.edu> References: <200904212141.n3LLfnZ4030631@camembert.async.caltech.edu> Message-ID: <49EE0E7B.1E75.00D7.1@scires.com> Mika: You state that "Checked runtime errors cannot violate invariants of the runtime system, so it ought to be safe to ..." Are you sure this statement is true for all implementations? I would tend to think that SPIN was able to do this mapping for itself, but in general, it would be difficult to be able to do this for any arbitrary OS environment, esp with differences in underlying libraries and implementations, which is part of what Greg alluded to in the Threads article you reference. Note also on pg 47 of the green book under "2.5.7 Safety" the notes about intrinsic safety and when the compiler makes the guarantee vs. the programmer. I also note from the path in your example (ezm3) that you may not be using the current cm3. Is it possible that the NIL dereference problem in your example has been solved in a later implementation? Regards, Randy >>> Mika Nystrom 4/21/2009 5:41 PM >>> Hello Modula-3ers, I know this is a question that comes up from time to time, and I am aware of Greg Nelson's short article in "Threads" about why Modula-3 doesn't map runtime errors to exceptions, but the Green Book does allude to mapping runtime errors to exceptions, and I know that the SPIN OS did that. How hard would this be to support in CM3? Attached is a transcript of an interactive session with my current Scheme environment. I think it ought to be obvious why I ask about exceptions. In Modula-3, from safe code, only checked runtime errors can occur. Checked runtime errors cannot violate invariants of the runtime system, so it ought to be safe to convert them to exceptions that can be caught, and then permit the program to continue. I realize this isn't *always* what you want to do, but in an interactive environment, making the system dump core on runtime errors sort of spoils the whole experience. In this application, there are many places where you may want to raise an exception that hasn't been declared. In a non-interactive environment, it is probably best to go for the core dump, but in an interactive environment, it seems to me it ought to just return control to the read-eval-print loop.... Mika LITHP ITH LITHENING. > (define wr (scheme-procedure-stubs-call '(TextWr . New) '())) wr > wr > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) "hello!" > (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) "" > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) #t > (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) "hello!hello!hello!hello!hello!" > (scheme-procedure-stubs-call '(TextWr . ToText) (list '()) '()) *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x80c69c8 = LockMutex + 0x28 in /usr/ports/lang/ezm3/work/ezm3-1.0/libs/m3core/src/thread/POSIX/ThreadPosix.m3 *** use option @M3stackdump to get a stack trace Abort 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 mika at async.caltech.edu Wed Apr 22 00:41:19 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 21 Apr 2009 15:41:19 -0700 Subject: [M3devel] an old, recurring issue: mapping runtime errors to exceptions? In-Reply-To: Your message of "Tue, 21 Apr 2009 18:22:28 EDT." <49EE0E7B.1E75.00D7.1@scires.com> Message-ID: <200904212241.n3LMfJB7032643@camembert.async.caltech.edu> Well the point of "safety" is that the system can guarantee that the runtime environment hasn't been damaged by a misbehaving program, no? In fact, in Threads 3 there are not one but *two* reports of implementations that "reflect" runtime errors as exceptions. On of them is SPIN, the other is the commercial CM3 with JVM. See http://www.modula3.org/threads/3/ Nelson's article in Threads 2 doesn't give the possibility of having had the runtime invariants violated as a reason to abort. His arguments are more practical, having to do with debugging. I agree, and I think that the default method of dealing with runtime errors should be to abort the program. But it just is very unfriendly in an interactive environment, and I would love some kind of (possibly very implementation-dependent) way of catching the runtime error. The way Java does it would be ideal, I think..... Nelson's article is here http://www.modula3.org/threads/2/ [Tony, the link in your M3 bibliography is broken!] I'm running this example in a PM3/EZM3 environment right now but that's not relevant. The code I showed you *should* crash. In plain M3 it was: TextWr.ToText(NIL) But in an interactive environment, the user can do this sort of thing. It should give you a nasty error message, not crash your whole environment. Mika "Randy Coleburn" writes: >This is a MIME message. If you are reading this text, you may want to >consider changing to a mail reader or gateway that understands how to >properly handle MIME multipart messages. > >--=__PartBC941634.0__= >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: quoted-printable > >Mika: >=20 >You state that "Checked runtime errors cannot violate invariants of the = >runtime system, so it ought to be safe to ..." >=20 >Are you sure this statement is true for all implementations? >=20 >I would tend to think that SPIN was able to do this mapping for itself, = >but in general, it would be difficult to be able to do this for any = >arbitrary OS environment, esp with differences in underlying libraries and = >implementations, which is part of what Greg alluded to in the Threads = >article you reference. >=20 >Note also on pg 47 of the green book under "2.5.7 Safety" the notes about = >intrinsic safety and when the compiler makes the guarantee vs. the = >programmer. >=20 >I also note from the path in your example (ezm3) that you may not be using = >the current cm3. Is it possible that the NIL dereference problem in your = >example has been solved in a later implementation? >=20 >Regards, >Randy > >>>> Mika Nystrom 4/21/2009 5:41 PM >>> > >Hello Modula-3ers, > >I know this is a question that comes up from time to time, and I >am aware of Greg Nelson's short article in "Threads" about why=20 >Modula-3 doesn't map runtime errors to exceptions, but the Green Book >does allude to mapping runtime errors to exceptions, and I know that >the SPIN OS did that. > >How hard would this be to support in CM3? > >Attached is a transcript of an interactive session with my current >Scheme environment. I think it ought to be obvious why I ask about >exceptions. In Modula-3, from safe code, only checked runtime errors >can occur. Checked runtime errors cannot violate invariants of the >runtime system, so it ought to be safe to convert them to exceptions >that can be caught, and then permit the program to continue. =20 > >I realize this isn't *always* what you want to do, but in an interactive >environment, making the system dump core on runtime errors sort of >spoils the whole experience. > >In this application, there are many places where you may want to >raise an exception that hasn't been declared. In a non-interactive >environment, it is probably best to go for the core dump, but in >an interactive environment, it seems to me it ought to just return >control to the read-eval-print loop.... > Mika > >LITHP ITH LITHENING. >> (define wr (scheme-procedure-stubs-call '(TextWr . New) '())) >wr >> wr > >> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >#t >> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >"hello!" >> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >"" >> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >#t >> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >#t >> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >#t >> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >#t >> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >#t >> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >"hello!hello!hello!hello!hello!" >> (scheme-procedure-stubs-call '(TextWr . ToText) (list '()) '()) > > >*** >*** runtime error: >*** Segmentation violation - possible attempt to dereference NIL >*** pc =3D 0x80c69c8 =3D LockMutex + 0x28 in /usr/ports/lang/ezm3/work/e= >zm3-1.0/libs/m3core/src/thread/POSIX/ThreadPosix.m3 >*** > > use option @M3stackdump to get a stack trace >Abort > > > > > > > >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. > > >--=__PartBC941634.0__= >Content-Type: text/html; charset=US-ASCII >Content-Transfer-Encoding: quoted-printable >Content-Description: HTML > > >"> > > >
Mika:
>
 
>
You state that "Checked runtime errors cannot violate invariants of = >the runtime system, so it ought to be safe to ..."
>
 
>
Are you sure this statement is true for all implementations?> >
 
>
I would tend to think that SPIN was able to do this mapping for = >itself, but in general, it would be difficult to be able to do this for = >any arbitrary OS environment, esp with differences in underlying libraries = >and implementations, which is part of what Greg alluded to in the Threads = >article you reference.
>
 
>
Note also on pg 47 of the green book under "2.5.7 Safety" the notes = >about intrinsic safety and when the compiler makes the guarantee vs. the = >programmer.
>
 
>
I also note from the path in your example (ezm3) that you may not be = >using the current cm3.  Is it possible that the NIL dereference = >problem in your example has been solved in a later implementation?
>
 
>
Regards,
>
Randy

>>> Mika Nystrom <mika at async.caltech.edu> = >4/21/2009 5:41 PM >>>

Hello Modula-3ers,

I know = >this is a question that comes up from time to time, and I
am aware of = >Greg Nelson's short article in "Threads" about why
Modula-3 doesn't = >map runtime errors to exceptions, but the Green Book
does allude to = >mapping runtime errors to exceptions, and I know that
the SPIN OS did = >that.

How hard would this be to support in CM3?

Attached is = >a transcript of an interactive session with my current
Scheme environmen= >t.  I think it ought to be obvious why I ask about
exceptions. = >; In Modula-3, from safe code, only checked runtime errors
can = >occur.  Checked runtime errors cannot violate invariants of the
run= >time system, so it ought to be safe to convert them to exceptions
that = >can be caught, and then permit the program to continue. 

I = >realize this isn't *always* what you want to do, but in an interactive
e= >nvironment, making the system dump core on runtime errors sort of
spoils= > the whole experience.

In this application, there are many places = >where you may want to
raise an exception that hasn't been declared. = >; In a non-interactive
environment, it is probably best to go for the = >core dump, but in
an interactive environment, it seems to me it ought = >to just return
control to the read-eval-print loop....

 &nbs= >p;   Mika

LITHP ITH LITHENING.
> (define wr = >(scheme-procedure-stubs-call '(TextWr . New) '()))
wr
> wr
<= >Modula-3 object : TextWr.T, BRANDED TextWr_^%#%^__0001M>
> = >(scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '())
#t<= >BR>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) = >'())
"hello!"
> (scheme-procedure-stubs-call '(TextWr . ToText) = >(list wr) '())
""
> (scheme-procedure-stubs-call '(Wr . PutText) = >(list wr "hello!") '())
#t
> (scheme-procedure-stubs-call '(Wr . = >PutText) (list wr "hello!") '())
#t
> (scheme-procedure-stubs-call= > '(Wr . PutText) (list wr "hello!") '())
#t
> (scheme-procedure-st= >ubs-call '(Wr . PutText) (list wr "hello!") '())
#t
> (scheme-proc= >edure-stubs-call '(Wr . PutText) (list wr "hello!") '())
#t
> = >(scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '())
"hello!he= >llo!hello!hello!hello!"
> (scheme-procedure-stubs-call '(TextWr . = >ToText) (list '()) '())


***
*** runtime error:
*** &n= >bsp;  Segmentation violation - possible attempt to dereference = >NIL
***    pc =3D 0x80c69c8 =3D LockMutex + 0x28 in = >/usr/ports/lang/ezm3/work/ezm3-1.0/libs/m3core/src/thread/POSIX/ThreadPosix= >.m3
***

  use option @M3stackdump to get a stack trace
Ab= >ort






> >--=__PartBC941634.0__=-- From hosking at cs.purdue.edu Wed Apr 22 02:02:52 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Apr 2009 10:02:52 +1000 Subject: [M3devel] explanation of CheckLoadTracedRef? In-Reply-To: References: Message-ID: <19C20763-18A0-413A-9440-3D7ED0C918B1@cs.purdue.edu> On 21 Apr 2009, at 19:37, Jay wrote: > > > How bad/unportable was it the previous way, the VM-synchronized > way? > > > > Not compatible with system threading. > > > Really? NT386 wasn't VM-synchronized back in 3.6, 4.1, etc.? It was, but every system call had to be wrapped with a call to acquire the global heap lock! > Or only with great cost? Yes, taking the lock was expensive and prevented scaling on multi-cores. > I have to admit, those old import .libs, kernel32.lib, etc. I didn't > realize what was in them when I deleted them. I thought they were > just regular import .libs. There was also the work to wrap all dll symbols to acquire the lock. > I think I got luckly in that the overlap between me deleting them > and you removing VM-synchronized GC was small or zero. You should have seen the mess it was before... ;-) > > You should *never* access a field in the heap in C code! All > > accesses to traced fields in the heap must take place in Modula-3. > > Otherwise things will break! C wrappers should not do anything other > > than forward calls to C library calls. They should not perform heap > > accesses. > > > Ok, that makes sense. > Important "out" is the accessing stack is always ok. Yes, so long as a references to an object is held on the stack then it is safe to pass an address within it to external calls. Thus, many C functions can take VAR arguments that may end being references to the fields of objects. The compiler injects the necessary CheckLoad/ CheckStore operations when passing VAR parameters, etc., and the GC maintains the invariant that all stack-referenced objects don't move, stay black (for incremental GC), and remain dirty (for generational GC). > But this is a requirement I didn't keep in mind. > Now, luckily, the C wrappers are all relatively thin and not difficult > to re-review in their entirety. Right. I think I did see you compute and pass an offset to C code, but that may have only been in code you e-mailed me for perusal rather than code that got checked in. Might be worth reviewing... > But, take for example "open". > The first parameter to it is bound to be in the heap. The ambiguous roots garbage collector we use maintains the invariant that pointers to the interior of heap objects from the stack *pin* that object in the heap: it will not move while the pointer from the stack exists, and invariants will be maintained so that its contenst can be manipulated safely even in the face of incremental and generational GC. > But probably it is untraced or somehow ok, since it does > come from a module used primarily for C interop. Certainly, C code should never be manipulating the *traced* fields of traced heap objects. It is fine for it to manipulate the untraced fields of traced heap objects. > And, the line between C wrappers and the "C library" that they > forward to > does not exist. > If I, say, pass a VAR to a VAR..no check is made? Not sure what you mean by this. Any call that passes traced VAR params will generate a check as necessary before the call. > Important to declare extern/C functions as taking UNTRACED REF and > not VAR? No, VAR is fine. So long as the VAR value being passed is not traced. > > I think you are confusing incremental and incremental GC. > You assume I understand more than I do (I assume you have a typo. :)) ;-) > "generational" -- the concept that most objects die young. > (aka most objects could have been allocated on the stack...) Not quite. The idea is that the likelihood of an object dying is a function of its age. There is a *weak* generational hypothesis that "most objects die young", and a *strong* generational hypothesis that "the older an object is the less likely it is to die". Many (but not all) programs support these hypotheses, which permits generational GC to focus effort where it is likely to be profitable (i.e., to free up a lot of space). > But does that imply detailed implementation choices, or is just like > a "guiding principle"? > I guess it implies the heap is split into at least two generations, > old and young. > Though I guess in reality there is a range of young, less young, > lesser young, least young, etc. Right, many different collectors have exploited age in this way. For the M3 collector we have just two generations: old and young. > And that has objects age, they should be moved from young to old > heaps, and references to them either updated right away, or "caught" > upon use and updated then...something like that. Old-space objects are "clean" if they contain no references to young- space objects. The Modula-3 compiler injects checks to make sure that whenever we store a reference into a clean old-space object it is marked "dirty". When a young-space collection occurs we must process the references in dirty old-space objects as roots into the young-space. > "incremental" -- don't pause the world.. Not quite. The opposite of stop-the-world (stopping all the mutator threads to process their stacks) is on-the-fly. Incremental refers to the ability to interleave GC work with mutator work. If the GC work can be interleaved with mutator threads without stopping the mutator threads at each increment then the collector is said to be concurrent (GC work proceeds concurrently with mutator work). The current M3 collector has a stop-the-world non-moving phase, followed by an concurrent copying phase. I have some incomplete work that will also make the M3 collector on-the-fly (no STW phase) and parallel (multiple GC threads can operate concurrently). Hope all this helps! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Apr 22 02:10:09 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Apr 2009 10:10:09 +1000 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <20090421122648.GB25465@topoi.pooq.com> References: <49EC7A06.5040403@cox.net> <20090421122648.GB25465@topoi.pooq.com> Message-ID: I'd prefer something like TAGGEDINT or some such. But I am still not convinced that the minimalist proposal and this proposal differ in any significant way. On 21 Apr 2009, at 22:26, hendrik at topoi.pooq.com wrote: > On Mon, Apr 20, 2009 at 08:35:02AM -0500, Rodney M. Bates wrote: >> >> --------------------------------------------------------------------- >> My (Rodney's) "safe" proposal: >> >> There is a new type named TAGABLE. It is a subrange of INTEGER, >> whose > > Please spell it TAGGABLE. TAG doubles its last consonant when adding > suffixes: TAGGED, TAGGING. > > -- hendrik From hosking at cs.purdue.edu Wed Apr 22 02:11:53 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Apr 2009 10:11:53 +1000 Subject: [M3devel] crummy ThreadWin32.m3 implementation? In-Reply-To: References: <14FDB4AD-26AA-43B0-BD25-925C596452EF@cs.purdue.edu> <3577783C-1892-435E-95E3-5E967C9BA638@cs.purdue.edu> Message-ID: <591C91AF-5362-43FE-8564-7FB9F4D32ECB@cs.purdue.edu> I'd be curious what OpenJDK does on Windows... On 21 Apr 2009, at 22:46, Jay wrote: > did more "research" (search the web..) > > It sounds like: > if fairness not critical, and pre NT 4.0 compat is needed, there > are options where mutex/lock=criticalsection > > If fairness is important, and NT 4.0 can be used, and perf can be > degraded, then mutex/lock=kernel mutex, and use the SignalAndWait > function > > They never seem to use a global lock like ours. > > Should we maybe adopt Boost's code? > e.g.: > > http://svn.boost.org/trac/boost/browser/trunk/boost/thread/win32/mutex.hpp > http://svn.boost.org/trac/boost/browser/trunk/boost/thread/win32/condition_variable.hpp > > I don't know, it all seems kind of unforunate. > > Perhaps there should be two types of locks, one that can be > associated with a conditionvariable (kernel mutex), one that cannot > (criticalsection)? > > I guess our implementation is quite simple and solves "all the > problems" by throwing scalability right out -- lots of independent > threads acquiring lots of independent locks will all interfere > somewhat with each other, but not a ton. The "giant" lock protects > too much data, but not for long durations. > > It might be interesting to see what cygwin does..but I > notice..pthread is a superset, e.g. timedwait, trylock, etc. > > - Jay > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Tue, 21 Apr 2009 04:41:55 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? > > I'm not keen on it. > Checking the version and having two implementation switched between > at initialization would be ok though -- actually using function > pointers like so: > > void DoSomething_v2(void) { } > void DoSomething_v1(void) { } > void DoSomething_init(void) > { > if (... ) > DoSomething = DoSomething_v1; > else > DoSomething = DoSomething_v2; > DoSomething(); > } > > void (*DoSomething)(void) = DoSomething_init; > > Something more if switching multiple pointers though -- switching a > pointer to a struct of function pointers. > > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 21 Apr 2009 14:33:29 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? > > Might not be such a bad thing ;-) > > On 21 Apr 2009, at 14:14, Jay wrote: > > Only if you drop support for pre-Vista versions. > > - Jay > > > > > From: hosking at cs.purdue.edu > > To: jay.krell at cornell.edu > > Date: Tue, 21 Apr 2009 07:53:57 +1000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] crummy ThreadWin32.m3 implementation? > > > > Also, note that win32 now supports CVs directly! No need for > > semaphores. > > > > On 20 Apr 2009, at 19:11, Jay wrote: > > > > > > > > Searching the web...finds this which seems very relevant: > > > > > > http://birrell.org/andrew/papers/ImplementingCVs.pdf > > > > > > - Jay > > > > > > > > > > > > ---------------------------------------- > > >> From: jay.krell at cornell.edu > > >> To: m3devel at elegosoft.com > > >> Date: Mon, 20 Apr 2009 08:47:21 +0000 > > >> Subject: [M3devel] crummy ThreadWin32.m3 implementation? > > >> > > >> > > >> Um, ThreadWin32.m3 looks pretty crummy -- all LockMutex calls > > >> bottleneck on one giant lock. .v0 and .v1 aren't bad this way. > > >> > > >> > > >> - Jay > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 22 02:54:00 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 22 Apr 2009 00:54:00 +0000 Subject: [M3devel] explanation of CheckLoadTracedRef? In-Reply-To: <19C20763-18A0-413A-9440-3D7ED0C918B1@cs.purdue.edu> References: <19C20763-18A0-413A-9440-3D7ED0C918B1@cs.purdue.edu> Message-ID: Yes this helps, thank you. Maybe checkin under doc? One thing you didn't understand my wording about and you seemed to contradict is "VAR to VAR". PROCEDURE F1() = VAR i; BEGIN F2(i); END F1; PROCEDURE F2(VAR a:INTEGER)= BEGIN F3(i); END F2; PROCEDURE F3(VAR a:INTEGER)= BEGIN a := 1; END F3; Where are the calls to CheckLoad/StoreTracedRef? (Duh, I can try it out..) It seems redundant to put them "everywhere". Esp. it seems that F2 shouldn't have do anything. But throw in that F3 might extern and that is unclear. So I just made up a suggestion that VAR is not good to pass to C code. That checks are inserted when 1) a pointer is dereferenced -- loaded or stored in Modula-3 or 2) a pointer becomes untraced (var becomes untraced ref, among others). > Right. I think I did see you compute and pass an offset to C code I had something like that very recently but think I didn't set it or commit it. I had something like: size_t offset; Init(Mutex* root, int* interior) { offset = (size_t)interior - (size_t)root; } DoSomething(Mutex* anotherRoot) { int* interior = (int*)(offset + (size_t)anotherRoot); printf("%d\n", *interior); } but I came up with a way to avoid that I think, and then rolled it all back or something anyway. - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] explanation of CheckLoadTracedRef? Date: Wed, 22 Apr 2009 10:02:52 +1000 On 21 Apr 2009, at 19:37, Jay wrote: > > How bad/unportable was it the previous way, the VM-synchronized way? > > Not compatible with system threading. Really? NT386 wasn't VM-synchronized back in 3.6, 4.1, etc.? It was, but every system call had to be wrapped with a call to acquire the global heap lock! Or only with great cost? Yes, taking the lock was expensive and prevented scaling on multi-cores. I have to admit, those old import .libs, kernel32.lib, etc. I didn't realize what was in them when I deleted them. I thought they were just regular import .libs. There was also the work to wrap all dll symbols to acquire the lock. I think I got luckly in that the overlap between me deleting them and you removing VM-synchronized GC was small or zero. You should have seen the mess it was before... ;-) > You should *never* access a field in the heap in C code! All > accesses to traced fields in the heap must take place in Modula-3. > Otherwise things will break! C wrappers should not do anything other > than forward calls to C library calls. They should not perform heap > accesses. Ok, that makes sense. Important "out" is the accessing stack is always ok. Yes, so long as a references to an object is held on the stack then it is safe to pass an address within it to external calls. Thus, many C functions can take VAR arguments that may end being references to the fields of objects. The compiler injects the necessary CheckLoad/CheckStore operations when passing VAR parameters, etc., and the GC maintains the invariant that all stack-referenced objects don't move, stay black (for incremental GC), and remain dirty (for generational GC). But this is a requirement I didn't keep in mind. Now, luckily, the C wrappers are all relatively thin and not difficult to re-review in their entirety. Right. I think I did see you compute and pass an offset to C code, but that may have only been in code you e-mailed me for perusal rather than code that got checked in. Might be worth reviewing... But, take for example "open". The first parameter to it is bound to be in the heap. The ambiguous roots garbage collector we use maintains the invariant that pointers to the interior of heap objects from the stack *pin* that object in the heap: it will not move while the pointer from the stack exists, and invariants will be maintained so that its contenst can be manipulated safely even in the face of incremental and generational GC. But probably it is untraced or somehow ok, since it does come from a module used primarily for C interop. Certainly, C code should never be manipulating the *traced* fields of traced heap objects. It is fine for it to manipulate the untraced fields of traced heap objects. And, the line between C wrappers and the "C library" that they forward to does not exist. If I, say, pass a VAR to a VAR..no check is made? Not sure what you mean by this. Any call that passes traced VAR params will generate a check as necessary before the call. Important to declare extern/C functions as taking UNTRACED REF and not VAR? No, VAR is fine. So long as the VAR value being passed is not traced. > I think you are confusing incremental and incremental GC. You assume I understand more than I do (I assume you have a typo. :)) ;-) "generational" -- the concept that most objects die young. (aka most objects could have been allocated on the stack...) Not quite. The idea is that the likelihood of an object dying is a function of its age. There is a *weak* generational hypothesis that "most objects die young", and a *strong* generational hypothesis that "the older an object is the less likely it is to die". Many (but not all) programs support these hypotheses, which permits generational GC to focus effort where it is likely to be profitable (i.e., to free up a lot of space). But does that imply detailed implementation choices, or is just like a "guiding principle"? I guess it implies the heap is split into at least two generations, old and young. Though I guess in reality there is a range of young, less young, lesser young, least young, etc. Right, many different collectors have exploited age in this way. For the M3 collector we have just two generations: old and young. And that has objects age, they should be moved from young to old heaps, and references to them either updated right away, or "caught" upon use and updated then...something like that. Old-space objects are "clean" if they contain no references to young-space objects. The Modula-3 compiler injects checks to make sure that whenever we store a reference into a clean old-space object it is marked "dirty". When a young-space collection occurs we must process the references in dirty old-space objects as roots into the young-space. "incremental" -- don't pause the world.. Not quite. The opposite of stop-the-world (stopping all the mutator threads to process their stacks) is on-the-fly. Incremental refers to the ability to interleave GC work with mutator work. If the GC work can be interleaved with mutator threads without stopping the mutator threads at each increment then the collector is said to be concurrent (GC work proceeds concurrently with mutator work). The current M3 collector has a stop-the-world non-moving phase, followed by an concurrent copying phase. I have some incomplete work that will also make the M3 collector on-the-fly (no STW phase) and parallel (multiple GC threads can operate concurrently). Hope all this helps! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Apr 22 04:14:13 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Apr 2009 12:14:13 +1000 Subject: [M3devel] Latest ThreadPThread In-Reply-To: <49EE1088.6030006@taltos.org> References: <8510055B-CBC6-4A02-BAFA-B26AF9A827EC@cs.purdue.edu> <49EE1088.6030006@taltos.org> Message-ID: <16FF28FE-78F3-4C16-A756-72C8D55437D5@cs.purdue.edu> On 22 Apr 2009, at 04:29, Carson Gaspar wrote: > Tony Hosking wrote: > >> I'm pretty sure that is only in the user-level threading model, >> where thread switches only occur on delivery of a signal to the >> process. I am unaware of any OS/hardware that will deliver a thread >> switch signal in the middle of INC/DEC. So, effectively, for user >> level threads INC/DEC can be assumed atomic. That's what the >> comments are meant to imply. Outside ThreadPosix, all other uses >> of INC/DEC manipulate state that is already protected appropriately >> by a lock so should be thread safe. > > I'm not sure what you mean by INC/DEC... but if it involves changing > a value in memory (as opposed to a register), then it is _not_ > atomic and _must_ use a lock. The most common mistake I've seen is a > variable modified in a signal handler and in the main code, > especially SIGCHLD. "nchildren++" is _not_ signal or thread safe. Indeed, on a multi-processor with system-scheduled threads that is the case. My comments pertain only to the rather narrow implementation of single-processor user-level threads using signal-handling that the Modula-3 user-level threads implementation uses/used. That implementation is pretty much unused on modern platforms where we support proper hardware-level parallelism. There, all memory operations must be protected by proper synchronization. From hosking at cs.purdue.edu Wed Apr 22 04:26:01 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Apr 2009 12:26:01 +1000 Subject: [M3devel] an old, recurring issue: mapping runtime errors to exceptions? In-Reply-To: <200904212241.n3LMfJB7032643@camembert.async.caltech.edu> References: <200904212241.n3LMfJB7032643@camembert.async.caltech.edu> Message-ID: CM3 does map some (I'm not sure if all) run-time errors to exceptions. See RuntimeError.i3 for details of what exceptions might occur. On 22 Apr 2009, at 08:41, Mika Nystrom wrote: > > Well the point of "safety" is that the system can guarantee that the > runtime environment hasn't been damaged by a misbehaving program, no? > > In fact, in Threads 3 there are not one but *two* reports of > implementations that "reflect" runtime errors as exceptions. On > of them is SPIN, the other is the commercial CM3 with JVM. > > See > > http://www.modula3.org/threads/3/ > > Nelson's article in Threads 2 doesn't give the possibility of having > had the runtime invariants violated as a reason to abort. His > arguments are more practical, having to do with debugging. I agree, > and I think that the default method of dealing with runtime errors > should be to abort the program. But it just is very unfriendly in > an interactive environment, and I would love some kind of (possibly > very implementation-dependent) way of catching the runtime error. > The way Java does it would be ideal, I think..... > > Nelson's article is here > > http://www.modula3.org/threads/2/ > > [Tony, the link in your M3 bibliography is broken!] > > I'm running this example in a PM3/EZM3 environment right now but > that's not relevant. The code I showed you *should* crash. In > plain M3 it was: > > TextWr.ToText(NIL) > > But in an interactive environment, the user can do this sort of > thing. It should give you a nasty error message, not crash your > whole environment. > > Mika > > > > "Randy Coleburn" writes: >> This is a MIME message. If you are reading this text, you may want to >> consider changing to a mail reader or gateway that understands how to >> properly handle MIME multipart messages. >> >> --=__PartBC941634.0__= >> Content-Type: text/plain; charset=US-ASCII >> Content-Transfer-Encoding: quoted-printable >> >> Mika: >> =20 >> You state that "Checked runtime errors cannot violate invariants of >> the = >> runtime system, so it ought to be safe to ..." >> =20 >> Are you sure this statement is true for all implementations? >> =20 >> I would tend to think that SPIN was able to do this mapping for >> itself, = >> but in general, it would be difficult to be able to do this for any = >> arbitrary OS environment, esp with differences in underlying >> libraries and = >> implementations, which is part of what Greg alluded to in the >> Threads = >> article you reference. >> =20 >> Note also on pg 47 of the green book under "2.5.7 Safety" the notes >> about = >> intrinsic safety and when the compiler makes the guarantee vs. the = >> programmer. >> =20 >> I also note from the path in your example (ezm3) that you may not >> be using = >> the current cm3. Is it possible that the NIL dereference problem >> in your = >> example has been solved in a later implementation? >> =20 >> Regards, >> Randy >> >>>>> Mika Nystrom 4/21/2009 5:41 PM >>> >> >> Hello Modula-3ers, >> >> I know this is a question that comes up from time to time, and I >> am aware of Greg Nelson's short article in "Threads" about why=20 >> Modula-3 doesn't map runtime errors to exceptions, but the Green Book >> does allude to mapping runtime errors to exceptions, and I know that >> the SPIN OS did that. >> >> How hard would this be to support in CM3? >> >> Attached is a transcript of an interactive session with my current >> Scheme environment. I think it ought to be obvious why I ask about >> exceptions. In Modula-3, from safe code, only checked runtime errors >> can occur. Checked runtime errors cannot violate invariants of the >> runtime system, so it ought to be safe to convert them to exceptions >> that can be caught, and then permit the program to continue. =20 >> >> I realize this isn't *always* what you want to do, but in an >> interactive >> environment, making the system dump core on runtime errors sort of >> spoils the whole experience. >> >> In this application, there are many places where you may want to >> raise an exception that hasn't been declared. In a non-interactive >> environment, it is probably best to go for the core dump, but in >> an interactive environment, it seems to me it ought to just return >> control to the read-eval-print loop.... > >> Mika >> >> LITHP ITH LITHENING. >>> (define wr (scheme-procedure-stubs-call '(TextWr . New) '())) >> wr >>> wr >> >>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >> #t >>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >> "hello!" >>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >> "" >>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >> #t >>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >> #t >>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >> #t >>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >> #t >>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >> #t >>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >> "hello!hello!hello!hello!hello!" >>> (scheme-procedure-stubs-call '(TextWr . ToText) (list '()) '()) >> >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL >> *** pc =3D 0x80c69c8 =3D LockMutex + 0x28 in /usr/ports/lang/ >> ezm3/work/e= >> zm3-1.0/libs/m3core/src/thread/POSIX/ThreadPosix.m3 >> *** >> >> use option @M3stackdump to get a stack trace >> Abort >> >> >> >> >> >> >> >> 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. >> >> >> --=__PartBC941634.0__= >> Content-Type: text/html; charset=US-ASCII >> Content-Transfer-Encoding: quoted-printable >> Content-Description: HTML >> >> >> > charset=3Diso-8859-15= >> "> >> >> >>
Mika:
>>
 
>>
You state that "Checked runtime errors cannot violate >> invariants of = >> the runtime system, so it ought to be safe to ..."
>>
 
>>
Are you sure this statement is true for all >> implementations?>> >>
 
>>
I would tend to think that SPIN was able to do this mapping >> for = >> itself, but in general, it would be difficult to be able to do this >> for = >> any arbitrary OS environment, esp with differences in underlying >> libraries = >> and implementations, which is part of what Greg alluded to in the >> Threads = >> article you reference.
>>
 
>>
Note also on pg 47 of the green book under "2.5.7 Safety" the >> notes = >> about intrinsic safety and when the compiler makes the guarantee >> vs. the = >> programmer.
>>
 
>>
I also note from the path in your example (ezm3) that you may >> not be = >> using the current cm3.  Is it possible that the NIL >> dereference = >> problem in your example has been solved in a later implementation?> DIV> >>
 
>>
Regards,
>>
Randy

>>> Mika Nystrom <mika at async.caltech.edu >> > = >> 4/21/2009 5:41 PM >>>

Hello Modula-3ers,

I >> know = >> this is a question that comes up from time to time, and I
am >> aware of = >> Greg Nelson's short article in "Threads" about why
Modula-3 >> doesn't = >> map runtime errors to exceptions, but the Green Book
does allude >> to = >> mapping runtime errors to exceptions, and I know that
the SPIN >> OS did = >> that.

How hard would this be to support in CM3? >>

Attached is = >> a transcript of an interactive session with my current
Scheme >> environmen= >> t.  I think it ought to be obvious why I ask >> about
exceptions. = >> ; In Modula-3, from safe code, only checked runtime errors
can = >> occur.  Checked runtime errors cannot violate invariants of >> the
run= >> time system, so it ought to be safe to convert them to >> exceptions
that = >> can be caught, and then permit the program to continue.  >>

I = >> realize this isn't *always* what you want to do, but in an >> interactive
e= >> nvironment, making the system dump core on runtime errors sort >> of
spoils= >> the whole experience.

In this application, there are many >> places = >> where you may want to
raise an exception that hasn't been >> declared. = >> ; In a non-interactive
environment, it is probably best to go >> for the = >> core dump, but in
an interactive environment, it seems to me it >> ought = >> to just return
control to the read-eval-print >> loop....

 &nbs= >> p;   Mika

LITHP ITH LITHENING.
> (define wr = >> (scheme-procedure-stubs-call '(TextWr . New) '()))
wr
> >> wr
<= >> Modula-3 object : TextWr.T, BRANDED TextWr_^%#%^__0001M>
> = >> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") >> '())
#t<= >> BR>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) = >> '())
"hello!"
> (scheme-procedure-stubs-call '(TextWr . >> ToText) = >> (list wr) '())
""
> (scheme-procedure-stubs-call '(Wr . >> PutText) = >> (list wr "hello!") '())
#t
> (scheme-procedure-stubs-call >> '(Wr . = >> PutText) (list wr "hello!") '())
#t
> (scheme-procedure- >> stubs-call= >> '(Wr . PutText) (list wr "hello!") '())
#t
> (scheme- >> procedure-st= >> ubs-call '(Wr . PutText) (list wr "hello!") '())
#t
> >> (scheme-proc= >> edure-stubs-call '(Wr . PutText) (list wr "hello!") >> '())
#t
> = >> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) >> '())
"hello!he= >> llo!hello!hello!hello!"
> (scheme-procedure-stubs-call >> '(TextWr . = >> ToText) (list '()) '())


***
*** runtime >> error:
*** &n= >> bsp;  Segmentation violation - possible attempt to dereference = >> NIL
***    pc =3D 0x80c69c8 =3D LockMutex + 0x28 >> in = >> /usr/ports/lang/ezm3/work/ezm3-1.0/libs/m3core/src/thread/POSIX/ >> ThreadPosix= >> .m3
***

  use option @M3stackdump to get a stack >> trace
Ab= >> ort






>> >> --=__PartBC941634.0__=-- From mika at async.caltech.edu Wed Apr 22 04:38:18 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 21 Apr 2009 19:38:18 -0700 Subject: [M3devel] an old, recurring issue: mapping runtime errors to exceptions? In-Reply-To: Your message of "Wed, 22 Apr 2009 12:26:01 +1000." Message-ID: <200904220238.n3M2cIWk040392@camembert.async.caltech.edu> It's as simple as that!? Wow! Tony Hosking writes: >CM3 does map some (I'm not sure if all) run-time errors to >exceptions. See RuntimeError.i3 for details of what exceptions might >occur. > >On 22 Apr 2009, at 08:41, Mika Nystrom wrote: > >> > Well the point of "safety" is that the system can guarantee that the >> runtime environment hasn't been damaged by a misbehaving program, no? >> >> In fact, in Threads 3 there are not one but *two* reports of >> implementations that "reflect" runtime errors as exceptions. On >> of them is SPIN, the other is the commercial CM3 with JVM. >> >> See >> >> http://www.modula3.org/threads/3/ >> >> Nelson's article in Threads 2 doesn't give the possibility of having >> had the runtime invariants violated as a reason to abort. His >> arguments are more practical, having to do with debugging. I agree, >> and I think that the default method of dealing with runtime errors >> should be to abort the program. But it just is very unfriendly in >> an interactive environment, and I would love some kind of (possibly >> very implementation-dependent) way of catching the runtime error. >> The way Java does it would be ideal, I think..... >> >> Nelson's article is here >> >> http://www.modula3.org/threads/2/ >> >> [Tony, the link in your M3 bibliography is broken!] >> >> I'm running this example in a PM3/EZM3 environment right now but >> that's not relevant. The code I showed you *should* crash. In >> plain M3 it was: >> >> TextWr.ToText(NIL) >> >> But in an interactive environment, the user can do this sort of >> thing. It should give you a nasty error message, not crash your >> whole environment. >> >> Mika >> >> >> >> "Randy Coleburn" writes: >>> This is a MIME message. If you are reading this text, you may want to >>> consider changing to a mail reader or gateway that understands how to >>> properly handle MIME multipart messages. >>> >>> --=__PartBC941634.0__= >>> Content-Type: text/plain; charset=US-ASCII >>> Content-Transfer-Encoding: quoted-printable >>> >>> Mika: >>> =20 >>> You state that "Checked runtime errors cannot violate invariants of >>> the = >>> runtime system, so it ought to be safe to ..." >>> =20 >>> Are you sure this statement is true for all implementations? >>> =20 >>> I would tend to think that SPIN was able to do this mapping for >>> itself, = >>> but in general, it would be difficult to be able to do this for any = >>> arbitrary OS environment, esp with differences in underlying >>> libraries and = >>> implementations, which is part of what Greg alluded to in the >>> Threads = >>> article you reference. >>> =20 >>> Note also on pg 47 of the green book under "2.5.7 Safety" the notes >>> about = >>> intrinsic safety and when the compiler makes the guarantee vs. the = >>> programmer. >>> =20 >>> I also note from the path in your example (ezm3) that you may not >>> be using = >>> the current cm3. Is it possible that the NIL dereference problem >>> in your = >>> example has been solved in a later implementation? >>> =20 >>> Regards, >>> Randy >>> >>>>>> Mika Nystrom 4/21/2009 5:41 PM >>> >>> >>> Hello Modula-3ers, >>> >>> I know this is a question that comes up from time to time, and I >>> am aware of Greg Nelson's short article in "Threads" about why=20 >>> Modula-3 doesn't map runtime errors to exceptions, but the Green Book >>> does allude to mapping runtime errors to exceptions, and I know that >>> the SPIN OS did that. >>> >>> How hard would this be to support in CM3? >>> >>> Attached is a transcript of an interactive session with my current >>> Scheme environment. I think it ought to be obvious why I ask about >>> exceptions. In Modula-3, from safe code, only checked runtime errors >>> can occur. Checked runtime errors cannot violate invariants of the >>> runtime system, so it ought to be safe to convert them to exceptions >>> that can be caught, and then permit the program to continue. =20 >>> >>> I realize this isn't *always* what you want to do, but in an >>> interactive >>> environment, making the system dump core on runtime errors sort of >>> spoils the whole experience. >>> >>> In this application, there are many places where you may want to >>> raise an exception that hasn't been declared. In a non-interactive >>> environment, it is probably best to go for the core dump, but in >>> an interactive environment, it seems to me it ought to just return >>> control to the read-eval-print loop.... >> >>> Mika >>> >>> LITHP ITH LITHENING. >>>> (define wr (scheme-procedure-stubs-call '(TextWr . New) '())) >>> wr >>>> wr >>> >>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>> #t >>>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >>> "hello!" >>>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >>> "" >>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>> #t >>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>> #t >>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>> #t >>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>> #t >>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>> #t >>>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >>> "hello!hello!hello!hello!hello!" >>>> (scheme-procedure-stubs-call '(TextWr . ToText) (list '()) '()) >>> >>> >>> *** >>> *** runtime error: >>> *** Segmentation violation - possible attempt to dereference NIL >>> *** pc =3D 0x80c69c8 =3D LockMutex + 0x28 in /usr/ports/lang/ >>> ezm3/work/e= >>> zm3-1.0/libs/m3core/src/thread/POSIX/ThreadPosix.m3 >>> *** >>> >>> use option @M3stackdump to get a stack trace >>> Abort >>> >>> >>> >>> >>> >>> >>> >>> 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. >>> >>> >>> --=__PartBC941634.0__= >>> Content-Type: text/html; charset=US-ASCII >>> Content-Transfer-Encoding: quoted-printable >>> Content-Description: HTML >>> >>> >>> >> charset=3Diso-8859-15= >>> "> >>> >>> >>>
Mika:
>>>
 
>>>
You state that "Checked runtime errors cannot violate >>> invariants of = >>> the runtime system, so it ought to be safe to ..."
>>>
 
>>>
Are you sure this statement is true for all >>> implementations?>>> >>>
 
>>>
I would tend to think that SPIN was able to do this mapping >>> for = >>> itself, but in general, it would be difficult to be able to do this >>> for = >>> any arbitrary OS environment, esp with differences in underlying >>> libraries = >>> and implementations, which is part of what Greg alluded to in the >>> Threads = >>> article you reference.
>>>
 
>>>
Note also on pg 47 of the green book under "2.5.7 Safety" the >>> notes = >>> about intrinsic safety and when the compiler makes the guarantee >>> vs. the = >>> programmer.
>>>
 
>>>
I also note from the path in your example (ezm3) that you may >>> not be = >>> using the current cm3.  Is it possible that the NIL >>> dereference = >>> problem in your example has been solved in a later implementation?>> DIV> >>>
 
>>>
Regards,
>>>
Randy

>>> Mika Nystrom <mika at async.caltech.edu >>> > = >>> 4/21/2009 5:41 PM >>>

Hello Modula-3ers,

I >>> know = >>> this is a question that comes up from time to time, and I
am >>> aware of = >>> Greg Nelson's short article in "Threads" about why
Modula-3 >>> doesn't = >>> map runtime errors to exceptions, but the Green Book
does allude >>> to = >>> mapping runtime errors to exceptions, and I know that
the SPIN >>> OS did = >>> that.

How hard would this be to support in CM3? >>>

Attached is = >>> a transcript of an interactive session with my current
Scheme >>> environmen= >>> t.  I think it ought to be obvious why I ask >>> about
exceptions. = >>> ; In Modula-3, from safe code, only checked runtime errors
can = >>> occur.  Checked runtime errors cannot violate invariants of >>> the
run= >>> time system, so it ought to be safe to convert them to >>> exceptions
that = >>> can be caught, and then permit the program to continue.  >>>

I = >>> realize this isn't *always* what you want to do, but in an >>> interactive
e= >>> nvironment, making the system dump core on runtime errors sort >>> of
spoils= >>> the whole experience.

In this application, there are many >>> places = >>> where you may want to
raise an exception that hasn't been >>> declared. = >>> ; In a non-interactive
environment, it is probably best to go >>> for the = >>> core dump, but in
an interactive environment, it seems to me it >>> ought = >>> to just return
control to the read-eval-print >>> loop....

 &nbs= >>> p;   Mika

LITHP ITH LITHENING.
> (define wr = >>> (scheme-procedure-stubs-call '(TextWr . New) '()))
wr
> >>> wr
<= >>> Modula-3 object : TextWr.T, BRANDED TextWr_^%#%^__0001M>
> = >>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") >>> '())
#t<= >>> BR>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) = >>> '())
"hello!"
> (scheme-procedure-stubs-call '(TextWr . >>> ToText) = >>> (list wr) '())
""
> (scheme-procedure-stubs-call '(Wr . >>> PutText) = >>> (list wr "hello!") '())
#t
> (scheme-procedure-stubs-call >>> '(Wr . = >>> PutText) (list wr "hello!") '())
#t
> (scheme-procedure- >>> stubs-call= >>> '(Wr . PutText) (list wr "hello!") '())
#t
> (scheme- >>> procedure-st= >>> ubs-call '(Wr . PutText) (list wr "hello!") '())
#t
> >>> (scheme-proc= >>> edure-stubs-call '(Wr . PutText) (list wr "hello!") >>> '())
#t
> = >>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) >>> '())
"hello!he= >>> llo!hello!hello!hello!"
> (scheme-procedure-stubs-call >>> '(TextWr . = >>> ToText) (list '()) '())


***
*** runtime >>> error:
*** &n= >>> bsp;  Segmentation violation - possible attempt to dereference = >>> NIL
***    pc =3D 0x80c69c8 =3D LockMutex + 0x28 >>> in = >>> /usr/ports/lang/ezm3/work/ezm3-1.0/libs/m3core/src/thread/POSIX/ >>> ThreadPosix= >>> .m3
***

  use option @M3stackdump to get a stack >>> trace
Ab= >>> ort






>>> >>> --=__PartBC941634.0__=-- From hosking at cs.purdue.edu Wed Apr 22 04:37:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Apr 2009 12:37:36 +1000 Subject: [M3devel] explanation of CheckLoadTracedRef? In-Reply-To: References: <19C20763-18A0-413A-9440-3D7ED0C918B1@cs.purdue.edu> Message-ID: I believe there is just one check when the parameter is first passed. On 22 Apr 2009, at 10:54, Jay wrote: > Yes this helps, thank you. Maybe checkin under doc? One thing you > didn't understand my wording about and you seemed to contradict is > "VAR to VAR". > > > PROCEDURE F1() = > VAR i; > BEGIN > F2(i); > END F1; > > > PROCEDURE F2(VAR a:INTEGER)= > BEGIN > F3(i); > END F2; > > > PROCEDURE F3(VAR a:INTEGER)= > BEGIN > a := 1; > END F3; > > > Where are the calls to CheckLoad/StoreTracedRef? > (Duh, I can try it out..) > It seems redundant to put them "everywhere". > Esp. it seems that F2 shouldn't have do anything. > > > But throw in that F3 might extern and that is unclear. > So I just made up a suggestion that VAR is not good to pass to C code. > That checks are inserted when 1) a pointer is dereferenced -- loaded > or stored in Modula-3 or 2) a > pointer becomes untraced (var becomes untraced ref, among others). > > > > Right. I think I did see you compute and pass an offset to C code > > > I had something like that very recently but think I didn't set it or > commit it. > I had something like: > > > size_t offset; > > > Init(Mutex* root, int* interior) > { > offset = (size_t)interior - (size_t)root; > } > > > DoSomething(Mutex* anotherRoot) > { > int* interior = (int*)(offset + (size_t)anotherRoot); > printf("%d\n", *interior); > } > > > but I came up with a way to avoid that I think, and then rolled it > all back or something anyway. > > > > - Jay > > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] explanation of CheckLoadTracedRef? > Date: Wed, 22 Apr 2009 10:02:52 +1000 > > On 21 Apr 2009, at 19:37, Jay wrote: > > > > How bad/unportable was it the previous way, the VM-synchronized > way? > > > > Not compatible with system threading. > > > Really? NT386 wasn't VM-synchronized back in 3.6, 4.1, etc.? > > It was, but every system call had to be wrapped with a call to > acquire the global heap lock! > > Or only with great cost? > > Yes, taking the lock was expensive and prevented scaling on multi- > cores. > > I have to admit, those old import .libs, kernel32.lib, etc. I didn't > realize what was in them when I deleted them. I thought they were > just regular import .libs. > > There was also the work to wrap all dll symbols to acquire the lock. > > I think I got luckly in that the overlap between me deleting them > and you removing VM-synchronized GC was small or zero. > > You should have seen the mess it was before... ;-) > > > You should *never* access a field in the heap in C code! All > > accesses to traced fields in the heap must take place in Modula-3. > > Otherwise things will break! C wrappers should not do anything other > > than forward calls to C library calls. They should not perform heap > > accesses. > > > Ok, that makes sense. > Important "out" is the accessing stack is always ok. > > Yes, so long as a references to an object is held on the stack then > it is safe to pass an address within it to external calls. Thus, > many C functions can take VAR arguments that may end being > references to the fields of objects. The compiler injects the > necessary CheckLoad/CheckStore operations when passing VAR > parameters, etc., and the GC maintains the invariant that all stack- > referenced objects don't move, stay black (for incremental GC), and > remain dirty (for generational GC). > > But this is a requirement I didn't keep in mind. > Now, luckily, the C wrappers are all relatively thin and not difficult > to re-review in their entirety. > > Right. I think I did see you compute and pass an offset to C code, > but that may have only been in code you e-mailed me for perusal > rather than code that got checked in. Might be worth reviewing... > > But, take for example "open". > The first parameter to it is bound to be in the heap. > > The ambiguous roots garbage collector we use maintains the invariant > that pointers to the interior of heap objects from the stack *pin* > that object in the heap: it will not move while the pointer from the > stack exists, and invariants will be maintained so that its contenst > can be manipulated safely even in the face of incremental and > generational GC. > > But probably it is untraced or somehow ok, since it does > come from a module used primarily for C interop. > > Certainly, C code should never be manipulating the *traced* fields > of traced heap objects. It is fine for it to manipulate the > untraced fields of traced heap objects. > > And, the line between C wrappers and the "C library" that they > forward to > does not exist. > If I, say, pass a VAR to a VAR..no check is made? > > Not sure what you mean by this. Any call that passes traced VAR > params will generate a check as necessary before the call. > > Important to declare extern/C functions as taking UNTRACED REF and > not VAR? > > No, VAR is fine. So long as the VAR value being passed is not traced. > > > I think you are confusing incremental and incremental GC. > You assume I understand more than I do (I assume you have a typo. :)) > > ;-) > > "generational" -- the concept that most objects die young. > (aka most objects could have been allocated on the stack...) > > Not quite. The idea is that the likelihood of an object dying is a > function of its age. There is a *weak* generational hypothesis that > "most objects die young", and a *strong* generational hypothesis > that "the older an object is the less likely it is to die". Many > (but not all) programs support these hypotheses, which permits > generational GC to focus effort where it is likely to be profitable > (i.e., to free up a lot of space). > > But does that imply detailed implementation choices, or is just like > a "guiding principle"? > I guess it implies the heap is split into at least two generations, > old and young. > Though I guess in reality there is a range of young, less young, > lesser young, least young, etc. > > Right, many different collectors have exploited age in this way. > For the M3 collector we have just two generations: old and young. > > And that has objects age, they should be moved from young to old > heaps, and references to them either updated right away, or "caught" > upon use and updated then...something like that. > > Old-space objects are "clean" if they contain no references to young- > space objects. The Modula-3 compiler injects checks to make sure > that whenever we store a reference into a clean old-space object it > is marked "dirty". When a young-space collection occurs we must > process the references in dirty old-space objects as roots into the > young-space. > > "incremental" -- don't pause the world.. > > Not quite. The opposite of stop-the-world (stopping all the mutator > threads to process their stacks) is on-the-fly. Incremental refers > to the ability to interleave GC work with mutator work. If the GC > work can be interleaved with mutator threads without stopping the > mutator threads at each increment then the collector is said to be > concurrent (GC work proceeds concurrently with mutator work). > The current M3 collector has a stop-the-world non-moving phase, > followed by an concurrent copying phase. I have some incomplete > work that will also make the M3 collector on-the-fly (no STW phase) > and parallel (multiple GC threads can operate concurrently). > > Hope all this helps! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Apr 22 08:54:37 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 22 Apr 2009 08:54:37 +0200 Subject: [M3devel] an old, recurring issue: mapping runtime errors to exceptions? In-Reply-To: <200904220238.n3M2cIWk040392@camembert.async.caltech.edu> References: <200904220238.n3M2cIWk040392@camembert.async.caltech.edu> Message-ID: <20090422085437.i0hqnzu6rk0gw80w@mail.elegosoft.com> Quoting Mika Nystrom : > > It's as simple as that!? IMO it should just work. See m3-sys/m3tests/src/p2/p208/Main.m3: % cat m3-sys/m3tests/src/p2/p208/Main.m3 MODULE Main; IMPORT RuntimeError, IO, Process; CONST Tag = RuntimeError.Tag; PROCEDURE CatchAssert() = BEGIN TRY <*ASSERT FALSE*> EXCEPT RuntimeError.E( t ) => IO.Put( "OK: caught RuntimeError.Assert: " & Tag( t ) & "\n" ); END; END CatchAssert; PROCEDURE TestAll() = BEGIN CatchAssert(); END TestAll; BEGIN TRY <*NOWARN*> TestAll(); EXCEPT ELSE IO.Put( "ERROR: caught unexpected exception\n" ); Process.Exit( 1 ); END; END Main. Olaf > > Wow! > > Tony Hosking writes: >> CM3 does map some (I'm not sure if all) run-time errors to >> exceptions. See RuntimeError.i3 for details of what exceptions might >> occur. >> >> On 22 Apr 2009, at 08:41, Mika Nystrom wrote: >> >>> >> Well the point of "safety" is that the system can guarantee that the >>> runtime environment hasn't been damaged by a misbehaving program, no? >>> >>> In fact, in Threads 3 there are not one but *two* reports of >>> implementations that "reflect" runtime errors as exceptions. On >>> of them is SPIN, the other is the commercial CM3 with JVM. >>> >>> See >>> >>> http://www.modula3.org/threads/3/ >>> >>> Nelson's article in Threads 2 doesn't give the possibility of having >>> had the runtime invariants violated as a reason to abort. His >>> arguments are more practical, having to do with debugging. I agree, >>> and I think that the default method of dealing with runtime errors >>> should be to abort the program. But it just is very unfriendly in >>> an interactive environment, and I would love some kind of (possibly >>> very implementation-dependent) way of catching the runtime error. >>> The way Java does it would be ideal, I think..... >>> >>> Nelson's article is here >>> >>> http://www.modula3.org/threads/2/ >>> >>> [Tony, the link in your M3 bibliography is broken!] >>> >>> I'm running this example in a PM3/EZM3 environment right now but >>> that's not relevant. The code I showed you *should* crash. In >>> plain M3 it was: >>> >>> TextWr.ToText(NIL) >>> >>> But in an interactive environment, the user can do this sort of >>> thing. It should give you a nasty error message, not crash your >>> whole environment. >>> >>> Mika >>> >>> >>> >>> "Randy Coleburn" writes: >>>> This is a MIME message. If you are reading this text, you may want to >>>> consider changing to a mail reader or gateway that understands how to >>>> properly handle MIME multipart messages. >>>> >>>> --=__PartBC941634.0__= >>>> Content-Type: text/plain; charset=US-ASCII >>>> Content-Transfer-Encoding: quoted-printable >>>> >>>> Mika: >>>> =20 >>>> You state that "Checked runtime errors cannot violate invariants of >>>> the = >>>> runtime system, so it ought to be safe to ..." >>>> =20 >>>> Are you sure this statement is true for all implementations? >>>> =20 >>>> I would tend to think that SPIN was able to do this mapping for >>>> itself, = >>>> but in general, it would be difficult to be able to do this for any = >>>> arbitrary OS environment, esp with differences in underlying >>>> libraries and = >>>> implementations, which is part of what Greg alluded to in the >>>> Threads = >>>> article you reference. >>>> =20 >>>> Note also on pg 47 of the green book under "2.5.7 Safety" the notes >>>> about = >>>> intrinsic safety and when the compiler makes the guarantee vs. the = >>>> programmer. >>>> =20 >>>> I also note from the path in your example (ezm3) that you may not >>>> be using = >>>> the current cm3. Is it possible that the NIL dereference problem >>>> in your = >>>> example has been solved in a later implementation? >>>> =20 >>>> Regards, >>>> Randy >>>> >>>>>>> Mika Nystrom 4/21/2009 5:41 PM >>> >>>> >>>> Hello Modula-3ers, >>>> >>>> I know this is a question that comes up from time to time, and I >>>> am aware of Greg Nelson's short article in "Threads" about why=20 >>>> Modula-3 doesn't map runtime errors to exceptions, but the Green Book >>>> does allude to mapping runtime errors to exceptions, and I know that >>>> the SPIN OS did that. >>>> >>>> How hard would this be to support in CM3? >>>> >>>> Attached is a transcript of an interactive session with my current >>>> Scheme environment. I think it ought to be obvious why I ask about >>>> exceptions. In Modula-3, from safe code, only checked runtime errors >>>> can occur. Checked runtime errors cannot violate invariants of the >>>> runtime system, so it ought to be safe to convert them to exceptions >>>> that can be caught, and then permit the program to continue. =20 >>>> >>>> I realize this isn't *always* what you want to do, but in an >>>> interactive >>>> environment, making the system dump core on runtime errors sort of >>>> spoils the whole experience. >>>> >>>> In this application, there are many places where you may want to >>>> raise an exception that hasn't been declared. In a non-interactive >>>> environment, it is probably best to go for the core dump, but in >>>> an interactive environment, it seems to me it ought to just return >>>> control to the read-eval-print loop.... >>> >>>> Mika >>>> >>>> LITHP ITH LITHENING. >>>>> (define wr (scheme-procedure-stubs-call '(TextWr . New) '())) >>>> wr >>>>> wr >>>> >>>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>>> #t >>>>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >>>> "hello!" >>>>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >>>> "" >>>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>>> #t >>>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>>> #t >>>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>>> #t >>>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>>> #t >>>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '()) >>>> #t >>>>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '()) >>>> "hello!hello!hello!hello!hello!" >>>>> (scheme-procedure-stubs-call '(TextWr . ToText) (list '()) '()) >>>> >>>> >>>> *** >>>> *** runtime error: >>>> *** Segmentation violation - possible attempt to dereference NIL >>>> *** pc =3D 0x80c69c8 =3D LockMutex + 0x28 in /usr/ports/lang/ >>>> ezm3/work/e= >>>> zm3-1.0/libs/m3core/src/thread/POSIX/ThreadPosix.m3 >>>> *** >>>> >>>> use option @M3stackdump to get a stack trace >>>> Abort >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> 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. >>>> >>>> >>>> --=__PartBC941634.0__= >>>> Content-Type: text/html; charset=US-ASCII >>>> Content-Transfer-Encoding: quoted-printable >>>> Content-Description: HTML >>>> >>>> >>>> >>> charset=3Diso-8859-15= >>>> "> >>>> >>>> >>>>
Mika:
>>>>
 
>>>>
You state that "Checked runtime errors cannot violate >>>> invariants of = >>>> the runtime system, so it ought to be safe to ..."
>>>>
 
>>>>
Are you sure this statement is true for all >>>> implementations?>>>> >>>>
 
>>>>
I would tend to think that SPIN was able to do this mapping >>>> for = >>>> itself, but in general, it would be difficult to be able to do this >>>> for = >>>> any arbitrary OS environment, esp with differences in underlying >>>> libraries = >>>> and implementations, which is part of what Greg alluded to in the >>>> Threads = >>>> article you reference.
>>>>
 
>>>>
Note also on pg 47 of the green book under "2.5.7 Safety" the >>>> notes = >>>> about intrinsic safety and when the compiler makes the guarantee >>>> vs. the = >>>> programmer.
>>>>
 
>>>>
I also note from the path in your example (ezm3) that you may >>>> not be = >>>> using the current cm3.  Is it possible that the NIL >>>> dereference = >>>> problem in your example has been solved in a later implementation?>>> DIV> >>>>
 
>>>>
Regards,
>>>>
Randy

>>> Mika Nystrom <mika at async.caltech.edu >>>> > = >>>> 4/21/2009 5:41 PM >>>

Hello Modula-3ers,

I >>>> know = >>>> this is a question that comes up from time to time, and I
am >>>> aware of = >>>> Greg Nelson's short article in "Threads" about why
Modula-3 >>>> doesn't = >>>> map runtime errors to exceptions, but the Green Book
does allude >>>> to = >>>> mapping runtime errors to exceptions, and I know that
the SPIN >>>> OS did = >>>> that.

How hard would this be to support in CM3? >>>>

Attached is = >>>> a transcript of an interactive session with my current
Scheme >>>> environmen= >>>> t.  I think it ought to be obvious why I ask >>>> about
exceptions. = >>>> ; In Modula-3, from safe code, only checked runtime errors
can = >>>> occur.  Checked runtime errors cannot violate invariants of >>>> the
run= >>>> time system, so it ought to be safe to convert them to >>>> exceptions
that = >>>> can be caught, and then permit the program to continue.  >>>>

I = >>>> realize this isn't *always* what you want to do, but in an >>>> interactive
e= >>>> nvironment, making the system dump core on runtime errors sort >>>> of
spoils= >>>> the whole experience.

In this application, there are many >>>> places = >>>> where you may want to
raise an exception that hasn't been >>>> declared. = >>>> ; In a non-interactive
environment, it is probably best to go >>>> for the = >>>> core dump, but in
an interactive environment, it seems to me it >>>> ought = >>>> to just return
control to the read-eval-print >>>> loop....

 &nbs= >>>> p;   Mika

LITHP ITH LITHENING.
> (define wr = >>>> (scheme-procedure-stubs-call '(TextWr . New) '()))
wr
> >>>> wr
<= >>>> Modula-3 object : TextWr.T, BRANDED TextWr_^%#%^__0001M>
> = >>>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") >>>> '())
#t<= >>>> BR>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) = >>>> '())
"hello!"
> (scheme-procedure-stubs-call '(TextWr . >>>> ToText) = >>>> (list wr) '())
""
> (scheme-procedure-stubs-call '(Wr . >>>> PutText) = >>>> (list wr "hello!") '())
#t
> (scheme-procedure-stubs-call >>>> '(Wr . = >>>> PutText) (list wr "hello!") '())
#t
> (scheme-procedure- >>>> stubs-call= >>>> '(Wr . PutText) (list wr "hello!") '())
#t
> (scheme- >>>> procedure-st= >>>> ubs-call '(Wr . PutText) (list wr "hello!") '())
#t
> >>>> (scheme-proc= >>>> edure-stubs-call '(Wr . PutText) (list wr "hello!") >>>> '())
#t
> = >>>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) >>>> '())
"hello!he= >>>> llo!hello!hello!hello!"
> (scheme-procedure-stubs-call >>>> '(TextWr . = >>>> ToText) (list '()) '())


***
*** runtime >>>> error:
*** &n= >>>> bsp;  Segmentation violation - possible attempt to dereference = >>>> NIL
***    pc =3D 0x80c69c8 =3D LockMutex + 0x28 >>>> in = >>>> /usr/ports/lang/ezm3/work/ezm3-1.0/libs/m3core/src/thread/POSIX/ >>>> ThreadPosix= >>>> .m3
***

  use option @M3stackdump to get a stack >>>> trace
Ab= >>>> ort






>>>> >>>> --=__PartBC941634.0__=-- > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Wed Apr 22 18:00:03 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 22 Apr 2009 11:00:03 -0500 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: References: <49EC7A06.5040403@cox.net> Message-ID: <49EF3F03.5090104@cox.net> Tony Hosking wrote: > On 20 Apr 2009, at 23:35, Rodney M. Bates wrote: > >> I am going to try to resummarize the various proposals, as their >> description has now gotten rather scattered around in all the >> discussion. >> --------------------------------------------------------------------- >> Mika's proposal (I'll call it the "minimalist" propsal): >> >> Mika, please correct me if I misrepresent what you are proposing. >> >> There are no language changes at all, only changes in implementation. >> The implementation of the existing type REFANY, and no other type, >> allows it to have values whose lsb is nonzero. ISTYPE, NARROW, >> TYPECASE, and narrowing assignments, when and only when applied to >> REFANY, have their generated code fixed so it checks the lsb, and, if >> it is nonzero, consider the runtime type check to have failed, in >> whichever way such a failure is already handled. >> >> The only effect is to liberalize the rules unsafe code must follow to >> avoid undermining the safety of safe code. Only unsafe code can >> create or detect these misaligned values. Today, it must never return >> them in a variable of any reference type, lest the four narrowing >> operations unexpectedly crash. In the proposal, unsafe code would be >> able to return such values in variables of type REFANY, but not any >> other type. > > I don't see why we can't have safe creation of the misaligned values > as per Mika's interface. Well, somebody has to implement that interface, and that module will have to be UNSAFE. You weren't thinking of implementing it in C were you? ;-) > >> Already, the only things safe code can do with values of REFANY are >> copy them around (which would happily work on misaligned values) and >> narrow them. With the implementation of the narrowing operations >> changed, misaligned values can never escape from REFANY variables. >> >> In safe code, there is no way to detect whether a value of type REFANY >> is misaligned. Doing it by elimination, trying to narrow to any >> proper subtype of REFANY, is impractical, as there are an unbounded >> number of REF types to eliminate. > > An alternative would be to loosen the language spec to allow > TYPECODE(REFANY) and use this typecode for tagged references. Then > one can explicitly test for it without elimination of alternatives. > >> If there is more than one abstract data type that uses this mechanism, >> client code can not be prevented from mixing up values from the >> different abstractions. (Perhaps this could be fixed by a language >> change allowing BRANDED REFANY?) > > Indeed. > >> --------------------------------------------------------------------- >> My (Rodney's) "safe" proposal: >> >> There is a new type named TAGABLE. It is a subrange of INTEGER, whose >> bounds are implementation-defined. These can be queried by the >> existing FIRST and LAST functions. Similar to CARDINAL, it has all >> the properties of a subrange type but is not the same type as the >> corresponding subrange. >> >> There is a new type constructor TAGGED. If T is any traced or object >> type, including branded and opaque types, then TAGGED T is a new type >> whose value set is the union of the value sets of T and TAGABLE. >> Moreover, >> >> TAGABLE <: TAGGED T >> T <: TAGGED T. >> >> IF T # U, then TAGGED T and TAGGED U are not the same type and have no >> subtype or assignability relation to each other. >> >> The semantics of ISTYPE, NARROW, TYPECASE, and assignability of a type >> to a type are generalized so that their to-be-narrowed operand can >> have a tagged type, and if it does, their to-be-narrowed-to type can >> be TAGABLE. > > Hmm. It seems there is a nasty loophole in your spec. > Consider: > > TYPE T = BRANDED OBJECT END > TYPE U = BRANDED OBJECT END > > These are unrelated types. > > Now, the rules let me take: > > t: TAGGED T > > and obtain: > > i: TAGABLE := NARROW(t, TAGABLE); > > But TAGABLE <: TAGGED U > > so I can do: > > u: TAGGED U := t; > > Is that your intention? > >> >> >> Comments: >> >> Making TAGGED T have no relation to TAGGED U avoids a lot of really >> complicated type equality and subtype rules. The former would be a >> drastic departure from the current state of Modula-3. >> >> It is up to the implementation to decide the bit representation of >> tagged types, including how values of TAGABLE will be distinguished >> from reference values. Though the language would not require it, most >> likely a word the same size as a pointer will be used. Using the lsb >> as the tag bit is an efficient encoding, because in any currently >> conceivable machine, it will be zero for all pointers to heap objects. >> There is no reason pickles would have to use the same representation >> as compiler-generated code. >> >> The implementation should define the bounds of TAGABLE to be whatever >> it can fit in its representation, after removing the values that are >> true pointers. If the lsb is used as a tag, this will no doubt be a >> 31-bit integer on a 32-bit machine and 63-bit integer on a 64-bit >> machine. The language wouldn't even specify whether it is signed, >> although somehow unsigned seems nice to me. If it is unsigned and the >> suggested encodings are used, TAGABLE would have the same bounds as >> CARDINAL, but it really should be a separate type, so as not to >> overconstrain the implementation. >> >> If T is branded, then the effects of branding will propagate to TAGGED >> T, thus allowing independent abstract data types to ensure each one's >> values can't be mixed up with the other's. This will statically >> detect misuses by client code. However, TAGGED T is not a branded >> type. >> >> If T is an opaque type, then TAGGED T can be used to combine the space >> efficiency of tagging with the ability of an opaque type to reveal >> some but not all of its properties. To use this, client code will >> have to narrow a value first, since access to methods/fields could not >> have a definable meaning for a value in TAGABLE. >> >> On the other hand, T could be an opaque subtype of REFANY, thus >> revealing almost nothing about TAGGED T to clients. This would give >> tagged types the existing ability of ensuring statically, that the >> code in a revealed context will never get TAGGED REFANY, thus avoiding >> extra runtime type checks. > > From rodney.m.bates at cox.net Wed Apr 22 18:33:13 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 22 Apr 2009 11:33:13 -0500 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: References: <49EC7A06.5040403@cox.net> <20090421122648.GB25465@topoi.pooq.com> Message-ID: <49EF46C9.6050503@cox.net> Tony Hosking wrote: > I'd prefer something like TAGGEDINT or some such. But I am still not > convinced that the minimalist proposal and this proposal differ in any > significant way. The minimalist proposal forces you to give up some static safety you have in the current language, that the safe proposal allows. In the minimalist proposal, you cannot both use tagged pointers and have any of the following: 1) An abstract data type T can (and today virtually always is) some proper subtype of REFANY. This statically restricts values to this type. In minimalist, T can only be declared REFANY, allowing a client to provide a value that was neither tagged nor of the type the abstraction expects. Instead, the type constraint will be checked at runtime, on every call into the abstraction. And this is a more expensive check than just a tag bit check. Aside from the overhead, going from static to runtime type checking requires an extensive test suite to get somewhere short of the same level of confidence that a mere compile would guarantee. In the safe proposal, T could be replaced by TAGGED T, and the static rules would guarantee its values are always either integer or T, comparable to the current language. 2) If there is more than one abstraction that uses tagged types, minimalist loses static guarantee that they are not mixed up by client code. Since Abs1.T and Abs2.T must both be REFANY, a client can get a value from Abs1 and pass it to Abs2. Again, this is a demotion of static to runtime type checking. In safe, Abs1.T and Abs2.T could be tagged types built from different opaque types, giving the same separation that we get in the current language. 3) The type declared in an abstraction can currently be an opaque subtype of some proper subtype of REFANY. This allows the abstraction writer to give clients the ability to directly access some fields/methods, while hiding others. Once again, the restriction that only REFANY can be tagged makes this impossible in minimalist. I suppose this could be worked around by providing accessors, mutators, and plain procedures in the abstraction, but then these would have to take REFANY too, just making for more instances of loss of static checking. > > On 21 Apr 2009, at 22:26, hendrik at topoi.pooq.com wrote: > >> On Mon, Apr 20, 2009 at 08:35:02AM -0500, Rodney M. Bates wrote: >>> >>> --------------------------------------------------------------------- >>> My (Rodney's) "safe" proposal: >>> >>> There is a new type named TAGABLE. It is a subrange of INTEGER, whose >> >> Please spell it TAGGABLE. TAG doubles its last consonant when adding >> suffixes: TAGGED, TAGGING. >> >> -- hendrik > > From mika at async.caltech.edu Thu Apr 23 01:41:22 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 22 Apr 2009 16:41:22 -0700 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: Your message of "Wed, 22 Apr 2009 11:00:03 CDT." <49EF3F03.5090104@cox.net> Message-ID: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> "Rodney M. Bates" writes: >Tony Hosking wrote: >> On 20 Apr 2009, at 23:35, Rodney M. Bates wrote: >> >>> I am going to try to resummarize the various proposals, as their >>> description has now gotten rather scattered around in all the >>> discussion. >>> --------------------------------------------------------------------- >>> Mika's proposal (I'll call it the "minimalist" propsal): >>> >>> Mika, please correct me if I misrepresent what you are proposing. >>> >>> There are no language changes at all, only changes in implementation. >>> The implementation of the existing type REFANY, and no other type, >>> allows it to have values whose lsb is nonzero. ISTYPE, NARROW, >>> TYPECASE, and narrowing assignments, when and only when applied to >>> REFANY, have their generated code fixed so it checks the lsb, and, if >>> it is nonzero, consider the runtime type check to have failed, in >>> whichever way such a failure is already handled. >>> >>> The only effect is to liberalize the rules unsafe code must follow to >>> avoid undermining the safety of safe code. Only unsafe code can >>> create or detect these misaligned values. Today, it must never return >>> them in a variable of any reference type, lest the four narrowing >>> operations unexpectedly crash. In the proposal, unsafe code would be >>> able to return such values in variables of type REFANY, but not any >>> other type. This is pretty much exactly what I was proposing, yes. Only one point to add, and that is that you need a TYPECODE value. I think Tony and I discussed having all the ISTYPE etc. behave as if the tagged values were of a specific opaque type that cannot be dereferenced, newed, etc., in safe modules. (I.e., revealed as <: REFANY only) This seems conceptually simpler than introducing a "nonexistent" type, and has the same safety properties. >> >> I don't see why we can't have safe creation of the misaligned values >> as per Mika's interface. > >Well, somebody has to implement that interface, and that module will >have to be UNSAFE. >You weren't thinking of implementing it in C were you? ;-) I don't see how to do it "safely" unless you add it to the compiler itself? (Which means it's no longer minimalist!) >> >>> Already, the only things safe code can do with values of REFANY are >>> copy them around (which would happily work on misaligned values) and >>> narrow them. With the implementation of the narrowing operations >>> changed, misaligned values can never escape from REFANY variables. >>> >>> In safe code, there is no way to detect whether a value of type REFANY >>> is misaligned. Doing it by elimination, trying to narrow to any >>> proper subtype of REFANY, is impractical, as there are an unbounded >>> number of REF types to eliminate. >> >> An alternative would be to loosen the language spec to allow >> TYPECODE(REFANY) and use this typecode for tagged references. Then >> one can explicitly test for it without elimination of alternatives. Yes you could do this or use the specific type idea mentioned above. I don't see what harm there is in letting a safe module know that it's holding a tagged value. Nothing it can do with that information anyhow... it can't extract the value. >> >>> If there is more than one abstract data type that uses this mechanism, >>> client code can not be prevented from mixing up values from the >>> different abstractions. (Perhaps this could be fixed by a language >>> change allowing BRANDED REFANY?) >> >> Indeed. Right. As it stands, the clients would have to sort on what's going on inside. No help from compiler or runtime. You can't do anything about what's checkable at runtime, but adding TAGGED could let you check a lot of things at compile time. I still think, though (referring to what's below), that the advantage of not having to change existing "container" code outweighs the cost of checking the LSB (which is likely to be negligble), and I would therefore recommend that the type called "REFANY" be able to hold "TAGGED" values after such a language change. Mika >> >>> --------------------------------------------------------------------- >>> My (Rodney's) "safe" proposal: >>> >>> There is a new type named TAGABLE. It is a subrange of INTEGER, whose >>> bounds are implementation-defined. These can be queried by the >>> existing FIRST and LAST functions. Similar to CARDINAL, it has all >>> the properties of a subrange type but is not the same type as the >>> corresponding subrange. >>> >>> There is a new type constructor TAGGED. If T is any traced or object >>> type, including branded and opaque types, then TAGGED T is a new type >>> whose value set is the union of the value sets of T and TAGABLE. >>> Moreover, >>> >>> TAGABLE <: TAGGED T >>> T <: TAGGED T. >>> >>> IF T # U, then TAGGED T and TAGGED U are not the same type and have no >>> subtype or assignability relation to each other. >>> >>> The semantics of ISTYPE, NARROW, TYPECASE, and assignability of a type >>> to a type are generalized so that their to-be-narrowed operand can >>> have a tagged type, and if it does, their to-be-narrowed-to type can >>> be TAGABLE. >> >> Hmm. It seems there is a nasty loophole in your spec. >> Consider: >> >> TYPE T = BRANDED OBJECT END >> TYPE U = BRANDED OBJECT END >> >> These are unrelated types. >> >> Now, the rules let me take: >> >> t: TAGGED T >> >> and obtain: >> >> i: TAGABLE := NARROW(t, TAGABLE); >> >> But TAGABLE <: TAGGED U >> >> so I can do: >> >> u: TAGGED U := t; >> >> Is that your intention? >> >>> >>> >>> Comments: >>> >>> Making TAGGED T have no relation to TAGGED U avoids a lot of really >>> complicated type equality and subtype rules. The former would be a >>> drastic departure from the current state of Modula-3. >>> >>> It is up to the implementation to decide the bit representation of >>> tagged types, including how values of TAGABLE will be distinguished >>> from reference values. Though the language would not require it, most >>> likely a word the same size as a pointer will be used. Using the lsb >>> as the tag bit is an efficient encoding, because in any currently >>> conceivable machine, it will be zero for all pointers to heap objects. >>> There is no reason pickles would have to use the same representation >>> as compiler-generated code. >>> >>> The implementation should define the bounds of TAGABLE to be whatever >>> it can fit in its representation, after removing the values that are >>> true pointers. If the lsb is used as a tag, this will no doubt be a >>> 31-bit integer on a 32-bit machine and 63-bit integer on a 64-bit >>> machine. The language wouldn't even specify whether it is signed, >>> although somehow unsigned seems nice to me. If it is unsigned and the >>> suggested encodings are used, TAGABLE would have the same bounds as >>> CARDINAL, but it really should be a separate type, so as not to >>> overconstrain the implementation. >>> >>> If T is branded, then the effects of branding will propagate to TAGGED >>> T, thus allowing independent abstract data types to ensure each one's >>> values can't be mixed up with the other's. This will statically >>> detect misuses by client code. However, TAGGED T is not a branded >>> type. >>> >>> If T is an opaque type, then TAGGED T can be used to combine the space >>> efficiency of tagging with the ability of an opaque type to reveal >>> some but not all of its properties. To use this, client code will >>> have to narrow a value first, since access to methods/fields could not >>> have a definable meaning for a value in TAGABLE. >>> >>> On the other hand, T could be an opaque subtype of REFANY, thus >>> revealing almost nothing about TAGGED T to clients. This would give >>> tagged types the existing ability of ensuring statically, that the >>> code in a revealed context will never get TAGGED REFANY, thus avoiding >>> extra runtime type checks. >> >> From mika at async.caltech.edu Thu Apr 23 01:51:10 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 22 Apr 2009 16:51:10 -0700 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: Your message of "Wed, 22 Apr 2009 11:33:13 CDT." <49EF46C9.6050503@cox.net> Message-ID: <200904222351.n3MNpA3v086629@camembert.async.caltech.edu> Rodney, Yes I agree that minimalist doesn't solve your problems as well as TAGGED does. However, if you allow REFANY to hold tagged values in the future (once you have TAGGED in the language), adding TAGGED will be a backward-compatible step on top of minimalist. In my application anything that might want to be TAGGED is today declared as (exactly) REFANY, so I'm happy either way. But of course I realize I am not the only Modula-3 programmer in the world (even if sometimes it does feel a bit like it). Mika "Rodney M. Bates" writes: >Tony Hosking wrote: >> I'd prefer something like TAGGEDINT or some such. But I am still not >> convinced that the minimalist proposal and this proposal differ in any >> significant way. >The minimalist proposal forces you to give up some static safety you have >in the current language, that the safe proposal allows. In the minimalist >proposal, you cannot both use tagged pointers and have any of the >following: > >1) An abstract data type T can (and today virtually always is) some >proper subtype > of REFANY. This statically restricts values to this type. In >minimalist, T can > only be declared REFANY, allowing a client to provide a value that >was neither > tagged nor of the type the abstraction expects. Instead, the type >constraint will be > checked at runtime, on every call into the abstraction. And this >is a more expensive > check than just a tag bit check. Aside from the overhead, going >from static to runtime type checking requires an extensive test suite to get >somewhere short > of the same level of confidence that a mere compile would >guarantee. In the safe > proposal, T could be replaced by TAGGED T, and the static rules >would guarantee > its values are always either integer or T, comparable to the current >language. > >2) If there is more than one abstraction that uses tagged types, >minimalist loses static > guarantee that they are not mixed up by client code. Since Abs1.T >and Abs2.T must > both be REFANY, a client can get a value from Abs1 and pass it to >Abs2. Again, this > is a demotion of static to runtime type checking. In safe, Abs1.T >and Abs2.T could > be tagged types built from different opaque types, giving the same >separation that > we get in the current language. > >3) The type declared in an abstraction can currently be an opaque >subtype of some > proper subtype of REFANY. This allows the abstraction writer to >give clients the > ability to directly access some fields/methods, while hiding >others. Once again, > the restriction that only REFANY can be tagged makes this impossible >in minimalist. > I suppose this could be worked around by providing accessors, >mutators, and plain > procedures in the abstraction, but then these would have to take >REFANY too, just > making for more instances of loss of static checking. >> >> On 21 Apr 2009, at 22:26, hendrik at topoi.pooq.com wrote: >> >>> On Mon, Apr 20, 2009 at 08:35:02AM -0500, Rodney M. Bates wrote: >>>> >>>> --------------------------------------------------------------------- >>>> My (Rodney's) "safe" proposal: >>>> >>>> There is a new type named TAGABLE. It is a subrange of INTEGER, whose >>> >>> Please spell it TAGGABLE. TAG doubles its last consonant when adding >>> suffixes: TAGGED, TAGGING. >>> >>> -- hendrik >> >> From hosking at cs.purdue.edu Thu Apr 23 03:07:25 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 23 Apr 2009 11:07:25 +1000 Subject: [M3devel] Resummary of tagged reference proposals In-Reply-To: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> References: <200904222341.n3MNfMkp086142@camembert.async.caltech.edu> Message-ID: <690A324D-3F1A-433F-BFC0-78CFF9D22713@cs.purdue.edu> On 23 Apr 2009, at 09:41, Mika Nystrom wrote: > "Rodney M. Bates" writes: >> Tony Hosking wrote: >>> On 20 Apr 2009, at 23:35, Rodney M. Bates wrote: >>> >>>> I am going to try to resummarize the various proposals, as their >>>> description has now gotten rather scattered around in all the >>>> discussion. >>>> --------------------------------------------------------------------- >>>> Mika's proposal (I'll call it the "minimalist" propsal): >>>> >>>> Mika, please correct me if I misrepresent what you are proposing. >>>> >>>> There are no language changes at all, only changes in >>>> implementation. >>>> The implementation of the existing type REFANY, and no other type, >>>> allows it to have values whose lsb is nonzero. ISTYPE, NARROW, >>>> TYPECASE, and narrowing assignments, when and only when applied to >>>> REFANY, have their generated code fixed so it checks the lsb, >>>> and, if >>>> it is nonzero, consider the runtime type check to have failed, in >>>> whichever way such a failure is already handled. >>>> >>>> The only effect is to liberalize the rules unsafe code must >>>> follow to >>>> avoid undermining the safety of safe code. Only unsafe code can >>>> create or detect these misaligned values. Today, it must never >>>> return >>>> them in a variable of any reference type, lest the four narrowing >>>> operations unexpectedly crash. In the proposal, unsafe code >>>> would be >>>> able to return such values in variables of type REFANY, but not any >>>> other type. > > This is pretty much exactly what I was proposing, yes. > > Only one point to add, and that is that you need a TYPECODE value. Yes. I currently have a full-blown implementation in the compiler and run-time that uses RT0.RefanyTypecode as the typecode. Since the only thing that will respond with the typecode are tagged references, and it is not legal to say TYPECODE(REFANY) we can hide that fact in an implementation of the tagged interface where we use TYPECODE(r) = RT0.RefanyTypecode, or ISTYPE(r, RT0.RefanyTypecode). Currently, no other type in the system will respond with that. > I think Tony and I discussed having all the ISTYPE etc. behave as > if the tagged values were of a specific opaque type that cannot be > dereferenced, newed, etc., in safe modules. (I.e., revealed as <: > REFANY only) Done (modulo what typecode to use as described above). > This seems conceptually simpler than introducing a "nonexistent" > type, and has the same safety properties. > >>> >>> I don't see why we can't have safe creation of the misaligned values >>> as per Mika's interface. >> >> Well, somebody has to implement that interface, and that module will >> have to be UNSAFE. >> You weren't thinking of implementing it in C were you? ;-) > > I don't see how to do it "safely" unless you add it to the compiler > itself? (Which means it's no longer minimalist!) It would be hidden behind a safe interface. >>>> Already, the only things safe code can do with values of REFANY are >>>> copy them around (which would happily work on misaligned values) >>>> and >>>> narrow them. With the implementation of the narrowing operations >>>> changed, misaligned values can never escape from REFANY variables. >>>> >>>> In safe code, there is no way to detect whether a value of type >>>> REFANY >>>> is misaligned. Doing it by elimination, trying to narrow to any >>>> proper subtype of REFANY, is impractical, as there are an unbounded >>>> number of REF types to eliminate. >>> >>> An alternative would be to loosen the language spec to allow >>> TYPECODE(REFANY) and use this typecode for tagged references. Then >>> one can explicitly test for it without elimination of alternatives. > > Yes you could do this or use the specific type idea mentioned above. > > I don't see what harm there is in letting a safe module know that > it's holding a tagged value. Nothing it can do with that information > anyhow... it can't extract the value. > >>> >>>> If there is more than one abstract data type that uses this >>>> mechanism, >>>> client code can not be prevented from mixing up values from the >>>> different abstractions. (Perhaps this could be fixed by a language >>>> change allowing BRANDED REFANY?) >>> >>> Indeed. > > Right. As it stands, the clients would have to sort on what's going > on inside. No help from compiler or runtime. You can't do anything > about what's checkable at runtime, but adding TAGGED could let you > check a lot of things at compile time. > > I still think, though (referring to what's below), that the advantage > of not having to change existing "container" code outweighs the > cost of checking the LSB (which is likely to be negligble), and I > would > therefore recommend that the type called "REFANY" be able to hold > "TAGGED" > values after such a language change. Right. > > > Mika > >>> >>>> --------------------------------------------------------------------- >>>> My (Rodney's) "safe" proposal: >>>> >>>> There is a new type named TAGABLE. It is a subrange of INTEGER, >>>> whose >>>> bounds are implementation-defined. These can be queried by the >>>> existing FIRST and LAST functions. Similar to CARDINAL, it has all >>>> the properties of a subrange type but is not the same type as the >>>> corresponding subrange. >>>> >>>> There is a new type constructor TAGGED. If T is any traced or >>>> object >>>> type, including branded and opaque types, then TAGGED T is a new >>>> type >>>> whose value set is the union of the value sets of T and TAGABLE. >>>> Moreover, >>>> >>>> TAGABLE <: TAGGED T >>>> T <: TAGGED T. >>>> >>>> IF T # U, then TAGGED T and TAGGED U are not the same type and >>>> have no >>>> subtype or assignability relation to each other. >>>> >>>> The semantics of ISTYPE, NARROW, TYPECASE, and assignability of a >>>> type >>>> to a type are generalized so that their to-be-narrowed operand can >>>> have a tagged type, and if it does, their to-be-narrowed-to type >>>> can >>>> be TAGABLE. >>> >>> Hmm. It seems there is a nasty loophole in your spec. >>> Consider: >>> >>> TYPE T = BRANDED OBJECT END >>> TYPE U = BRANDED OBJECT END >>> >>> These are unrelated types. >>> >>> Now, the rules let me take: >>> >>> t: TAGGED T >>> >>> and obtain: >>> >>> i: TAGABLE := NARROW(t, TAGABLE); >>> >>> But TAGABLE <: TAGGED U >>> >>> so I can do: >>> >>> u: TAGGED U := t; >>> >>> Is that your intention? >>> >>>> >>>> >>>> Comments: >>>> >>>> Making TAGGED T have no relation to TAGGED U avoids a lot of really >>>> complicated type equality and subtype rules. The former would be a >>>> drastic departure from the current state of Modula-3. >>>> >>>> It is up to the implementation to decide the bit representation of >>>> tagged types, including how values of TAGABLE will be distinguished >>>> from reference values. Though the language would not require it, >>>> most >>>> likely a word the same size as a pointer will be used. Using the >>>> lsb >>>> as the tag bit is an efficient encoding, because in any currently >>>> conceivable machine, it will be zero for all pointers to heap >>>> objects. >>>> There is no reason pickles would have to use the same >>>> representation >>>> as compiler-generated code. >>>> >>>> The implementation should define the bounds of TAGABLE to be >>>> whatever >>>> it can fit in its representation, after removing the values that >>>> are >>>> true pointers. If the lsb is used as a tag, this will no doubt >>>> be a >>>> 31-bit integer on a 32-bit machine and 63-bit integer on a 64-bit >>>> machine. The language wouldn't even specify whether it is signed, >>>> although somehow unsigned seems nice to me. If it is unsigned >>>> and the >>>> suggested encodings are used, TAGABLE would have the same bounds as >>>> CARDINAL, but it really should be a separate type, so as not to >>>> overconstrain the implementation. >>>> >>>> If T is branded, then the effects of branding will propagate to >>>> TAGGED >>>> T, thus allowing independent abstract data types to ensure each >>>> one's >>>> values can't be mixed up with the other's. This will statically >>>> detect misuses by client code. However, TAGGED T is not a branded >>>> type. >>>> >>>> If T is an opaque type, then TAGGED T can be used to combine the >>>> space >>>> efficiency of tagging with the ability of an opaque type to reveal >>>> some but not all of its properties. To use this, client code will >>>> have to narrow a value first, since access to methods/fields >>>> could not >>>> have a definable meaning for a value in TAGABLE. >>>> >>>> On the other hand, T could be an opaque subtype of REFANY, thus >>>> revealing almost nothing about TAGGED T to clients. This would >>>> give >>>> tagged types the existing ability of ensuring statically, that the >>>> code in a revealed context will never get TAGGED REFANY, thus >>>> avoiding >>>> extra runtime type checks. >>> >>> From mika at async.caltech.edu Fri Apr 24 08:54:46 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 23 Apr 2009 23:54:46 -0700 Subject: [M3devel] bug in Wx.ToText, CM3 TEXTs Message-ID: <200904240654.n3O6skJM072255@camembert.async.caltech.edu> Hello Modula-3ers, These CM3 TEXTs simply won't stop dogging me! There's a bug that I just fixed in Wx.ToText. I seem not to have the repository checked out as me again, so could I bother someone else to commit the change? Synopsis -------- Under SRC and P M3, the way you created a new TEXT of a given size was you imported TextF and allocated a TEXT using NEW(TEXT, n + 1) where n is the length of the TEXT you want. Under CM3, you're supposed to call (e.g.) Text8.New(n) Line 171 of Wx.m3 has: PROCEDURE ToText (t: T): TEXT = VAR txt := Text8.Create(t.nFull * ChunkSize + t.next + 1); (* line 171 *) c := t.head; n := 0; BEGIN (The code t.nFull + ... + 1 is copied exactly from the older implementation, and is wrong.) Fix --- The 1 needs to be removed, to make: PROCEDURE ToText (t: T): TEXT = VAR txt := Text8.Create(t.nFull * ChunkSize + t.next); (* line 171 *) c := t.head; n := 0; BEGIN The path is m3-libs/libbuf/src/Wx.m3 I'm surprised no one has noticed this before. Does no one else use Wx? Mika From mika at async.caltech.edu Fri Apr 24 18:57:32 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 24 Apr 2009 09:57:32 -0700 Subject: [M3devel] Sneaky C++isms in m3cc Message-ID: <200904241657.n3OGvWh4000584@camembert.async.caltech.edu> As usual, my quest to switch to CM3 ends up in my attempting (usually not very well) to bootstrap CM3. This time I am trying to build with cm3 5.3.1 on FreeBSD 4.11. The reason for this is that the "FreeBSD4" snapshot on elego does not appear to be a FreeBSD4 snapshot at all. Anyone know what OS this builds on? (Links to the 5.5.0 -min I contributed from a real FreeBSD 4 system are broken, and I can't find the source myself.) But enough of that. I noticed the following in parse.c (under m3cc): 2395 static void 2396 m3cg_set_source_line (void) 2397 { 2398 INTEGER (i); 2399 2400 if (option_source_line_trace) fprintf(stderr, " source line %4ld\n", i); 2401 #ifdef USE_MAPPED_LOCATION 2402 source_location s = linemap_line_start (line_table, i, 80); 2403 input_location = s; 2404 #else 2405 input_line = i; 2406 #endif 2407 } The code on line 2402 is a C++ism. You cannot declare variables in the middle of code in C. Unless it has changed with the new version of C, but it still won't build with older C compilers. (I'm using gcc 2.95.4) Mika From jay.krell at cornell.edu Sat Apr 25 00:02:23 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 24 Apr 2009 22:02:23 +0000 Subject: [M3devel] Sneaky C++isms in m3cc In-Reply-To: <200904241657.n3OGvWh4000584@camembert.async.caltech.edu> References: <200904241657.n3OGvWh4000584@camembert.async.caltech.edu> Message-ID: It's 7.0 or 7.1. file should tell you this. In time it should be renamed I386_FREEBSD. In time maybe I'll get out regular "boot" archives that are version-independent. The Modula-3 code pretty much only interfaces with our own C code, thus making the assembly for our Modula-3 ABI-independent (the part of ABI that is the signatures of open, etc., not the part that is the function call protocol). I'll fix the C++-ism. Well understood. - Jay ---------------------------------------- > To: m3devel at elegosoft.com > Date: Fri, 24 Apr 2009 09:57:32 -0700 > From: mika at async.caltech.edu > CC: mika at camembert.async.caltech.edu > Subject: [M3devel] Sneaky C++isms in m3cc > > > As usual, my quest to switch to CM3 ends up in my attempting (usually > not very well) to bootstrap CM3. This time I am trying to build with > cm3 5.3.1 on FreeBSD 4.11. > > The reason for this is that the "FreeBSD4" snapshot on elego does > not appear to be a FreeBSD4 snapshot at all. Anyone know what OS > this builds on? (Links to the 5.5.0 -min I contributed from a real > FreeBSD 4 system are broken, and I can't find the source myself.) > > But enough of that. I noticed the following in parse.c (under m3cc): > > 2395 static void > 2396 m3cg_set_source_line (void) > 2397 { > 2398 INTEGER (i); > 2399 > 2400 if (option_source_line_trace) fprintf(stderr, " source line %4ld\n", i); > 2401 #ifdef USE_MAPPED_LOCATION > 2402 source_location s = linemap_line_start (line_table, i, 80); > 2403 input_location = s; > 2404 #else > 2405 input_line = i; > 2406 #endif > 2407 } > > The code on line 2402 is a C++ism. You cannot declare variables > in the middle of code in C. Unless it has changed with the new > version of C, but it still won't build with older C compilers. (I'm > using gcc 2.95.4) > > Mika > From mika at async.caltech.edu Sat Apr 25 00:12:20 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 24 Apr 2009 15:12:20 -0700 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? Message-ID: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> Hi Modula-3ers, I'm trying to boot CM3 on FreeBSD 4.11 right now. Yes, I know it's an old system, but really, the older, the better. Once I have it running on 4.11, I'll have a binary archive that should work on *any* FreeBSD system from 4.x up to 7.x, not just the latest releases. My problems are not with FreeBSD. Well to some extent they are. I had to turn off pthreads: FreeBSD 4 has only a partial implementation, from what I can tell (in libc_r, not libpthreads) No, what's going on is I am trying to boot with CM3 5.3.1, which was the most recent binary I was able to get running on my FreeBSD 4 system. I inserted lots and lots of "LONGINT = INTEGER" in the code, but I'm still running into this one: -> linking cm3 UtilsPosix.mo: In function `UtilsPosix__MakeRelative': /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:23: undefined reference to `ThreadF__handlerStack' /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:23: undefined reference to `ThreadF__handlerStack' /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:33: undefined reference to `ThreadF__handlerStack' /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:50: undefined reference to `ThreadF__handlerStack' /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:60: undefined reference to `ThreadF__handlerStack' Builder.mo:/home/mika/cm3-cvs/cm3/m3-sys/cm3/FreeBSD4/Builder.m3:188: more undefined references to `ThreadF__handlerStack' follow Fatal Error: package build failed No matter what I try... I tried to make ThreadF.handlerStack invariantly equal to ThreadPosix.self.context.handlers... it won't link. Somehow it's not letting me slip in a "handlerStack" in the interface? Anyone have an idea for workarounds? Mika From mika at async.caltech.edu Sat Apr 25 00:20:00 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 24 Apr 2009 15:20:00 -0700 Subject: [M3devel] Suspicious code in Cstdio.i3 for FreeBSD Message-ID: <200904242220.n3OMK0K3016010@camembert.async.caltech.edu> This code looks a bit suspicious: FILE = RECORD p : unsigned_char_star; (* current position in (some) buffer *) r : int; (* read space left for getc() *) w : int; (* write space left for putc() *) flags : short_int; (* flags, below; this FILE is free if 0 *) file : short_int; (* fileno, if Unix descriptor, else -1 *) bf : SBUF; (* the buffer (at least 1 byte, if !NULL) *) lbfsize : int; (* 0 or -_bf._size, for inline putc *) (* operations *) cookie : void_star; (* cookie passed to io functions *) xxclose: void_star; xxread : void_star; xxseek : void_star; xxwrite: void_star; (* separate buffer for long sequences of ungetc() *) ub : SBUF; (* ungetc buffer *) up : unsigned_char_star; (* saved _p when _p is doing ungetc data *) ur : int; (* saved _r when _r is counting ungetc data *) (* tricks to meet minimum requirements even when malloc() fails *) ubuf : ARRAY[0..2] OF unsigned_char; (* guarantee an ungetc() buffer *) nbuf : ARRAY[0..0] OF unsigned_char; (* guarantee a getc() buffer *) (* separate buffer for fgetln() when line crosses buffer boundary *) lb : SBUF; (* buffer for fgetln() *) (* Unix stdio files get aligned to block boundaries on fseek() *) blksize : int; (* stat.st_blksize (may be != _bf._size) *) offset : off_t; (* current lseek offset *) pad1 : int; (* assume high 4 bytes of offset are 0 *) END; Note the "offset" and "pad1". Now... off_t = int64_t; int64_t = BITS 64 FOR Ctypes.long_long; Is this right or is there a bit too much padding here? Is the padding also assuming little-endianness? Hmm... Mika From jay.krell at cornell.edu Sat Apr 25 00:22:53 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 24 Apr 2009 22:22:53 +0000 Subject: [M3devel] Suspicious code in Cstdio.i3 for FreeBSD In-Reply-To: <200904242220.n3OMK0K3016010@camembert.async.caltech.edu> References: <200904242220.n3OMK0K3016010@camembert.async.caltech.edu> Message-ID: I believe this is all dead anyway. - Jay ---------------------------------------- > To: m3devel at elegosoft.com > Date: Fri, 24 Apr 2009 15:20:00 -0700 > From: mika at async.caltech.edu > CC: mika at camembert.async.caltech.edu > Subject: [M3devel] Suspicious code in Cstdio.i3 for FreeBSD > > > This code looks a bit suspicious: > > FILE = RECORD > p : unsigned_char_star; (* current position in (some) buffer *) > r : int; (* read space left for getc() *) > w : int; (* write space left for putc() *) > flags : short_int; (* flags, below; this FILE is free if 0 *) > file : short_int; (* fileno, if Unix descriptor, else -1 *) > bf : SBUF; (* the buffer (at least 1 byte, if !NULL) *) > lbfsize : int; (* 0 or -_bf._size, for inline putc *) > > (* operations *) > cookie : void_star; (* cookie passed to io functions *) > xxclose: void_star; > xxread : void_star; > xxseek : void_star; > xxwrite: void_star; > > (* separate buffer for long sequences of ungetc() *) > ub : SBUF; (* ungetc buffer *) > up : unsigned_char_star; (* saved _p when _p is doing ungetc data *) > ur : int; (* saved _r when _r is counting ungetc data *) > > (* tricks to meet minimum requirements even when malloc() fails *) > ubuf : ARRAY[0..2] OF unsigned_char; (* guarantee an ungetc() buffer *) > nbuf : ARRAY[0..0] OF unsigned_char; (* guarantee a getc() buffer *) > > (* separate buffer for fgetln() when line crosses buffer boundary *) > lb : SBUF; (* buffer for fgetln() *) > > (* Unix stdio files get aligned to block boundaries on fseek() *) > blksize : int; (* stat.st_blksize (may be != _bf._size) *) > offset : off_t; (* current lseek offset *) > pad1 : int; (* assume high 4 bytes of offset are 0 *) > > END; > > > Note the "offset" and "pad1". > > Now... > > off_t = int64_t; > > int64_t = BITS 64 FOR Ctypes.long_long; > > Is this right or is there a bit too much padding here? > > Is the padding also assuming little-endianness? Hmm... > > > Mika From jay.krell at cornell.edu Sat Apr 25 00:23:36 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 24 Apr 2009 22:23:36 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> References: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> Message-ID: ouch, really, no adequate pthreads here? Well, I can still give you an archive to try, but less certain it will work. I never test the user thread stuff.. - Jay ---------------------------------------- > To: m3devel at elegosoft.com > Date: Fri, 24 Apr 2009 15:12:20 -0700 > From: mika at async.caltech.edu > CC: mika at camembert.async.caltech.edu > Subject: [M3devel] help booting CM3 on FreeBSD 4.11? > > Hi Modula-3ers, > > I'm trying to boot CM3 on FreeBSD 4.11 right now. > > Yes, I know it's an old system, but really, the older, the better. > Once I have it running on 4.11, I'll have a binary archive that > should work on *any* FreeBSD system from 4.x up to 7.x, not just > the latest releases. > > My problems are not with FreeBSD. Well to some extent they are. > I had to turn off pthreads: FreeBSD 4 has only a partial implementation, > from what I can tell (in libc_r, not libpthreads) > > No, what's going on is I am trying to boot with CM3 5.3.1, which was the > most recent binary I was able to get running on my FreeBSD 4 system. > > I inserted lots and lots of "LONGINT = INTEGER" in the code, but I'm > still running into this one: > > -> linking cm3 > UtilsPosix.mo: In function `UtilsPosix__MakeRelative': > /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:23: undefined reference to `ThreadF__handlerStack' > /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:23: undefined reference to `ThreadF__handlerStack' > /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:33: undefined reference to `ThreadF__handlerStack' > /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:50: undefined reference to `ThreadF__handlerStack' > /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:60: undefined reference to `ThreadF__handlerStack' > Builder.mo:/home/mika/cm3-cvs/cm3/m3-sys/cm3/FreeBSD4/Builder.m3:188: more undefined references to `ThreadF__handlerStack' follow > Fatal Error: package build failed > > No matter what I try... I tried to make ThreadF.handlerStack > invariantly equal to ThreadPosix.self.context.handlers... it won't > link. Somehow it's not letting me slip in a "handlerStack" in the > interface? > > Anyone have an idea for workarounds? > > Mika From jay.krell at cornell.edu Sat Apr 25 00:26:43 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 24 Apr 2009 22:26:43 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> References: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> Message-ID: You shouldn't have to muck with LONGINT actually. When you bootstrap, you use your existing libm3 and m3core. And you build sysutils, m3front, m3middle, m3quake, cm3, etc. -- none of which should be using LONGINT. upgrade.py and upgrade.sh get this right. If LONGINT has crept into those packages, that would be a problem. But LONGINT in m3core and libm3 can/does exist and is not a problem. I'll fix handlerStack for you in a sec. Would help if you had pthreads though. - Jay ---------------------------------------- > To: m3devel at elegosoft.com > Date: Fri, 24 Apr 2009 15:12:20 -0700 > From: mika at async.caltech.edu > CC: mika at camembert.async.caltech.edu > Subject: [M3devel] help booting CM3 on FreeBSD 4.11? > > Hi Modula-3ers, > > I'm trying to boot CM3 on FreeBSD 4.11 right now. > > Yes, I know it's an old system, but really, the older, the better. > Once I have it running on 4.11, I'll have a binary archive that > should work on *any* FreeBSD system from 4.x up to 7.x, not just > the latest releases. > > My problems are not with FreeBSD. Well to some extent they are. > I had to turn off pthreads: FreeBSD 4 has only a partial implementation, > from what I can tell (in libc_r, not libpthreads) > > No, what's going on is I am trying to boot with CM3 5.3.1, which was the > most recent binary I was able to get running on my FreeBSD 4 system. > > I inserted lots and lots of "LONGINT = INTEGER" in the code, but I'm > still running into this one: > > -> linking cm3 > UtilsPosix.mo: In function `UtilsPosix__MakeRelative': > /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:23: undefined reference to `ThreadF__handlerStack' > /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:23: undefined reference to `ThreadF__handlerStack' > /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:33: undefined reference to `ThreadF__handlerStack' > /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:50: undefined reference to `ThreadF__handlerStack' > /home/mika/cm3/m3-sys/cm3/FreeBSD4/UtilsPosix.m3:60: undefined reference to `ThreadF__handlerStack' > Builder.mo:/home/mika/cm3-cvs/cm3/m3-sys/cm3/FreeBSD4/Builder.m3:188: more undefined references to `ThreadF__handlerStack' follow > Fatal Error: package build failed > > No matter what I try... I tried to make ThreadF.handlerStack > invariantly equal to ThreadPosix.self.context.handlers... it won't > link. Somehow it's not letting me slip in a "handlerStack" in the > interface? > > Anyone have an idea for workarounds? > > Mika From jay.krell at cornell.edu Sat Apr 25 00:34:45 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 24 Apr 2009 22:34:45 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> References: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> Message-ID: > I'll fix handlerStack for you in a sec. No, nevermind that. Just use your installed m3core/libm3 and you don't need it "fixed". You already have it. You aren't bootstrapping in the right order I presume. Try upgrade.sh or upgrade.py. They build the current compiler against the existing runtime. Oh, I guess you'll hit a problem in sysutils. It uses Cerrno which is relatively new. You can just comment that out -- assume there is no error. sysutils should maybe carry its own errno wrapper because of this. Trivial. I've hit it multiple times building on Darwin from older distributions. - Jay From jay.krell at cornell.edu Sat Apr 25 00:40:41 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 24 Apr 2009 22:40:41 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> References: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> Message-ID: > > Would help if you had pthreads though. IF you have a working-enough pthreads, no matter what library they are in, take a look at: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-FreeBSD4-1.tar.gz It's a little gross -- one directory with LOTS of files. And a few subdirectories you don't need. Be sure to look at the start of the Makefile and possibly adjust it. There are some *.sh files, redundant with the Makefile. The output of this is just cm3. You can use that to then build up the system from the bottom of the dependeny tree and on up -- m3cc, m3core, libm3, etc. do-cm3-core.sh/do-cm3-core.py should do that. This is different than "upgrade", which uses an existing m3core/libm3. This is how I do cross builds, both to existing systems and new systems. It has worked several times for me. Most often from a Cygwin host but maybe not always, and it isn't Cygwin specific. If you really don't have a working pthreads, well, I'd just have to rebuild this with one edit...maybe I can do that quickly (it'll be -2 if so..), maybe it'll work...maybe... - Jay From mika at async.caltech.edu Sat Apr 25 01:03:13 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 24 Apr 2009 16:03:13 -0700 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: Your message of "Fri, 24 Apr 2009 22:34:45 -0000." Message-ID: <200904242303.n3ON3DO0018052@camembert.async.caltech.edu> yes it sounds like I'm just using the wrong bootstrapping order. I'm going on an old email from Tony, but there were fewer updates back then to worry about. I'll try your version and report back! Thanks! Mika Jay writes: > >> I'll fix handlerStack for you in a sec. > >No, nevermind that. >Just use your installed m3core/libm3 and you don't need it "fixed". >You already have it. > > >You aren't bootstrapping in the right order I presume. >Try upgrade.sh or upgrade.py. >They build the current compiler against the existing runtime. > > >Oh, I guess you'll hit a problem in sysutils. It uses Cerrno which is relative >ly new. >You can just comment that out -- assume there is no error. >sysutils should maybe carry its own errno wrapper because of this. > Trivial. >I've hit it multiple times building on Darwin from older distributions. > > > - Jay > From mika at async.caltech.edu Sat Apr 25 01:05:06 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 24 Apr 2009 16:05:06 -0700 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: Your message of "Fri, 24 Apr 2009 22:40:41 -0000." Message-ID: <200904242305.n3ON56IS018186@camembert.async.caltech.edu> By the way, I take it booting the compiler "old-fashionedly" with PM3 is out of the question? I have a very well-working PM3... reason it's taken me so long to get around to really pushing on updating to CM3... But let me fiddle around for a bit and see if I need you again. Mika Jay writes: > >> >> Would help if you had pthreads though. > > >IF you have a working-enough pthreads, no matter what library they are in, tak >e a look at: > > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-FreeBSD4-1.tar.gz > > > >It's a little gross -- one directory with LOTS of files. >And a few subdirectories you don't need. > > >Be sure to look at the start of the Makefile and possibly adjust it. >There are some *.sh files, redundant with the Makefile. > > >The output of this is just cm3. >You can use that to then build up the system from the bottom of the dependeny >tree and on up -- m3cc, m3core, libm3, etc. do-cm3-core.sh/do-cm3-core.py shou >ld do that. >This is different than "upgrade", which uses an existing m3core/libm3. > >This is how I do cross builds, both to existing systems and new systems. >It has worked several times for me. Most often from a Cygwin host but maybe no >t always, and it isn't Cygwin specific. > > > >If you really don't have a working pthreads, well, I'd just have to rebuild th >is with one edit...maybe I can do that quickly (it'll be -2 if so..), maybe it >'ll work...maybe... > > > - Jay From jay.krell at cornell.edu Sat Apr 25 01:21:49 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 24 Apr 2009 23:21:49 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <200904242305.n3ON56IS018186@camembert.async.caltech.edu> References: Your message of "Fri, 24 Apr 2009 22:40:41 -0000." <200904242305.n3ON56IS018186@camembert.async.caltech.edu> Message-ID: > By the way, I take it booting the compiler "old-fashionedly" with > PM3 is out of the question? What is the PM3 way? The SRC way is out of the question at least (unless you want to /start/ with it and go through a few releases...). I gather that the PM3 was good and could be resusitated. But it is is some work..maybe too much. I gather that PM3 factored out word size and endianness from the IL? And padding/alignment? And jmpbuf size? And whatever else is target-dependent? There isn't much. Not impossible, but seems a bit onerous. padding/alignment actually don't have to be factored out, kind of. They can be made "worst case", as long as the interactions with C are correct. word size and endianness are in the IL but I think only barely. jmpbuf size is easy to factor out at a small perf cost. or again, make it worst case. These "worst cases" are likely to be pretty bad, such that they are ok for building the first compiler, but then you'd want to immediately rebuild it "ideally". jmpbuf size varies from around 16 bytes to over 200 bytes for example. You could also use extern int jmpbufsize; jmpbuf = alloca(jmpbufsize) thereby not blowing stack, but still being slow. Again, fine for bootstrap purposes but it should end there. "aligned procedures" can be factored out easily via acting worst case. Is this what PM3 did though? Shipped one textual IL for all platforms, built m3cc (which doesn't /really/ require having cm3), then built everything from the portable IL, then rebuilt it all again more ideally? I think if a portable distribution format is to be had, maybe go all the way to using a C backend? However that doesn't solve all/many/any of the above problems, given how low level the IL is. - Jay From jay.krell at cornell.edu Sat Apr 25 01:24:30 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 24 Apr 2009 23:24:30 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <200904242303.n3ON3DO0018052@camembert.async.caltech.edu> References: Your message of "Fri, 24 Apr 2009 22:34:45 -0000." <200904242303.n3ON3DO0018052@camembert.async.caltech.edu> Message-ID: The main out of date thing about what Tony did is that sysutils might not have existed at the time. His statement as to "all" the one place to cheat on LONGINT is out of date too, it is used in more than one place, but you don't have do this anyway. You might also try a cross build.. :) - Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Fri, 24 Apr 2009 16:03:13 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] help booting CM3 on FreeBSD 4.11? > > yes it sounds like I'm just using the wrong bootstrapping order. > I'm going on an old email from Tony, but there were fewer updates > back then to worry about. > > I'll try your version and report back! > > Thanks! > > Mika > > Jay writes: >> >>> I'll fix handlerStack for you in a sec. >> >>No, nevermind that. >>Just use your installed m3core/libm3 and you don't need it "fixed". >>You already have it. >> >> >>You aren't bootstrapping in the right order I presume. >>Try upgrade.sh or upgrade.py. >>They build the current compiler against the existing runtime. >> >> >>Oh, I guess you'll hit a problem in sysutils. It uses Cerrno which is relative >>ly new. >>You can just comment that out -- assume there is no error. >>sysutils should maybe carry its own errno wrapper because of this. >> Trivial. >>I've hit it multiple times building on Darwin from older distributions. >> >> >> - Jay >> From jay.krell at cornell.edu Sat Apr 25 01:42:40 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 24 Apr 2009 23:42:40 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: References: Your message of "Fri, 24 Apr 2009 22:40:41 -0000." <200904242305.n3ON56IS018186@camembert.async.caltech.edu> Message-ID: > I said > word size and endianness are in the IL but I think only barely. [I think] Actually the front end lays out all the types, so word size is all over the place. It's actually a little bit bad, because the gcc backend performs the layout too and they have to match, and they don't always.. (x86 aligned double...) - Jay From jay.krell at cornell.edu Sat Apr 25 01:53:09 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 24 Apr 2009 23:53:09 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> References: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> Message-ID: This /might/ help: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-FreeBSD4-1-userthreads.tar.gz Assuming there are a small number of problems though, the best ways to get more rapid turnaround are to do a cross build or at least first make sure userthreads work on more recent FreeBSD. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu; m3devel at elegosoft.com > CC: mika at camembert.async.caltech.edu > Subject: RE: [M3devel] help booting CM3 on FreeBSD 4.11? > Date: Fri, 24 Apr 2009 22:40:41 +0000 > > >> >> Would help if you had pthreads though. > > > IF you have a working-enough pthreads, no matter what library they are in, take a look at: > > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-FreeBSD4-1.tar.gz > > > It's a little gross -- one directory with LOTS of files. > And a few subdirectories you don't need. > > > Be sure to look at the start of the Makefile and possibly adjust it. > There are some *.sh files, redundant with the Makefile. > > > The output of this is just cm3. > You can use that to then build up the system from the bottom of the dependeny tree and on up -- m3cc, m3core, libm3, etc. do-cm3-core.sh/do-cm3-core.py should do that. > This is different than "upgrade", which uses an existing m3core/libm3. > > This is how I do cross builds, both to existing systems and new systems. > It has worked several times for me. Most often from a Cygwin host but maybe not always, and it isn't Cygwin specific. > > > > If you really don't have a working pthreads, well, I'd just have to rebuild this with one edit...maybe I can do that quickly (it'll be -2 if so..), maybe it'll work...maybe... > > > - Jay From jay.krell at cornell.edu Sat Apr 25 02:05:21 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 00:05:21 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: References: <200904242212.n3OMCKmM015706@camembert.async.caltech.edu> Message-ID: ps: you'll want something like: C:\dev2\cm3.2\m3-libs\m3core\src>cvs -z3 diff thread.quake Index: thread.quake =================================================================== RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread.quake,v retrieving revision 1.5 diff -r1.5 thread.quake 40c40 < "FreeBSD4" : TRUE, --- > "FreeBSD4" : FALSE, or C:\dev2\cm3.2\m3-libs\m3core\src>grep defined thread.quake if (NO_USER_THREADS contains TARGET) or ((not defined("NOPTHREAD")) and USE_ PTHREADS{TARGET}) cm3 -DNOPTHREAD - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu; m3devel at elegosoft.com > Date: Fri, 24 Apr 2009 23:53:09 +0000 > CC: mika at camembert.async.caltech.edu > Subject: Re: [M3devel] help booting CM3 on FreeBSD 4.11? > > > This /might/ help: > > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-FreeBSD4-1-userthreads.tar.gz > > > Assuming there are a small number of problems though, the best ways to get more rapid turnaround are to do a cross build or at least first make sure userthreads work on more recent FreeBSD. > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: mika at async.caltech.edu; m3devel at elegosoft.com >> CC: mika at camembert.async.caltech.edu >> Subject: RE: [M3devel] help booting CM3 on FreeBSD 4.11? >> Date: Fri, 24 Apr 2009 22:40:41 +0000 >> >> >>> >>> Would help if you had pthreads though. >> >> >> IF you have a working-enough pthreads, no matter what library they are in, take a look at: >> >> >> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-FreeBSD4-1.tar.gz >> >> >> It's a little gross -- one directory with LOTS of files. >> And a few subdirectories you don't need. >> >> >> Be sure to look at the start of the Makefile and possibly adjust it. >> There are some *.sh files, redundant with the Makefile. >> >> >> The output of this is just cm3. >> You can use that to then build up the system from the bottom of the dependeny tree and on up -- m3cc, m3core, libm3, etc. do-cm3-core.sh/do-cm3-core.py should do that. >> This is different than "upgrade", which uses an existing m3core/libm3. >> >> This is how I do cross builds, both to existing systems and new systems From mika at async.caltech.edu Sat Apr 25 05:38:17 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 24 Apr 2009 20:38:17 -0700 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: Your message of "Fri, 24 Apr 2009 22:40:41 -0000." Message-ID: <200904250338.n3P3cHlc030469@camembert.async.caltech.edu> Jay (and others), Success! I think.... I was able to build the compiler, after much experimentation, by using Jay's build order and linking with -libc_r. Mentor works, and that's usually a good sign. Jay, your assembly worked too! And as you say, it's much easier to bootstrap with that than to do what I was trying to do (but I did both, several times, just to make sure). I don't know why I was having linking problems with -libc_r earlier. Now it just seems to work. So, pthreads on FreeBSD 4. If I use user threads, it's a different story (which is probably too bad, as I know that user threads work absolutely fine in my old version of CM3): I can build a compiler fine, but the bootstrapped cm3 crashes in the user thread code. Note that exactly the same thing happens whether I bootstrap with the assembly version from Jay or from v. 5.3.4, which I think is what I had. Here we go: Starting program: /usr/local/cm3/pkg/cm3/FreeBSD4/cm3 Program received signal SIGSEGV, Segmentation fault. 16_82568bb in RTHooks.PushEFrame (frame=16_bfbff3f4) at ../src/thread/POSIX/ThreadPosix.m3:1599 1599 f.next := self.context.handlers; (gdb) where #0 16_82568bb in RTHooks.PushEFrame (frame=16_bfbff3f4) at ../src/thread/POSIX/ThreadPosix.m3:1599 #1 16_824c91e in RTType.Calloc (n=1024, n_bytes=4) at ../src/runtime/common/RTType.m3:815 #2 16_824c39a in RTType.Expand (m=RECORD name = 16_82f0e50; is_equal = 16_824c6a6; rehash = 16_824c6e8; initial_size = 1024; full = 512; cnt = 0; max = 1024; mask = 1023; map = NIL; END) at ../src/runtime/common/RTType.m3:724 #3 16_824c26f in RTType.FindSlot (m=RECORD name = 16_82f0e50; is_equal = 16_824c6a6; rehash = 16_824c6e8; initial_size = 1024; full = 512; cnt = 0; max = 1024; mask = 1023; map = NIL; END, key=-1025633461, aux=NIL) at ../src/runtime/common/RTType.m3:699 #4 16_824b007 in RTTypeSRC.AddTypecell (def=16_82eb8b4, m=16_82eb880) at ../src/runtime/common/RTType.m3:163 #5 16_8244d89 in RTLinker.DeclareModuleTypes (m=16_82eb880) at ../src/runtime/common/RTLinker.m3:280 #6 16_8244b52 in RTLinker.FixTypes () at ../src/runtime/common/RTLinker.m3:234 #7 16_82446f9 in RTLinker.AddUnitI (m=16_82eefa0) at ../src/runtime/common/RTLinker.m3:112 #8 16_824478f in RTLinker.AddUnit (b=16_82443e0) at ../src/runtime/common/RTLinker.m3:122 #9 16_8244493 in RTLinker.InitRuntime (p_argc=1, p_argv=16_bfbff68c, p_envp=16_bfbff694, p_instance=NIL) at ../src/runtime/common/RTLinker.m3:42 module "_m3main": missing debug info for global data I'm not able to print self in m3gdb, for some reason. Mika Jay writes: > >> >> Would help if you had pthreads though. > > >IF you have a working-enough pthreads, no matter what library they are in, take a look at: > > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-FreeBSD4-1.tar.gz > > >It's a little gross -- one directory with LOTS of files. >And a few subdirectories you don't need. > > >Be sure to look at the start of the Makefile and possibly adjust it. >There are some *.sh files, redundant with the Makefile. > > >The output of this is just cm3. >You can use that to then build up the system from the bottom of the dependeny tree and on up -- m3cc, m3core, libm3, etc. do-cm3-core.sh/do-cm3-core.py should do that. >This is different than "upgrade", which uses an existing m3core/libm3. > >This is how I do cross builds, both to existing systems and new systems. >It has worked several times for me. Most often from a Cygwin host but maybe not always, and it isn't Cygwin specific. > > > >If you really don't have a working pthreads, well, I'd just have to rebuild this with one edit...maybe I can do that quickly (it'll be -2 if so..), maybe it'll work...maybe... > > > - Jay From mika at async.caltech.edu Sat Apr 25 05:41:04 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 24 Apr 2009 20:41:04 -0700 Subject: [M3devel] inconsistencies in external interfaces Message-ID: <200904250341.n3P3f4O8030634@camembert.async.caltech.edu> All right, here's another little oddity. m3-libs/m3core/src/unix/freebsd-4/Utime.i3 has the following: time_t = int; (* seconds since the Epoch *) ... <*EXTERNAL*> PROCEDURE localtime (clock: long_star): struct_tm_star; Huh? What's the point of declaring time_t if you're not going to use it? (I think it used to be that long_star and time_t resolved to the same type, before the LONGINT work or some other foreign interface updating, but they no longer seem to...) Mika From jay.krell at cornell.edu Sat Apr 25 06:12:54 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 04:12:54 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <200904250338.n3P3cHlc030469@camembert.async.caltech.edu> References: Your message of "Fri, 24 Apr 2009 22:40:41 -0000." <200904250338.n3P3cHlc030469@camembert.async.caltech.edu> Message-ID: Cool. > If I use user threads, it's a different story (which is probably too bad, Oops, right, I forgot, I should have mentioned that, user threads have likely been broken on all platforms for a while. I noticed that on PPC_LINUX. I think it is trivial to fix. Or use pthreads.. - Jay > To: jay.krell at cornell.edu > Date: Fri, 24 Apr 2009 20:38:17 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] help booting CM3 on FreeBSD 4.11? > > Jay (and others), > > Success! I think.... I was able to build the compiler, after much > experimentation, by using Jay's build order and linking with -libc_r. > Mentor works, and that's usually a good sign. > > Jay, your assembly worked too! And as you say, it's much easier to > bootstrap with that than to do what I was trying to do (but I did > both, several times, just to make sure). > > I don't know why I was having linking problems with -libc_r earlier. > Now it just seems to work. So, pthreads on FreeBSD 4. > > If I use user threads, it's a different story (which is probably too bad, > as I know that user threads work absolutely fine in my old version of CM3): > > I can build a compiler fine, but the bootstrapped cm3 crashes in > the user thread code. Note that exactly the same thing happens whether > I bootstrap with the assembly version from Jay or from v. 5.3.4, which > I think is what I had. Here we go: > > Starting program: /usr/local/cm3/pkg/cm3/FreeBSD4/cm3 > > Program received signal SIGSEGV, Segmentation fault. > 16_82568bb in RTHooks.PushEFrame (frame=16_bfbff3f4) at ../src/thread/POSIX/ThreadPosix.m3:1599 > 1599 f.next := self.context.handlers; > (gdb) where > #0 16_82568bb in RTHooks.PushEFrame (frame=16_bfbff3f4) at ../src/thread/POSIX/ThreadPosix.m3:1599 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 25 06:50:44 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 04:50:44 +0000 Subject: [M3devel] inconsistencies in external interfaces In-Reply-To: <200904250341.n3P3f4O8030634@camembert.async.caltech.edu> References: <200904250341.n3P3f4O8030634@camembert.async.caltech.edu> Message-ID: 1) I THINK these files are often a pretty direct translation of /usr/include, dead stuff, comments, and all. Posix often mandates that certain types are certain headers, even if they aren't used by any function in that header. Utime.i3 would declare time_t not necessarily for its own purposes but so that C code (nonsense example but ok): #include int main() { time_t t = 0; /* ... */ } translates "directly" to Modula-3 (ha): IMPORT Utime; VAR t: Utime.time_t := 0 BEGIN (* ... *) END Main. 2) Almost everything in m3core/src/unix is dead anyway, outside of the common directory, and Usysdeps.i3, and the userthread support. Look at the m3makefile. It is mostly if'ed out. The only active platforms using their own full assortment of cloned /usr/include are I386_DARWIN and AMD64_DARWIN..until I get around to them. If OpenDarwin/x86 7.0 will run in a VM, I386_DARWIN will fall soon. AMD64_DARWIN must wait for additional hardware, or someone else to switch it (Tony?) - Jay > To: m3devel at elegosoft.com > Date: Fri, 24 Apr 2009 20:41:04 -0700 > From: mika at async.caltech.edu > Subject: [M3devel] inconsistencies in external interfaces > > > All right, here's another little oddity. > > m3-libs/m3core/src/unix/freebsd-4/Utime.i3 has the following: > > time_t = int; (* seconds since the Epoch *) > > ... > > <*EXTERNAL*> PROCEDURE localtime (clock: long_star): struct_tm_star; > > Huh? What's the point of declaring time_t if you're not going to > use it? > > (I think it used to be that long_star and time_t resolved to the > same type, before the LONGINT work or some other foreign interface > updating, but they no longer seem to...) > > Mika > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sat Apr 25 07:32:37 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 24 Apr 2009 22:32:37 -0700 Subject: [M3devel] inconsistencies in external interfaces In-Reply-To: Your message of "Sat, 25 Apr 2009 04:50:44 -0000." Message-ID: <200904250532.n3P5Wb7V035782@camembert.async.caltech.edu> Well, I hear you, but in this case I doubt it. /usr/include/time.h has struct tm *localtime __P((const time_t *)); and man localtime yields... struct tm * localtime(const time_t *clock); It looks like a manual job to me. Mika Jay writes: >--_7e282a72-e70c-455d-9d62-0c65873ebb2d_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >1) I THINK these files are often a pretty direct translation of /usr/includ= >e=2C dead stuff=2C comments=2C and all. Posix often mandates that certain t= >ypes are certain headers=2C even if they aren't used by any function in tha= >t header. > >=20 > >=20 > >Utime.i3 would declare time_t not necessarily for its own purposes but so t= >hat C code (nonsense example but ok): > >=20 > >=20 > >#include > >=20 > >int main() > >{ > > time_t t =3D 0=3B > > /* ... */ > >} > >=20 > >=20 >translates "directly" to Modula-3 (ha): > >=20 > >=20 > >IMPORT Utime=3B > >VAR > > t: Utime.time_t :=3D 0 > >BEGIN > > (* ... *) > >END Main. > > =20 > >2) Almost everything in m3core/src/unix is dead anyway=2C outside of the co= >mmon directory=2C and Usysdeps.i3=2C and the userthread support. > >Look at the m3makefile. It is mostly if'ed out. > >The only active platforms using their own full assortment of cloned /usr/in= >clude are I386_DARWIN and AMD64_DARWIN..until I get around to them. If Open= >Darwin/x86 7.0 will run in a VM=2C I386_DARWIN will fall soon. AMD64_DARWIN= > must wait for additional hardware=2C or someone else to switch it (Tony?) > >=20 > >=20 > > - Jay > >=20 >> To: m3devel at elegosoft.com >> Date: Fri=2C 24 Apr 2009 20:41:04 -0700 >> From: mika at async.caltech.edu >> Subject: [M3devel] inconsistencies in external interfaces >>=20 >>=20 >> All right=2C here's another little oddity. >>=20 >> m3-libs/m3core/src/unix/freebsd-4/Utime.i3 has the following: >>=20 >> time_t =3D int=3B (* seconds since the Epoch *) >>=20 >> ... >>=20 >> <*EXTERNAL*> PROCEDURE localtime (clock: long_star): struct_tm_star=3B >>=20 >> Huh? What's the point of declaring time_t if you're not going to >> use it? >>=20 >> (I think it used to be that long_star and time_t resolved to the >> same type=2C before the LONGINT work or some other foreign interface >> updating=2C but they no longer seem to...) >>=20 >> Mika >>=20 >>=20 > >--_7e282a72-e70c-455d-9d62-0c65873ebb2d_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >1) I THINK these files are often a pretty direct =3Btranslation of /usr= >/include=2C dead stuff=2C comments=2C and all. Posix often mandates that ce= >rtain types are certain headers=2C even if they aren't used by any function= > in that header.
> =3B
> =3B
>Utime.i3 would =3Bdeclare time_t not necessarily for its own purposes b= >ut so that C code (nonsense example but ok):
> =3B
> =3B
>#include <=3Btime.h>=3B
> =3B
>int main()
>{
> =3B =3Btime_t t =3D 0=3B
> =3B /* ... */
>}
> =3B
> =3B
>translates "directly" to Modula-3 (ha):
> =3B
> =3B
>IMPORT Utime=3B
>VAR
> =3B t: Utime.time_t =3B:=3D 0
>BEGIN
> =3B (* ... *)
>END Main.
> =3B

2) Almost everything in m3core/src/unix is dead anyway=2C = >outside of the common directory=2C and Usysdeps.i3=2C and the userthread su= >pport.
>Look at the m3makefile. It is mostly if'ed out.
>The only active platforms using their own full assortment of cloned /usr/in= >clude are I386_DARWIN and AMD64_DARWIN..until I get around to them. If Open= >Darwin/x86 7.0 will run in a VM=2C I386_DARWIN will fall soon. AMD64_DARWIN= > must wait for additional hardware=2C or someone else to switch it (Tony?)<= >BR> > =3B
> =3B
> =3B- Jay

 =3B
>=3B To: m3devel at elegosoft.com
>=3B= > Date: Fri=2C 24 Apr 2009 20:41:04 -0700
>=3B From: mika at async.caltech= >.edu
>=3B Subject: [M3devel] inconsistencies in external interfaces>>=3B
>=3B
>=3B All right=2C here's another little oddity.>>=3B
>=3B m3-libs/m3core/src/unix/freebsd-4/Utime.i3 has the follo= >wing:
>=3B
>=3B time_t =3D int=3B (* seconds since the Epoch *)<= >BR>>=3B
>=3B ...
>=3B
>=3B <=3B*EXTERNAL*>=3B PROCED= >URE localtime (clock: long_star): struct_tm_star=3B
>=3B
>=3B Hu= >h? What's the point of declaring time_t if you're not going to
>=3B us= >e it?
>=3B
>=3B (I think it used to be that long_star and time_t= > resolved to the
>=3B same type=2C before the LONGINT work or some oth= >er foreign interface
>=3B updating=2C but they no longer seem to...)R>>=3B
>=3B Mika
>=3B
>=3B
>= > >--_7e282a72-e70c-455d-9d62-0c65873ebb2d_-- From mika at async.caltech.edu Sat Apr 25 07:58:23 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 24 Apr 2009 22:58:23 -0700 Subject: [M3devel] Uresource on freebsd 4? Message-ID: <200904250558.n3P5wNE1036977@camembert.async.caltech.edu> Is there any particular reason Uresource no longer exists on FreeBSD4? The m3makefile m3core/src/unix/freebsd-4/m3makefile looks like the following, and Uresource isn't picked up anywhere else: if TRUE Module ("Usignal") Interface ("Uucontext") else Interface ("Udir") Interface ("Uerror") %Interface ("Ugrp") Interface ("Uipc") Interface ("Umman") Module ("Umsg") Interface ("Unix") Interface ("Uprocess") Interface ("Upthread") Interface ("Upwd") Interface ("Uresource") Interface ("Usem") Interface ("Usched") Interface ("Ushm") Module ("Usignal") Interface ("Ustat") Interface ("Usocket") Interface ("Usyslog") Interface ("Utime") Module ("Utypes") Interface ("Uucontext") Interface ("Uugid") Interface ("Uuio") Interface ("Uutsname") end From jay.krell at cornell.edu Sat Apr 25 08:14:28 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 06:14:28 +0000 Subject: [M3devel] Uresource on freebsd 4? In-Reply-To: <200904250558.n3P5wNE1036977@camembert.async.caltech.edu> References: <200904250558.n3P5wNE1036977@camembert.async.caltech.edu> Message-ID: Do you need it? Is there a sufficient common/Uresource.i3? I generally removed whatever isn't used, and made the remainders portable. I can look into restoring more, but what do you need and what is there? (I can look.) - Jay > To: m3devel at elegosoft.com > Date: Fri, 24 Apr 2009 22:58:23 -0700 > From: mika at async.caltech.edu > CC: mika at camembert.async.caltech.edu > Subject: [M3devel] Uresource on freebsd 4? > > > Is there any particular reason Uresource no longer exists on FreeBSD4? > The m3makefile > > m3core/src/unix/freebsd-4/m3makefile > > looks like the following, and Uresource isn't picked up anywhere else: > > if TRUE > > Module ("Usignal") > Interface ("Uucontext") > > else > > Interface ("Udir") > Interface ("Uerror") > %Interface ("Ugrp") > Interface ("Uipc") > Interface ("Umman") > Module ("Umsg") > Interface ("Unix") > Interface ("Uprocess") > Interface ("Upthread") > Interface ("Upwd") > Interface ("Uresource") > Interface ("Usem") > Interface ("Usched") > Interface ("Ushm") > Module ("Usignal") > Interface ("Ustat") > Interface ("Usocket") > Interface ("Usyslog") > Interface ("Utime") > Module ("Utypes") > Interface ("Uucontext") > Interface ("Uugid") > Interface ("Uuio") > Interface ("Uutsname") > > end > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sat Apr 25 08:32:29 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 24 Apr 2009 23:32:29 -0700 Subject: [M3devel] Uresource on freebsd 4? In-Reply-To: Your message of "Sat, 25 Apr 2009 06:14:28 -0000." Message-ID: <200904250632.n3P6WThS038574@camembert.async.caltech.edu> I use it for timing programs (getrusage). Is there another way of doing that in Modula-3? This declaration: <*EXTERNAL*> PROCEDURE getrusage (who: int; VAR rus: struct_rusage): int; I'm sure getrlimit is useful too. These things have been in Modula-3 for a long time... It's the only thing that's missing that I personally use. Except for some disturbances in m3tk things are now compiling for me... Mika Jay writes: >--_55ac72c8-d027-4bd6-a303-434a73dcc5db_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Do you need it? > >Is there a sufficient common/Uresource.i3? > >=20 > >I generally removed whatever isn't used=2C and made the remainders portable= >. > >I can look into restoring more=2C but what do you need and what is there? (= >I can look.) > >=20 > >=20 > > - Jay > >=20 >> To: m3devel at elegosoft.com >> Date: Fri=2C 24 Apr 2009 22:58:23 -0700 >> From: mika at async.caltech.edu >> CC: mika at camembert.async.caltech.edu >> Subject: [M3devel] Uresource on freebsd 4? >>=20 >>=20 >> Is there any particular reason Uresource no longer exists on FreeBSD4? >> The m3makefile >>=20 >> m3core/src/unix/freebsd-4/m3makefile >>=20 >> looks like the following=2C and Uresource isn't picked up anywhere else: >>=20 >> if TRUE >>=20 >> Module ("Usignal") >> Interface ("Uucontext") >>=20 >> else >>=20 >> Interface ("Udir") >> Interface ("Uerror") >> %Interface ("Ugrp") >> Interface ("Uipc") >> Interface ("Umman") >> Module ("Umsg") >> Interface ("Unix") >> Interface ("Uprocess") >> Interface ("Upthread") >> Interface ("Upwd") >> Interface ("Uresource") >> Interface ("Usem") >> Interface ("Usched") >> Interface ("Ushm") >> Module ("Usignal") >> Interface ("Ustat") >> Interface ("Usocket") >> Interface ("Usyslog") >> Interface ("Utime") >> Module ("Utypes") >> Interface ("Uucontext") >> Interface ("Uugid") >> Interface ("Uuio") >> Interface ("Uutsname") >>=20 >> end >>=20 > >--_55ac72c8-d027-4bd6-a303-434a73dcc5db_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >Do you need it?
>Is there a sufficient common/Uresource.i3?
> =3B
>I generally removed whatever isn't used=2C and made the remainders portable= >.
>I can look into restoring more=2C but what do you need and what is there? (= >I can look.)
> =3B
> =3B
> =3B- Jay

 =3B
>=3B To: m3devel at elegosoft.com
>=3B= > Date: Fri=2C 24 Apr 2009 22:58:23 -0700
>=3B From: mika at async.caltech= >.edu
>=3B CC: mika at camembert.async.caltech.edu
>=3B Subject: [M3d= >evel] Uresource on freebsd 4?
>=3B
>=3B
>=3B Is there any = >particular reason Uresource no longer exists on FreeBSD4?
>=3B The m3m= >akefile
>=3B
>=3B m3core/src/unix/freebsd-4/m3makefile
>=3B= >
>=3B looks like the following=2C and Uresource isn't picked up anywh= >ere else:
>=3B
>=3B if TRUE
>=3B
>=3B Module ("Usigna= >l")
>=3B Interface ("Uucontext")
>=3B
>=3B else
>=3B <= >BR>>=3B Interface ("Udir")
>=3B Interface ("Uerror")
>=3B %Inte= >rface ("Ugrp")
>=3B Interface ("Uipc")
>=3B Interface ("Umman")R>>=3B Module ("Umsg")
>=3B Interface ("Unix")
>=3B Interface (= >"Uprocess")
>=3B Interface ("Upthread")
>=3B Interface ("Upwd")R>>=3B Interface ("Uresource")
>=3B Interface ("Usem")
>=3B Int= >erface ("Usched")
>=3B Interface ("Ushm")
>=3B Module ("Usignal")= >
>=3B Interface ("Ustat")
>=3B Interface ("Usocket")
>=3B In= >terface ("Usyslog")
>=3B Interface ("Utime")
>=3B Module ("Utypes= >")
>=3B Interface ("Uucontext")
>=3B Interface ("Uugid")
>= >=3B Interface ("Uuio")
>=3B Interface ("Uutsname")
>=3B
>= >=3B end
>=3B
>= > >--_55ac72c8-d027-4bd6-a303-434a73dcc5db_-- From jay.krell at cornell.edu Sat Apr 25 09:52:31 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 07:52:31 +0000 Subject: [M3devel] Uresource on freebsd 4? In-Reply-To: <200904250632.n3P6WThS038574@camembert.async.caltech.edu> References: Your message of "Sat, 25 Apr 2009 06:14:28 -0000." <200904250632.n3P6WThS038574@camembert.async.caltech.edu> Message-ID: Does something like this suffice? Seconds used by current process as a float (including sub-second resolution). http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/runtime/POSIX/Attic/RTProcessPosix.i3?rev=1.1;content-type=text%2Fplain http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/runtime/POSIX/Attic/RTProcessPosixC.c?rev=1.7;content-type=text%2Fplain Notice it is in Attic. If not, can you write your own similar? The full getrusage has that huge struct.. seems best to not expose the whole thing but have folks write little C wrappers for just what they need. A portable wrapper would copy out all the fields, for "all the fields" defined as all the ones implemented by all systems. Only to have most users probably ignore most of them. Notice the cruft: struct_rusage = RECORD ru_utime: Utime.struct_timeval; (* user time used *) ru_stime: Utime.struct_timeval; (* system time used *) ru_maxrss: long; ru_ixrss: long; (* integral shared text size *) (* Unsupported in Linux 1.0: ru_ismrss: long; (* integral shared memory size*) ******************************) kind of makes you wonder....when the FreeBSD path has stuff commented out because Linux 1.0 doesn't support it, which parts are correct? And is it still correct in FreeBSD 5, 6, 7, 9, 10? (Did it get copied blindly to other directoryes, like maybe Darwin?) I guess the only client used utime and stime (based on the code in the Attic). Mistakes here -- such as commenting out fields that are actually there -- would generally result in stack corruption, which might be ok, on some days, on some systems, with some compilers, with some compiler flags, depending on what is nearby on the stack, and what it gets overwritten with. Very dangerous stuff.. For Win32, lookup GetProcessTimes and GetThreadTimes. getrlimit doesn't look so problematic, at least based on the FreeBSD4 version. (Something is really weird with mail encoding, could be me, using a variety of modern mail clients..) - Jay > To: jay.krell at cornell.edu > Date: Fri, 24 Apr 2009 23:32:29 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Uresource on freebsd 4? > > > I use it for timing programs (getrusage). Is there another way of > doing that in Modula-3? > > This declaration: > > <*EXTERNAL*> PROCEDURE getrusage (who: int; VAR rus: struct_rusage): int; > > I'm sure getrlimit is useful too. > > These things have been in Modula-3 for a long time... > > It's the only thing that's missing that I personally use. Except > for some disturbances in m3tk things are now compiling for me... > > Mika > > > Jay writes: > >--_55ac72c8-d027-4bd6-a303-434a73dcc5db_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Do you need it? > > > >Is there a sufficient common/Uresource.i3? > > > >=20 > > > >I generally removed whatever isn't used=2C and made the remainders portable= > >. > > > >I can look into restoring more=2C but what do you need and what is there? (= > >I can look.) > > > >=20 > > > >=20 > > > > - Jay > > > >=20 > >> To: m3devel at elegosoft.com > >> Date: Fri=2C 24 Apr 2009 22:58:23 -0700 > >> From: mika at async.caltech.edu > >> CC: mika at camembert.async.caltech.edu > >> Subject: [M3devel] Uresource on freebsd 4? > >>=20 > >>=20 > >> Is there any particular reason Uresource no longer exists on FreeBSD4? > >> The m3makefile > >>=20 > >> m3core/src/unix/freebsd-4/m3makefile > >>=20 > >> looks like the following=2C and Uresource isn't picked up anywhere else: > >>=20 > >> if TRUE > >>=20 > >> Module ("Usignal") > >> Interface ("Uucontext") > >>=20 > >> else > >>=20 > >> Interface ("Udir") > >> Interface ("Uerror") > >> %Interface ("Ugrp") > >> Interface ("Uipc") > >> Interface ("Umman") > >> Module ("Umsg") > >> Interface ("Unix") > >> Interface ("Uprocess") > >> Interface ("Upthread") > >> Interface ("Upwd") > >> Interface ("Uresource") > >> Interface ("Usem") > >> Interface ("Usched") > >> Interface ("Ushm") > >> Module ("Usignal") > >> Interface ("Ustat") > >> Interface ("Usocket") > >> Interface ("Usyslog") > >> Interface ("Utime") > >> Module ("Utypes") > >> Interface ("Uucontext") > >> Interface ("Uugid") > >> Interface ("Uuio") > >> Interface ("Uutsname") > >>=20 > >> end > >>=20 > > > >--_55ac72c8-d027-4bd6-a303-434a73dcc5db_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > >Do you need it?
> >Is there a sufficient common/Uresource.i3?
> > =3B
> >I generally removed whatever isn't used=2C and made the remainders portable= > >.
> >I can look into restoring more=2C but what do you need and what is there? (= > >I can look.)
> > =3B
> > =3B
> > =3B- Jay

 =3B
>=3B To: m3devel at elegosoft.com
>=3B= > > Date: Fri=2C 24 Apr 2009 22:58:23 -0700
>=3B From: mika at async.caltech= > >.edu
>=3B CC: mika at camembert.async.caltech.edu
>=3B Subject: [M3d= > >evel] Uresource on freebsd 4?
>=3B
>=3B
>=3B Is there any = > >particular reason Uresource no longer exists on FreeBSD4?
>=3B The m3m= > >akefile
>=3B
>=3B m3core/src/unix/freebsd-4/m3makefile
>=3B= > >
>=3B looks like the following=2C and Uresource isn't picked up anywh= > >ere else:
>=3B
>=3B if TRUE
>=3B
>=3B Module ("Usigna= > >l")
>=3B Interface ("Uucontext")
>=3B
>=3B else
>=3B <= > >BR>>=3B Interface ("Udir")
>=3B Interface ("Uerror")
>=3B %Inte= > >rface ("Ugrp")
>=3B Interface ("Uipc")
>=3B Interface ("Umman") >R>>=3B Module ("Umsg")
>=3B Interface ("Unix")
>=3B Interface (= > >"Uprocess")
>=3B Interface ("Upthread")
>=3B Interface ("Upwd") >R>>=3B Interface ("Uresource")
>=3B Interface ("Usem")
>=3B Int= > >erface ("Usched")
>=3B Interface ("Ushm")
>=3B Module ("Usignal")= > >
>=3B Interface ("Ustat")
>=3B Interface ("Usocket")
>=3B In= > >terface ("Usyslog")
>=3B Interface ("Utime")
>=3B Module ("Utypes= > >")
>=3B Interface ("Uucontext")
>=3B Interface ("Uugid")
>= > >=3B Interface ("Uuio")
>=3B Interface ("Uutsname")
>=3B
>= > >=3B end
>=3B
> >= > > > >--_55ac72c8-d027-4bd6-a303-434a73dcc5db_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 25 10:01:12 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 08:01:12 +0000 Subject: [M3devel] Uresource on freebsd 4? In-Reply-To: <200904250632.n3P6WThS038574@camembert.async.caltech.edu> References: Your message of "Sat, 25 Apr 2009 06:14:28 -0000." <200904250632.n3P6WThS038574@camembert.async.caltech.edu> Message-ID: I should have read the docs first. http://www.opengroup.org/onlinepubs/000095399/basedefs/sys/resource.h.html Only guarantees ru_utime and ru_stime. So maybe a portable wrapper isn't such a bad idea, since it'd only copy back so little. The various time_t, struct timeval, struct tm, struct itimerval, are some of the only system-dependent code/types remaining but maybe I should have to live with them not going away. Maybe. Modula-3 does layer over all of these anyway so more "refactoring" can probably remove them all. (ie: pushing some of the wrapping up to libm3). But if that's adequate -- exposing just ru_utime and ru_stime, then so is probably the old RTProcessPosix. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] Uresource on freebsd 4? Date: Sat, 25 Apr 2009 07:52:31 +0000 Does something like this suffice? Seconds used by current process as a float (including sub-second resolution). http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/runtime/POSIX/Attic/RTProcessPosix.i3?rev=1.1;content-type=text%2Fplain http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/runtime/POSIX/Attic/RTProcessPosixC.c?rev=1.7;content-type=text%2Fplain Notice it is in Attic. If not, can you write your own similar? The full getrusage has that huge struct.. seems best to not expose the whole thing but have folks write little C wrappers for just what they need. A portable wrapper would copy out all the fields, for "all the fields" defined as all the ones implemented by all systems. Only to have most users probably ignore most of them. Notice the cruft: struct_rusage = RECORD ru_utime: Utime.struct_timeval; (* user time used *) ru_stime: Utime.struct_timeval; (* system time used *) ru_maxrss: long; ru_ixrss: long; (* integral shared text size *) (* Unsupported in Linux 1.0: ru_ismrss: long; (* integral shared memory size*) ******************************) kind of makes you wonder....when the FreeBSD path has stuff commented out because Linux 1.0 doesn't support it, which parts are correct? And is it still correct in FreeBSD 5, 6, 7, 9, 10? (Did it get copied blindly to other directoryes, like maybe Darwin?) I guess the only client used utime and stime (based on the code in the Attic). Mistakes here -- such as commenting out fields that are actually there -- would generally result in stack corruption, which might be ok, on some days, on some systems, with some compilers, with some compiler flags, depending on what is nearby on the stack, and what it gets overwritten with. Very dangerous stuff.. For Win32, lookup GetProcessTimes and GetThreadTimes. getrlimit doesn't look so problematic, at least based on the FreeBSD4 version. (Something is really weird with mail encoding, could be me, using a variety of modern mail clients..) - Jay > To: jay.krell at cornell.edu > Date: Fri, 24 Apr 2009 23:32:29 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Uresource on freebsd 4? > > > I use it for timing programs (getrusage). Is there another way of > doing that in Modula-3? > > This declaration: > > <*EXTERNAL*> PROCEDURE getrusage (who: int; VAR rus: struct_rusage): int; > > I'm sure getrlimit is useful too. > > These things have been in Modula-3 for a long time... > > It's the only thing that's missing that I personally use. Except > for some disturbances in m3tk things are now compiling for me... > > Mika > > > Jay writes: > >--_55ac72c8-d027-4bd6-a303-434a73dcc5db_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Do you need it? > > > >Is there a sufficient common/Uresource.i3? > > > >=20 > > > >I generally removed whatever isn't used=2C and made the remainders portable= > >. > > > >I can look into restoring more=2C but what do you need and what is there? (= > >I can look.) > > > >=20 > > > >=20 > > > > - Jay > > > >=20 > >> To: m3devel at elegosoft.com > >> Date: Fri=2C 24 Apr 2009 22:58:23 -0700 > >> From: mika at async.caltech.edu > >> CC: mika at camembert.async.caltech.edu > >> Subject: [M3devel] Uresource on freebsd 4? > >>=20 > >>=20 > >> Is there any particular reason Uresource no longer exists on FreeBSD4? > >> The m3makefile > >>=20 > >> m3core/src/unix/freebsd-4/m3makefile > >>=20 > >> looks like the following=2C and Uresource isn't picked up anywhere else: > >>=20 > >> if TRUE > >>=20 > >> Module ("Usignal") > >> Interface ("Uucontext") > >>=20 > >> else > >>=20 > >> Interface ("Udir") > >> Interface ("Uerror") > >> %Interface ("Ugrp") > >> Interface ("Uipc") > >> Interface ("Umman") > >> Module ("Umsg") > >> Interface ("Unix") > >> Interface ("Uprocess") > >> Interface ("Upthread") > >> Interface ("Upwd") > >> Interface ("Uresource") > >> Interface ("Usem") > >> Interface ("Usched") > >> Interface ("Ushm") > >> Module ("Usignal") > >> Interface ("Ustat") > >> Interface ("Usocket") > >> Interface ("Usyslog") > >> Interface ("Utime") > >> Module ("Utypes") > >> Interface ("Uucontext") > >> Interface ("Uugid") > >> Interface ("Uuio") > >> Interface ("Uutsname") > >>=20 > >> end > >>=20 > > > >--_55ac72c8-d027-4bd6-a303-434a73dcc5db_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > >Do you need it?
> >Is there a sufficient common/Uresource.i3?
> > =3B
> >I generally removed whatever isn't used=2C and made the remainders portable= > >.
> >I can look into restoring more=2C but what do you need and what is there? (= > >I can look.)
> > =3B
> > =3B
> > =3B- Jay

 =3B
>=3B To: m3devel at elegosoft.com
>=3B= > > Date: Fri=2C 24 Apr 2009 22:58:23 -0700
>=3B From: mika at async.caltech= > >.edu
>=3B CC: mika at camembert.async.caltech.edu
>=3B Subject: [M3d= > >evel] Uresource on freebsd 4?
>=3B
>=3B
>=3B Is there any = > >particular reason Uresource no longer exists on FreeBSD4?
>=3B The m3m= > >akefile
>=3B
>=3B m3core/src/unix/freebsd-4/m3makefile
>=3B= > >
>=3B looks like the following=2C and Uresource isn't picked up anywh= > >ere else:
>=3B
>=3B if TRUE
>=3B
>=3B Module ("Usigna= > >l")
>=3B Interface ("Uucontext")
>=3B
>=3B else
>=3B <= > >BR>>=3B Interface ("Udir")
>=3B Interface ("Uerror")
>=3B %Inte= > >rface ("Ugrp")
>=3B Interface ("Uipc")
>=3B Interface ("Umman") >R>>=3B Module ("Umsg")
>=3B Interface ("Unix")
>=3B Interface (= > >"Uprocess")
>=3B Interface ("Upthread")
>=3B Interface ("Upwd") >R>>=3B Interface ("Uresource")
>=3B Interface ("Usem")
>=3B Int= > >erface ("Usched")
>=3B Interface ("Ushm")
>=3B Module ("Usignal")= > >
>=3B Interface ("Ustat")
>=3B Interface ("Usocket")
>=3B In= > >terface ("Usyslog")
>=3B Interface ("Utime")
>=3B Module ("Utypes= > >")
>=3B Interface ("Uucontext")
>=3B Interface ("Uugid")
>= > >=3B Interface ("Uuio")
>=3B Interface ("Uutsname")
>=3B
>= > >=3B end
>=3B
> >= > > > >--_55ac72c8-d027-4bd6-a303-434a73dcc5db_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 25 10:12:23 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 08:12:23 +0000 Subject: [M3devel] FW: Uresource on freebsd 4? In-Reply-To: <200904250632.n3P6WThS038574@camembert.async.caltech.edu> References: Your message of "Sat, 25 Apr 2009 06:14:28 -0000." <200904250632.n3P6WThS038574@camembert.async.caltech.edu> Message-ID: was slightly truncated: >> But if that's adequate -- exposing just ru_utime and ru_stime, then so is probably the old RTProcessPosix. The Linux/*BSD struct rusage documentation suggests they are all identical, so I admit, I was crying wolf/fire without knowing. But Solaris 2.9 documentation suggests ours is/was wrong, but I haven't really checked. It is fairly moot now anyway, unless someone really wants getrusage restored along with its full struct. Surely the options of a) do nothing b) restore RTProcessPosix c) add a new safe/copying wrapper that only return ru_[us]time are more likely.. [truncated deliberatley] -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 25 10:41:20 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 08:41:20 +0000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <200904250338.n3P3cHlc030469@camembert.async.caltech.edu> References: Your message of "Fri, 24 Apr 2009 22:40:41 -0000." <200904250338.n3P3cHlc030469@camembert.async.caltech.edu> Message-ID: > Jay, your assembly worked too! And as you say, it's much easier to As an /experiment/ you might try building that assembly yourself? First you need to cd to m3cc and cm3 -DM3CC_TARGET=foo. My config files probe around for the correct seeming m3cg and use it. And then scripts/python/boot1.py foo. The point of the "experiment" would be see if anyone else can produce these "bootstrap" archives, as a possible first toward elevating their status -- ie: using them as a form of distribution. But not clear if they should be or not -- to what extent os /version/ is a problem and to what extent it should be dealt with, and if that should be via building on the various hosts or these "bootstrap" archives, or something else. You know, ideally, maybe, given time/energy, there'd be regulary produced (daily) "bootstrap" archives for "all" the platforms, "min", and "std". Including maybe even a cm3cg..though that cm3cg would be "Canadian" and seems maybe a dubious thing to depend on working regularly. So, while we might output binary distributions for various "current" platforms, these could be fallbacks for other older/newer versions. As well, esp. if the Canadian cm3cg worked out, these could even be the real distributions -- benefit being that they can all be cross built from one or a few machines -- without having to automate each host platform. Though maybe that's too much to do on one machine. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Apr 26 06:49:38 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Apr 2009 14:49:38 +1000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: References: Your message of "Fri, 24 Apr 2009 22:40:41 -0000." <200904242305.n3ON56IS018186@camembert.async.caltech.edu> Message-ID: <2D59910B-DD11-406E-BA79-C0891F4D7260@cs.purdue.edu> On 25 Apr 2009, at 09:21, Jay wrote: > >> By the way, I take it booting the compiler "old-fashionedly" with >> PM3 is out of the question? > > > What is the PM3 way? > The SRC way is out of the question at least (unless you want to / > start/ with it and go through a few releases...). > > I gather that the PM3 was good and could be resusitated. > But it is is some work..maybe too much. > > I gather that PM3 factored out word size and endianness from the IL? > And padding/alignment? And jmpbuf size? Nope. Same as cm3. > > And whatever else is target-dependent? > There isn't much. > Not impossible, but seems a bit onerous. > > padding/alignment actually don't have to be factored out, kind of. > They can be made "worst case", as long as the interactions with C > are correct. > > word size and endianness are in the IL but I think only barely. > > jmpbuf size is easy to factor out at a small perf cost. > or again, make it worst case. > > > These "worst cases" are likely to be pretty bad, such that they are > ok for building the first compiler, but then you'd want to > immediately rebuild it "ideally". > jmpbuf size varies from around 16 bytes to over 200 bytes for example. > You could also use > extern int jmpbufsize; > jmpbuf = alloca(jmpbufsize) > > > thereby not blowing stack, but still being slow. > Again, fine for bootstrap purposes but it should end there. > > > "aligned procedures" can be factored out easily via acting worst case. > > > Is this what PM3 did though? > Shipped one textual IL for all platforms, built m3cc (which doesn't / > really/ > require having cm3), then built everything from the portable IL, > then rebuilt it all again more ideally? > > I think if a portable distribution format is to be had, maybe go all > the way to using a C backend? However that doesn't solve all/many/ > any of the above problems, given how low level the IL is. > > > - Jay From hosking at cs.purdue.edu Sun Apr 26 06:51:45 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Apr 2009 14:51:45 +1000 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: References: Your message of "Fri, 24 Apr 2009 22:40:41 -0000." <200904250338.n3P3cHlc030469@camembert.async.caltech.edu> Message-ID: Broken mostly because updated libraries detect forging of thread contexts (state) for security reasons and blow up. On 25 Apr 2009, at 14:12, Jay wrote: > Cool. > > > If I use user threads, it's a different story (which is probably > too bad, > > Oops, right, I forgot, I should have mentioned that, user threads > have likely been broken on all platforms for a while. I noticed that > on PPC_LINUX. I think it is trivial to fix. Or use pthreads.. > > > - Jay > > > > To: jay.krell at cornell.edu > > Date: Fri, 24 Apr 2009 20:38:17 -0700 > > From: mika at async.caltech.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] help booting CM3 on FreeBSD 4.11? > > > > Jay (and others), > > > > Success! I think.... I was able to build the compiler, after much > > experimentation, by using Jay's build order and linking with - > libc_r. > > Mentor works, and that's usually a good sign. > > > > Jay, your assembly worked too! And as you say, it's much easier to > > bootstrap with that than to do what I was trying to do (but I did > > both, several times, just to make sure). > > > > I don't know why I was having linking problems with -libc_r earlier. > > Now it just seems to work. So, pthreads on FreeBSD 4. > > > > If I use user threads, it's a different story (which is probably > too bad, > > as I know that user threads work absolutely fine in my old version > of CM3): > > > > I can build a compiler fine, but the bootstrapped cm3 crashes in > > the user thread code. Note that exactly the same thing happens > whether > > I bootstrap with the assembly version from Jay or from v. 5.3.4, > which > > I think is what I had. Here we go: > > > > Starting program: /usr/local/cm3/pkg/cm3/FreeBSD4/cm3 > > > > Program received signal SIGSEGV, Segmentation fault. > > 16_82568bb in RTHooks.PushEFrame (frame=16_bfbff3f4) at ../src/ > thread/POSIX/ThreadPosix.m3:1599 > > 1599 f.next := self.context.handlers; > > (gdb) where > > #0 16_82568bb in RTHooks.PushEFrame (frame=16_bfbff3f4) at ../src/ > thread/POSIX/ThreadPosix.m3:1599 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Apr 26 07:22:00 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 25 Apr 2009 22:22:00 -0700 Subject: [M3devel] Performance issues with CM3 Message-ID: <200904260522.n3Q5M01a000401@camembert.async.caltech.edu> Hello again, Now I've managed to get all the code up and running under CM3. I found and committed fixes to a bug in Wx and some code in one of the m3tk libraries that looked like it never was finished in the first place. As I mentioned earlier, I wasn't able to get user threads working in CM3 on FreeBSD 4.11. But with some help from Jay, I was able to get things working with libc_r. Performance, unfortunately, leaves something to be desired. For the first time I've been able to compare timings on identical hardware between the PM3 I was using and the CM3 that's out now. Note that optimization doesn't seem to work..? (Not even -O, much less -O3... the compiler segfaults.) Here's what I get, using no optimization either in PM3 or CM3. The test is my Scheme interpreter generating SQL and Modula-3 code (a bit like the Hibernate system you can get for Java): CPU seconds CM3 PM3 First version 5.269 1.366 Fewer NEWs 2.039 0.440 (code cleanup on my part) TYPECASE hack 1.770 (see below) Some "poor man's profiling" (i.e., ctrl-C'ing in m3gdb) suggests that most of the time is spent either in threading code (this could just be a lousy implementation in libc_r), the garbage collector, or in "ScanTypecase". The only one of these routines I am qualified to do anything about is ScanTypecase. I don't know why the Critical Mass people... .. all over this code. I assume it has something to do with Java. The PM3 code (from SRC?) has this wonderful, concise, efficient bit: PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = VAR t := Get (b); BEGIN IF (a >= RT0u.nTypes) THEN BadType (a) END; IF (a = 0) THEN RETURN TRUE END; RETURN (t.typecode <= a AND a <= t.lastSubTypeTC); END IsSubtype; replaced with the following absolute abomination in CM3: PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = VAR t: RT0.TypeDefn; BEGIN IF (a = RT0.NilTypecode) THEN RETURN TRUE END; t := Get (a); IF (t = NIL) THEN RETURN FALSE; END; IF (t.typecode = b) THEN RETURN TRUE END; WHILE (t.kind = ORD (TK.Obj)) DO IF (t.link_state = 0) THEN FinishTypecell (t, NIL); END; t := LOOPHOLE (t, RT0.ObjectTypeDefn).parent; IF (t = NIL) THEN RETURN FALSE; END; IF (t.typecode = b) THEN RETURN TRUE; END; END; IF (t.traced # 0) THEN RETURN (b = RT0.RefanyTypecode); ELSE RETURN (b = RT0.AddressTypecode); END; END IsSubtype; Furthermore, CM3 has a hook for "ScanTypecase" that's missing in PM3 (the older compiler actually generates code for this): PROCEDURE ScanTypecase (ref: REFANY; x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; BEGIN IF (ref = NIL) THEN RETURN 0; END; tc := TYPECODE (ref); p := x; i := 0; LOOP IF (p.uid = 0) THEN RETURN i; END; IF (p.defn = NIL) THEN p.defn := FindType (p.uid); IF (p.defn = NIL) THEN Fail (RTE.MissingType, RTModule.FromDataAddress(x), LOOPHOLE (p.uid, ADDRESS), NIL); END; END; xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; IF (tc = xc) OR IsSubtype (tc, xc) THEN RETURN i; END; INC (p, ADRSIZE (p^)); INC (i); END; END ScanTypecase; Where to begin? A loop with all kinds of runtime checks of properties that are supposedly known at compile time? IsSubtype (itself a loop) called from inside the loop? I was able to cut out almost all of the typecase activity from my program by using the following code in RTType.m3, which depends on the ADDRESS x never changing (well more specifically never being the same for two TYPECASE statements): TYPE TypeCaseResult = RECORD x : ADDRESS; tc : Typecode; arm : INTEGER; END; CONST TCCachePow = 6; TCCacheSize = Word.Shift(1,TCCachePow); TCMask = TCCacheSize-1; VAR TCCache := ARRAY [0..TCCacheSize-1] OF TypeCaseResult { TypeCaseResult { LOOPHOLE(0,ADDRESS), 0, -1 } , .. }; (* VAR tcScans := 0; tcHits := 0; (* instrumenting counters *) *) PROCEDURE ScanTypecase (ref: REFANY; x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; BEGIN tc := TYPECODE (ref); IF (ref = NIL) THEN RETURN 0; END; WITH hash = Word.And(Word.Times(tc, Word.RightShift(LOOPHOLE(x,Word.T),2)), TCMask), entry = TCCache[hash] DO (*INC(tcScans);*) IF entry.x = x AND entry.tc = tc THEN (*INC(tcHits);*) RETURN entry.arm END; p := x; i := 0; LOOP IF (p.uid = 0) THEN entry.x := x; entry.tc := tc; entry.arm := i; RETURN i; END; IF (p.defn = NIL) THEN p.defn := FindType (p.uid); IF (p.defn = NIL) THEN Fail (RTE.MissingType, RTModule.FromDataAddress(x), LOOPHOLE (p.uid, ADDRESS), NIL); END; END; xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; IF (tc = xc) OR IsSubtype (tc, xc) THEN entry.x := x; entry.tc := tc; entry.arm := i; RETURN i; END; INC (p, ADRSIZE (p^)); INC (i); END; END; END ScanTypecase; I'm guessing the speedup for TYPECASE itself is a factor of at least ten. But it's still a pretty nasty hack. And there is still a lot of IsSubtype activity from narrowing. I suppose that the way the typecodes are generated in CM3 is sufficiently different (meant to be extended at runtime?) from how it was done in PM3 that one can't really go back to the old code. Cardelli's idea of keeping an array of parents up to ROOT plus a "depth" for each type might have merit, though. To see if a is a subtype of b, something like: b = a.ancestors[a.depth-b.depth-1] (* with appropriate range checks *) Would this be easy to put in? I'm not sure how one can be sure that typecodes are done being generated? There's something called RTTypeSRC.FinishObjectTypes .. And PM3 still generates code that's four times faster. Mika From mika at async.caltech.edu Sun Apr 26 07:28:25 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 25 Apr 2009 22:28:25 -0700 Subject: [M3devel] Confusing, but non-critical bug... Message-ID: <200904260528.n3Q5SPcu000732@camembert.async.caltech.edu> So I have a library, built against m3tk. Everything compiles, but when cm3 tries to "ar" the library: new "TypeTranslator.io" -> archiving libsstubgen.a Fatal Error: incomplete library missing compiled interface "M3AST_all.io" imported by: M3AST_SM_F.i3 M3AST_PG.m3 M3AST_SM.m3 TypeNames.m3 AstToVal.m3 AstToType.m3 M3ASTScopeNames.m3 M3AST_PG_M.i3: missing object types: _t1ee311ce imported by: M3AST_PG.m3 M3AST_all.i3: missing object types: _t8eb32ef8 _t9ffde2a4 _ta2581bcc _t52bfa811 _t249b6ddc _t172a75ba _t774a90ea _tc92a7e8c _t1d23b703 _t2812849 _t1796950e _te47b91c _tccbf0da _tb53c334a _tf38721e4 _tbbcfc2cb _teec6ca97 imported by: M3AST_PG.m3 AstToType.m3 AstToVal.m3 M3AST_SM.m3 M3AST_SM_F.i3 missing compiled interface "M3AST_PG_M.io" imported by: M3AST_PG.m3 seconds #times operation 0.06 22 inhaling library link info 0.01 27 checking old link info 0.21 896 merging new link info 0.05 4 garbage collection --------------------------------------------------- 0.34 TOTAL rm m3make.args cd ../src So I add "IMPORT M3AST_all;" to one of my interfaces (it's not used there at all): (1943)trs80:~/t-cm3/mscheme/sstubgen/src>cm3 -x --- building in ../FreeBSD4 --- ignoring override("sstubgen", "/home/mika/t-cm3/mscheme") new source -> compiling TypeTranslator.i3 "../src/TypeTranslator.i3", line 12: warning: not used (M3AST_all) 1 warning encountered new source -> compiling TypeTranslator.m3 "../src/TypeTranslator.m3", line 353: warning: not used (Add) 1 warning encountered new opaque info -> recompiling TypeTranslator.m3 "../src/TypeTranslator.m3", line 353: warning: not used (Add) 1 warning encountered new "TypeTranslator.io" -> archiving libsstubgen.a (1944)trs80:~/t-cm3/mscheme/sstubgen/src> Hmmmmmmmmmmmmm....... is anyone interested in looking at this? As I said, it's non-critical (I can get things working, clearly, even with the bug present), but it's very confusing. I have to import an interface I'm not using...why? Where to begin looking? Mika From mika at async.caltech.edu Sun Apr 26 07:30:01 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 25 Apr 2009 22:30:01 -0700 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: Your message of "Sat, 25 Apr 2009 22:28:05 PDT." <0FB5E4EA-571C-4CB9-8606-92F12B91A40B@gmail.com> Message-ID: <200904260530.n3Q5U1NE000824@camembert.async.caltech.edu> User threads certainly work fine on this machine (see my previous email) with PM3... some would say they work "better"... :-) Jay writes: > >--Apple-Mail-1-423481883 >Content-Type: text/plain; > charset=us-ascii; > format=flowed; > delsp=yes >Content-Transfer-Encoding: 7bit > >I think also due to simple use before init. > > - Jay (phone) > >On Apr 25, 2009, at 9:51 PM, Tony Hosking wrote: > >> Broken mostly because updated libraries detect forging of thread >> contexts (state) for security reasons and blow up. >> >> On 25 Apr 2009, at 14:12, Jay wrote: >> >>> Cool. >>> >>> > If I use user threads, it's a different story (which is probably >>> too bad, >>> >>> Oops, right, I forgot, I should have mentioned that, user threads >>> have likely been broken on all platforms for a while. I noticed >>> that on PPC_LINUX. I > > >--Apple-Mail-1-423481883 >Content-Type: text/html; > charset=utf-8 >Content-Transfer-Encoding: quoted-printable > >
I think also due to simple use = >before init.

 - Jay (phonestyle=3D"-webkit-composition-fill-color: rgba(175, 192, 227, 0.231373); = >-webkit-composition-frame-color: rgba(77, 128, 180, 0.231373); = >">)

On Apr 25, 2009, at 9:51 PM, Tony Hosking = ><hosking at cs.purdue.edu> = >wrote:

apple-content-edited=3D"true">style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >normal; font-variant: normal; font-weight: normal; letter-spacing: = >normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; = >-khtml-line-break: after-white-space; ">style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >normal; font-variant: normal; font-weight: normal; letter-spacing: = >normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">Broken mostly = >because updated libraries detect forging of thread contexts (state) for = >security reasons and blow up.

On = >25 Apr 2009, at 14:12, Jay wrote:

class=3D"Apple-interchange-newline">
class=3D"Apple-style-span" style=3D"border-collapse: separate; color: = >rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >normal; font-variant: normal; font-weight: normal; letter-spacing: = >normal; line-height: normal; orphans: 2; text-align: auto; text-indent: = >0px; text-transform: none; white-space: normal; widows: 2; word-spacing: = >0px; -webkit-border-horizontal-spacing: 0px; = >-webkit-border-vertical-spacing: 0px; = >-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = >auto; -webkit-text-stroke-width: 0; ">
style=3D"font-size: 10pt; font-family: Verdana; = >">Cool.
 
 > If I use user threads, it's a different = >story (which is probably too bad,

Oops, right, I forgot, I should = >have mentioned that, user threads have likely been broken on all = >platforms for a while. I noticed that on PPC_LINUX. = >I

= > >--Apple-Mail-1-423481883-- From mika at async.caltech.edu Sun Apr 26 07:33:08 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 25 Apr 2009 22:33:08 -0700 Subject: [M3devel] FW: Uresource on freebsd 4? In-Reply-To: Your message of "Sat, 25 Apr 2009 08:12:23 -0000." Message-ID: <200904260533.n3Q5X8UW001003@camembert.async.caltech.edu> As far as I'm concerned, I've sucked in all the Uresource junk into interfaces inside my own application, so forget I said anything about it. (One day when I'm ambitious (or get weird segfaults!), I'll write the C wrappers; for now they're just copies of the old PM3 interfaces..) Mika Jay writes: >--_c686b76c-f145-4c40-913c-ad76373e06f4_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >was slightly truncated: > >=20 > > >> But if that's adequate -- exposing just ru_utime and ru_stime=2C then s= >o is probably the old RTProcessPosix. > > > >The Linux/*BSD struct rusage documentation suggests they are all identical= >=2C so I admit=2C I was crying wolf/fire without knowing. > >But Solaris 2.9 documentation suggests ours is/was wrong=2C but I haven't r= >eally checked. > >It is fairly moot now anyway=2C unless someone really wants getrusage resto= >red along with its full struct. Surely the options of a) do nothing b) rest= >ore RTProcessPosix c) add a new safe/copying wrapper that only return ru_[u= >s]time are more likely.. > >=20 > >=20 > > [truncated deliberatley]=20 > >--_c686b76c-f145-4c40-913c-ad76373e06f4_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >was slightly truncated:
> =3B
> =3B>=3B>=3B But if that's adequate -- exposing just ru_utime and r= >u_stime=2C then so is probably the old RTProcessPosix.


>The Linux/*BSD struct rusage documentation suggests they are all identical= >=2C so I admit=2C I was crying wolf/fire without knowing.
>But =3BSolaris 2.9 documentation suggests =3Bours is/was wrong=2C b= >ut I haven't really checked.
>It is fairly moot now anyway=2C unless someone really wants getrusage resto= >red along with its full struct. Surely the options of a) do nothing b) rest= >ore RTProcessPosix c) add a new =3Bsafe/copying wrapper that only retur= >n ru_[us]time are more likely..
> =3B
> =3B
> =3B[truncated deliberatley]
>= > >--_c686b76c-f145-4c40-913c-ad76373e06f4_-- From jay.krell at cornell.edu Sun Apr 26 07:37:04 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 22:37:04 -0700 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <2D59910B-DD11-406E-BA79-C0891F4D7260@cs.purdue.edu> References: Your message of "Fri, 24 Apr 2009 22:40:41 -0000." <200904242305.n3ON56IS018186@camembert.async.caltech.edu> <2D59910B-DD11-406E-BA79-C0891F4D7260@cs.purdue.edu> Message-ID: <3BD2A0FC-BDA0-4C43-A229-B8E042E76BA6@gmail.com> Oh phew. Someone said they played tricks with il, so I thought of beneficial but difficult tricks. Um but what is the CM3 way?(somewhat rhetorical..must stop,see signature..) - Jay (phone!) On Apr 25, 2009, at 9:49 PM, Tony Hosking wrote: > > On 25 Apr 2009, at 09:21, Jay wrote: > >> >>> By the way, I take it booting the compiler "old-fashionedly" with >>> PM3 is out of the question? >> >> >> What is the PM3 way? >> The SRC way is out of the question at least (unless you want to / >> start/ with it and go through a few releases...). >> >> I gather that the PM3 was good and could be resusitated. >> But it is is some work..maybe too much. >> >> I gather that PM3 factored out word size and endianness from the IL? >> And padding/alignment? And jmpbuf size? > > Nope. Same as cm3. > >> >> And whatever else is target-dependent? >> There isn't much. >> Not impossible, but seems a bit onerous. >> >> >> >> >> >> >> >> >> >> >> >> >> >> From jay.krell at cornell.edu Sun Apr 26 07:28:05 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 22:28:05 -0700 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: References: Your message of "Fri, 24 Apr 2009 22:40:41 -0000." <200904250338.n3P3cHlc030469@camembert.async.caltech.edu> Message-ID: <0FB5E4EA-571C-4CB9-8606-92F12B91A40B@gmail.com> I think also due to simple use before init. - Jay (phone) On Apr 25, 2009, at 9:51 PM, Tony Hosking wrote: > Broken mostly because updated libraries detect forging of thread > contexts (state) for security reasons and blow up. > > On 25 Apr 2009, at 14:12, Jay wrote: > >> Cool. >> >> > If I use user threads, it's a different story (which is probably >> too bad, >> >> Oops, right, I forgot, I should have mentioned that, user threads >> have likely been broken on all platforms for a while. I noticed >> that on PPC_LINUX. I -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 26 07:40:34 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 22:40:34 -0700 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <200904260530.n3Q5U1NE000824@camembert.async.caltech.edu> References: <200904260530.n3Q5U1NE000824@camembert.async.caltech.edu> Message-ID: <09E195AF-2D6E-4A76-9328-DC4F29049719@gmail.com> It is easy to fix for many non Linux systems.and possible for Linux. Fairly well worn topic. - Jay (phone) On Apr 25, 2009, at 10:30 PM, Mika Nystrom wrote: > User threads certainly work fine on this machine (see my previous > email) with PM3... some would say they work "better"... :-) > > Jay writes: >> >> --Apple-Mail-1-423481883 >> Content-Type: text/plain; >> charset=us-ascii; >> format=flowed; >> delsp=yes >> Content-Transfer-Encoding: 7bit >> >> I think also due to simple use before init. >> >> - Jay (phone) >> >> On Apr 25, 2009, at 9:51 PM, Tony Hosking >> wrote: >> >>> Broken mostly because updated libraries detect forging of thread >>> contexts (state) for security reasons and blow up. >>> >>> On 25 Apr 2009, at 14:12, Jay wrote: >>> >>>> Cool. >>>> >>>>> If I use user threads, it's a different story (which is probably >>>> too bad, >>>> >>>> Oops, right, I forgot, I should have mentioned that, user threads >>>> have likely been broken on all platforms for a while. I noticed >>>> that on PPC_LINUX. I >> >> >> --Apple-Mail-1-423481883 >> Content-Type: text/html; >> charset=utf-8 >> Content-Transfer-Encoding: quoted-printable >> >>
I think also due to simple use = >> before init.

 - Jay (phone> span" = >> style=3D"-webkit-composition-fill-color: rgba(175, 192, 227, >> 0.231373); = >> -webkit-composition-frame-color: rgba(77, 128, 180, 0.231373); = >> ">)

On Apr 25, 2009, at 9:51 PM, Tony Hosking = >> <hosking at cs.purdue.edu> a>> = >> wrote:

> apple-content-edited=3D"true">> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >> normal; font-variant: normal; font-weight: normal; letter-spacing: = >> normal; line-height: normal; text-align: auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">
> style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; = >> -khtml-line-break: after-white-space; ">> span" = >> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >> normal; font-variant: normal; font-weight: normal; letter-spacing: = >> normal; line-height: normal; text-align: auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">Broken mostly = >> because updated libraries detect forging of thread contexts (state) >> for = >> security reasons and blow up.
 > div>
On = >> 25 Apr 2009, at 14:12, Jay wrote:

> class=3D"Apple-interchange-newline">
> class=3D"Apple-style-span" style=3D"border-collapse: separate; >> color: = >> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >> normal; font-variant: normal; font-weight: normal; letter-spacing: = >> normal; line-height: normal; orphans: 2; text-align: auto; text- >> indent: = >> 0px; text-transform: none; white-space: normal; widows: 2; word- >> spacing: = >> 0px; -webkit-border-horizontal-spacing: 0px; = >> -webkit-border-vertical-spacing: 0px; = >> -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = >> auto; -webkit-text-stroke-width: 0; ">
> style=3D"font-size: 10pt; font-family: Verdana; = >> ">Cool.
 
 > If I use user threads, it's a >> different = >> story (which is probably too bad,

Oops, right, I forgot, I >> should = >> have mentioned that, user threads have likely been broken on all = >> platforms for a while. I noticed that on PPC_LINUX. = >> I

> body>= >> >> --Apple-Mail-1-423481883-- From jay.krell at cornell.edu Sun Apr 26 07:46:05 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 25 Apr 2009 22:46:05 -0700 Subject: [M3devel] FW: Uresource on freebsd 4? In-Reply-To: <200904260533.n3Q5X8UW001003@camembert.async.caltech.edu> References: <200904260533.n3Q5X8UW001003@camembert.async.caltech.edu> Message-ID: <818A2D47-EEB1-4EFB-B779-8237076A4C89@gmail.com> Cool. But reasonable imho to see your code and restore rtprocessposix if it suffices.. Or maybe other. Double check what you have, it is dangerous. - Jay (phone) On Apr 25, 2009, at 10:33 PM, Mika Nystrom wrote: > > As far as I'm concerned, I've sucked in all the Uresource junk into > interfaces inside my own application, so forget I said anything > about it. (One day when I'm ambitious (or get weird segfaults!), > I'll write the C wrappers; for now they're just copies of the old > PM3 interfaces..) > > Mika > > Jay writes: >> >> >> >> >> >> >> >> >> >> From hosking at cs.purdue.edu Sun Apr 26 10:54:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Apr 2009 18:54:57 +1000 Subject: [M3devel] Performance issues with CM3 In-Reply-To: <200904260522.n3Q5M01a000401@camembert.async.caltech.edu> References: <200904260522.n3Q5M01a000401@camembert.async.caltech.edu> Message-ID: On 26 Apr 2009, at 15:22, Mika Nystrom wrote: > > Hello again, > > Now I've managed to get all the code up and running under CM3. I > found and committed fixes to a bug in Wx and some code in one of > the m3tk libraries that looked like it never was finished in the > first place. > > As I mentioned earlier, I wasn't able to get user threads working > in CM3 on FreeBSD 4.11. But with some help from Jay, I was able to > get things working with libc_r. Performance, unfortunately, > leaves something to be desired. > > For the first time I've been able to compare timings on identical > hardware between the PM3 I was using and the CM3 that's out now. > > Note that optimization doesn't seem to work..? (Not even -O, much > less -O3... the compiler segfaults.) Are you passing -gstabs? It should not segfault on -O3 - this is a regression if it does. > Here's what I get, using no optimization either in PM3 or CM3. The > test is my Scheme interpreter generating SQL and Modula-3 code > (a bit like the Hibernate system you can get for Java): > > > CPU seconds CM3 PM3 > First version 5.269 1.366 > Fewer NEWs 2.039 0.440 (code cleanup on my part) > TYPECASE hack 1.770 (see below) > > Some "poor man's profiling" (i.e., ctrl-C'ing in m3gdb) suggests that > most of the time is spent either in threading code (this could just > be a lousy implementation in libc_r), the garbage collector, or in > "ScanTypecase". > > The only one of these routines I am qualified to do anything about is > ScanTypecase. I don't know why the Critical Mass people... colorful > language can one use on m3devel?>.. all over this code. I assume it > has > something to do with Java. > > The PM3 code (from SRC?) has this wonderful, concise, efficient bit: > > PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = > VAR t := Get (b); > BEGIN > IF (a >= RT0u.nTypes) THEN BadType (a) END; > IF (a = 0) THEN RETURN TRUE END; > RETURN (t.typecode <= a AND a <= t.lastSubTypeTC); > END IsSubtype; > > replaced with the following absolute abomination in CM3: > > PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = > VAR t: RT0.TypeDefn; > BEGIN > IF (a = RT0.NilTypecode) THEN RETURN TRUE END; > t := Get (a); > IF (t = NIL) THEN RETURN FALSE; END; > IF (t.typecode = b) THEN RETURN TRUE END; > WHILE (t.kind = ORD (TK.Obj)) DO > IF (t.link_state = 0) THEN FinishTypecell (t, NIL); END; > t := LOOPHOLE (t, RT0.ObjectTypeDefn).parent; > IF (t = NIL) THEN RETURN FALSE; END; > IF (t.typecode = b) THEN RETURN TRUE; END; > END; > IF (t.traced # 0) > THEN RETURN (b = RT0.RefanyTypecode); > ELSE RETURN (b = RT0.AddressTypecode); > END; > END IsSubtype; This is all to support dynamic loading of libraries. > Furthermore, CM3 has a hook for "ScanTypecase" that's missing > in PM3 (the older compiler actually generates code for this): > > PROCEDURE ScanTypecase (ref: REFANY; > x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = > VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; > BEGIN > IF (ref = NIL) THEN RETURN 0; END; > tc := TYPECODE (ref); > p := x; i := 0; > LOOP > IF (p.uid = 0) THEN RETURN i; END; > IF (p.defn = NIL) THEN > p.defn := FindType (p.uid); > IF (p.defn = NIL) THEN > Fail (RTE.MissingType, RTModule.FromDataAddress(x), > LOOPHOLE (p.uid, ADDRESS), NIL); > END; > END; > xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; > IF (tc = xc) OR IsSubtype (tc, xc) THEN RETURN i; END; > INC (p, ADRSIZE (p^)); INC (i); > END; > END ScanTypecase; > > Where to begin? A loop with all kinds of runtime checks of properties > that are supposedly known at compile time? IsSubtype (itself a loop) > called from inside the loop? Not if dynamically loaded! > I was able to cut out almost all of the typecase activity from my > program by using the following code in RTType.m3, which depends on > the ADDRESS x never changing (well more specifically never being > the same for two TYPECASE statements): > > TYPE > TypeCaseResult = RECORD > x : ADDRESS; > tc : Typecode; > arm : INTEGER; > END; > > CONST > TCCachePow = 6; > TCCacheSize = Word.Shift(1,TCCachePow); > TCMask = TCCacheSize-1; > > VAR TCCache := ARRAY [0..TCCacheSize-1] OF TypeCaseResult { > TypeCaseResult { LOOPHOLE(0,ADDRESS), 0, -1 } , > .. > }; > > (* > VAR tcScans := 0; tcHits := 0; (* instrumenting counters *) > *) > > PROCEDURE ScanTypecase (ref: REFANY; > x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = > VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; > BEGIN > tc := TYPECODE (ref); > IF (ref = NIL) THEN RETURN 0; END; > > WITH hash = Word.And(Word.Times(tc, > > Word.RightShift(LOOPHOLE(x,Word.T),2)), > TCMask), > entry = TCCache[hash] DO > (*INC(tcScans);*) > IF entry.x = x AND entry.tc = tc THEN > (*INC(tcHits);*) > RETURN entry.arm > END; > > p := x; i := 0; > LOOP > IF (p.uid = 0) THEN entry.x := x; entry.tc := tc; > entry.arm := i; RETURN i; END; > IF (p.defn = NIL) THEN > p.defn := FindType (p.uid); > IF (p.defn = NIL) THEN > Fail (RTE.MissingType, RTModule.FromDataAddress(x), > LOOPHOLE (p.uid, ADDRESS), NIL); > END; > END; > xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; > IF (tc = xc) OR IsSubtype (tc, xc) THEN entry.x := x; > entry.tc := tc; entry.arm := i; RETURN i; END; > INC (p, ADRSIZE (p^)); INC (i); > END; > END; > END ScanTypecase; > > I'm guessing the speedup for TYPECASE itself is a factor of at least > ten. But it's still a pretty nasty hack. And there is still a lot > of IsSubtype activity from narrowing. > > I suppose that the way the typecodes are generated in CM3 is > sufficiently different (meant to be extended at runtime?) from how > it was done in PM3 that one can't really go back to the old code. > Cardelli's idea of keeping an array of parents up to ROOT plus a > "depth" for each type might have merit, though. > > To see if a is a subtype of b, something like: > > b = a.ancestors[a.depth-b.depth-1] (* with appropriate range checks *) > > Would this be easy to put in? I'm not sure how one can be sure > that typecodes are done being generated? There's something called > RTTypeSRC.FinishObjectTypes .. > > And PM3 still generates code that's four times faster. > > Mika > From hosking at cs.purdue.edu Sun Apr 26 11:08:22 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Apr 2009 19:08:22 +1000 Subject: [M3devel] Confusing, but non-critical bug... In-Reply-To: <200904260528.n3Q5SPcu000732@camembert.async.caltech.edu> References: <200904260528.n3Q5SPcu000732@camembert.async.caltech.edu> Message-ID: <388F44BC-9826-4E4E-AE6B-FD91AE2E9B35@cs.purdue.edu> Definitely something broken in the build. On 26 Apr 2009, at 15:28, Mika Nystrom wrote: > > So I have a library, built against m3tk. Everything compiles, but > when cm3 tries to "ar" the library: > > > new "TypeTranslator.io" -> archiving libsstubgen.a > > Fatal Error: incomplete library > > missing compiled interface "M3AST_all.io" imported by: M3AST_SM_F.i3 > M3AST_PG.m3 M3AST_SM.m3 TypeNames.m3 AstToVal.m3 AstToType.m3 > M3ASTScopeNames.m3 > M3AST_PG_M.i3: missing object types: _t1ee311ce > imported by: M3AST_PG.m3 > M3AST_all.i3: missing object types: _t8eb32ef8 _t9ffde2a4 > _ta2581bcc > _t52bfa811 _t249b6ddc _t172a75ba _t774a90ea _tc92a7e8c > _t1d23b703 > _t2812849 _t1796950e _te47b91c _tccbf0da _tb53c334a _tf38721e4 > _tbbcfc2cb _teec6ca97 > imported by: M3AST_PG.m3 AstToType.m3 AstToVal.m3 M3AST_SM.m3 > M3AST_SM_F.i3 > missing compiled interface "M3AST_PG_M.io" imported by: M3AST_PG.m3 > > seconds #times operation > 0.06 22 inhaling library link info > 0.01 27 checking old link info > 0.21 896 merging new link info > 0.05 4 garbage collection > --------------------------------------------------- > 0.34 TOTAL > > rm m3make.args > cd ../src > > So I add "IMPORT M3AST_all;" to one of my interfaces (it's not used > there at all): > > (1943)trs80:~/t-cm3/mscheme/sstubgen/src>cm3 -x > --- building in ../FreeBSD4 --- > > ignoring override("sstubgen", "/home/mika/t-cm3/mscheme") > > new source -> compiling TypeTranslator.i3 > "../src/TypeTranslator.i3", line 12: warning: not used (M3AST_all) > 1 warning encountered > new source -> compiling TypeTranslator.m3 > "../src/TypeTranslator.m3", line 353: warning: not used (Add) > 1 warning encountered > new opaque info -> recompiling TypeTranslator.m3 > "../src/TypeTranslator.m3", line 353: warning: not used (Add) > 1 warning encountered > new "TypeTranslator.io" -> archiving libsstubgen.a > (1944)trs80:~/t-cm3/mscheme/sstubgen/src> > > Hmmmmmmmmmmmmm....... is anyone interested in looking at this? > As I said, it's non-critical (I can get things working, clearly, > even with the bug present), but it's very confusing. I have to > import an interface I'm not using...why? Where to begin looking? > > Mika From mika at async.caltech.edu Sun Apr 26 20:12:35 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 26 Apr 2009 11:12:35 -0700 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: Your message of "Sun, 26 Apr 2009 18:54:57 +1000." Message-ID: <200904261812.n3QICZYX035390@camembert.async.caltech.edu> Hi Tony, I looked at this more closely, and I was wrong. The compiler doesn't actually segfault on -O. I was using -gstabs+ but switched to -gstabs after your email (doesn't seem to matter). I get a ton of warnings at either optimization level, and there are definitely bugs in the optimizer. The resulting code is generally not correct. (By comparison, I had to turn off PM3's optimizer for only one of the hundred or so packages I build.) Things often fail to compile, even at -O. At -O3, I get one segfault: new source -> compiling TextCommandQueueTbl.i3 cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack exception handling new source -> compiling CommandLoop.m3 cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack exception handling ../src/CommandLoop.m3: In function 'CommandLoop__Run': ../src/CommandLoop.m3:279: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: CommandLoop.mc new source -> compiling CommandLoopDefaultCommand.m3 cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack exception handling new source -> compiling TextCommandTbl.m3 where: 272 (***************************************************************************** 273 * * 274 * Command Loop Main * 275 * * 276 *****************************************************************************) 277 278 279 PROCEDURE Run(self: T; source: Pathname.T := NIL; term: Term.T := NIL) = 280 CONST 281 Comment = SET OF CHAR{'%','#'}; 282 VAR 283 completer := NEW(StdCompleter, loop:=self); 284 line: TEXT; 285 BEGIN 286 IF term = NIL THEN 287 self.term := Term.Default(); 288 ELSE 289 self.term := term; 290 END; 291 LOOP 292 TRY 293 IF source # NIL THEN 294 DoLoad(self.load, TextList.List2("",source), self.term); 295 source := NIL; ... Even at -O, things don't work right. Here's a typical output: new source -> compiling PassiveArb1.m3 "../src/PassiveArb1.m3", line 68: warning: not used (e) "../src/PassiveArb1.m3", line 45: warning: not used (newCon) 2 warnings encountered ../src/PassiveArb1.m3: In function 'PassiveArb1__FApply': ../src/PassiveArb1.m3:81: warning: variable 'M3_Cwb5VA_buyO' might be clobbered by 'longjmp' or 'vfork' ../src/PassiveArb1.m3:81: warning: variable 'M3_Cwb5VA_selO' might be clobbered by 'longjmp' or 'vfork' new source -> compiling PassiveArb2.i3 new source -> compiling ExecRecorder2.i3 new source -> compiling ArbPingPong.i3 new source -> compiling PassiveArb2.m3 ../src/PassiveArb2.m3: In function 'PassiveArb2__Apply': ../src/PassiveArb2.m3:388: warning: variable 'M3_EWPD1K_delta' might be clobbered by 'longjmp' or 'vfork' ../src/PassiveArb2.m3:388: warning: variable 'M3_Cwb5VA_toExec' might be clobbered by 'longjmp' or 'vfork' new source -> compiling Globals.i3 new source -> compiling ActiveArb1.i3 new source -> compiling ActiveArb1.m3 new source -> compiling ExecRecorder.i3 new source -> compiling ExecRecorder.m3 new source -> compiling ExecRec.i3 new source -> compiling ExecRecorder2.m3 new source -> compiling ExecRec.m3 new source -> compiling ArbPingPong.m3 new source -> compiling Main.m3 "../src/Main.m3", line 72: warning: potentially unhandled exception: OSError.E "../src/Main.m3", line 30: warning: potentially unhandled exceptions: Rd.EndOfFile, Rd.Failure, Thread.Alerted "../src/Main.m3", line 31: warning: potentially unhandled exceptions: Thread.Alerted, Wr.Failure "../src/Main.m3", line 32: warning: potentially unhandled exceptions: Thread.Alerted, Wr.Failure "../src/Main.m3", line 33: warning: potentially unhandled exceptions: Thread.Alerted, Wr.Failure "../src/Main.m3", line 118: warning: potentially unhandled exception: OSError.E "../src/Main.m3", line 204: warning: potentially unhandled exception: OSError.E 7 warnings encountered -> linking testtrade /usr/lib/libc.so: WARNING! setkey(3) not present in the system! /usr/lib/libc.so: warning: this program uses gets(), which is unsafe. /usr/lib/libc.so: warning: mktemp() possibly used unsafely; consider using mkstemp() /usr/lib/libc.so: WARNING! des_setkey(3) not present in the system! /usr/lib/libc.so: WARNING! encrypt(3) not present in the system! /usr/lib/libc.so: warning: tmpnam() possibly used unsafely; consider using mkstemp() /usr/lib/libc.so: warning: this program uses f_prealloc(), which is not recommended. /usr/lib/libc.so: WARNING! des_cipher(3) not present in the system! /usr/lib/libc.so: warning: tempnam() possibly used unsafely; consider using mkstemp() Main.mo: In function `Main_M3': ../src/Main.m3:164: undefined reference to `Main__5__1__1__CanStart.198' /home/mika/t-cm3/calarm/twslib/FreeBSD4/libtwslib.so: undefined reference to `TWSReader__RCApply__RD.332' m3_link => 1 linker failed linking: testtrade Fatal Error: package build failed Mika Tony Hosking writes: > >On 26 Apr 2009, at 15:22, Mika Nystrom wrote: > >> >> Hello again, >> >> Now I've managed to get all the code up and running under CM3. I >> found and committed fixes to a bug in Wx and some code in one of >> the m3tk libraries that looked like it never was finished in the >> first place. >> >> As I mentioned earlier, I wasn't able to get user threads working >> in CM3 on FreeBSD 4.11. But with some help from Jay, I was able to >> get things working with libc_r. Performance, unfortunately, >> leaves something to be desired. >> >> For the first time I've been able to compare timings on identical >> hardware between the PM3 I was using and the CM3 that's out now. >> >> Note that optimization doesn't seem to work..? (Not even -O, much >> less -O3... the compiler segfaults.) > >Are you passing -gstabs? It should not segfault on -O3 - this is a >regression if it does. > >> Here's what I get, using no optimization either in PM3 or CM3. The >> test is my Scheme interpreter generating SQL and Modula-3 code >> (a bit like the Hibernate system you can get for Java): >> >> >> CPU seconds CM3 PM3 >> First version 5.269 1.366 >> Fewer NEWs 2.039 0.440 (code cleanup on my part) >> TYPECASE hack 1.770 (see below) >> >> Some "poor man's profiling" (i.e., ctrl-C'ing in m3gdb) suggests that >> most of the time is spent either in threading code (this could just >> be a lousy implementation in libc_r), the garbage collector, or in >> "ScanTypecase". >> >> The only one of these routines I am qualified to do anything about is >> ScanTypecase. I don't know why the Critical Mass people... > colorful >> language can one use on m3devel?>.. all over this code. I assume it >> has >> something to do with Java. >> >> The PM3 code (from SRC?) has this wonderful, concise, efficient bit: >> >> PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = >> VAR t := Get (b); >> BEGIN >> IF (a >= RT0u.nTypes) THEN BadType (a) END; >> IF (a = 0) THEN RETURN TRUE END; >> RETURN (t.typecode <= a AND a <= t.lastSubTypeTC); >> END IsSubtype; >> >> replaced with the following absolute abomination in CM3: >> >> PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = >> VAR t: RT0.TypeDefn; >> BEGIN >> IF (a = RT0.NilTypecode) THEN RETURN TRUE END; >> t := Get (a); >> IF (t = NIL) THEN RETURN FALSE; END; >> IF (t.typecode = b) THEN RETURN TRUE END; >> WHILE (t.kind = ORD (TK.Obj)) DO >> IF (t.link_state = 0) THEN FinishTypecell (t, NIL); END; >> t := LOOPHOLE (t, RT0.ObjectTypeDefn).parent; >> IF (t = NIL) THEN RETURN FALSE; END; >> IF (t.typecode = b) THEN RETURN TRUE; END; >> END; >> IF (t.traced # 0) >> THEN RETURN (b = RT0.RefanyTypecode); >> ELSE RETURN (b = RT0.AddressTypecode); >> END; >> END IsSubtype; > >This is all to support dynamic loading of libraries. > >> Furthermore, CM3 has a hook for "ScanTypecase" that's missing >> in PM3 (the older compiler actually generates code for this): >> >> PROCEDURE ScanTypecase (ref: REFANY; >> x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = >> VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; >> BEGIN >> IF (ref = NIL) THEN RETURN 0; END; >> tc := TYPECODE (ref); >> p := x; i := 0; >> LOOP >> IF (p.uid = 0) THEN RETURN i; END; >> IF (p.defn = NIL) THEN >> p.defn := FindType (p.uid); >> IF (p.defn = NIL) THEN >> Fail (RTE.MissingType, RTModule.FromDataAddress(x), >> LOOPHOLE (p.uid, ADDRESS), NIL); >> END; >> END; >> xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; >> IF (tc = xc) OR IsSubtype (tc, xc) THEN RETURN i; END; >> INC (p, ADRSIZE (p^)); INC (i); >> END; >> END ScanTypecase; >> >> Where to begin? A loop with all kinds of runtime checks of properties >> that are supposedly known at compile time? IsSubtype (itself a loop) >> called from inside the loop? > >Not if dynamically loaded! > >> I was able to cut out almost all of the typecase activity from my >> program by using the following code in RTType.m3, which depends on >> the ADDRESS x never changing (well more specifically never being >> the same for two TYPECASE statements): >> >> TYPE >> TypeCaseResult = RECORD >> x : ADDRESS; >> tc : Typecode; >> arm : INTEGER; >> END; >> >> CONST >> TCCachePow = 6; >> TCCacheSize = Word.Shift(1,TCCachePow); >> TCMask = TCCacheSize-1; >> >> VAR TCCache := ARRAY [0..TCCacheSize-1] OF TypeCaseResult { >> TypeCaseResult { LOOPHOLE(0,ADDRESS), 0, -1 } , >> .. >> }; >> >> (* >> VAR tcScans := 0; tcHits := 0; (* instrumenting counters *) >> *) >> >> PROCEDURE ScanTypecase (ref: REFANY; >> x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = >> VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; >> BEGIN >> tc := TYPECODE (ref); >> IF (ref = NIL) THEN RETURN 0; END; >> >> WITH hash = Word.And(Word.Times(tc, >> >> Word.RightShift(LOOPHOLE(x,Word.T),2)), >> TCMask), >> entry = TCCache[hash] DO >> (*INC(tcScans);*) >> IF entry.x = x AND entry.tc = tc THEN >> (*INC(tcHits);*) >> RETURN entry.arm >> END; >> >> p := x; i := 0; >> LOOP >> IF (p.uid = 0) THEN entry.x := x; entry.tc := tc; >> entry.arm := i; RETURN i; END; >> IF (p.defn = NIL) THEN >> p.defn := FindType (p.uid); >> IF (p.defn = NIL) THEN >> Fail (RTE.MissingType, RTModule.FromDataAddress(x), >> LOOPHOLE (p.uid, ADDRESS), NIL); >> END; >> END; >> xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; >> IF (tc = xc) OR IsSubtype (tc, xc) THEN entry.x := x; >> entry.tc := tc; entry.arm := i; RETURN i; END; >> INC (p, ADRSIZE (p^)); INC (i); >> END; >> END; >> END ScanTypecase; >> >> I'm guessing the speedup for TYPECASE itself is a factor of at least >> ten. But it's still a pretty nasty hack. And there is still a lot >> of IsSubtype activity from narrowing. >> >> I suppose that the way the typecodes are generated in CM3 is >> sufficiently different (meant to be extended at runtime?) from how >> it was done in PM3 that one can't really go back to the old code. >> Cardelli's idea of keeping an array of parents up to ROOT plus a >> "depth" for each type might have merit, though. >> >> To see if a is a subtype of b, something like: >> >> b = a.ancestors[a.depth-b.depth-1] (* with appropriate range checks *) >> >> Would this be easy to put in? I'm not sure how one can be sure >> that typecodes are done being generated? There's something called >> RTTypeSRC.FinishObjectTypes .. >> >> And PM3 still generates code that's four times faster. >> >> Mika >> From mika at async.caltech.edu Sun Apr 26 22:08:00 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 26 Apr 2009 13:08:00 -0700 Subject: [M3devel] Performance issues with CM3 In-Reply-To: Your message of "Sun, 26 Apr 2009 18:54:57 +1000." Message-ID: <200904262008.n3QK80hc040654@camembert.async.caltech.edu> Tony Hosking writes: > >On 26 Apr 2009, at 15:22, Mika Nystrom wrote: > >> >> Hello again, ... >> PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = >> VAR t: RT0.TypeDefn; >> BEGIN >> IF (a = RT0.NilTypecode) THEN RETURN TRUE END; >> t := Get (a); >> IF (t = NIL) THEN RETURN FALSE; END; >> IF (t.typecode = b) THEN RETURN TRUE END; >> WHILE (t.kind = ORD (TK.Obj)) DO >> IF (t.link_state = 0) THEN FinishTypecell (t, NIL); END; >> t := LOOPHOLE (t, RT0.ObjectTypeDefn).parent; >> IF (t = NIL) THEN RETURN FALSE; END; >> IF (t.typecode = b) THEN RETURN TRUE; END; >> END; >> IF (t.traced # 0) >> THEN RETURN (b = RT0.RefanyTypecode); >> ELSE RETURN (b = RT0.AddressTypecode); >> END; >> END IsSubtype; > >This is all to support dynamic loading of libraries. > >> Furthermore, CM3 has a hook for "ScanTypecase" that's missing >> in PM3 (the older compiler actually generates code for this): >> >> PROCEDURE ScanTypecase (ref: REFANY; >> x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = >> VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; >> BEGIN >> IF (ref = NIL) THEN RETURN 0; END; >> tc := TYPECODE (ref); >> p := x; i := 0; >> LOOP >> IF (p.uid = 0) THEN RETURN i; END; >> IF (p.defn = NIL) THEN >> p.defn := FindType (p.uid); >> IF (p.defn = NIL) THEN >> Fail (RTE.MissingType, RTModule.FromDataAddress(x), >> LOOPHOLE (p.uid, ADDRESS), NIL); >> END; >> END; >> xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; >> IF (tc = xc) OR IsSubtype (tc, xc) THEN RETURN i; END; >> INC (p, ADRSIZE (p^)); INC (i); >> END; >> END ScanTypecase; >> >> Where to begin? A loop with all kinds of runtime checks of properties >> that are supposedly known at compile time? IsSubtype (itself a loop) >> called from inside the loop? > >Not if dynamically loaded! > Tony, all right, but the code is still an abomination! The program only gets loaded once (even if dynamically). The TYPECASE might be executed millions, billions, trillions of times... if you execute this code a billion times, those IF statements are only "effective" once and just return the same value 999,999,999 times. Surely this information can be pre-computed at load time and stored somewhere so the IFs don't have to be re-interpreted? I don't know what the best solution is here. Is it really impossible to construct and re-construct the data structures that PM3 uses, or something equivalent? For instance, Cardelli's method of keeping the supertypes of a given type in an array would work fine with dynamic loading. It's almost as fast as the PM3 method but takes a bit more memory. One could limit these arrays to a certain size and then skip to the next array, to make a hybrid between what we have now in CM3 and a full array for every type. Do you think my hash table approach is safe? It's not nearly as elegant as the Cardelli method, but it works really well for a quick and dirty. It's ugly, but it's very fast. Or can the arrays used by the TYPECASEs move during program execution? In any case, with the standard CM3 implementation, my program spends more time in TYPECASE than the whole thing does under PM3. Do we have any code in CM3 that loads new types dynamically? I can see loading code dynamically, but types...? I'm very curious, is there an interface for it that "mortals" can use? If we have the mechanism, might as well put it to work... Another thing that bothers me a bit is that PushEFrame (sp?) seems to take a lot of cycles. Is the use of this routine due to the absence of a "stack walker"? I thought FreeBSD had a working stack walker in the Modula-3 runtime...? The thing about PushEFrame is that it makes the programmer want to avoid procedure calls, which is a real pity. Sussman and Steele's railings against the inefficient procedure calls in PL/I circa 1975 are legendary. (It's true, procedural abstraction is really wonderful.) Mika P.S. My hash table code re-attached in case someone wants to look at it again (instrumenting code commented out): TYPE TypeCaseResult = RECORD x : ADDRESS; tc : Typecode; arm : INTEGER; END; CONST TCCachePow = 6; TCCacheSize = Word.Shift(1,TCCachePow); TCMask = TCCacheSize-1; VAR TCCache := ARRAY [0..TCCacheSize-1] OF TypeCaseResult { TypeCaseResult { LOOPHOLE(0,ADDRESS), 0, -1 } , .. }; (* VAR tcScans := 0; tcHits := 0; *) PROCEDURE ScanTypecase (ref: REFANY; x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; BEGIN tc := TYPECODE (ref); IF (ref = NIL) THEN RETURN 0; END; WITH hash = Word.And(Word.Times(tc, Word.RightShift(LOOPHOLE(x,Word.T),2)), TCMask), entry = TCCache[hash] DO (*INC(tcScans);*) IF entry.x = x AND entry.tc = tc THEN (*INC(tcHits);*) RETURN entry.arm END; p := x; i := 0; LOOP IF (p.uid = 0) THEN entry.x := x; entry.tc := tc; entry.arm := i; RETURN i; END; IF (p.defn = NIL) THEN p.defn := FindType (p.uid); IF (p.defn = NIL) THEN Fail (RTE.MissingType, RTModule.FromDataAddress(x), LOOPHOLE (p.uid, ADDRESS), NIL); END; END; xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; IF (tc = xc) OR IsSubtype (tc, xc) THEN entry.x := x; entry.tc := tc; entry.arm := i; RETURN i; END; INC (p, ADRSIZE (p^)); INC (i); END; END; END ScanTypecase; From hosking at cs.purdue.edu Mon Apr 27 02:04:26 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Apr 2009 10:04:26 +1000 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: <200904261812.n3QICZYX035390@camembert.async.caltech.edu> References: <200904261812.n3QICZYX035390@camembert.async.caltech.edu> Message-ID: <34EE25E2-4DE9-493A-AC88-8D11A8545536@cs.purdue.edu> I am very disturbed about this since it suggests a regression. I had spent a huge amount of time a year or so back making sure the backend would play properly with gcc -O3, but it seems we are now back in a bad place. I'm not sure what changes have occurred to the backend since then, but they would be the prime candidates. Unfortunately, I don't have a lot of time right now to try to debug these -O3 problems, but I do want to fix them since they will eventually impinge on my own work. It would be really good to get our regressions framework back up and running and to put -O3 in there as the default build option -- it seems there have been ongoing Tinderbox problems for a while now, since my SOLgnu regression runs appear to have stopped completely. I'll need to check the logs. On 27 Apr 2009, at 04:12, Mika Nystrom wrote: > Hi Tony, > > I looked at this more closely, and I was wrong. The compiler doesn't > actually segfault on -O. I was using -gstabs+ but switched to -gstabs > after your email (doesn't seem to matter). > > I get a ton of warnings at either optimization level, and there are > definitely bugs in the optimizer. The resulting code is generally > not correct. (By comparison, I had to turn off PM3's optimizer for > only one of the hundred or so packages I build.) Things often fail > to compile, even at -O. > > At -O3, I get one segfault: > > new source -> compiling TextCommandQueueTbl.i3 > cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack > exception handling > new source -> compiling CommandLoop.m3 > cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack > exception handling > ../src/CommandLoop.m3: In function 'CommandLoop__Run': > ../src/CommandLoop.m3:279: internal compiler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > m3_backend => 4 > m3cc (aka cm3cg) failed compiling: CommandLoop.mc > new source -> compiling CommandLoopDefaultCommand.m3 > cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack > exception handling > new source -> compiling TextCommandTbl.m3 > > where: > > 272 > (***************************************************************************** > 273 > * * > 274 * Command Loop > Main * > 275 > * * > 276 > *****************************************************************************) > 277 > 278 > 279 PROCEDURE Run(self: T; source: Pathname.T := NIL; term: > Term.T := NIL) = > 280 CONST > 281 Comment = SET OF CHAR{'%','#'}; > 282 VAR > 283 completer := NEW(StdCompleter, loop:=self); > 284 line: TEXT; > 285 BEGIN > 286 IF term = NIL THEN > 287 self.term := Term.Default(); > 288 ELSE > 289 self.term := term; > 290 END; > 291 LOOP > 292 TRY > 293 IF source # NIL THEN > 294 DoLoad(self.load, TextList.List2("",source), > self.term); > 295 source := NIL; > > ... > > Even at -O, things don't work right. Here's a typical output: > > new source -> compiling PassiveArb1.m3 > "../src/PassiveArb1.m3", line 68: warning: not used (e) > "../src/PassiveArb1.m3", line 45: warning: not used (newCon) > 2 warnings encountered > ../src/PassiveArb1.m3: In function 'PassiveArb1__FApply': > ../src/PassiveArb1.m3:81: warning: variable 'M3_Cwb5VA_buyO' might > be clobbered by 'longjmp' or 'vfork' > ../src/PassiveArb1.m3:81: warning: variable 'M3_Cwb5VA_selO' might > be clobbered by 'longjmp' or 'vfork' > new source -> compiling PassiveArb2.i3 > new source -> compiling ExecRecorder2.i3 > new source -> compiling ArbPingPong.i3 > new source -> compiling PassiveArb2.m3 > ../src/PassiveArb2.m3: In function 'PassiveArb2__Apply': > ../src/PassiveArb2.m3:388: warning: variable 'M3_EWPD1K_delta' might > be clobbered by 'longjmp' or 'vfork' > ../src/PassiveArb2.m3:388: warning: variable 'M3_Cwb5VA_toExec' > might be clobbered by 'longjmp' or 'vfork' > new source -> compiling Globals.i3 > new source -> compiling ActiveArb1.i3 > new source -> compiling ActiveArb1.m3 > new source -> compiling ExecRecorder.i3 > new source -> compiling ExecRecorder.m3 > new source -> compiling ExecRec.i3 > new source -> compiling ExecRecorder2.m3 > new source -> compiling ExecRec.m3 > new source -> compiling ArbPingPong.m3 > new source -> compiling Main.m3 > "../src/Main.m3", line 72: warning: potentially unhandled exception: > OSError.E > "../src/Main.m3", line 30: warning: potentially unhandled > exceptions: Rd.EndOfFile, Rd.Failure, Thread.Alerted > "../src/Main.m3", line 31: warning: potentially unhandled > exceptions: Thread.Alerted, Wr.Failure > "../src/Main.m3", line 32: warning: potentially unhandled > exceptions: Thread.Alerted, Wr.Failure > "../src/Main.m3", line 33: warning: potentially unhandled > exceptions: Thread.Alerted, Wr.Failure > "../src/Main.m3", line 118: warning: potentially unhandled > exception: OSError.E > "../src/Main.m3", line 204: warning: potentially unhandled > exception: OSError.E > 7 warnings encountered > -> linking testtrade > /usr/lib/libc.so: WARNING! setkey(3) not present in the system! > /usr/lib/libc.so: warning: this program uses gets(), which is unsafe. > /usr/lib/libc.so: warning: mktemp() possibly used unsafely; consider > using mkstemp() > /usr/lib/libc.so: WARNING! des_setkey(3) not present in the system! > /usr/lib/libc.so: WARNING! encrypt(3) not present in the system! > /usr/lib/libc.so: warning: tmpnam() possibly used unsafely; consider > using mkstemp() > /usr/lib/libc.so: warning: this program uses f_prealloc(), which is > not recommended. > /usr/lib/libc.so: WARNING! des_cipher(3) not present in the system! > /usr/lib/libc.so: warning: tempnam() possibly used unsafely; > consider using mkstemp() > Main.mo: In function `Main_M3': > ../src/Main.m3:164: undefined reference to `Main__5__1__1__CanStart. > 198' > /home/mika/t-cm3/calarm/twslib/FreeBSD4/libtwslib.so: undefined > reference to `TWSReader__RCApply__RD.332' > m3_link => 1 > linker failed linking: testtrade > Fatal Error: package build failed > > > Mika > > > > Tony Hosking writes: >> >> On 26 Apr 2009, at 15:22, Mika Nystrom wrote: >> >>> >>> Hello again, >>> >>> Now I've managed to get all the code up and running under CM3. I >>> found and committed fixes to a bug in Wx and some code in one of >>> the m3tk libraries that looked like it never was finished in the >>> first place. >>> >>> As I mentioned earlier, I wasn't able to get user threads working >>> in CM3 on FreeBSD 4.11. But with some help from Jay, I was able to >>> get things working with libc_r. Performance, unfortunately, >>> leaves something to be desired. >>> >>> For the first time I've been able to compare timings on identical >>> hardware between the PM3 I was using and the CM3 that's out now. >>> >>> Note that optimization doesn't seem to work..? (Not even -O, much >>> less -O3... the compiler segfaults.) >> >> Are you passing -gstabs? It should not segfault on -O3 - this is a >> regression if it does. >> >>> Here's what I get, using no optimization either in PM3 or CM3. The >>> test is my Scheme interpreter generating SQL and Modula-3 code >>> (a bit like the Hibernate system you can get for Java): >>> >>> >>> CPU seconds CM3 PM3 >>> First version 5.269 1.366 >>> Fewer NEWs 2.039 0.440 (code cleanup on my part) >>> TYPECASE hack 1.770 (see below) >>> >>> Some "poor man's profiling" (i.e., ctrl-C'ing in m3gdb) suggests >>> that >>> most of the time is spent either in threading code (this could just >>> be a lousy implementation in libc_r), the garbage collector, or in >>> "ScanTypecase". >>> >>> The only one of these routines I am qualified to do anything about >>> is >>> ScanTypecase. I don't know why the Critical Mass people... >> colorful >>> language can one use on m3devel?>.. all over this code. I assume it >>> has >>> something to do with Java. >>> >>> The PM3 code (from SRC?) has this wonderful, concise, efficient bit: >>> >>> PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = >>> VAR t := Get (b); >>> BEGIN >>> IF (a >= RT0u.nTypes) THEN BadType (a) END; >>> IF (a = 0) THEN RETURN TRUE END; >>> RETURN (t.typecode <= a AND a <= t.lastSubTypeTC); >>> END IsSubtype; >>> >>> replaced with the following absolute abomination in CM3: >>> >>> PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = >>> VAR t: RT0.TypeDefn; >>> BEGIN >>> IF (a = RT0.NilTypecode) THEN RETURN TRUE END; >>> t := Get (a); >>> IF (t = NIL) THEN RETURN FALSE; END; >>> IF (t.typecode = b) THEN RETURN TRUE END; >>> WHILE (t.kind = ORD (TK.Obj)) DO >>> IF (t.link_state = 0) THEN FinishTypecell (t, NIL); END; >>> t := LOOPHOLE (t, RT0.ObjectTypeDefn).parent; >>> IF (t = NIL) THEN RETURN FALSE; END; >>> IF (t.typecode = b) THEN RETURN TRUE; END; >>> END; >>> IF (t.traced # 0) >>> THEN RETURN (b = RT0.RefanyTypecode); >>> ELSE RETURN (b = RT0.AddressTypecode); >>> END; >>> END IsSubtype; >> >> This is all to support dynamic loading of libraries. >> >>> Furthermore, CM3 has a hook for "ScanTypecase" that's missing >>> in PM3 (the older compiler actually generates code for this): >>> >>> PROCEDURE ScanTypecase (ref: REFANY; >>> x: ADDRESS(*ARRAY [0..] OF Cell*)): >>> INTEGER = >>> VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; >>> BEGIN >>> IF (ref = NIL) THEN RETURN 0; END; >>> tc := TYPECODE (ref); >>> p := x; i := 0; >>> LOOP >>> IF (p.uid = 0) THEN RETURN i; END; >>> IF (p.defn = NIL) THEN >>> p.defn := FindType (p.uid); >>> IF (p.defn = NIL) THEN >>> Fail (RTE.MissingType, RTModule.FromDataAddress(x), >>> LOOPHOLE (p.uid, ADDRESS), NIL); >>> END; >>> END; >>> xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; >>> IF (tc = xc) OR IsSubtype (tc, xc) THEN RETURN i; END; >>> INC (p, ADRSIZE (p^)); INC (i); >>> END; >>> END ScanTypecase; >>> >>> Where to begin? A loop with all kinds of runtime checks of >>> properties >>> that are supposedly known at compile time? IsSubtype (itself a loop) >>> called from inside the loop? >> >> Not if dynamically loaded! >> >>> I was able to cut out almost all of the typecase activity from my >>> program by using the following code in RTType.m3, which depends on >>> the ADDRESS x never changing (well more specifically never being >>> the same for two TYPECASE statements): >>> >>> TYPE >>> TypeCaseResult = RECORD >>> x : ADDRESS; >>> tc : Typecode; >>> arm : INTEGER; >>> END; >>> >>> CONST >>> TCCachePow = 6; >>> TCCacheSize = Word.Shift(1,TCCachePow); >>> TCMask = TCCacheSize-1; >>> >>> VAR TCCache := ARRAY [0..TCCacheSize-1] OF TypeCaseResult { >>> TypeCaseResult { LOOPHOLE(0,ADDRESS), 0, -1 } , >>> .. >>> }; >>> >>> (* >>> VAR tcScans := 0; tcHits := 0; (* instrumenting counters *) >>> *) >>> >>> PROCEDURE ScanTypecase (ref: REFANY; >>> x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = >>> VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; >>> BEGIN >>> tc := TYPECODE (ref); >>> IF (ref = NIL) THEN RETURN 0; END; >>> >>> WITH hash = Word.And(Word.Times(tc, >>> >>> Word.RightShift(LOOPHOLE(x,Word.T),2)), >>> TCMask), >>> entry = TCCache[hash] DO >>> (*INC(tcScans);*) >>> IF entry.x = x AND entry.tc = tc THEN >>> (*INC(tcHits);*) >>> RETURN entry.arm >>> END; >>> >>> p := x; i := 0; >>> LOOP >>> IF (p.uid = 0) THEN entry.x := x; entry.tc := tc; >>> entry.arm := i; RETURN i; END; >>> IF (p.defn = NIL) THEN >>> p.defn := FindType (p.uid); >>> IF (p.defn = NIL) THEN >>> Fail (RTE.MissingType, RTModule.FromDataAddress(x), >>> LOOPHOLE (p.uid, ADDRESS), NIL); >>> END; >>> END; >>> xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; >>> IF (tc = xc) OR IsSubtype (tc, xc) THEN entry.x := x; >>> entry.tc := tc; entry.arm := i; RETURN i; END; >>> INC (p, ADRSIZE (p^)); INC (i); >>> END; >>> END; >>> END ScanTypecase; >>> >>> I'm guessing the speedup for TYPECASE itself is a factor of at least >>> ten. But it's still a pretty nasty hack. And there is still a lot >>> of IsSubtype activity from narrowing. >>> >>> I suppose that the way the typecodes are generated in CM3 is >>> sufficiently different (meant to be extended at runtime?) from how >>> it was done in PM3 that one can't really go back to the old code. >>> Cardelli's idea of keeping an array of parents up to ROOT plus a >>> "depth" for each type might have merit, though. >>> >>> To see if a is a subtype of b, something like: >>> >>> b = a.ancestors[a.depth-b.depth-1] (* with appropriate range >>> checks *) >>> >>> Would this be easy to put in? I'm not sure how one can be sure >>> that typecodes are done being generated? There's something called >>> RTTypeSRC.FinishObjectTypes .. >>> >>> And PM3 still generates code that's four times faster. >>> >>> Mika >>> From mika at async.caltech.edu Mon Apr 27 02:31:42 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 26 Apr 2009 17:31:42 -0700 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: Your message of "Mon, 27 Apr 2009 10:04:26 +1000." <34EE25E2-4DE9-493A-AC88-8D11A8545536@cs.purdue.edu> Message-ID: <200904270031.n3R0VgjC052408@camembert.async.caltech.edu> Tony, it might not be as bad as all that. Well, on one level it is. Things are certainly not perfect. But I am able to operate with m3core built with -O (as well as with -O3). Lots of scary-looking compiler warnings, but things do work. There are just a few programs that won't build. I didn't try "all" in the CM3 dist---only my own programs and m3core (since m3core has the biggest performance impact). With lots of tweaks and adjustments, I now see my code running about 100% slower under CM3 than the same code does under PM3 (on the same machine). This is including my typecase hacks, as described earlier today. I'm guessing most of it is the FreeBSD pthreads implementation in libc_r + the calls to PushEFrame. Mika Tony Hosking writes: >I am very disturbed about this since it suggests a regression. I had >spent a huge amount of time a year or so back making sure the backend >would play properly with gcc -O3, but it seems we are now back in a >bad place. I'm not sure what changes have occurred to the backend >since then, but they would be the prime candidates. Unfortunately, I >don't have a lot of time right now to try to debug these -O3 problems, >but I do want to fix them since they will eventually impinge on my own >work. It would be really good to get our regressions framework back >up and running and to put -O3 in there as the default build option -- >it seems there have been ongoing Tinderbox problems for a while now, >since my SOLgnu regression runs appear to have stopped completely. >I'll need to check the logs. > >On 27 Apr 2009, at 04:12, Mika Nystrom wrote: > >> Hi Tony, >> >> I looked at this more closely, and I was wrong. The compiler doesn't >> actually segfault on -O. I was using -gstabs+ but switched to -gstabs >> after your email (doesn't seem to matter). >> >> I get a ton of warnings at either optimization level, and there are >> definitely bugs in the optimizer. The resulting code is generally >> not correct. (By comparison, I had to turn off PM3's optimizer for >> only one of the hundred or so packages I build.) Things often fail >> to compile, even at -O. >> >> At -O3, I get one segfault: >> >> new source -> compiling TextCommandQueueTbl.i3 >> cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack >> exception handling >> new source -> compiling CommandLoop.m3 >> cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack >> exception handling >> ../src/CommandLoop.m3: In function 'CommandLoop__Run': >> ../src/CommandLoop.m3:279: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> m3_backend => 4 >> m3cc (aka cm3cg) failed compiling: CommandLoop.mc >> new source -> compiling CommandLoopDefaultCommand.m3 >> cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack >> exception handling >> new source -> compiling TextCommandTbl.m3 >> >> where: >> >> 272 >> (***************************************************************************** >> 273 >> * * >> 274 * Command Loop >> Main * >> 275 >> * * >> 276 >> *****************************************************************************) >> 277 >> 278 >> 279 PROCEDURE Run(self: T; source: Pathname.T := NIL; term: >> Term.T := NIL) = >> 280 CONST >> 281 Comment = SET OF CHAR{'%','#'}; >> 282 VAR >> 283 completer := NEW(StdCompleter, loop:=self); >> 284 line: TEXT; >> 285 BEGIN >> 286 IF term = NIL THEN >> 287 self.term := Term.Default(); >> 288 ELSE >> 289 self.term := term; >> 290 END; >> 291 LOOP >> 292 TRY >> 293 IF source # NIL THEN >> 294 DoLoad(self.load, TextList.List2("",source), >> self.term); >> 295 source := NIL; >> >> ... >> >> Even at -O, things don't work right. Here's a typical output: >> >> new source -> compiling PassiveArb1.m3 >> "../src/PassiveArb1.m3", line 68: warning: not used (e) >> "../src/PassiveArb1.m3", line 45: warning: not used (newCon) >> 2 warnings encountered >> ../src/PassiveArb1.m3: In function 'PassiveArb1__FApply': >> ../src/PassiveArb1.m3:81: warning: variable 'M3_Cwb5VA_buyO' might >> be clobbered by 'longjmp' or 'vfork' >> ../src/PassiveArb1.m3:81: warning: variable 'M3_Cwb5VA_selO' might >> be clobbered by 'longjmp' or 'vfork' >> new source -> compiling PassiveArb2.i3 >> new source -> compiling ExecRecorder2.i3 >> new source -> compiling ArbPingPong.i3 >> new source -> compiling PassiveArb2.m3 >> ../src/PassiveArb2.m3: In function 'PassiveArb2__Apply': >> ../src/PassiveArb2.m3:388: warning: variable 'M3_EWPD1K_delta' might >> be clobbered by 'longjmp' or 'vfork' >> ../src/PassiveArb2.m3:388: warning: variable 'M3_Cwb5VA_toExec' >> might be clobbered by 'longjmp' or 'vfork' >> new source -> compiling Globals.i3 >> new source -> compiling ActiveArb1.i3 >> new source -> compiling ActiveArb1.m3 >> new source -> compiling ExecRecorder.i3 >> new source -> compiling ExecRecorder.m3 >> new source -> compiling ExecRec.i3 >> new source -> compiling ExecRecorder2.m3 >> new source -> compiling ExecRec.m3 >> new source -> compiling ArbPingPong.m3 >> new source -> compiling Main.m3 >> "../src/Main.m3", line 72: warning: potentially unhandled exception: >> OSError.E >> "../src/Main.m3", line 30: warning: potentially unhandled >> exceptions: Rd.EndOfFile, Rd.Failure, Thread.Alerted >> "../src/Main.m3", line 31: warning: potentially unhandled >> exceptions: Thread.Alerted, Wr.Failure >> "../src/Main.m3", line 32: warning: potentially unhandled >> exceptions: Thread.Alerted, Wr.Failure >> "../src/Main.m3", line 33: warning: potentially unhandled >> exceptions: Thread.Alerted, Wr.Failure >> "../src/Main.m3", line 118: warning: potentially unhandled >> exception: OSError.E >> "../src/Main.m3", line 204: warning: potentially unhandled >> exception: OSError.E >> 7 warnings encountered >> -> linking testtrade >> /usr/lib/libc.so: WARNING! setkey(3) not present in the system! >> /usr/lib/libc.so: warning: this program uses gets(), which is unsafe. >> /usr/lib/libc.so: warning: mktemp() possibly used unsafely; consider >> using mkstemp() >> /usr/lib/libc.so: WARNING! des_setkey(3) not present in the system! >> /usr/lib/libc.so: WARNING! encrypt(3) not present in the system! >> /usr/lib/libc.so: warning: tmpnam() possibly used unsafely; consider >> using mkstemp() >> /usr/lib/libc.so: warning: this program uses f_prealloc(), which is >> not recommended. >> /usr/lib/libc.so: WARNING! des_cipher(3) not present in the system! >> /usr/lib/libc.so: warning: tempnam() possibly used unsafely; >> consider using mkstemp() >> Main.mo: In function `Main_M3': >> ../src/Main.m3:164: undefined reference to `Main__5__1__1__CanStart. >> 198' >> /home/mika/t-cm3/calarm/twslib/FreeBSD4/libtwslib.so: undefined >> reference to `TWSReader__RCApply__RD.332' >> m3_link => 1 >> linker failed linking: testtrade >> Fatal Error: package build failed >> >> >> Mika >> >> >> >> Tony Hosking writes: >>> >>> On 26 Apr 2009, at 15:22, Mika Nystrom wrote: >>> >>>> >>>> Hello again, >>>> >>>> Now I've managed to get all the code up and running under CM3. I >>>> found and committed fixes to a bug in Wx and some code in one of >>>> the m3tk libraries that looked like it never was finished in the >>>> first place. >>>> >>>> As I mentioned earlier, I wasn't able to get user threads working >>>> in CM3 on FreeBSD 4.11. But with some help from Jay, I was able to >>>> get things working with libc_r. Performance, unfortunately, >>>> leaves something to be desired. >>>> >>>> For the first time I've been able to compare timings on identical >>>> hardware between the PM3 I was using and the CM3 that's out now. >>>> >>>> Note that optimization doesn't seem to work..? (Not even -O, much >>>> less -O3... the compiler segfaults.) >>> >>> Are you passing -gstabs? It should not segfault on -O3 - this is a >>> regression if it does. >>> >>>> Here's what I get, using no optimization either in PM3 or CM3. The >>>> test is my Scheme interpreter generating SQL and Modula-3 code >>>> (a bit like the Hibernate system you can get for Java): >>>> >>>> >>>> CPU seconds CM3 PM3 >>>> First version 5.269 1.366 >>>> Fewer NEWs 2.039 0.440 (code cleanup on my part) >>>> TYPECASE hack 1.770 (see below) >>>> >>>> Some "poor man's profiling" (i.e., ctrl-C'ing in m3gdb) suggests >>>> that >>>> most of the time is spent either in threading code (this could just >>>> be a lousy implementation in libc_r), the garbage collector, or in >>>> "ScanTypecase". >>>> >>>> The only one of these routines I am qualified to do anything about >>>> is >>>> ScanTypecase. I don't know why the Critical Mass people... >>> colorful >>>> language can one use on m3devel?>.. all over this code. I assume it >>>> has >>>> something to do with Java. >>>> >>>> The PM3 code (from SRC?) has this wonderful, concise, efficient bit: >>>> >>>> PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = >>>> VAR t := Get (b); >>>> BEGIN >>>> IF (a >= RT0u.nTypes) THEN BadType (a) END; >>>> IF (a = 0) THEN RETURN TRUE END; >>>> RETURN (t.typecode <= a AND a <= t.lastSubTypeTC); >>>> END IsSubtype; >>>> >>>> replaced with the following absolute abomination in CM3: >>>> >>>> PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = >>>> VAR t: RT0.TypeDefn; >>>> BEGIN >>>> IF (a = RT0.NilTypecode) THEN RETURN TRUE END; >>>> t := Get (a); >>>> IF (t = NIL) THEN RETURN FALSE; END; >>>> IF (t.typecode = b) THEN RETURN TRUE END; >>>> WHILE (t.kind = ORD (TK.Obj)) DO >>>> IF (t.link_state = 0) THEN FinishTypecell (t, NIL); END; >>>> t := LOOPHOLE (t, RT0.ObjectTypeDefn).parent; >>>> IF (t = NIL) THEN RETURN FALSE; END; >>>> IF (t.typecode = b) THEN RETURN TRUE; END; >>>> END; >>>> IF (t.traced # 0) >>>> THEN RETURN (b = RT0.RefanyTypecode); >>>> ELSE RETURN (b = RT0.AddressTypecode); >>>> END; >>>> END IsSubtype; >>> >>> This is all to support dynamic loading of libraries. >>> >>>> Furthermore, CM3 has a hook for "ScanTypecase" that's missing >>>> in PM3 (the older compiler actually generates code for this): >>>> >>>> PROCEDURE ScanTypecase (ref: REFANY; >>>> x: ADDRESS(*ARRAY [0..] OF Cell*)): >>>> INTEGER = >>>> VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; >>>> BEGIN >>>> IF (ref = NIL) THEN RETURN 0; END; >>>> tc := TYPECODE (ref); >>>> p := x; i := 0; >>>> LOOP >>>> IF (p.uid = 0) THEN RETURN i; END; >>>> IF (p.defn = NIL) THEN >>>> p.defn := FindType (p.uid); >>>> IF (p.defn = NIL) THEN >>>> Fail (RTE.MissingType, RTModule.FromDataAddress(x), >>>> LOOPHOLE (p.uid, ADDRESS), NIL); >>>> END; >>>> END; >>>> xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; >>>> IF (tc = xc) OR IsSubtype (tc, xc) THEN RETURN i; END; >>>> INC (p, ADRSIZE (p^)); INC (i); >>>> END; >>>> END ScanTypecase; >>>> >>>> Where to begin? A loop with all kinds of runtime checks of >>>> properties >>>> that are supposedly known at compile time? IsSubtype (itself a loop) >>>> called from inside the loop? >>> >>> Not if dynamically loaded! >>> >>>> I was able to cut out almost all of the typecase activity from my >>>> program by using the following code in RTType.m3, which depends on >>>> the ADDRESS x never changing (well more specifically never being >>>> the same for two TYPECASE statements): >>>> >>>> TYPE >>>> TypeCaseResult = RECORD >>>> x : ADDRESS; >>>> tc : Typecode; >>>> arm : INTEGER; >>>> END; >>>> >>>> CONST >>>> TCCachePow = 6; >>>> TCCacheSize = Word.Shift(1,TCCachePow); >>>> TCMask = TCCacheSize-1; >>>> >>>> VAR TCCache := ARRAY [0..TCCacheSize-1] OF TypeCaseResult { >>>> TypeCaseResult { LOOPHOLE(0,ADDRESS), 0, -1 } , >>>> .. >>>> }; >>>> >>>> (* >>>> VAR tcScans := 0; tcHits := 0; (* instrumenting counters *) >>>> *) >>>> >>>> PROCEDURE ScanTypecase (ref: REFANY; >>>> x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = >>>> VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; >>>> BEGIN >>>> tc := TYPECODE (ref); >>>> IF (ref = NIL) THEN RETURN 0; END; >>>> >>>> WITH hash = Word.And(Word.Times(tc, >>>> >>>> Word.RightShift(LOOPHOLE(x,Word.T),2)), >>>> TCMask), >>>> entry = TCCache[hash] DO >>>> (*INC(tcScans);*) >>>> IF entry.x = x AND entry.tc = tc THEN >>>> (*INC(tcHits);*) >>>> RETURN entry.arm >>>> END; >>>> >>>> p := x; i := 0; >>>> LOOP >>>> IF (p.uid = 0) THEN entry.x := x; entry.tc := tc; >>>> entry.arm := i; RETURN i; END; >>>> IF (p.defn = NIL) THEN >>>> p.defn := FindType (p.uid); >>>> IF (p.defn = NIL) THEN >>>> Fail (RTE.MissingType, RTModule.FromDataAddress(x), >>>> LOOPHOLE (p.uid, ADDRESS), NIL); >>>> END; >>>> END; >>>> xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; >>>> IF (tc = xc) OR IsSubtype (tc, xc) THEN entry.x := x; >>>> entry.tc := tc; entry.arm := i; RETURN i; END; >>>> INC (p, ADRSIZE (p^)); INC (i); >>>> END; >>>> END; >>>> END ScanTypecase; >>>> >>>> I'm guessing the speedup for TYPECASE itself is a factor of at least >>>> ten. But it's still a pretty nasty hack. And there is still a lot >>>> of IsSubtype activity from narrowing. >>>> >>>> I suppose that the way the typecodes are generated in CM3 is >>>> sufficiently different (meant to be extended at runtime?) from how >>>> it was done in PM3 that one can't really go back to the old code. >>>> Cardelli's idea of keeping an array of parents up to ROOT plus a >>>> "depth" for each type might have merit, though. >>>> >>>> To see if a is a subtype of b, something like: >>>> >>>> b = a.ancestors[a.depth-b.depth-1] (* with appropriate range >>>> checks *) >>>> >>>> Would this be easy to put in? I'm not sure how one can be sure >>>> that typecodes are done being generated? There's something called >>>> RTTypeSRC.FinishObjectTypes .. >>>> >>>> And PM3 still generates code that's four times faster. >>>> >>>> Mika >>>> > From hosking at cs.purdue.edu Mon Apr 27 02:26:06 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Apr 2009 10:26:06 +1000 Subject: [M3devel] Performance issues with CM3 In-Reply-To: <200904262008.n3QK80hc040654@camembert.async.caltech.edu> References: <200904262008.n3QK80hc040654@camembert.async.caltech.edu> Message-ID: <7FA8A570-6672-4B29-8349-5A6EFA6F0562@cs.purdue.edu> >>> Tony, all right, but the code is still an abomination! The program > only gets loaded once (even if dynamically). The TYPECASE might > be executed millions, billions, trillions of times... if you > execute this code a billion times, those IF statements are only > "effective" once and just return the same value 999,999,999 times. > Surely this information can be pre-computed at load time and stored > somewhere so the IFs don't have to be re-interpreted? I haven't looked closely at this code but it's been there since the Critical Mass days. The dynamic loading I refer to is for explicit opening and linking of .so files -- not the usual dynamic linking that takes place with .so files resolved at link time. Anyway, perhaps the code can be cleaned up. > I don't know what the best solution is here. Is it really impossible > to construct and re-construct the data structures that PM3 uses, > or something equivalent? I don't know. Possibly. Again, I don't know enough about this corner of the world to answer all of the following questions: > For instance, Cardelli's method of keeping the supertypes of a given > type in an array would work fine with dynamic loading. It's almost > as fast as the PM3 method but takes a bit more memory. One could > limit these arrays to a certain size and then skip to the next > array, to make a hybrid between what we have now in CM3 and a full > array for every type. > > Do you think my hash table approach is safe? It's not nearly as > elegant as the Cardelli method, but it works really well for a quick > and dirty. It's ugly, but it's very fast. Or can the arrays used > by the TYPECASEs move during program execution? > > In any case, with the standard CM3 implementation, my program spends > more time in TYPECASE than the whole thing does under PM3. > > Do we have any code in CM3 that loads new types dynamically? I can > see loading code dynamically, but types...? I'm very curious, is > there an interface for it that "mortals" can use? If we have the > mechanism, might as well put it to work... AFAIK you need to invoke RTLinker.AddUnit after using the native dlopen/dlsym facilities to get the symbol corresponding to the unit being loaded. I've never tried using it but I did have some plans to do so back in my persistence days (when retrieving an instance of an unknown subtype we'd need to also dynamically load its defining module). > Another thing that bothers me a bit is that PushEFrame (sp?) seems to > take a lot of cycles. Is the use of this routine due to the absence > of a "stack walker"? I thought FreeBSD had a working stack walker > in the Modula-3 runtime...? The stack walker is not usable for exception handling, only for printing a stack dump (IIRC). Same was true for PM3. We should do something about using the gcc-backend native stack walking support. Most of the overhead for PushEFrame (as compared to user-threaded PM3) is obtaining the thread-local stack. For user-threaded PM3 it was a compiled in global variable (which obviously breaks for native threads). > The thing about PushEFrame is that it makes the programmer want to > avoid procedure calls, which is a real pity. Sussman and Steele's > railings against the inefficient procedure calls in PL/I circa 1975 > are legendary. (It's true, procedural abstraction is really > wonderful.) I agree. I've maintained the SOLgnu stack walking code for years so that I don't have to pay the overhead of the explicit exception stack. > > > Mika > > P.S. My hash table code re-attached in case someone wants to look at > it > again (instrumenting code commented out): > > TYPE > TypeCaseResult = RECORD > x : ADDRESS; > tc : Typecode; > arm : INTEGER; > END; > > CONST > TCCachePow = 6; > TCCacheSize = Word.Shift(1,TCCachePow); > TCMask = TCCacheSize-1; > > VAR TCCache := ARRAY [0..TCCacheSize-1] OF TypeCaseResult { > TypeCaseResult { LOOPHOLE(0,ADDRESS), 0, -1 } , > .. > }; > > (* > VAR tcScans := 0; tcHits := 0; > *) > > PROCEDURE ScanTypecase (ref: REFANY; > x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = > VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; > BEGIN > tc := TYPECODE (ref); > IF (ref = NIL) THEN RETURN 0; END; > > WITH hash = Word.And(Word.Times(tc, > > Word.RightShift(LOOPHOLE(x,Word.T),2)), > TCMask), > entry = TCCache[hash] DO > (*INC(tcScans);*) > IF entry.x = x AND entry.tc = tc THEN > (*INC(tcHits);*) > RETURN entry.arm > END; > > p := x; i := 0; > LOOP > IF (p.uid = 0) THEN entry.x := x; entry.tc := tc; > entry.arm := i; RETURN i; END; > IF (p.defn = NIL) THEN > p.defn := FindType (p.uid); > IF (p.defn = NIL) THEN > Fail (RTE.MissingType, RTModule.FromDataAddress(x), > LOOPHOLE (p.uid, ADDRESS), NIL); > END; > END; > xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; > IF (tc = xc) OR IsSubtype (tc, xc) THEN entry.x := x; > entry.tc := tc; entry.arm := i; RETURN i; END; > INC (p, ADRSIZE (p^)); INC (i); > END; > END; > END ScanTypecase; > From hosking at cs.purdue.edu Mon Apr 27 02:37:09 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Apr 2009 10:37:09 +1000 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: <200904270031.n3R0VgjC052408@camembert.async.caltech.edu> References: <200904270031.n3R0VgjC052408@camembert.async.caltech.edu> Message-ID: <678F2302-90D4-4F96-9EF6-7DA1167A97BA@cs.purdue.edu> On 27 Apr 2009, at 10:31, Mika Nystrom wrote: > > Tony, it might not be as bad as all that. Well, on one level it > is. Things are certainly not perfect. > > But I am able to operate with m3core built with -O (as well as with > -O3). Lots of scary-looking compiler warnings, but things do work. > There are just a few programs that won't build. I didn't try "all" > in the CM3 dist---only my own programs and m3core (since m3core has > the biggest performance impact). This is weird, since I assume you are targetting x86 which is the same (except I386_DARWIN in my case) as I have used -O3 for without problems previously. I shall have to rebuild everything in cm3 with - O3 to see if I can track down the problems. I can't remember the last time I checked that it all worked, but the CVS logs will probably reveal more (cf my log messages for parse.c in the gcc-based backend). > With lots of tweaks and adjustments, I now see my code running about > 100% slower under CM3 than the same code does under PM3 (on the > same machine). This is including my typecase hacks, as described > earlier today. I'm guessing most of it is the FreeBSD pthreads > implementation in libc_r + the calls to PushEFrame. Yikes! How much of this is module initialization (startup) time? > > > Mika > > Tony Hosking writes: >> I am very disturbed about this since it suggests a regression. I had >> spent a huge amount of time a year or so back making sure the backend >> would play properly with gcc -O3, but it seems we are now back in a >> bad place. I'm not sure what changes have occurred to the backend >> since then, but they would be the prime candidates. Unfortunately, I >> don't have a lot of time right now to try to debug these -O3 >> problems, >> but I do want to fix them since they will eventually impinge on my >> own >> work. It would be really good to get our regressions framework back >> up and running and to put -O3 in there as the default build option -- >> it seems there have been ongoing Tinderbox problems for a while now, >> since my SOLgnu regression runs appear to have stopped completely. >> I'll need to check the logs. >> >> On 27 Apr 2009, at 04:12, Mika Nystrom wrote: >> >>> Hi Tony, >>> >>> I looked at this more closely, and I was wrong. The compiler >>> doesn't >>> actually segfault on -O. I was using -gstabs+ but switched to - >>> gstabs >>> after your email (doesn't seem to matter). >>> >>> I get a ton of warnings at either optimization level, and there are >>> definitely bugs in the optimizer. The resulting code is generally >>> not correct. (By comparison, I had to turn off PM3's optimizer for >>> only one of the hundred or so packages I build.) Things often fail >>> to compile, even at -O. >>> >>> At -O3, I get one segfault: >>> >>> new source -> compiling TextCommandQueueTbl.i3 >>> cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack >>> exception handling >>> new source -> compiling CommandLoop.m3 >>> cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack >>> exception handling >>> ../src/CommandLoop.m3: In function 'CommandLoop__Run': >>> ../src/CommandLoop.m3:279: internal compiler error: Segmentation >>> fault >>> Please submit a full bug report, >>> with preprocessed source if appropriate. >>> See for instructions. >>> m3_backend => 4 >>> m3cc (aka cm3cg) failed compiling: CommandLoop.mc >>> new source -> compiling CommandLoopDefaultCommand.m3 >>> cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack >>> exception handling >>> new source -> compiling TextCommandTbl.m3 >>> >>> where: >>> >>> 272 >>> (***************************************************************************** >>> 273 >>> * * >>> 274 * Command Loop >>> Main * >>> 275 >>> * * >>> 276 >>> *****************************************************************************) >>> 277 >>> 278 >>> 279 PROCEDURE Run(self: T; source: Pathname.T := NIL; term: >>> Term.T := NIL) = >>> 280 CONST >>> 281 Comment = SET OF CHAR{'%','#'}; >>> 282 VAR >>> 283 completer := NEW(StdCompleter, loop:=self); >>> 284 line: TEXT; >>> 285 BEGIN >>> 286 IF term = NIL THEN >>> 287 self.term := Term.Default(); >>> 288 ELSE >>> 289 self.term := term; >>> 290 END; >>> 291 LOOP >>> 292 TRY >>> 293 IF source # NIL THEN >>> 294 DoLoad(self.load, TextList.List2("",source), >>> self.term); >>> 295 source := NIL; >>> >>> ... >>> >>> Even at -O, things don't work right. Here's a typical output: >>> >>> new source -> compiling PassiveArb1.m3 >>> "../src/PassiveArb1.m3", line 68: warning: not used (e) >>> "../src/PassiveArb1.m3", line 45: warning: not used (newCon) >>> 2 warnings encountered >>> ../src/PassiveArb1.m3: In function 'PassiveArb1__FApply': >>> ../src/PassiveArb1.m3:81: warning: variable 'M3_Cwb5VA_buyO' might >>> be clobbered by 'longjmp' or 'vfork' >>> ../src/PassiveArb1.m3:81: warning: variable 'M3_Cwb5VA_selO' might >>> be clobbered by 'longjmp' or 'vfork' >>> new source -> compiling PassiveArb2.i3 >>> new source -> compiling ExecRecorder2.i3 >>> new source -> compiling ArbPingPong.i3 >>> new source -> compiling PassiveArb2.m3 >>> ../src/PassiveArb2.m3: In function 'PassiveArb2__Apply': >>> ../src/PassiveArb2.m3:388: warning: variable 'M3_EWPD1K_delta' might >>> be clobbered by 'longjmp' or 'vfork' >>> ../src/PassiveArb2.m3:388: warning: variable 'M3_Cwb5VA_toExec' >>> might be clobbered by 'longjmp' or 'vfork' >>> new source -> compiling Globals.i3 >>> new source -> compiling ActiveArb1.i3 >>> new source -> compiling ActiveArb1.m3 >>> new source -> compiling ExecRecorder.i3 >>> new source -> compiling ExecRecorder.m3 >>> new source -> compiling ExecRec.i3 >>> new source -> compiling ExecRecorder2.m3 >>> new source -> compiling ExecRec.m3 >>> new source -> compiling ArbPingPong.m3 >>> new source -> compiling Main.m3 >>> "../src/Main.m3", line 72: warning: potentially unhandled exception: >>> OSError.E >>> "../src/Main.m3", line 30: warning: potentially unhandled >>> exceptions: Rd.EndOfFile, Rd.Failure, Thread.Alerted >>> "../src/Main.m3", line 31: warning: potentially unhandled >>> exceptions: Thread.Alerted, Wr.Failure >>> "../src/Main.m3", line 32: warning: potentially unhandled >>> exceptions: Thread.Alerted, Wr.Failure >>> "../src/Main.m3", line 33: warning: potentially unhandled >>> exceptions: Thread.Alerted, Wr.Failure >>> "../src/Main.m3", line 118: warning: potentially unhandled >>> exception: OSError.E >>> "../src/Main.m3", line 204: warning: potentially unhandled >>> exception: OSError.E >>> 7 warnings encountered >>> -> linking testtrade >>> /usr/lib/libc.so: WARNING! setkey(3) not present in the system! >>> /usr/lib/libc.so: warning: this program uses gets(), which is >>> unsafe. >>> /usr/lib/libc.so: warning: mktemp() possibly used unsafely; consider >>> using mkstemp() >>> /usr/lib/libc.so: WARNING! des_setkey(3) not present in the system! >>> /usr/lib/libc.so: WARNING! encrypt(3) not present in the system! >>> /usr/lib/libc.so: warning: tmpnam() possibly used unsafely; consider >>> using mkstemp() >>> /usr/lib/libc.so: warning: this program uses f_prealloc(), which is >>> not recommended. >>> /usr/lib/libc.so: WARNING! des_cipher(3) not present in the system! >>> /usr/lib/libc.so: warning: tempnam() possibly used unsafely; >>> consider using mkstemp() >>> Main.mo: In function `Main_M3': >>> ../src/Main.m3:164: undefined reference to `Main__5__1__1__CanStart. >>> 198' >>> /home/mika/t-cm3/calarm/twslib/FreeBSD4/libtwslib.so: undefined >>> reference to `TWSReader__RCApply__RD.332' >>> m3_link => 1 >>> linker failed linking: testtrade >>> Fatal Error: package build failed >>> >>> >>> Mika >>> >>> >>> >>> Tony Hosking writes: >>>> >>>> On 26 Apr 2009, at 15:22, Mika Nystrom wrote: >>>> >>>>> >>>>> Hello again, >>>>> >>>>> Now I've managed to get all the code up and running under CM3. I >>>>> found and committed fixes to a bug in Wx and some code in one of >>>>> the m3tk libraries that looked like it never was finished in the >>>>> first place. >>>>> >>>>> As I mentioned earlier, I wasn't able to get user threads working >>>>> in CM3 on FreeBSD 4.11. But with some help from Jay, I was able >>>>> to >>>>> get things working with libc_r. Performance, unfortunately, >>>>> leaves something to be desired. >>>>> >>>>> For the first time I've been able to compare timings on identical >>>>> hardware between the PM3 I was using and the CM3 that's out now. >>>>> >>>>> Note that optimization doesn't seem to work..? (Not even -O, much >>>>> less -O3... the compiler segfaults.) >>>> >>>> Are you passing -gstabs? It should not segfault on -O3 - this is a >>>> regression if it does. >>>> >>>>> Here's what I get, using no optimization either in PM3 or CM3. >>>>> The >>>>> test is my Scheme interpreter generating SQL and Modula-3 code >>>>> (a bit like the Hibernate system you can get for Java): >>>>> >>>>> >>>>> CPU seconds CM3 PM3 >>>>> First version 5.269 1.366 >>>>> Fewer NEWs 2.039 0.440 (code cleanup on my part) >>>>> TYPECASE hack 1.770 (see below) >>>>> >>>>> Some "poor man's profiling" (i.e., ctrl-C'ing in m3gdb) suggests >>>>> that >>>>> most of the time is spent either in threading code (this could >>>>> just >>>>> be a lousy implementation in libc_r), the garbage collector, or in >>>>> "ScanTypecase". >>>>> >>>>> The only one of these routines I am qualified to do anything about >>>>> is >>>>> ScanTypecase. I don't know why the Critical Mass people... >>>> colorful >>>>> language can one use on m3devel?>.. all over this code. I >>>>> assume it >>>>> has >>>>> something to do with Java. >>>>> >>>>> The PM3 code (from SRC?) has this wonderful, concise, efficient >>>>> bit: >>>>> >>>>> PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = >>>>> VAR t := Get (b); >>>>> BEGIN >>>>> IF (a >= RT0u.nTypes) THEN BadType (a) END; >>>>> IF (a = 0) THEN RETURN TRUE END; >>>>> RETURN (t.typecode <= a AND a <= t.lastSubTypeTC); >>>>> END IsSubtype; >>>>> >>>>> replaced with the following absolute abomination in CM3: >>>>> >>>>> PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN = >>>>> VAR t: RT0.TypeDefn; >>>>> BEGIN >>>>> IF (a = RT0.NilTypecode) THEN RETURN TRUE END; >>>>> t := Get (a); >>>>> IF (t = NIL) THEN RETURN FALSE; END; >>>>> IF (t.typecode = b) THEN RETURN TRUE END; >>>>> WHILE (t.kind = ORD (TK.Obj)) DO >>>>> IF (t.link_state = 0) THEN FinishTypecell (t, NIL); END; >>>>> t := LOOPHOLE (t, RT0.ObjectTypeDefn).parent; >>>>> IF (t = NIL) THEN RETURN FALSE; END; >>>>> IF (t.typecode = b) THEN RETURN TRUE; END; >>>>> END; >>>>> IF (t.traced # 0) >>>>> THEN RETURN (b = RT0.RefanyTypecode); >>>>> ELSE RETURN (b = RT0.AddressTypecode); >>>>> END; >>>>> END IsSubtype; >>>> >>>> This is all to support dynamic loading of libraries. >>>> >>>>> Furthermore, CM3 has a hook for "ScanTypecase" that's missing >>>>> in PM3 (the older compiler actually generates code for this): >>>>> >>>>> PROCEDURE ScanTypecase (ref: REFANY; >>>>> x: ADDRESS(*ARRAY [0..] OF Cell*)): >>>>> INTEGER = >>>>> VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; >>>>> BEGIN >>>>> IF (ref = NIL) THEN RETURN 0; END; >>>>> tc := TYPECODE (ref); >>>>> p := x; i := 0; >>>>> LOOP >>>>> IF (p.uid = 0) THEN RETURN i; END; >>>>> IF (p.defn = NIL) THEN >>>>> p.defn := FindType (p.uid); >>>>> IF (p.defn = NIL) THEN >>>>> Fail (RTE.MissingType, RTModule.FromDataAddress(x), >>>>> LOOPHOLE (p.uid, ADDRESS), NIL); >>>>> END; >>>>> END; >>>>> xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; >>>>> IF (tc = xc) OR IsSubtype (tc, xc) THEN RETURN i; END; >>>>> INC (p, ADRSIZE (p^)); INC (i); >>>>> END; >>>>> END ScanTypecase; >>>>> >>>>> Where to begin? A loop with all kinds of runtime checks of >>>>> properties >>>>> that are supposedly known at compile time? IsSubtype (itself a >>>>> loop) >>>>> called from inside the loop? >>>> >>>> Not if dynamically loaded! >>>> >>>>> I was able to cut out almost all of the typecase activity from my >>>>> program by using the following code in RTType.m3, which depends on >>>>> the ADDRESS x never changing (well more specifically never being >>>>> the same for two TYPECASE statements): >>>>> >>>>> TYPE >>>>> TypeCaseResult = RECORD >>>>> x : ADDRESS; >>>>> tc : Typecode; >>>>> arm : INTEGER; >>>>> END; >>>>> >>>>> CONST >>>>> TCCachePow = 6; >>>>> TCCacheSize = Word.Shift(1,TCCachePow); >>>>> TCMask = TCCacheSize-1; >>>>> >>>>> VAR TCCache := ARRAY [0..TCCacheSize-1] OF TypeCaseResult { >>>>> TypeCaseResult { LOOPHOLE(0,ADDRESS), 0, -1 } , >>>>> .. >>>>> }; >>>>> >>>>> (* >>>>> VAR tcScans := 0; tcHits := 0; (* instrumenting counters *) >>>>> *) >>>>> >>>>> PROCEDURE ScanTypecase (ref: REFANY; >>>>> x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER = >>>>> VAR p: UNTRACED REF TypecaseCell; i: INTEGER; tc, xc: Typecode; >>>>> BEGIN >>>>> tc := TYPECODE (ref); >>>>> IF (ref = NIL) THEN RETURN 0; END; >>>>> >>>>> WITH hash = Word.And(Word.Times(tc, >>>>> >>>>> Word.RightShift(LOOPHOLE(x,Word.T),2)), >>>>> TCMask), >>>>> entry = TCCache[hash] DO >>>>> (*INC(tcScans);*) >>>>> IF entry.x = x AND entry.tc = tc THEN >>>>> (*INC(tcHits);*) >>>>> RETURN entry.arm >>>>> END; >>>>> >>>>> p := x; i := 0; >>>>> LOOP >>>>> IF (p.uid = 0) THEN entry.x := x; entry.tc := tc; >>>>> entry.arm := i; RETURN i; END; >>>>> IF (p.defn = NIL) THEN >>>>> p.defn := FindType (p.uid); >>>>> IF (p.defn = NIL) THEN >>>>> Fail (RTE.MissingType, RTModule.FromDataAddress(x), >>>>> LOOPHOLE (p.uid, ADDRESS), NIL); >>>>> END; >>>>> END; >>>>> xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode; >>>>> IF (tc = xc) OR IsSubtype (tc, xc) THEN entry.x := x; >>>>> entry.tc := tc; entry.arm := i; RETURN i; END; >>>>> INC (p, ADRSIZE (p^)); INC (i); >>>>> END; >>>>> END; >>>>> END ScanTypecase; >>>>> >>>>> I'm guessing the speedup for TYPECASE itself is a factor of at >>>>> least >>>>> ten. But it's still a pretty nasty hack. And there is still a >>>>> lot >>>>> of IsSubtype activity from narrowing. >>>>> >>>>> I suppose that the way the typecodes are generated in CM3 is >>>>> sufficiently different (meant to be extended at runtime?) from how >>>>> it was done in PM3 that one can't really go back to the old code. >>>>> Cardelli's idea of keeping an array of parents up to ROOT plus a >>>>> "depth" for each type might have merit, though. >>>>> >>>>> To see if a is a subtype of b, something like: >>>>> >>>>> b = a.ancestors[a.depth-b.depth-1] (* with appropriate range >>>>> checks *) >>>>> >>>>> Would this be easy to put in? I'm not sure how one can be sure >>>>> that typecodes are done being generated? There's something called >>>>> RTTypeSRC.FinishObjectTypes .. >>>>> >>>>> And PM3 still generates code that's four times faster. >>>>> >>>>> Mika >>>>> >> From rodney.m.bates at cox.net Mon Apr 27 03:05:41 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Sun, 26 Apr 2009 20:05:41 -0500 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: <200904261812.n3QICZYX035390@camembert.async.caltech.edu> References: <200904261812.n3QICZYX035390@camembert.async.caltech.edu> Message-ID: <49F504E5.9000100@cox.net> FWIW, some m3gdb functions don't get the info they need with -gstabs, wereas -gstabx+ gives it to them. Mika Nystrom wrote: > Hi Tony, > > I looked at this more closely, and I was wrong. The compiler doesn't > actually segfault on -O. I was using -gstabs+ but switched to -gstabs > after your email (doesn't seem to matter). > > From mika at async.caltech.edu Mon Apr 27 03:17:24 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 26 Apr 2009 18:17:24 -0700 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: Your message of "Mon, 27 Apr 2009 10:37:09 +1000." <678F2302-90D4-4F96-9EF6-7DA1167A97BA@cs.purdue.edu> Message-ID: <200904270117.n3R1HOMt054469@camembert.async.caltech.edu> Tony Hosking writes: ... >> With lots of tweaks and adjustments, I now see my code running about >> 100% slower under CM3 than the same code does under PM3 (on the >> same machine). This is including my typecase hacks, as described >> earlier today. I'm guessing most of it is the FreeBSD pthreads >> implementation in libc_r + the calls to PushEFrame. > >Yikes! How much of this is module initialization (startup) time? > Ok, I re-checked just to make sure. As far as I know, exactly the same code, no initialization overhead (program's already running): CM3: > (time-call (lambda()(make-standard-stuff "Example"))) 1.309586018207483 > PM3: > (time-call (lambda()(make-standard-stuff "Example"))) 0.5641579627990723 > Bear in mind this is pretty close to a worst-case test for the "delta" between PM3 and CM3. Lots of small procedures, lots of typecases. Well, actually, I can make it worse. Turn on locking in the Scheme environments (so that they could be used by multi-threaded interpreters): CM3: > (time-call (lambda()(make-standard-stuff "Example"))) 2.1610950572649017 > PM3: > (time-call (lambda()(make-standard-stuff "Example"))) 0.6010241508483887 > CM3 without my change to RTType: > (time-call (lambda()(make-standard-stuff "Example"))) 2.2972461158642545 > 250% slower. But it is very demanding on pthreads. Lots of little procedures, lots of typecases, lots of locking. (No contention, though.) Mika P.S. the code in question is a scheme-m3 stub generator; it's making stub interfaces in the tests above. From hosking at cs.purdue.edu Mon Apr 27 03:29:04 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Apr 2009 11:29:04 +1000 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: <200904270117.n3R1HOMt054469@camembert.async.caltech.edu> References: <200904270117.n3R1HOMt054469@camembert.async.caltech.edu> Message-ID: Hmm. Interesting. What about exception scopes? On 27 Apr 2009, at 11:17, Mika Nystrom wrote: > Tony Hosking writes: > ... >>> With lots of tweaks and adjustments, I now see my code running about >>> 100% slower under CM3 than the same code does under PM3 (on the >>> same machine). This is including my typecase hacks, as described >>> earlier today. I'm guessing most of it is the FreeBSD pthreads >>> implementation in libc_r + the calls to PushEFrame. >> >> Yikes! How much of this is module initialization (startup) time? >> > > Ok, I re-checked just to make sure. As far as I know, exactly the > same code, > no initialization overhead (program's already running): > > CM3: > >> (time-call (lambda()(make-standard-stuff "Example"))) > 1.309586018207483 >> > > PM3: > >> (time-call (lambda()(make-standard-stuff "Example"))) > 0.5641579627990723 >> > > Bear in mind this is pretty close to a worst-case test for the > "delta" between > PM3 and CM3. Lots of small procedures, lots of typecases. > > Well, actually, I can make it worse. Turn on locking in the Scheme > environments > (so that they could be used by multi-threaded interpreters): > > CM3: > >> (time-call (lambda()(make-standard-stuff "Example"))) > 2.1610950572649017 >> > > PM3: > >> (time-call (lambda()(make-standard-stuff "Example"))) > 0.6010241508483887 >> > > CM3 without my change to RTType: > >> (time-call (lambda()(make-standard-stuff "Example"))) > 2.2972461158642545 >> > > 250% slower. > > But it is very demanding on pthreads. Lots of little procedures, > lots of typecases, lots of locking. (No contention, though.) > > Mika > > P.S. the code in question is a scheme-m3 stub generator; it's making > stub interfaces in the tests above. From hendrik at topoi.pooq.com Mon Apr 27 04:14:58 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 26 Apr 2009 22:14:58 -0400 Subject: [M3devel] Scheme in m3? In-Reply-To: <200904270117.n3R1HOMt054469@camembert.async.caltech.edu> References: <678F2302-90D4-4F96-9EF6-7DA1167A97BA@cs.purdue.edu> <200904270117.n3R1HOMt054469@camembert.async.caltech.edu> Message-ID: <20090427021457.GB6064@topoi.pooq.com> On Sun, Apr 26, 2009 at 06:17:24PM -0700, Mika Nystrom wrote: > > Well, actually, I can make it worse. Turn on locking in the Scheme environments ... > CM3: > > > (time-call (lambda()(make-standard-stuff "Example"))) > 2.1610950572649017 > > > > PM3: > > > (time-call (lambda()(make-standard-stuff "Example"))) > 0.6010241508483887 > > > A Scheme in M3? What do you do for tail-calls? -- hendrik From mika at async.caltech.edu Mon Apr 27 04:28:42 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 26 Apr 2009 19:28:42 -0700 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: Your message of "Mon, 27 Apr 2009 11:29:04 +1000." Message-ID: <200904270228.n3R2SgLC057723@camembert.async.caltech.edu> How would I know? I'm trying to turn on profiling but it seems to be a bit involved. Involves re-building all the libraries? (cm3 -profile seems to look for FreeBSD4p instead of plain FreeBSD4...) Mika Tony Hosking writes: >Hmm. Interesting. What about exception scopes? > >On 27 Apr 2009, at 11:17, Mika Nystrom wrote: > >> Tony Hosking writes: >> ... >>>> With lots of tweaks and adjustments, I now see my code running about >>>> 100% slower under CM3 than the same code does under PM3 (on the >>>> same machine). This is including my typecase hacks, as described >>>> earlier today. I'm guessing most of it is the FreeBSD pthreads >>>> implementation in libc_r + the calls to PushEFrame. >>> >> Yikes! How much of this is module initialization (startup) time? >>> >> >> Ok, I re-checked just to make sure. As far as I know, exactly the >> same code, >> no initialization overhead (program's already running): >> >> CM3: >> >>> (time-call (lambda()(make-standard-stuff "Example"))) >> 1.309586018207483 >>> >> >> PM3: >> >>> (time-call (lambda()(make-standard-stuff "Example"))) >> 0.5641579627990723 >>> >> >> Bear in mind this is pretty close to a worst-case test for the >> "delta" between >> PM3 and CM3. Lots of small procedures, lots of typecases. >> >> Well, actually, I can make it worse. Turn on locking in the Scheme >> environments >> (so that they could be used by multi-threaded interpreters): >> >> CM3: >> >>> (time-call (lambda()(make-standard-stuff "Example"))) >> 2.1610950572649017 >>> >> >> PM3: >> >>> (time-call (lambda()(make-standard-stuff "Example"))) >> 0.6010241508483887 >>> >> >> CM3 without my change to RTType: >> >>> (time-call (lambda()(make-standard-stuff "Example"))) >> 2.2972461158642545 >>> >> >> 250% slower. >> >> But it is very demanding on pthreads. Lots of little procedures, >> lots of typecases, lots of locking. (No contention, though.) >> >> Mika >> >> P.S. the code in question is a scheme-m3 stub generator; it's making >> stub interfaces in the tests above. > From hosking at cs.purdue.edu Mon Apr 27 04:37:17 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Apr 2009 12:37:17 +1000 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: <200904270228.n3R2SgLC057723@camembert.async.caltech.edu> References: <200904270228.n3R2SgLC057723@camembert.async.caltech.edu> Message-ID: <9AE70027-6818-4404-A4A6-BBEAD31B7935@cs.purdue.edu> I was just wondering if your code has a lot of TRY blocks, which come with the PushEFrame overhead. On 27 Apr 2009, at 12:28, Mika Nystrom wrote: > How would I know? I'm trying to turn on profiling but it seems to > be a > bit involved. Involves re-building all the libraries? > > (cm3 -profile seems to look for FreeBSD4p instead of plain > FreeBSD4...) > > Mika > > Tony Hosking writes: >> Hmm. Interesting. What about exception scopes? >> >> On 27 Apr 2009, at 11:17, Mika Nystrom wrote: >> >>> Tony Hosking writes: >>> ... >>>>> With lots of tweaks and adjustments, I now see my code running >>>>> about >>>>> 100% slower under CM3 than the same code does under PM3 (on the >>>>> same machine). This is including my typecase hacks, as described >>>>> earlier today. I'm guessing most of it is the FreeBSD pthreads >>>>> implementation in libc_r + the calls to PushEFrame. >>>> >>> Yikes! How much of this is module initialization (startup) time? >>>> >>> >>> Ok, I re-checked just to make sure. As far as I know, exactly the >>> same code, >>> no initialization overhead (program's already running): >>> >>> CM3: >>> >>>> (time-call (lambda()(make-standard-stuff "Example"))) >>> 1.309586018207483 >>>> >>> >>> PM3: >>> >>>> (time-call (lambda()(make-standard-stuff "Example"))) >>> 0.5641579627990723 >>>> >>> >>> Bear in mind this is pretty close to a worst-case test for the >>> "delta" between >>> PM3 and CM3. Lots of small procedures, lots of typecases. >>> >>> Well, actually, I can make it worse. Turn on locking in the Scheme >>> environments >>> (so that they could be used by multi-threaded interpreters): >>> >>> CM3: >>> >>>> (time-call (lambda()(make-standard-stuff "Example"))) >>> 2.1610950572649017 >>>> >>> >>> PM3: >>> >>>> (time-call (lambda()(make-standard-stuff "Example"))) >>> 0.6010241508483887 >>>> >>> >>> CM3 without my change to RTType: >>> >>>> (time-call (lambda()(make-standard-stuff "Example"))) >>> 2.2972461158642545 >>>> >>> >>> 250% slower. >>> >>> But it is very demanding on pthreads. Lots of little procedures, >>> lots of typecases, lots of locking. (No contention, though.) >>> >>> Mika >>> >>> P.S. the code in question is a scheme-m3 stub generator; it's making >>> stub interfaces in the tests above. >> From mika at async.caltech.edu Mon Apr 27 04:44:28 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 26 Apr 2009 19:44:28 -0700 Subject: [M3devel] Scheme in m3? In-Reply-To: Your message of "Sun, 26 Apr 2009 22:14:58 EDT." <20090427021457.GB6064@topoi.pooq.com> Message-ID: <200904270244.n3R2iSw8058447@camembert.async.caltech.edu> LOOP! I just copied Peter Norvig's Java code, as a starting point. (JScheme something or other.) Just like his interpreter, mine doesn't implement call-with-current-continuation completely. But normal tail calls are fine. An abbreviated version of eval: PROCEDURE Eval(env : Environment; x : Object) : Object = BEGIN LOOP IF x # NIL AND ISTYPE(x,Symbol) THEN RETURN env.lookup(x) ELSE VAR fn := x.car; BEGIN IF (* special forms *) THEN ... ELSE (* procedure call *) fn := Eval(fn, env); TYPECASE fn OF Closure(c) => x := c.body; (* tail call *) env := NEW(Environment).init(c.params,c.env) ... END END END END END END Eval; Mika hendrik at topoi.pooq.com writes: >On Sun, Apr 26, 2009 at 06:17:24PM -0700, Mika Nystrom wrote: > >> >> Well, actually, I can make it worse. Turn on locking in the Scheme environments >... >> CM3: >> >> > (time-call (lambda()(make-standard-stuff "Example"))) >> 2.1610950572649017 >> > >> >> PM3: >> >> > (time-call (lambda()(make-standard-stuff "Example"))) >> 0.6010241508483887 >> > >> > >A Scheme in M3? What do you do for tail-calls? > >-- hendrik From jay.krell at cornell.edu Mon Apr 27 04:32:12 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 26 Apr 2009 19:32:12 -0700 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: References: <200904270117.n3R1HOMt054469@camembert.async.caltech.edu> Message-ID: I think Tony means do you have many 'try' and hav you tried reducing them? That is where pusheframe comes from (and lock). We can give you back user threads, and probably speed up pthreads on some platforms with __thread instead of pthread_setspecific.on some platforms it exists and is more than just syntactic sugar, I think. I assume typecase can be much faster even with dynamic loading but need to dig, much later. - Jay (phone) On Apr 26, 2009, at 6:29 PM, Tony Hosking wrote: > Hmm. Interesting. What about exception scopes? > > On 27 Apr 2009, at 11:17, Mika Nystrom >>> >>> >> >> >>> >> >>> >> >> >> >>> >> >>> >> >>> >> >> >> >> From mika at async.caltech.edu Mon Apr 27 04:59:32 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 26 Apr 2009 19:59:32 -0700 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: Your message of "Mon, 27 Apr 2009 12:37:17 +1000." <9AE70027-6818-4404-A4A6-BBEAD31B7935@cs.purdue.edu> Message-ID: <200904270259.n3R2xWDX059155@camembert.async.caltech.edu> Ah, yeah... I have to admit it does. Whenever it pushes the stack in Scheme it makes a TRY block so it can print a pretty traceback if anything goes wrong... if something goes wrong deep into a call it prints an error message for every frame in Scheme (not tail calls obviously, see Hendrik's question), concatenating them as it pops out of the frames, until you're back at the REPL. Example: > (define (add1 x) ( + x 1)) add1 > (define (x) (map add1 '(1 2 3 junk))) x > (x) EXCEPTION! expected a double, got: junk (called from) eval (+ x 1) (called from) eval (x) > Hmm.. so if I disable tracebacks my code should get a lot faster. > (time-call (lambda()(make-standard-stuff "Example"))) 1.3191220290027559 > (toggle-tracebacks) #f > (time-call (lambda()(make-standard-stuff "Example"))) 1.1270759491017088 > Neat... sort of. 17% speedup is nothing to sneeze at, but I do like those tracebacks, too. Mika Tony Hosking writes: >I was just wondering if your code has a lot of TRY blocks, which come >with the PushEFrame overhead. > >On 27 Apr 2009, at 12:28, Mika Nystrom wrote: > >> How would I know? I'm trying to turn on profiling but it seems to >> be a >> bit involved. Involves re-building all the libraries? >> >> (cm3 -profile seems to look for FreeBSD4p instead of plain >> FreeBSD4...) >> >> Mika >> >> Tony Hosking writes: >>> Hmm. Interesting. What about exception scopes? >>> >>> On 27 Apr 2009, at 11:17, Mika Nystrom wrote: >>> >>>> Tony Hosking writes: >>>> ... >>>>>> With lots of tweaks and adjustments, I now see my code running >>>>>> about >>>>>> 100% slower under CM3 than the same code does under PM3 (on the >>>>>> same machine). This is including my typecase hacks, as described >>>>>> earlier today. I'm guessing most of it is the FreeBSD pthreads >>>>>> implementation in libc_r + the calls to PushEFrame. >>>>> >>>> Yikes! How much of this is module initialization (startup) time? >>>>> >>>> >>>> Ok, I re-checked just to make sure. As far as I know, exactly the >>>> same code, >>>> no initialization overhead (program's already running): >>>> >>>> CM3: >>>> >>>>> (time-call (lambda()(make-standard-stuff "Example"))) >>>> 1.309586018207483 >>>>> >>>> >>>> PM3: >>>> >>>>> (time-call (lambda()(make-standard-stuff "Example"))) >>>> 0.5641579627990723 >>>>> >>>> >>>> Bear in mind this is pretty close to a worst-case test for the >>>> "delta" between >>>> PM3 and CM3. Lots of small procedures, lots of typecases. >>>> >>>> Well, actually, I can make it worse. Turn on locking in the Scheme >>>> environments >>>> (so that they could be used by multi-threaded interpreters): >>>> >>>> CM3: >>>> >>>>> (time-call (lambda()(make-standard-stuff "Example"))) >>>> 2.1610950572649017 >>>>> >>>> >>>> PM3: >>>> >>>>> (time-call (lambda()(make-standard-stuff "Example"))) >>>> 0.6010241508483887 >>>>> >>>> >>>> CM3 without my change to RTType: >>>> >>>>> (time-call (lambda()(make-standard-stuff "Example"))) >>>> 2.2972461158642545 >>>>> >>>> >>>> 250% slower. >>>> >>>> But it is very demanding on pthreads. Lots of little procedures, >>>> lots of typecases, lots of locking. (No contention, though.) >>>> >>>> Mika >>>> >>>> P.S. the code in question is a scheme-m3 stub generator; it's making >>>> stub interfaces in the tests above. >>> > From jay.krell at cornell.edu Mon Apr 27 04:36:09 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 26 Apr 2009 19:36:09 -0700 Subject: [M3devel] optimization [ was Re: Performance issues with CM3 ] In-Reply-To: <200904270228.n3R2SgLC057723@camembert.async.caltech.edu> References: <200904270228.n3R2SgLC057723@camembert.async.caltech.edu> Message-ID: <4F21234C-997C-485D-A02F-FBD85A0E0A57@hotmail.com> It does that, yes, but try hacking it out of the config file. - Jay (phone) On Apr 26, 2009, at 7:28 PM, Mika Nystrom wrote: > How would I know? I'm trying to turn on profiling but it seems to > be a > bit involved. Involves re-building all the libraries? > > (cm3 -profile seems to look for FreeBSD4p instead of plain > FreeBSD4...) > > Mika > > Tony Hosking writes: >> >>>> >>>> >>> >>> >>>> >>> >>>> >>> >>> >>> >>>> >>> >>>> >>> >>>> >>> >>> >>> >>> >> From wagner at elegosoft.com Mon Apr 27 08:46:18 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 27 Apr 2009 08:46:18 +0200 Subject: [M3devel] Fwd: Modula-2 to Modula-3 translator by Aachen University Message-ID: <20090427084618.hnk460mh440c880c@mail.elegosoft.com> Perhaps somebody on the public list knows something... ----- Forwarded message from trijezdci at gmail.com ----- Date: Sun, 26 Apr 2009 15:57:36 +0900 From: Benjamin Kowarsch Reply-To: Benjamin Kowarsch Subject: Modula-2 to Modula-3 translator by Aachen University To: m3-support at elego.de Dear Sirs, I am trying to get the Modula-2 section in the Catalog of Compilers updated and there is one entry of a Modula-2 to Modula-3 translator by Peter Klein at University of Aachen for which all links and email addresses seem to be dead. University of Aachen was unable to give me any information either. I wonder if you know whether this translator is still availabe and if so at which URL, or where his author Peter Klein can be contacted. thank you regards benjamin ----- 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 mika at async.caltech.edu Mon Apr 27 09:50:44 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 27 Apr 2009 00:50:44 -0700 Subject: [M3devel] RuntimeError doesn't work quite as advertised Message-ID: <200904270750.n3R7oiqH071966@camembert.async.caltech.edu> Maybe someone else knows more about this than me... The following program: MODULE Main; IMPORT RuntimeError, IO; PROCEDURE Range() = BEGIN EVAL VAL(-1,CARDINAL) END Range; PROCEDURE Assert() = BEGIN <*ASSERT FALSE*> END Assert; PROCEDURE NilJump() = VAR x : PROCEDURE() := NIL; BEGIN x() END NilJump; PROCEDURE NilDeref() = VAR x : REF INTEGER := NIL; b : INTEGER; BEGIN b := x^ END NilDeref; PROCEDURE NilMethod() = TYPE T = OBJECT METHODS m() END; VAR t : T; BEGIN t.m() END NilMethod; BEGIN WITH ps = ARRAY OF PROCEDURE() { Range, Assert, NilMethod, NilJump, NilDeref } DO FOR i := FIRST(ps) TO LAST(ps) DO TRY ps[i]() EXCEPT RuntimeError.E(e) => IO.Put("RuntimeError: " & RuntimeError.Tag(e) & " \n") END END END END Main. yields the following result: (1053)trs80:~/test/src>../FreeBSD4/prog RuntimeError: An enumeration or subrange value was out of range. RuntimeError: <*ASSERT*> failed. *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x8048a71 = NilMethod + 0x10 in ../src/Main.m3 *** Abort Seems to me I ought to see a few more exceptions and not a crash. I'm happy to investigate a bit more, but does anyone have a clue where to begin? Mika From mika at async.caltech.edu Mon Apr 27 10:31:21 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 27 Apr 2009 01:31:21 -0700 Subject: [M3devel] RuntimeError doesn't work quite as advertised In-Reply-To: Your message of "Mon, 27 Apr 2009 00:50:44 PDT." <200904270750.n3R7oiqH071966@camembert.async.caltech.edu> Message-ID: <200904270831.n3R8VLFe073838@camembert.async.caltech.edu> Ok so I tried the "obvious thing", namely, I changed RTSignal.SegV to do RAISE RuntimeError.E(RuntimeError.T.BadMemoryReference); Somewhat to my surprise, this does the right thing for a null method. But somewhat less surprisingly, it loops for NilJump and NilDeref. Is the machine jumping back and re-executing the same instructions after the signal handler returns? Would all hell break loose if one were to special-case EXCEPT RuntimeError.E to store a thread-local jmp_buf that one does a C-style longjmp to? (With a chain back to any higher RuntimeError.E handlers, I suppose...) Or is there a way to get the exception to work out of the signal handler with the normal exception mechanism? Mika Mika Nystrom writes: > >Maybe someone else knows more about this than me... > >The following program: > >MODULE Main; >IMPORT RuntimeError, IO; > >PROCEDURE Range() = BEGIN EVAL VAL(-1,CARDINAL) END Range; > >PROCEDURE Assert() = BEGIN <*ASSERT FALSE*> END Assert; > >PROCEDURE NilJump() = VAR x : PROCEDURE() := NIL; BEGIN x() END NilJump; > >PROCEDURE NilDeref() = > VAR x : REF INTEGER := NIL; b : INTEGER; > BEGIN b := x^ END NilDeref; > >PROCEDURE NilMethod() = > TYPE T = OBJECT METHODS m() END; > VAR t : T; BEGIN t.m() END NilMethod; > >BEGIN > WITH ps = ARRAY OF PROCEDURE() { Range, Assert, NilMethod, NilJump, NilDeref } DO > FOR i := FIRST(ps) TO LAST(ps) DO > TRY > ps[i]() > EXCEPT > RuntimeError.E(e) => IO.Put("RuntimeError: " & RuntimeError.Tag(e) & " \n") > END > END > END >END Main. > >yields the following result: > >(1053)trs80:~/test/src>../FreeBSD4/prog >RuntimeError: An enumeration or subrange value was out of range. >RuntimeError: <*ASSERT*> failed. > > >*** >*** runtime error: >*** Segmentation violation - possible attempt to dereference NIL >*** pc = 0x8048a71 = NilMethod + 0x10 in ../src/Main.m3 >*** > >Abort > >Seems to me I ought to see a few more exceptions and not a crash. > >I'm happy to investigate a bit more, but does anyone have a clue where >to begin? > > Mika From wagner at elegosoft.com Mon Apr 27 14:24:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 27 Apr 2009 14:24:26 +0200 Subject: [M3devel] help booting CM3 on FreeBSD 4.11? In-Reply-To: <09E195AF-2D6E-4A76-9328-DC4F29049719@gmail.com> References: <200904260530.n3Q5U1NE000824@camembert.async.caltech.edu> <09E195AF-2D6E-4A76-9328-DC4F29049719@gmail.com> Message-ID: <20090427142426.tlx54313ms88sgk0@mail.elegosoft.com> Quoting Jay : > It is easy to fix for many non Linux systems.and possible for Linux. > Fairly well worn topic. Could you please just fix it if it's easy? User threads always worked reliably and very fast on FreeBSD systems. As I stated earlier, I'd deem it a regrettable loss. Thanks in advance, Olaf > - Jay (phone) > > On Apr 25, 2009, at 10:30 PM, Mika Nystrom wrote: > >> User threads certainly work fine on this machine (see my previous >> email) with PM3... some would say they work "better"... :-) >> >> Jay writes: >>> >>> --Apple-Mail-1-423481883 >>> Content-Type: text/plain; >>> charset=us-ascii; >>> format=flowed; >>> delsp=yes >>> Content-Transfer-Encoding: 7bit >>> >>> I think also due to simple use before init. >>> >>> - Jay (phone) >>> >>> On Apr 25, 2009, at 9:51 PM, Tony Hosking wrote: >>> >>>> Broken mostly because updated libraries detect forging of thread >>>> contexts (state) for security reasons and blow up. >>>> >>>> On 25 Apr 2009, at 14:12, Jay wrote: >>>> >>>>> Cool. >>>>> >>>>>> If I use user threads, it's a different story (which is probably >>>>> too bad, >>>>> >>>>> Oops, right, I forgot, I should have mentioned that, user threads >>>>> have likely been broken on all platforms for a while. I noticed >>>>> that on PPC_LINUX. I >>> >>> >>> --Apple-Mail-1-423481883 >>> Content-Type: text/html; >>> charset=utf-8 >>> Content-Transfer-Encoding: quoted-printable >>> >>>
I think also due to simple use = >>> before init.

 - Jay (phone>> style=3D"-webkit-composition-fill-color: rgba(175, 192, 227, 0.231373); = >>> -webkit-composition-frame-color: rgba(77, 128, 180, 0.231373); = >>> ">)
>> apple-content-edited=3D"true">>> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >>> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >>> normal; font-variant: normal; font-weight: normal; letter-spacing: = >>> normal; line-height: normal; text-align: auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; ">
>> style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; = >>> -khtml-line-break: after-white-space; ">>> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >>> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >>> normal; font-variant: normal; font-weight: normal; letter-spacing: = >>> normal; line-height: normal; text-align: auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; ">Broken mostly = >>> because updated libraries detect forging of thread contexts (state) for = >>> security reasons and blow up.

On = >>> 25 Apr 2009, at 14:12, Jay wrote:

>> class=3D"Apple-interchange-newline">
>> class=3D"Apple-style-span" style=3D"border-collapse: separate; color: = >>> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >>> normal; font-variant: normal; font-weight: normal; letter-spacing: = >>> normal; line-height: normal; orphans: 2; text-align: auto; text-indent: = >>> 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: = >>> 0px; -webkit-border-horizontal-spacing: 0px; = >>> -webkit-border-vertical-spacing: 0px; = >>> -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = >>> auto; -webkit-text-stroke-width: 0; ">
>> style=3D"font-size: 10pt; font-family: Verdana; = >>> ">Cool.
 
 > If I use user threads, it's a different = >>> story (which is probably too bad,

Oops, right, I forgot, I should = >>> have mentioned that, user threads have likely been broken on all = >>> platforms for a while. I noticed that on PPC_LINUX. = >>> I

= >>> >>> --Apple-Mail-1-423481883-- -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Mon Apr 27 14:23:41 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Apr 2009 22:23:41 +1000 Subject: [M3devel] RuntimeError doesn't work quite as advertised In-Reply-To: <200904270831.n3R8VLFe073838@camembert.async.caltech.edu> References: <200904270831.n3R8VLFe073838@camembert.async.caltech.edu> Message-ID: <7F78EA61-BF67-4C18-85D4-F0CC5B45276A@cs.purdue.edu> It's probably not generally safe to use RAISE inside a signal handler. There are esoteric rules as to what signal handlers can handle... I think we need to think harder on how best to reflect NIL dereference as a signal. Perhaps we need explicit NIL checks after all... On 27 Apr 2009, at 18:31, Mika Nystrom wrote: > Ok so I tried the "obvious thing", namely, I changed RTSignal.SegV to > do > > RAISE RuntimeError.E(RuntimeError.T.BadMemoryReference); > > Somewhat to my surprise, this does the right thing for a null method. > But somewhat less surprisingly, it loops for NilJump and NilDeref. > Is the machine jumping back and re-executing the same instructions > after the signal handler returns? > > Would all hell break loose if one were to special-case EXCEPT > RuntimeError.E to store a thread-local jmp_buf that one does a > C-style longjmp to? (With a chain back to any higher RuntimeError.E > handlers, I suppose...) Or is there a way to get the exception to > work out of the signal handler with the normal exception mechanism? > > Mika > > Mika Nystrom writes: >> >> Maybe someone else knows more about this than me... >> >> The following program: >> >> MODULE Main; >> IMPORT RuntimeError, IO; >> >> PROCEDURE Range() = BEGIN EVAL VAL(-1,CARDINAL) END Range; >> >> PROCEDURE Assert() = BEGIN <*ASSERT FALSE*> END Assert; >> >> PROCEDURE NilJump() = VAR x : PROCEDURE() := NIL; BEGIN x() END >> NilJump; >> >> PROCEDURE NilDeref() = >> VAR x : REF INTEGER := NIL; b : INTEGER; >> BEGIN b := x^ END NilDeref; >> >> PROCEDURE NilMethod() = >> TYPE T = OBJECT METHODS m() END; >> VAR t : T; BEGIN t.m() END NilMethod; >> >> BEGIN >> WITH ps = ARRAY OF PROCEDURE() { Range, Assert, NilMethod, NilJump, >> NilDeref } DO >> FOR i := FIRST(ps) TO LAST(ps) DO >> TRY >> ps[i]() >> EXCEPT >> RuntimeError.E(e) => IO.Put("RuntimeError: " & >> RuntimeError.Tag(e) & " \n") >> END >> END >> END >> END Main. >> >> yields the following result: >> >> (1053)trs80:~/test/src>../FreeBSD4/prog >> RuntimeError: An enumeration or subrange value was out of range. >> RuntimeError: <*ASSERT*> failed. >> >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL >> *** pc = 0x8048a71 = NilMethod + 0x10 in ../src/Main.m3 >> *** >> >> Abort >> >> Seems to me I ought to see a few more exceptions and not a crash. >> >> I'm happy to investigate a bit more, but does anyone have a clue >> where >> to begin? >> >> Mika From rodney.m.bates at cox.net Mon Apr 27 16:27:39 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Mon, 27 Apr 2009 09:27:39 -0500 Subject: [M3devel] Fwd: Modula-2 to Modula-3 translator by Aachen University In-Reply-To: <20090427084618.hnk460mh440c880c@mail.elegosoft.com> References: <20090427084618.hnk460mh440c880c@mail.elegosoft.com> Message-ID: <49F5C0DB.5010409@cox.net> I have a local copy of it, but haven't built/run it in several years. I have used it successfully on two or three conversions in the past. Can we make space at elegosoft? I'm pretty busy moving house now, but could quickly put my current files up, then try in a couple of months to see if it has suffered any bitrot. Olaf Wagner wrote: > Perhaps somebody on the public list knows something... > > ----- Forwarded message from trijezdci at gmail.com ----- > Date: Sun, 26 Apr 2009 15:57:36 +0900 > From: Benjamin Kowarsch > Reply-To: Benjamin Kowarsch > Subject: Modula-2 to Modula-3 translator by Aachen University > To: m3-support at elego.de > > Dear Sirs, > > I am trying to get the Modula-2 section in the Catalog of Compilers > updated and there is one entry of a Modula-2 to Modula-3 translator by > Peter Klein at University of Aachen for which all links and email > addresses seem to be dead. University of Aachen was unable to give me > any information either. > > I wonder if you know whether this translator is still availabe and if > so at which URL, or where his author Peter Klein can be contacted. > > thank you > regards > benjamin > > > ----- End forwarded message ----- > > Rodney Bates rodney.m.bates at cox.net From mika at async.caltech.edu Tue Apr 28 03:18:10 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 27 Apr 2009 18:18:10 -0700 Subject: [M3devel] RuntimeError doesn't work quite as advertised In-Reply-To: Your message of "Mon, 27 Apr 2009 22:23:41 +1000." <7F78EA61-BF67-4C18-85D4-F0CC5B45276A@cs.purdue.edu> Message-ID: <200904280118.n3S1IAQ2021489@camembert.async.caltech.edu> I think it ought to be safe to use siglongjmp. So we could attach a sigjmpbuf to whatever structure PushEFrame builds only when it's doing it for a "RuntimeError", and on a runtime error that's not handled otherwise, we catch the unix signal and call siglongjmp to get back to the exception handler... Here's an example in C: #include #include sigjmp_buf env; void handler(int x) { siglongjmp(env,1); } main() { signal(SIGSEGV, handler); if(sigsetjmp(env,1)) { printf("caught signal\n"); exit(0); } else { printf("initialized env\n"); } { int *a=(void *)0; printf("a is %d\n", *a /* SEGV */); /* not reached */ } } Mika Tony Hosking writes: >It's probably not generally safe to use RAISE inside a signal >handler. There are esoteric rules as to what signal handlers can >handle... > >I think we need to think harder on how best to reflect NIL dereference >as a signal. Perhaps we need explicit NIL checks after all... > >On 27 Apr 2009, at 18:31, Mika Nystrom wrote: > >> Ok so I tried the "obvious thing", namely, I changed RTSignal.SegV to >> do >> >> RAISE RuntimeError.E(RuntimeError.T.BadMemoryReference); >> >> Somewhat to my surprise, this does the right thing for a null method. >> But somewhat less surprisingly, it loops for NilJump and NilDeref. >> Is the machine jumping back and re-executing the same instructions >> after the signal handler returns? >> >> Would all hell break loose if one were to special-case EXCEPT >> RuntimeError.E to store a thread-local jmp_buf that one does a >> C-style longjmp to? (With a chain back to any higher RuntimeError.E >> handlers, I suppose...) Or is there a way to get the exception to >> work out of the signal handler with the normal exception mechanism? >> >> Mika > >> Mika Nystrom writes: >>> >>> Maybe someone else knows more about this than me... >>> >>> The following program: >>> >>> MODULE Main; >>> IMPORT RuntimeError, IO; >>> >>> PROCEDURE Range() = BEGIN EVAL VAL(-1,CARDINAL) END Range; >>> >>> PROCEDURE Assert() = BEGIN <*ASSERT FALSE*> END Assert; >>> >>> PROCEDURE NilJump() = VAR x : PROCEDURE() := NIL; BEGIN x() END >>> NilJump; >>> >>> PROCEDURE NilDeref() = >>> VAR x : REF INTEGER := NIL; b : INTEGER; >>> BEGIN b := x^ END NilDeref; >>> >>> PROCEDURE NilMethod() = >>> TYPE T = OBJECT METHODS m() END; >>> VAR t : T; BEGIN t.m() END NilMethod; >>> >>> BEGIN >>> WITH ps = ARRAY OF PROCEDURE() { Range, Assert, NilMethod, NilJump, >>> NilDeref } DO >>> FOR i := FIRST(ps) TO LAST(ps) DO >>> TRY >>> ps[i]() >>> EXCEPT >>> RuntimeError.E(e) => IO.Put("RuntimeError: " & >>> RuntimeError.Tag(e) & " \n") >>> END >>> END >>> END >>> END Main. >>> >>> yields the following result: >>> >>> (1053)trs80:~/test/src>../FreeBSD4/prog >>> RuntimeError: An enumeration or subrange value was out of range. >>> RuntimeError: <*ASSERT*> failed. >>> >>> >>> *** >>> *** runtime error: >>> *** Segmentation violation - possible attempt to dereference NIL >>> *** pc = 0x8048a71 = NilMethod + 0x10 in ../src/Main.m3 >>> *** >>> >>> Abort >>> >>> Seems to me I ought to see a few more exceptions and not a crash. >>> >>> I'm happy to investigate a bit more, but does anyone have a clue >>> where >>> to begin? >>> >>> Mika From hosking at cs.purdue.edu Tue Apr 28 03:48:34 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 28 Apr 2009 11:48:34 +1000 Subject: [M3devel] RuntimeError doesn't work quite as advertised In-Reply-To: <200904280118.n3S1IAQ2021489@camembert.async.caltech.edu> References: <200904280118.n3S1IAQ2021489@camembert.async.caltech.edu> Message-ID: <186B6F66-B42D-4AB4-8151-470FE0296013@cs.purdue.edu> On 28 Apr 2009, at 11:18, Mika Nystrom wrote: > I think it ought to be safe to use siglongjmp. > > So we could attach a sigjmpbuf to whatever structure PushEFrame > builds only when it's doing it for a "RuntimeError", and on a runtime > error that's not handled otherwise, we catch the unix signal and > call siglongjmp to get back to the exception handler... I'm not sure we can statically determine how a frame will be used. Can someone (Jay?) confirm whether signal handling on platforms without a stack walker are actually already using siglongjmp? I have a feeling this may already be the case. > Here's an example in C: > > #include > #include > > sigjmp_buf env; > > void handler(int x) { siglongjmp(env,1); } > > main() > { > signal(SIGSEGV, handler); > > if(sigsetjmp(env,1)) { > printf("caught signal\n"); > exit(0); > } else { > printf("initialized env\n"); > } > > { > int *a=(void *)0; > printf("a is %d\n", *a /* SEGV */); > /* not reached */ > } > } > > Mika > > > Tony Hosking writes: >> It's probably not generally safe to use RAISE inside a signal >> handler. There are esoteric rules as to what signal handlers can >> handle... >> >> I think we need to think harder on how best to reflect NIL >> dereference >> as a signal. Perhaps we need explicit NIL checks after all... >> >> On 27 Apr 2009, at 18:31, Mika Nystrom wrote: >> >>> Ok so I tried the "obvious thing", namely, I changed RTSignal.SegV >>> to >>> do >>> >>> RAISE RuntimeError.E(RuntimeError.T.BadMemoryReference); >>> >>> Somewhat to my surprise, this does the right thing for a null >>> method. >>> But somewhat less surprisingly, it loops for NilJump and NilDeref. >>> Is the machine jumping back and re-executing the same instructions >>> after the signal handler returns? >>> >>> Would all hell break loose if one were to special-case EXCEPT >>> RuntimeError.E to store a thread-local jmp_buf that one does a >>> C-style longjmp to? (With a chain back to any higher RuntimeError.E >>> handlers, I suppose...) Or is there a way to get the exception to >>> work out of the signal handler with the normal exception mechanism? >>> >>> Mika >> >>> Mika Nystrom writes: >>>> >>>> Maybe someone else knows more about this than me... >>>> >>>> The following program: >>>> >>>> MODULE Main; >>>> IMPORT RuntimeError, IO; >>>> >>>> PROCEDURE Range() = BEGIN EVAL VAL(-1,CARDINAL) END Range; >>>> >>>> PROCEDURE Assert() = BEGIN <*ASSERT FALSE*> END Assert; >>>> >>>> PROCEDURE NilJump() = VAR x : PROCEDURE() := NIL; BEGIN x() END >>>> NilJump; >>>> >>>> PROCEDURE NilDeref() = >>>> VAR x : REF INTEGER := NIL; b : INTEGER; >>>> BEGIN b := x^ END NilDeref; >>>> >>>> PROCEDURE NilMethod() = >>>> TYPE T = OBJECT METHODS m() END; >>>> VAR t : T; BEGIN t.m() END NilMethod; >>>> >>>> BEGIN >>>> WITH ps = ARRAY OF PROCEDURE() { Range, Assert, NilMethod, NilJump, >>>> NilDeref } DO >>>> FOR i := FIRST(ps) TO LAST(ps) DO >>>> TRY >>>> ps[i]() >>>> EXCEPT >>>> RuntimeError.E(e) => IO.Put("RuntimeError: " & >>>> RuntimeError.Tag(e) & " \n") >>>> END >>>> END >>>> END >>>> END Main. >>>> >>>> yields the following result: >>>> >>>> (1053)trs80:~/test/src>../FreeBSD4/prog >>>> RuntimeError: An enumeration or subrange value was out of range. >>>> RuntimeError: <*ASSERT*> failed. >>>> >>>> >>>> *** >>>> *** runtime error: >>>> *** Segmentation violation - possible attempt to dereference NIL >>>> *** pc = 0x8048a71 = NilMethod + 0x10 in ../src/Main.m3 >>>> *** >>>> >>>> Abort >>>> >>>> Seems to me I ought to see a few more exceptions and not a crash. >>>> >>>> I'm happy to investigate a bit more, but does anyone have a clue >>>> where >>>> to begin? >>>> >>>> Mika From jay.krell at cornell.edu Tue Apr 28 03:50:58 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 01:50:58 +0000 Subject: [M3devel] RuntimeError doesn't work quite as advertised In-Reply-To: <200904280118.n3S1IAQ2021489@camembert.async.caltech.edu> References: Your message of "Mon, 27 Apr 2009 22:23:41 +1000." <7F78EA61-BF67-4C18-85D4-F0CC5B45276A@cs.purdue.edu> <200904280118.n3S1IAQ2021489@camembert.async.caltech.edu> Message-ID: 1) Should we just always use sigsetjmp/siglongjmp? Or, getting the signal mask is much extra expense usually unnecesary? (imagine the case of there being a stack walker, where not even setjmp is paid for) Folks aren't supposed to muck with it willy nilly and should expect raising/catching an exception to restore to that which it was at the point of the try? 2) The inlined NULL checks arounds the "barrier" calls: - Aren't they just bloating the code for the unusual case? - Aren't they better left in the barrier functions themselves? - Besides leading to smaller and therefore faster code (except in the usual case of there being a NULL pointer deref, which is always going to be slow anyway), can't this then double or mostly double for a place to fix this? That is, IF, but I doubt this is true, IF every pointer deref goes through a "barrier" function, the exceptions could be raised from them, right? Are the barrier calls placed adequately maybe????? I don't think they are placed for untraced derefs (a fix Tony recently put in) and I imagine you might want those to act the same as traced null derefs. Maybe a pragma??? - Jay > To: hosking at cs.purdue.edu > Date: Mon, 27 Apr 2009 18:18:10 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RuntimeError doesn't work quite as advertised > > I think it ought to be safe to use siglongjmp. > > So we could attach a sigjmpbuf to whatever structure PushEFrame > builds only when it's doing it for a "RuntimeError", and on a runtime > error that's not handled otherwise, we catch the unix signal and > call siglongjmp to get back to the exception handler... > > Here's an example in C: > > #include > #include > > sigjmp_buf env; > > void handler(int x) { siglongjmp(env,1); } > > main() > { > signal(SIGSEGV, handler); > > if(sigsetjmp(env,1)) { > printf("caught signal\n"); > exit(0); > } else { > printf("initialized env\n"); > } > > { > int *a=(void *)0; > printf("a is %d\n", *a /* SEGV */); > /* not reached */ > } > } > > Mika > > > Tony Hosking writes: > >It's probably not generally safe to use RAISE inside a signal > >handler. There are esoteric rules as to what signal handlers can > >handle... > > > >I think we need to think harder on how best to reflect NIL dereference > >as a signal. Perhaps we need explicit NIL checks after all... > > > >On 27 Apr 2009, at 18:31, Mika Nystrom wrote: > > > >> Ok so I tried the "obvious thing", namely, I changed RTSignal.SegV to > >> do > >> > >> RAISE RuntimeError.E(RuntimeError.T.BadMemoryReference); > >> > >> Somewhat to my surprise, this does the right thing for a null method. > >> But somewhat less surprisingly, it loops for NilJump and NilDeref. > >> Is the machine jumping back and re-executing the same instructions > >> after the signal handler returns? > >> > >> Would all hell break loose if one were to special-case EXCEPT > >> RuntimeError.E to store a thread-local jmp_buf that one does a > >> C-style longjmp to? (With a chain back to any higher RuntimeError.E > >> handlers, I suppose...) Or is there a way to get the exception to > >> work out of the signal handler with the normal exception mechanism? > >> > >> Mika > > > >> Mika Nystrom writes: > >>> > >>> Maybe someone else knows more about this than me... > >>> > >>> The following program: > >>> > >>> MODULE Main; > >>> IMPORT RuntimeError, IO; > >>> > >>> PROCEDURE Range() = BEGIN EVAL VAL(-1,CARDINAL) END Range; > >>> > >>> PROCEDURE Assert() = BEGIN <*ASSERT FALSE*> END Assert; > >>> > >>> PROCEDURE NilJump() = VAR x : PROCEDURE() := NIL; BEGIN x() END > >>> NilJump; > >>> > >>> PROCEDURE NilDeref() = > >>> VAR x : REF INTEGER := NIL; b : INTEGER; > >>> BEGIN b := x^ END NilDeref; > >>> > >>> PROCEDURE NilMethod() = > >>> TYPE T = OBJECT METHODS m() END; > >>> VAR t : T; BEGIN t.m() END NilMethod; > >>> > >>> BEGIN > >>> WITH ps = ARRAY OF PROCEDURE() { Range, Assert, NilMethod, NilJump, > >>> NilDeref } DO > >>> FOR i := FIRST(ps) TO LAST(ps) DO > >>> TRY > >>> ps[i]() > >>> EXCEPT > >>> RuntimeError.E(e) => IO.Put("RuntimeError: " & > >>> RuntimeError.Tag(e) & " \n") > >>> END > >>> END > >>> END > >>> END Main. > >>> > >>> yields the following result: > >>> > >>> (1053)trs80:~/test/src>../FreeBSD4/prog > >>> RuntimeError: An enumeration or subrange value was out of range. > >>> RuntimeError: <*ASSERT*> failed. > >>> > >>> > >>> *** > >>> *** runtime error: > >>> *** Segmentation violation - possible attempt to dereference NIL > >>> *** pc = 0x8048a71 = NilMethod + 0x10 in ../src/Main.m3 > >>> *** > >>> > >>> Abort > >>> > >>> Seems to me I ought to see a few more exceptions and not a crash. > >>> > >>> I'm happy to investigate a bit more, but does anyone have a clue > >>> where > >>> to begin? > >>> > >>> Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Apr 28 04:23:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 28 Apr 2009 12:23:57 +1000 Subject: [M3devel] RuntimeError doesn't work quite as advertised In-Reply-To: References: Your message of "Mon, 27 Apr 2009 22:23:41 +1000." <7F78EA61-BF67-4C18-85D4-F0CC5B45276A@cs.purdue.edu> <200904280118.n3S1IAQ2021489@camembert.async.caltech.edu> Message-ID: On 28 Apr 2009, at 11:50, Jay wrote: > 1) Should we just always use sigsetjmp/siglongjmp? > Or, getting the signal mask is much extra expense usually unnecesary? > (imagine the case of there being a stack walker, where not even > setjmp is paid for) > Folks aren't supposed to muck with it willy nilly and should expect > raising/catching an exception to restore to that which it was at the > point of the try? I would have thought so, yes. I thought I had seen use of setjmp/ longjmp instead of _setjmp/_longjmp but it appears some platforms don't restore signal masks (viz. I386_DARWIN). > 2) The inlined NULL checks arounds the "barrier" calls: > - Aren't they just bloating the code for the unusual case? > - Aren't they better left in the barrier functions themselves? > - Besides leading to smaller and therefore faster code (except in > the usual > case of there being a NULL pointer deref, which is always going to > be slow anyway), > can't this then double or mostly double for a place to fix this? > That is, IF, but I doubt this is true, IF every pointer deref goes > through a "barrier" > function, the exceptions could be raised from them, right The point is that we want to do a fast inline check via non-NIL references, so we need to explicitly check for those. This is not the standard NIL check, since it is legal to load NIL from the heap. There are no exceptions to be raised here. The explicit check for loading NIL is only for loads from the heap. Not for stores to the heap. > ? > > > Are the barrier calls placed adequately maybe????? > I don't think they are placed for untraced derefs (a fix Tony > recently put in) > and I imagine you might want those to act the same as traced null > derefs. > Maybe a pragma??? > > > - Jay > > > > To: hosking at cs.purdue.edu > > Date: Mon, 27 Apr 2009 18:18:10 -0700 > > From: mika at async.caltech.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] RuntimeError doesn't work quite as advertised > > > > I think it ought to be safe to use siglongjmp. > > > > So we could attach a sigjmpbuf to whatever structure PushEFrame > > builds only when it's doing it for a "RuntimeError", and on a > runtime > > error that's not handled otherwise, we catch the unix signal and > > call siglongjmp to get back to the exception handler... > > > > Here's an example in C: > > > > #include > > #include > > > > sigjmp_buf env; > > > > void handler(int x) { siglongjmp(env,1); } > > > > main() > > { > > signal(SIGSEGV, handler); > > > > if(sigsetjmp(env,1)) { > > printf("caught signal\n"); > > exit(0); > > } else { > > printf("initialized env\n"); > > } > > > > { > > int *a=(void *)0; > > printf("a is %d\n", *a /* SEGV */); > > /* not reached */ > > } > > } > > > > Mika > > > > > > Tony Hosking writes: > > >It's probably not generally safe to use RAISE inside a signal > > >handler. There are esoteric rules as to what signal handlers can > > >handle... > > > > > >I think we need to think harder on how best to reflect NIL > dereference > > >as a signal. Perhaps we need explicit NIL checks after all... > > > > > >On 27 Apr 2009, at 18:31, Mika Nystrom wrote: > > > > > >> Ok so I tried the "obvious thing", namely, I changed > RTSignal.SegV to > > >> do > > >> > > >> RAISE RuntimeError.E(RuntimeError.T.BadMemoryReference); > > >> > > >> Somewhat to my surprise, this does the right thing for a null > method. > > >> But somewhat less surprisingly, it loops for NilJump and > NilDeref. > > >> Is the machine jumping back and re-executing the same > instructions > > >> after the signal handler returns? > > >> > > >> Would all hell break loose if one were to special-case EXCEPT > > >> RuntimeError.E to store a thread-local jmp_buf that one does a > > >> C-style longjmp to? (With a chain back to any higher > RuntimeError.E > > >> handlers, I suppose...) Or is there a way to get the exception to > > >> work out of the signal handler with the normal exception > mechanism? > > >> > > >> Mika > > > > > >> Mika Nystrom writes: > > >>> > > >>> Maybe someone else knows more about this than me... > > >>> > > >>> The following program: > > >>> > > >>> MODULE Main; > > >>> IMPORT RuntimeError, IO; > > >>> > > >>> PROCEDURE Range() = BEGIN EVAL VAL(-1,CARDINAL) END Range; > > >>> > > >>> PROCEDURE Assert() = BEGIN <*ASSERT FALSE*> END Assert; > > >>> > > >>> PROCEDURE NilJump() = VAR x : PROCEDURE() := NIL; BEGIN x() END > > >>> NilJump; > > >>> > > >>> PROCEDURE NilDeref() = > > >>> VAR x : REF INTEGER := NIL; b : INTEGER; > > >>> BEGIN b := x^ END NilDeref; > > >>> > > >>> PROCEDURE NilMethod() = > > >>> TYPE T = OBJECT METHODS m() END; > > >>> VAR t : T; BEGIN t.m() END NilMethod; > > >>> > > >>> BEGIN > > >>> WITH ps = ARRAY OF PROCEDURE() { Range, Assert, NilMethod, > NilJump, > > >>> NilDeref } DO > > >>> FOR i := FIRST(ps) TO LAST(ps) DO > > >>> TRY > > >>> ps[i]() > > >>> EXCEPT > > >>> RuntimeError.E(e) => IO.Put("RuntimeError: " & > > >>> RuntimeError.Tag(e) & " \n") > > >>> END > > >>> END > > >>> END > > >>> END Main. > > >>> > > >>> yields the following result: > > >>> > > >>> (1053)trs80:~/test/src>../FreeBSD4/prog > > >>> RuntimeError: An enumeration or subrange value was out of range. > > >>> RuntimeError: <*ASSERT*> failed. > > >>> > > >>> > > >>> *** > > >>> *** runtime error: > > >>> *** Segmentation violation - possible attempt to dereference NIL > > >>> *** pc = 0x8048a71 = NilMethod + 0x10 in ../src/Main.m3 > > >>> *** > > >>> > > >>> Abort > > >>> > > >>> Seems to me I ought to see a few more exceptions and not a > crash. > > >>> > > >>> I'm happy to investigate a bit more, but does anyone have a clue > > >>> where > > >>> to begin? > > >>> > > >>> Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Apr 28 08:29:37 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 28 Apr 2009 08:29:37 +0200 Subject: [M3devel] CM3 release build regression tests not terminating Message-ID: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> Hi, does anybody know what's keeping the release-build tests for tinderbox from terminating? I've got lots of stalled regression process trees on my system, and the tinderbox display indicates that none of the release builds seem to succeed. Has anybody changed anything in the scripts? On a closer look, upgrade seems to be stuck in the installer: % ps -axwww 25310 PID TT STAT TIME COMMAND 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/luthien/current -o Jay, did you change any config files recently? Regression tests seemed to have been running again for some days, and then stopped again. I'll try to investigate further this evening, but must leave now for other work... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Tue Apr 28 08:45:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 28 Apr 2009 16:45:29 +1000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> Message-ID: <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> Yes, I had noticed this too. On 28 Apr 2009, at 16:29, Olaf Wagner wrote: > Hi, > > does anybody know what's keeping the release-build tests for tinderbox > from terminating? I've got lots of stalled regression process trees on > my system, and the tinderbox display indicates that none of the > release > builds seem to succeed. Has anybody changed anything in the scripts? > > On a closer look, upgrade seems to be stuck in the installer: > > % ps -axwww 25310 > PID TT STAT TIME COMMAND > 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ > pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ > luthien/current -o > > Jay, did you change any config files recently? > Regression tests seemed to have been running again for some days, > and then > stopped again. > > I'll try to investigate further this evening, but must leave now for > other work... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From jay.krell at cornell.edu Tue Apr 28 09:45:14 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 07:45:14 +0000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> Message-ID: I've never been able to get the tinderbox stuff to work for me. I'll try again. Nothing much from me lately -- pthreads movement to C, and then back. >> Jay, did you change any config files recently? FreeBSD config file changes on 2009-04-13. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: wagner at elegosoft.com > Date: Tue, 28 Apr 2009 16:45:29 +1000 > CC: m3devel at elegosoft.com; manderson at elegosoft.com > Subject: Re: [M3devel] CM3 release build regression tests not terminating > > Yes, I had noticed this too. > > On 28 Apr 2009, at 16:29, Olaf Wagner wrote: > >> Hi, >> >> does anybody know what's keeping the release-build tests for tinderbox >> from terminating? I've got lots of stalled regression process trees on >> my system, and the tinderbox display indicates that none of the >> release >> builds seem to succeed. Has anybody changed anything in the scripts? >> >> On a closer look, upgrade seems to be stuck in the installer: >> >> % ps -axwww 25310 >> PID TT STAT TIME COMMAND >> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >> luthien/current -o >> >> Jay, did you change any config files recently? >> Regression tests seemed to have been running again for some days, >> and then >> stopped again. >> >> I'll try to investigate further this evening, but must leave now for >> other work... >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >> Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> > From jay.krell at cornell.edu Tue Apr 28 10:03:13 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 08:03:13 +0000 Subject: [M3devel] how to find dependent .so files? Message-ID: Normally we have: /usr/local/cm3/bin/someexe /usr/local/cm3/lib/libfoo.so symlink to ../pkg/foo/target/libfoo.so /usr/local/cm3/lib/libbar.so symlink to ../pkg/bar/target/libbar.so Linking from someexe to $ORIGIN/../lib works, ok. But from libfoo to libbar requires $ORIGIN/../../../lib. or $ORIGIN/../../bar/target. Currently on FreeBSD I set the runpath to $ORIGIN/../lib:$ORIGIN/../../../lib or maybe $ORIGIN/../lib:$ORIGIN/../../lib:$ORIGIN/../../../lib I want to claim this is working, but there are unresolved Tinderbox problems. Let's assume for now it does. I find something as long as "../../.." starts feeling dangerous. It could land somewhere unrelated. I'd prefer a shorter runpath like just $ORIGIN/../lib. To fix this I propose one of two changes. 1) Reverse the symlink relationship: replace /usr/local/cm3/lib/libfoo.so symlink to ../pkg/foo/target/libfoo.so with /usr/local/cm3/lib/libfoo.so real file /usr/local/cm3/pkg/foo/target/libfoo.so symlink to previous This is kind of model changing. There is a package store and all files do really ship into it. Shorter more convenient paths are a higher level construct. I guess. It's a nice model, kind of, but also inconvenient. or 2) Make them hardlinks. Does that work? It seems less model changing. Sort of. It's really extremely similar to previous, except that the package store remains rather self contained. Meanwhile, shipped non-public binaries: /usr/local/cm3/pkg/someexe/target/someexe would would not work. I think they exist though, e.g. obliq. Maybe ship them to /usr/local/cm3/lib? NT386 isn't relevant, so go ahead apply symlinks/hardlinks to the problem pretty arbitrarily I think. There all the .so files (.dll) are in \cm3\bin next to the .exes. The searchpath for .dlls and .exes is roughly the same. NTFS has always had hardlinks. NTFS as of Vista has symlinks. FAT does not have either. Cygwin supports symlinks anywhere via higher level mechanisms (either its own files or usermode Explorer "shortcuts" (think of Mac "aliases")). - Jay From jay.krell at cornell.edu Tue Apr 28 11:14:47 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 09:14:47 +0000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> Message-ID: Well, on FreeBSD 7.0, I get as far as: ew source -> compiling EnvUtils.i3 libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" ew source -> compiling EnvUtils.m3 libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" ew source -> compiling FingerprintFmt.i3 libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" ew source -> compiling TextUtils.i3 libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" Yeah, I understand, I have libc.so.7. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; wagner at elegosoft.com > Date: Tue, 28 Apr 2009 07:45:14 +0000 > CC: m3devel at elegosoft.com; manderson at elegosoft.com > Subject: Re: [M3devel] CM3 release build regression tests not terminating > > > I've never been able to get the tinderbox stuff to work for me. > I'll try again. > Nothing much from me lately -- pthreads movement to C, and then back. > >>> Jay, did you change any config files recently? > > FreeBSD config file changes on 2009-04-13. > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: wagner at elegosoft.com >> Date: Tue, 28 Apr 2009 16:45:29 +1000 >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: Re: [M3devel] CM3 release build regression tests not terminating >> >> Yes, I had noticed this too. >> >> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >> >>> Hi, >>> >>> does anybody know what's keeping the release-build tests for tinderbox >>> from terminating? I've got lots of stalled regression process trees on >>> my system, and the tinderbox display indicates that none of the >>> release >>> builds seem to succeed. Has anybody changed anything in the scripts? >>> >>> On a closer look, upgrade seems to be stuck in the installer: >>> >>> % ps -axwww 25310 >>> PID TT STAT TIME COMMAND >>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>> luthien/current -o >>> >>> Jay, did you change any config files recently? >>> Regression tests seemed to have been running again for some days, >>> and then >>> stopped again. >>> >>> I'll try to investigate further this evening, but must leave now for >>> other work... >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> >> From wagner at elegosoft.com Tue Apr 28 11:40:00 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 28 Apr 2009 11:40:00 +0200 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> Message-ID: <20090428114000.kghi05wbw484cook@mail.elegosoft.com> Quoting Jay : > > Well, on FreeBSD 7.0, I get as far as: > > ew source -> compiling EnvUtils.i3 > libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" > ew source -> compiling EnvUtils.m3 > libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" > ew source -> compiling FingerprintFmt.i3 > libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" > ew source -> compiling TextUtils.i3 > libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" > > Yeah, I understand, I have libc.so.7. You need to install the FreeBSD compat packages for backward compatibility. Should work fine then (until cminstall hangs?). Olaf > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu; wagner at elegosoft.com >> Date: Tue, 28 Apr 2009 07:45:14 +0000 >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: Re: [M3devel] CM3 release build regression tests not terminating >> >> >> I've never been able to get the tinderbox stuff to work for me. >> I'll try again. >> Nothing much from me lately -- pthreads movement to C, and then back. >> >>>> Jay, did you change any config files recently? >> >> FreeBSD config file changes on 2009-04-13. >> >> - Jay >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: wagner at elegosoft.com >>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>> >>> Yes, I had noticed this too. >>> >>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>> >>>> Hi, >>>> >>>> does anybody know what's keeping the release-build tests for tinderbox >>>> from terminating? I've got lots of stalled regression process trees on >>>> my system, and the tinderbox display indicates that none of the >>>> release >>>> builds seem to succeed. Has anybody changed anything in the scripts? >>>> >>>> On a closer look, upgrade seems to be stuck in the installer: >>>> >>>> % ps -axwww 25310 >>>> PID TT STAT TIME COMMAND >>>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>>> luthien/current -o >>>> >>>> Jay, did you change any config files recently? >>>> Regression tests seemed to have been running again for some days, >>>> and then >>>> stopped again. >>>> >>>> I'll try to investigate further this evening, but must leave now for >>>> other work... >>>> >>>> Olaf >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>> Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>> 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>> Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> >>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 28 11:45:32 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 28 Apr 2009 11:45:32 +0200 Subject: [M3devel] Fwd: Modula-2 to Modula-3 translator by Aachen University In-Reply-To: <49F5C0DB.5010409@cox.net> References: <20090427084618.hnk460mh440c880c@mail.elegosoft.com> <49F5C0DB.5010409@cox.net> Message-ID: <20090428114532.sy26ftrzdgc448kw@mail.elegosoft.com> Hi Michael, could you take care of that and host Rodney's archives on birch with public access? If you drop me the URL, I'll insert it into the CM3 and/or modula3.org pages then. Thanks in advance, Olaf Quoting "Rodney M. Bates" : > I have a local copy of it, but haven't built/run it in several years. > I have used it successfully on two or three conversions in the past. > Can we make space at elegosoft? I'm pretty busy moving house now, > but could quickly put my current files up, then try in a couple of > months to see if it has suffered any bitrot. > > Olaf Wagner wrote: >> Perhaps somebody on the public list knows something... >> >> ----- Forwarded message from trijezdci at gmail.com ----- >> Date: Sun, 26 Apr 2009 15:57:36 +0900 >> From: Benjamin Kowarsch >> Reply-To: Benjamin Kowarsch >> Subject: Modula-2 to Modula-3 translator by Aachen University >> To: m3-support at elego.de >> >> Dear Sirs, >> >> I am trying to get the Modula-2 section in the Catalog of Compilers >> updated and there is one entry of a Modula-2 to Modula-3 translator by >> Peter Klein at University of Aachen for which all links and email >> addresses seem to be dead. University of Aachen was unable to give me >> any information either. >> >> I wonder if you know whether this translator is still availabe and if >> so at which URL, or where his author Peter Klein can be contacted. >> >> thank you >> regards >> benjamin >> >> >> ----- End forwarded message ----- >> >> > Rodney Bates > rodney.m.bates at cox.net -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 28 11:58:56 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 09:58:56 +0000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <20090428114000.kghi05wbw484cook@mail.elegosoft.com> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> Message-ID: Right, now it hangs having printed..I know this looks a bit of nonsense..stuff from right around: M3_BACKEND_MODE = "3" % -- defines how the frontend, backend, and assembler interact % "0" -- don't call m3_backend, M3CG produces object code % "1" -- don't call m3_backend, M3CG produces assembly code % "2" -- call m3_backend, it produces object code % "3" -- call m3_backend, it produces assembly code however, this is noticably pretty close to the last BEGIN_CONFIG. Maybe the carriage returns confused it. I'll see.. I did introduce them recently by accident. gdb reported some errors and no symbols in the callstack having connected to it, on FreeBSD. If need be I can try debugging it on another system.. (aside, philosophy: all text processing code should treat \n, \r, and \r\n in put the same, unless you are writing a terminal driver, then \r has a separate meaning useful for implementing spinners..) - Jay ---------------------------------------- > Date: Tue, 28 Apr 2009 11:40:00 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com > Subject: RE: [M3devel] CM3 release build regression tests not terminating > > Quoting Jay : > >> >> Well, on FreeBSD 7.0, I get as far as: >> >> ew source -> compiling EnvUtils.i3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" >> ew source -> compiling EnvUtils.m3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" >> ew source -> compiling FingerprintFmt.i3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" >> ew source -> compiling TextUtils.i3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" >> >> Yeah, I understand, I have libc.so.7. > > You need to install the FreeBSD compat packages for backward > compatibility. Should work fine then (until cminstall hangs?). > > Olaf > >> >> - Jay >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>> >>> >>> I've never been able to get the tinderbox stuff to work for me. >>> I'll try again. >>> Nothing much from me lately -- pthreads movement to C, and then back. >>> >>>>> Jay, did you change any config files recently? >>> >>> FreeBSD config file changes on 2009-04-13. >>> >>> - Jay >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> To: wagner at elegosoft.com >>>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>>> >>>> Yes, I had noticed this too. >>>> >>>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>>> >>>>> Hi, >>>>> >>>>> does anybody know what's keeping the release-build tests for tinderbox >>>>> from terminating? I've got lots of stalled regression process trees on >>>>> my system, and the tinderbox display indicates that none of the >>>>> release >>>>> builds seem to succeed. Has anybody changed anything in the scripts? >>>>> >>>>> On a closer look, upgrade seems to be stuck in the installer: >>>>> >>>>> % ps -axwww 25310 >>>>> PID TT STAT TIME COMMAND >>>>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>>>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>>>> luthien/current -o >>>>> >>>>> Jay, did you change any config files recently? >>>>> Regression tests seemed to have been running again for some days, >>>>> and then >>>>> stopped again. >>>>> >>>>> I'll try to investigate further this evening, but must leave now for >>>>> other work... >>>>> >>>>> Olaf >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>>> Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>> 45 86 95 >>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>>> Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>> DE163214194 >>>>> >>>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 28 12:14:37 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 10:14:37 +0000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <20090428114000.kghi05wbw484cook@mail.elegosoft.com> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> Message-ID: It creates a file named "df-k" and hangs here: (gdb) where #0 0x080f417f in select () #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, writefds=0x28127138, exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/FreeBSD4/select.c:13 #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, M3_CEtG8K_timeout=0xbfbfe6d8) at ThreadPosix.m3:714 #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, M3_AicXUJ_alertable=0 '\0') at ThreadPosix.m3:555 #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at ThreadPosix.m3:539 #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at ProcessPosix.m3:294 #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at System.m3:527 #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, M3_EkfbeH_env=0x0, M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at OSPOSIX.m3:19 #10 0x0804c31c in Main__DoIt () at Main.m3:122 #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at RTLinker.m3:395 #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at RTLinker.m3:109 #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at RTLinker.m3:118 #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at _m3main.mc:4 Notice it using user threads, so old m3core/libm3. df doesn't appear to be any longer running. Why it prints about the backend mode, I don't know. (and yes, I get it -- df -k is directly related to GetDiskSpace..if this is how one checks diskspace on Unix...I think we should punt, unless posix actually specifies the precise output format of this command it is very reliably parsed...) - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com > Subject: RE: [M3devel] CM3 release build regression tests not terminating > Date: Tue, 28 Apr 2009 09:58:56 +0000 > > > Right, now it hangs having printed..I know this looks a bit of nonsense..stuff from right around: > > > M3_BACKEND_MODE = "3" > % -- defines how the frontend, backend, and assembler interact > % "0" -- don't call m3_backend, M3CG produces object code > % "1" -- don't call m3_backend, M3CG produces assembly code > % "2" -- call m3_backend, it produces object code > % "3" -- call m3_backend, it produces assembly code > > > however, this is noticably pretty close to the last BEGIN_CONFIG. > > Maybe the carriage returns confused it. I'll see.. > I did introduce them recently by accident. > gdb reported some errors and no symbols in the callstack having connected to it, on FreeBSD. If need be I can try debugging it on another system.. > > > (aside, philosophy: all text processing code should treat \n, \r, and \r\n in put the same, unless you are writing a terminal driver, then \r has a separate meaning useful for implementing spinners..) > > > - Jay > > > ---------------------------------------- >> Date: Tue, 28 Apr 2009 11:40:00 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: RE: [M3devel] CM3 release build regression tests not terminating >> >> Quoting Jay : >> >>> >>> Well, on FreeBSD 7.0, I get as far as: >>> >>> ew source -> compiling EnvUtils.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" >>> ew source -> compiling EnvUtils.m3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" >>> ew source -> compiling FingerprintFmt.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" >>> ew source -> compiling TextUtils.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "cm3cg" >>> >>> Yeah, I understand, I have libc.so.7. >> >> You need to install the FreeBSD compat packages for backward >> compatibility. Should work fine then (until cminstall hangs?). >> >> Olaf >> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>>> >>>> >>>> I've never been able to get the tinderbox stuff to work for me. >>>> I'll try again. >>>> Nothing much from me lately -- pthreads movement to C, and then back. >>>> >>>>>> Jay, did you change any config files recently? >>>> >>>> FreeBSD config file changes on 2009-04-13. >>>> >>>> - Jay >>>> >>>> ---------------------------------------- >>>>> From: hosking at cs.purdue.edu >>>>> To: wagner at elegosoft.com >>>>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>>>> >>>>> Yes, I had noticed this too. >>>>> >>>>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> does anybody know what's keeping the release-build tests for tinderbox >>>>>> from terminating? I've got lots of stalled regression process trees on >>>>>> my system, and the tinderbox display indicates that none of the >>>>>> release >>>>>> builds seem to succeed. Has anybody changed anything in the scripts? >>>>>> >>>>>> On a closer look, upgrade seems to be stuck in the installer: >>>>>> >>>>>> % ps -axwww 25310 >>>>>> PID TT STAT TIME COMMAND >>>>>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>>>>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>>>>> luthien/current -o >>>>>> >>>>>> Jay, did you change any config files recently? >>>>>> Regression tests seemed to have been running again for some days, >>>>>> and then >>>>>> stopped again. >>>>>> >>>>>> I'll try to investigate further this evening, but must leave now for >>>>>> other work... >>>>>> >>>>>> Olaf >>>>>> -- >>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>>>> Germany >>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>>> 45 86 95 >>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>>>> Berlin >>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>> DE163214194 >>>>>> >>>>> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 28 12:48:55 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 28 Apr 2009 12:48:55 +0200 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> Message-ID: <20090428124855.paxjik1misgc00ow@mail.elegosoft.com> Quoting Jay : > > It creates a file named "df-k" and hangs here: > > (gdb) where > #0 0x080f417f in select () > #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, writefds=0x28127138, > exceptfds=0x28127148, timeout=0xbfbfe6d8) at > ../src/runtime/FreeBSD4/select.c:13 > #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, > M3_CEtG8K_timeout=0xbfbfe6d8) > at ThreadPosix.m3:714 > #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 > #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, > M3_AicXUJ_alertable=0 '\0') > at ThreadPosix.m3:555 > #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at > ThreadPosix.m3:539 > #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at > ProcessPosix.m3:294 > #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at System.m3:527 > #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, > M3_EkfbeH_env=0x0, > M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 > #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at > OSPOSIX.m3:19 > #10 0x0804c31c in Main__DoIt () at Main.m3:122 > #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 > #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at > RTLinker.m3:395 > #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at > RTLinker.m3:109 > #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at > RTLinker.m3:118 > #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at > _m3main.mc:4 > > Notice it using user threads, so old m3core/libm3. > df doesn't appear to be any longer running. > Why it prints about the backend mode, I don't know. > > (and yes, I get it -- df -k is directly related to GetDiskSpace..if > this is how one checks diskspace on Unix...I think we should punt, > unless posix actually specifies the precise output format of this > command it is very reliably parsed...) You mean it's trying to _read_ df-k, which should have been created by the packaging scripts? If so, it's my fault; it should not try to read a file that isn't there. Or do you really mean it's hanging when trying to create that file? Creating df-k should be pretty straight forward on any POSIX system, as long as the file system isn't corrupt. Olaf > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: RE: [M3devel] CM3 release build regression tests not terminating >> Date: Tue, 28 Apr 2009 09:58:56 +0000 >> >> >> Right, now it hangs having printed..I know this looks a bit of >> nonsense..stuff from right around: >> >> >> M3_BACKEND_MODE = "3" >> % -- defines how the frontend, backend, and assembler interact >> % "0" -- don't call m3_backend, M3CG produces object code >> % "1" -- don't call m3_backend, M3CG produces assembly code >> % "2" -- call m3_backend, it produces object code >> % "3" -- call m3_backend, it produces assembly code >> >> >> however, this is noticably pretty close to the last BEGIN_CONFIG. >> >> Maybe the carriage returns confused it. I'll see.. >> I did introduce them recently by accident. >> gdb reported some errors and no symbols in the callstack having >> connected to it, on FreeBSD. If need be I can try debugging it on >> another system.. >> >> >> (aside, philosophy: all text processing code should treat \n, \r, >> and \r\n in put the same, unless you are writing a terminal driver, >> then \r has a separate meaning useful for implementing spinners..) >> >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Tue, 28 Apr 2009 11:40:00 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: RE: [M3devel] CM3 release build regression tests not terminating >>> >>> Quoting Jay : >>> >>>> >>>> Well, on FreeBSD 7.0, I get as far as: >>>> >>>> ew source -> compiling EnvUtils.i3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> ew source -> compiling EnvUtils.m3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> ew source -> compiling FingerprintFmt.i3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> ew source -> compiling TextUtils.i3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> >>>> Yeah, I understand, I have libc.so.7. >>> >>> You need to install the FreeBSD compat packages for backward >>> compatibility. Should work fine then (until cminstall hangs?). >>> >>> Olaf >>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>>>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>>>> >>>>> >>>>> I've never been able to get the tinderbox stuff to work for me. >>>>> I'll try again. >>>>> Nothing much from me lately -- pthreads movement to C, and then back. >>>>> >>>>>>> Jay, did you change any config files recently? >>>>> >>>>> FreeBSD config file changes on 2009-04-13. >>>>> >>>>> - Jay >>>>> >>>>> ---------------------------------------- >>>>>> From: hosking at cs.purdue.edu >>>>>> To: wagner at elegosoft.com >>>>>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>>> terminating >>>>>> >>>>>> Yes, I had noticed this too. >>>>>> >>>>>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> does anybody know what's keeping the release-build tests for tinderbox >>>>>>> from terminating? I've got lots of stalled regression process trees on >>>>>>> my system, and the tinderbox display indicates that none of the >>>>>>> release >>>>>>> builds seem to succeed. Has anybody changed anything in the scripts? >>>>>>> >>>>>>> On a closer look, upgrade seems to be stuck in the installer: >>>>>>> >>>>>>> % ps -axwww 25310 >>>>>>> PID TT STAT TIME COMMAND >>>>>>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>>>>>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>>>>>> luthien/current -o >>>>>>> >>>>>>> Jay, did you change any config files recently? >>>>>>> Regression tests seemed to have been running again for some days, >>>>>>> and then >>>>>>> stopped again. >>>>>>> >>>>>>> I'll try to investigate further this evening, but must leave now for >>>>>>> other work... >>>>>>> >>>>>>> Olaf >>>>>>> -- >>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>>>>> Germany >>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>>>>>> 45 86 95 >>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>>>>> Berlin >>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>>> DE163214194 >>>>>>> >>>>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From michael.anderson at elego.de Tue Apr 28 12:58:00 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Tue, 28 Apr 2009 12:58:00 +0200 Subject: [M3devel] Fwd: Modula-2 to Modula-3 translator by Aachen University In-Reply-To: <20090428114532.sy26ftrzdgc448kw@mail.elegosoft.com> References: <20090427084618.hnk460mh440c880c@mail.elegosoft.com> <49F5C0DB.5010409@cox.net> <20090428114532.sy26ftrzdgc448kw@mail.elegosoft.com> Message-ID: <20090428125800.4y2x5a4m8kk4ssoo@mail.elegosoft.com> Hi Rodney, If you'd like to upload the archives to birch:/var/www/m2tom3/ , I'll get a public area set up for them. Cheers, -Mike Zitat von Olaf Wagner : > Hi Michael, > > could you take care of that and host Rodney's archives on birch > with public access? If you drop me the URL, I'll insert it into > the CM3 and/or modula3.org pages then. > > Thanks in advance, > > Olaf > > Quoting "Rodney M. Bates" : > >> I have a local copy of it, but haven't built/run it in several years. >> I have used it successfully on two or three conversions in the past. >> Can we make space at elegosoft? I'm pretty busy moving house now, >> but could quickly put my current files up, then try in a couple of >> months to see if it has suffered any bitrot. >> >> Olaf Wagner wrote: >>> Perhaps somebody on the public list knows something... >>> >>> ----- Forwarded message from trijezdci at gmail.com ----- >>> Date: Sun, 26 Apr 2009 15:57:36 +0900 >>> From: Benjamin Kowarsch >>> Reply-To: Benjamin Kowarsch >>> Subject: Modula-2 to Modula-3 translator by Aachen University >>> To: m3-support at elego.de >>> >>> Dear Sirs, >>> >>> I am trying to get the Modula-2 section in the Catalog of Compilers >>> updated and there is one entry of a Modula-2 to Modula-3 translator by >>> Peter Klein at University of Aachen for which all links and email >>> addresses seem to be dead. University of Aachen was unable to give me >>> any information either. >>> >>> I wonder if you know whether this translator is still availabe and if >>> so at which URL, or where his author Peter Klein can be contacted. >>> >>> thank you >>> regards >>> benjamin >>> >>> >>> ----- End forwarded message ----- >>> >>> >> Rodney Bates >> rodney.m.bates at cox.net > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From hosking at cs.purdue.edu Tue Apr 28 13:11:42 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 28 Apr 2009 21:11:42 +1000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> Message-ID: <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> What could possibly have changed here. It used to work fine on multiple platforms. On 28 Apr 2009, at 20:14, Jay wrote: > > It creates a file named "df-k" and hangs here: > > (gdb) where > #0 0x080f417f in select () > #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, > writefds=0x28127138, > exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ > FreeBSD4/select.c:13 > #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, > M3_CEtG8K_timeout=0xbfbfe6d8) > at ThreadPosix.m3:714 > #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 > #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, > M3_AicXUJ_alertable=0 '\0') > at ThreadPosix.m3:555 > #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at > ThreadPosix.m3:539 > #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at > ProcessPosix.m3:294 > #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at > System.m3:527 > #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, > M3_EkfbeH_env=0x0, > M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 > #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at > OSPOSIX.m3:19 > #10 0x0804c31c in Main__DoIt () at Main.m3:122 > #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 > #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at > RTLinker.m3:395 > #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at > RTLinker.m3:109 > #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at > RTLinker.m3:118 > #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at > _m3main.mc:4 > > Notice it using user threads, so old m3core/libm3. > df doesn't appear to be any longer running. > Why it prints about the backend mode, I don't know. > > (and yes, I get it -- df -k is directly related to GetDiskSpace..if > this is how one checks diskspace on Unix...I think we should punt, > unless posix actually specifies the precise output format of this > command it is very reliably parsed...) > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: RE: [M3devel] CM3 release build regression tests not >> terminating >> Date: Tue, 28 Apr 2009 09:58:56 +0000 >> >> >> Right, now it hangs having printed..I know this looks a bit of >> nonsense..stuff from right around: >> >> >> M3_BACKEND_MODE = "3" >> % -- defines how the frontend, backend, and assembler interact >> % "0" -- don't call m3_backend, M3CG produces object code >> % "1" -- don't call m3_backend, M3CG produces assembly code >> % "2" -- call m3_backend, it produces object code >> % "3" -- call m3_backend, it produces assembly code >> >> >> however, this is noticably pretty close to the last BEGIN_CONFIG. >> >> Maybe the carriage returns confused it. I'll see.. >> I did introduce them recently by accident. >> gdb reported some errors and no symbols in the callstack having >> connected to it, on FreeBSD. If need be I can try debugging it on >> another system.. >> >> >> (aside, philosophy: all text processing code should treat \n, \r, >> and \r\n in put the same, unless you are writing a terminal driver, >> then \r has a separate meaning useful for implementing spinners..) >> >> >> - Jay >> >> >> ---------------------------------------- >>> Date: Tue, 28 Apr 2009 11:40:00 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: RE: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> Quoting Jay : >>> >>>> >>>> Well, on FreeBSD 7.0, I get as far as: >>>> >>>> ew source -> compiling EnvUtils.i3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> ew source -> compiling EnvUtils.m3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> ew source -> compiling FingerprintFmt.i3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> ew source -> compiling TextUtils.i3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> >>>> Yeah, I understand, I have libc.so.7. >>> >>> You need to install the FreeBSD compat packages for backward >>> compatibility. Should work fine then (until cminstall hangs?). >>> >>> Olaf >>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>>>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>> terminating >>>>> >>>>> >>>>> I've never been able to get the tinderbox stuff to work for me. >>>>> I'll try again. >>>>> Nothing much from me lately -- pthreads movement to C, and then >>>>> back. >>>>> >>>>>>> Jay, did you change any config files recently? >>>>> >>>>> FreeBSD config file changes on 2009-04-13. >>>>> >>>>> - Jay >>>>> >>>>> ---------------------------------------- >>>>>> From: hosking at cs.purdue.edu >>>>>> To: wagner at elegosoft.com >>>>>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>>> terminating >>>>>> >>>>>> Yes, I had noticed this too. >>>>>> >>>>>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> does anybody know what's keeping the release-build tests for >>>>>>> tinderbox >>>>>>> from terminating? I've got lots of stalled regression process >>>>>>> trees on >>>>>>> my system, and the tinderbox display indicates that none of the >>>>>>> release >>>>>>> builds seem to succeed. Has anybody changed anything in the >>>>>>> scripts? >>>>>>> >>>>>>> On a closer look, upgrade seems to be stuck in the installer: >>>>>>> >>>>>>> % ps -axwww 25310 >>>>>>> PID TT STAT TIME COMMAND >>>>>>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>>>>>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>>>>>> luthien/current -o >>>>>>> >>>>>>> Jay, did you change any config files recently? >>>>>>> Regression tests seemed to have been running again for some >>>>>>> days, >>>>>>> and then >>>>>>> stopped again. >>>>>>> >>>>>>> I'll try to investigate further this evening, but must leave >>>>>>> now for >>>>>>> other work... >>>>>>> >>>>>>> Olaf >>>>>>> -- >>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>>>>> Germany >>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>>> 23 >>>>>>> 45 86 95 >>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>>>>> Berlin >>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>>> DE163214194 >>>>>>> >>>>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 28 13:17:29 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 11:17:29 +0000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> Message-ID: The changes went in two weeks ago 4/14, were they definitely working? I can try it again, hopefully without the full tinderbox stuff. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 28 Apr 2009 21:11:42 +1000 > CC: m3devel at elegosoft.com; manderson at elegosoft.com > Subject: Re: [M3devel] CM3 release build regression tests not terminating > > What could possibly have changed here. It used to work fine on > multiple platforms. > > On 28 Apr 2009, at 20:14, Jay wrote: > >> >> It creates a file named "df-k" and hangs here: >> >> (gdb) where >> #0 0x080f417f in select () >> #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, >> writefds=0x28127138, >> exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ >> FreeBSD4/select.c:13 >> #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, >> M3_CEtG8K_timeout=0xbfbfe6d8) >> at ThreadPosix.m3:714 >> #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 >> #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, >> M3_AicXUJ_alertable=0 '\0') >> at ThreadPosix.m3:555 >> #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at >> ThreadPosix.m3:539 >> #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at >> ProcessPosix.m3:294 >> #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at >> System.m3:527 >> #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, >> M3_EkfbeH_env=0x0, >> M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 >> #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at >> OSPOSIX.m3:19 >> #10 0x0804c31c in Main__DoIt () at Main.m3:122 >> #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 >> #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at >> RTLinker.m3:395 >> #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at >> RTLinker.m3:109 >> #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at >> RTLinker.m3:118 >> #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at >> _m3main.mc:4 >> >> Notice it using user threads, so old m3core/libm3. >> df doesn't appear to be any longer running. >> Why it prints about the backend mode, I don't know. >> >> (and yes, I get it -- df -k is directly related to GetDiskSpace..if >> this is how one checks diskspace on Unix...I think we should punt, >> unless posix actually specifies the precise output format of this >> command it is very reliably parsed...) >> >> - Jay >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com >>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: RE: [M3devel] CM3 release build regression tests not >>> terminating >>> Date: Tue, 28 Apr 2009 09:58:56 +0000 >>> >>> >>> Right, now it hangs having printed..I know this looks a bit of >>> nonsense..stuff from right around: >>> >>> >>> M3_BACKEND_MODE = "3" >>> % -- defines how the frontend, backend, and assembler interact >>> % "0" -- don't call m3_backend, M3CG produces object code >>> % "1" -- don't call m3_backend, M3CG produces assembly code >>> % "2" -- call m3_backend, it produces object code >>> % "3" -- call m3_backend, it produces assembly code >>> >>> >>> however, this is noticably pretty close to the last BEGIN_CONFIG. >>> >>> Maybe the carriage returns confused it. I'll see.. >>> I did introduce them recently by accident. >>> gdb reported some errors and no symbols in the callstack having >>> connected to it, on FreeBSD. If need be I can try debugging it on >>> another system.. >>> >>> >>> (aside, philosophy: all text processing code should treat \n, \r, >>> and \r\n in put the same, unless you are writing a terminal driver, >>> then \r has a separate meaning useful for implementing spinners..) >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> Date: Tue, 28 Apr 2009 11:40:00 +0200 >>>> From: wagner at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>>> Subject: RE: [M3devel] CM3 release build regression tests not >>>> terminating >>>> >>>> Quoting Jay : >>>> >>>>> >>>>> Well, on FreeBSD 7.0, I get as far as: >>>>> >>>>> ew source -> compiling EnvUtils.i3 >>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>> required by "cm3cg" >>>>> ew source -> compiling EnvUtils.m3 >>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>> required by "cm3cg" >>>>> ew source -> compiling FingerprintFmt.i3 >>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>> required by "cm3cg" >>>>> ew source -> compiling TextUtils.i3 >>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>> required by "cm3cg" >>>>> >>>>> Yeah, I understand, I have libc.so.7. >>>> >>>> You need to install the FreeBSD compat packages for backward >>>> compatibility. Should work fine then (until cminstall hangs?). >>>> >>>> Olaf >>>> >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>>>>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>>> terminating >>>>>> >>>>>> >>>>>> I've never been able to get the tinderbox stuff to work for me. >>>>>> I'll try again. >>>>>> Nothing much from me lately -- pthreads movement to C, and then >>>>>> back. >>>>>> >>>>>>>> Jay, did you change any config files recently? >>>>>> >>>>>> FreeBSD config file changes on 2009-04-13. >>>>>> >>>>>> - Jay >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: hosking at cs.purdue.edu >>>>>>> To: wagner at elegosoft.com >>>>>>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>>>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>>>> terminating >>>>>>> >>>>>>> Yes, I had noticed this too. >>>>>>> >>>>>>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> does anybody know what's keeping the release-build tests for >>>>>>>> tinderbox >>>>>>>> from terminating? I've got lots of stalled regression process >>>>>>>> trees on >>>>>>>> my system, and the tinderbox display indicates that none of the >>>>>>>> release >>>>>>>> builds seem to succeed. Has anybody changed anything in the >>>>>>>> scripts? >>>>>>>> >>>>>>>> On a closer look, upgrade seems to be stuck in the installer: >>>>>>>> >>>>>>>> % ps -axwww 25310 >>>>>>>> PID TT STAT TIME COMMAND >>>>>>>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>>>>>>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>>>>>>> luthien/current -o >>>>>>>> >>>>>>>> Jay, did you change any config files recently? >>>>>>>> Regression tests seemed to have been running again for some >>>>>>>> days, >>>>>>>> and then >>>>>>>> stopped again. >>>>>>>> >>>>>>>> I'll try to investigate further this evening, but must leave >>>>>>>> now for >>>>>>>> other work... >>>>>>>> >>>>>>>> Olaf >>>>>>>> -- >>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>>>>>> Germany >>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>>>> 23 >>>>>>>> 45 86 95 >>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>>>>>> Berlin >>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>>>> DE163214194 >>>>>>>> >>>>>>> >>>> >>>> >>>> >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 28 13:43:40 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 11:43:40 +0000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> Message-ID: Just a reminder, I THINK the hang is almost entirely in a 5.4 system. At least it is in m3core 5.4. And current sysutils/cminstall. And probably 5.4 cm3cg but I don't know for certain yet. Look at the stack below. Do we really care? I haven't tested if it hangs against current compiler/runtime. Here is a suggestion -- ok, bootstrapping from 5.4 is reasonable -- build the compiler -- but must tinderbox include running cminstall build against 5.4? I could be wrong, misobserving, whatever. I can go and fix user threads and see if cminstall hangs with that -- there is an issue of being inefficient wrt waitpid(nohang vs. 0). It is very easy to reproduce. Install 5.4 (which tinderbox does). Do a normal bootstrap thing -- skip m3core, libm3, but otherwise build up to cminstall. And then gdb --args cminstall -dumpcfg wait a sec, control-c. I'm assuming, but haven't tested, that it works ok against current. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com; manderson at elegosoft.com > Subject: RE: [M3devel] CM3 release build regression tests not terminating > Date: Tue, 28 Apr 2009 11:17:29 +0000 > > > The changes went in two weeks ago 4/14, were they definitely working? > I can try it again, hopefully without the full tinderbox stuff. > > - Jay > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Tue, 28 Apr 2009 21:11:42 +1000 >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: Re: [M3devel] CM3 release build regression tests not terminating >> >> What could possibly have changed here. It used to work fine on >> multiple platforms. >> >> On 28 Apr 2009, at 20:14, Jay wrote: >> >>> >>> It creates a file named "df-k" and hangs here: >>> >>> (gdb) where >>> #0 0x080f417f in select () >>> #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, >>> writefds=0x28127138, >>> exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ >>> FreeBSD4/select.c:13 >>> #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, >>> M3_CEtG8K_timeout=0xbfbfe6d8) >>> at ThreadPosix.m3:714 >>> #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 >>> #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, >>> M3_AicXUJ_alertable=0 '\0') >>> at ThreadPosix.m3:555 >>> #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at >>> ThreadPosix.m3:539 >>> #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at >>> ProcessPosix.m3:294 >>> #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at >>> System.m3:527 >>> #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, >>> M3_EkfbeH_env=0x0, >>> M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 >>> #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at >>> OSPOSIX.m3:19 >>> #10 0x0804c31c in Main__DoIt () at Main.m3:122 >>> #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 >>> #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at >>> RTLinker.m3:395 >>> #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at >>> RTLinker.m3:109 >>> #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at >>> RTLinker.m3:118 >>> #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at >>> _m3main.mc:4 >>> >>> Notice it using user threads, so old m3core/libm3. >>> df doesn't appear to be any longer running. >>> Why it prints about the backend mode, I don't know. >>> >>> (and yes, I get it -- df -k is directly related to GetDiskSpace..if >>> this is how one checks diskspace on Unix...I think we should punt, >>> unless posix actually specifies the precise output format of this >>> command it is very reliably parsed...) >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: wagner at elegosoft.com >>>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>>> Subject: RE: [M3devel] CM3 release build regression tests not >>>> terminating >>>> Date: Tue, 28 Apr 2009 09:58:56 +0000 >>>> >>>> >>>> Right, now it hangs having printed..I know this looks a bit of >>>> nonsense..stuff from right around: >>>> >>>> >>>> M3_BACKEND_MODE = "3" >>>> % -- defines how the frontend, backend, and assembler interact >>>> % "0" -- don't call m3_backend, M3CG produces object code >>>> % "1" -- don't call m3_backend, M3CG produces assembly code >>>> % "2" -- call m3_backend, it produces object code >>>> % "3" -- call m3_backend, it produces assembly code >>>> >>>> >>>> however, this is noticably pretty close to the last BEGIN_CONFIG. >>>> >>>> Maybe the carriage returns confused it. I'll see.. >>>> I did introduce them recently by accident. >>>> gdb reported some errors and no symbols in the callstack having >>>> connected to it, on FreeBSD. If need be I can try debugging it on >>>> another system.. >>>> >>>> >>>> (aside, philosophy: all text processing code should treat \n, \r, >>>> and \r\n in put the same, unless you are writing a terminal driver, >>>> then \r has a separate meaning useful for implementing spinners..) >>>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> Date: Tue, 28 Apr 2009 11:40:00 +0200 >>>>> From: wagner at elegosoft.com >>>>> To: jay.krell at cornell.edu >>>>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>>>> Subject: RE: [M3devel] CM3 release build regression tests not >>>>> terminating >>>>> >>>>> Quoting Jay : >>>>> >>>>>> >>>>>> Well, on FreeBSD 7.0, I get as far as: >>>>>> >>>>>> ew source -> compiling EnvUtils.i3 >>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>> required by "cm3cg" >>>>>> ew source -> compiling EnvUtils.m3 >>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>> required by "cm3cg" >>>>>> ew source -> compiling FingerprintFmt.i3 >>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>> required by "cm3cg" >>>>>> ew source -> compiling TextUtils.i3 >>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>> required by "cm3cg" >>>>>> >>>>>> Yeah, I understand, I have libc.so.7. >>>>> >>>>> You need to install the FreeBSD compat packages for backward >>>>> compatibility. Should work fine then (until cminstall hangs?). >>>>> >>>>> Olaf >>>>> >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>>>>>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>>>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>>>> terminating >>>>>>> >>>>>>> >>>>>>> I've never been able to get the tinderbox stuff to work for me. >>>>>>> I'll try again. >>>>>>> Nothing much from me lately -- pthreads movement to C, and then >>>>>>> back. >>>>>>> >>>>>>>>> Jay, did you change any config files recently? >>>>>>> >>>>>>> FreeBSD config file changes on 2009-04-13. >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: hosking at cs.purdue.edu >>>>>>>> To: wagner at elegosoft.com >>>>>>>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>>>>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>>>>> terminating >>>>>>>> >>>>>>>> Yes, I had noticed this too. >>>>>>>> >>>>>>>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> does anybody know what's keeping the release-build tests for >>>>>>>>> tinderbox >>>>>>>>> from terminating? I've got lots of stalled regression process >>>>>>>>> trees on >>>>>>>>> my system, and the tinderbox display indicates that none of the >>>>>>>>> release >>>>>>>>> builds seem to succeed. Has anybody changed anything in the >>>>>>>>> scripts? >>>>>>>>> >>>>>>>>> On a closer look, upgrade seems to be stuck in the installer: >>>>>>>>> >>>>>>>>> % ps -axwww 25310 >>>>>>>>> PID TT STAT TIME COMMAND >>>>>>>>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>>>>>>>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>>>>>>>> luthien/current -o >>>>>>>>> >>>>>>>>> Jay, did you change any config files recently? >>>>>>>>> Regression tests seemed to have been running again for some >>>>>>>>> days, >>>>>>>>> and then >>>>>>>>> stopped again. >>>>>>>>> >>>>>>>>> I'll try to investigate further this evening, but must leave >>>>>>>>> now for >>>>>>>>> other work... >>>>>>>>> >>>>>>>>> Olaf >>>>>>>>> -- >>>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>>>>>>> Germany >>>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>>>>> 23 >>>>>>>>> 45 86 95 >>>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>>>>>>> Berlin >>>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>>>>> DE163214194 >>>>>>>>> >>>>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 28 13:45:43 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 11:45:43 +0000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> Message-ID: once you control-c in gdb it completes with an error the df-k file is zero length.. I can poke more... but I doubt we care about the 5.4 mix.. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Tue, 28 Apr 2009 11:43:40 +0000 > CC: m3devel at elegosoft.com; manderson at elegosoft.com > Subject: Re: [M3devel] CM3 release build regression tests not terminating > > > Just a reminder, I THINK the hang is almost entirely in a 5.4 system. > At least it is in m3core 5.4. > And current sysutils/cminstall. > And probably 5.4 cm3cg but I don't know for certain yet. > Look at the stack below. > Do we really care? > > > I haven't tested if it hangs against current compiler/runtime. > > > Here is a suggestion -- ok, bootstrapping from 5.4 is reasonable -- build the compiler -- but must tinderbox include running cminstall build against 5.4? > > > I could be wrong, misobserving, whatever. > I can go and fix user threads and see if cminstall hangs with that -- there is an issue of being inefficient wrt waitpid(nohang vs. 0). > > > It is very easy to reproduce. > Install 5.4 (which tinderbox does). > Do a normal bootstrap thing -- skip m3core, libm3, but otherwise build up to cminstall. And then gdb --args cminstall -dumpcfg wait a sec, control-c. > > I'm assuming, but haven't tested, that it works ok against current. > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: RE: [M3devel] CM3 release build regression tests not terminating >> Date: Tue, 28 Apr 2009 11:17:29 +0000 >> >> >> The changes went in two weeks ago 4/14, were they definitely working? >> I can try it again, hopefully without the full tinderbox stuff. >> >> - Jay >> >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Tue, 28 Apr 2009 21:11:42 +1000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>> >>> What could possibly have changed here. It used to work fine on >>> multiple platforms. >>> >>> On 28 Apr 2009, at 20:14, Jay wrote: >>> >>>> >>>> It creates a file named "df-k" and hangs here: >>>> >>>> (gdb) where >>>> #0 0x080f417f in select () >>>> #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, >>>> writefds=0x28127138, >>>> exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ >>>> FreeBSD4/select.c:13 >>>> #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, >>>> M3_CEtG8K_timeout=0xbfbfe6d8) >>>> at ThreadPosix.m3:714 >>>> #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 >>>> #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, >>>> M3_AicXUJ_alertable=0 '\0') >>>> at ThreadPosix.m3:555 >>>> #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at >>>> ThreadPosix.m3:539 >>>> #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at >>>> ProcessPosix.m3:294 >>>> #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at >>>> System.m3:527 >>>> #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, >>>> M3_EkfbeH_env=0x0, >>>> M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 >>>> #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at >>>> OSPOSIX.m3:19 >>>> #10 0x0804c31c in Main__DoIt () at Main.m3:122 >>>> #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 >>>> #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at >>>> RTLinker.m3:395 >>>> #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at >>>> RTLinker.m3:109 >>>> #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at >>>> RTLinker.m3:118 >>>> #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at >>>> _m3main.mc:4 >>>> >>>> Notice it using user threads, so old m3core/libm3. >>>> df doesn't appear to be any longer running. >>>> Why it prints about the backend mode, I don't know. >>>> >>>> (and yes, I get it -- df -k is directly related to GetDiskSpace..if >>>> this is how one checks diskspace on Unix...I think we should punt, >>>> unless posix actually specifies the precise output format of this >>>> command it is very reliably parsed...) >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: wagner at elegosoft.com >>>>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>>>> Subject: RE: [M3devel] CM3 release build regression tests not >>>>> terminating >>>>> Date: Tue, 28 Apr 2009 09:58:56 +0000 >>>>> >>>>> >>>>> Right, now it hangs having printed..I know this looks a bit of >>>>> nonsense..stuff from right around: >>>>> >>>>> >>>>> M3_BACKEND_MODE = "3" >>>>> % -- defines how the frontend, backend, and assembler interact >>>>> % "0" -- don't call m3_backend, M3CG produces object code >>>>> % "1" -- don't call m3_backend, M3CG produces assembly code >>>>> % "2" -- call m3_backend, it produces object code >>>>> % "3" -- call m3_backend, it produces assembly code >>>>> >>>>> >>>>> however, this is noticably pretty close to the last BEGIN_CONFIG. >>>>> >>>>> Maybe the carriage returns confused it. I'll see.. >>>>> I did introduce them recently by accident. >>>>> gdb reported some errors and no symbols in the callstack having >>>>> connected to it, on FreeBSD. If need be I can try debugging it on >>>>> another system.. >>>>> >>>>> >>>>> (aside, philosophy: all text processing code should treat \n, \r, >>>>> and \r\n in put the same, unless you are writing a terminal driver, >>>>> then \r has a separate meaning useful for implementing spinners..) >>>>> >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ---------------------------------------- >>>>>> Date: Tue, 28 Apr 2009 11:40:00 +0200 >>>>>> From: wagner at elegosoft.com >>>>>> To: jay.krell at cornell.edu >>>>>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>>>>> Subject: RE: [M3devel] CM3 release build regression tests not >>>>>> terminating >>>>>> >>>>>> Quoting Jay : >>>>>> >>>>>>> >>>>>>> Well, on FreeBSD 7.0, I get as far as: >>>>>>> >>>>>>> ew source -> compiling EnvUtils.i3 >>>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>>> required by "cm3cg" >>>>>>> ew source -> compiling EnvUtils.m3 >>>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>>> required by "cm3cg" >>>>>>> ew source -> compiling FingerprintFmt.i3 >>>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>>> required by "cm3cg" >>>>>>> ew source -> compiling TextUtils.i3 >>>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>>> required by "cm3cg" >>>>>>> >>>>>>> Yeah, I understand, I have libc.so.7. >>>>>> >>>>>> You need to install the FreeBSD compat packages for backward >>>>>> compatibility. Should work fine then (until cminstall hangs?). >>>>>> >>>>>> Olaf >>>>>> >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: jay.krell at cornell.edu >>>>>>>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>>>>>>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>>>>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>>>>> terminating >>>>>>>> >>>>>>>> >>>>>>>> I've never been able to get the tinderbox stuff to work for me. >>>>>>>> I'll try again. >>>>>>>> Nothing much from me lately -- pthreads movement to C, and then >>>>>>>> back. >>>>>>>> >>>>>>>>>> Jay, did you change any config files recently? >>>>>>>> >>>>>>>> FreeBSD config file changes on 2009-04-13. >>>>>>>> >>>>>>>> - Jay >>>>>>>> >>>>>>>> ---------------------------------------- >>>>>>>>> From: hosking at cs.purdue.edu >>>>>>>>> To: wagner at elegosoft.com >>>>>>>>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>>>>>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>>>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>>>>>> terminating >>>>>>>>> >>>>>>>>> Yes, I had noticed this too. >>>>>>>>> >>>>>>>>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> does anybody know what's keeping the release-build tests for >>>>>>>>>> tinderbox >>>>>>>>>> from terminating? I've got lots of stalled regression process >>>>>>>>>> trees on >>>>>>>>>> my system, and the tinderbox display indicates that none of the >>>>>>>>>> release >>>>>>>>>> builds seem to succeed. Has anybody changed anything in the >>>>>>>>>> scripts? >>>>>>>>>> >>>>>>>>>> On a closer look, upgrade seems to be stuck in the installer: >>>>>>>>>> >>>>>>>>>> % ps -axwww 25310 >>>>>>>>>> PID TT STAT TIME COMMAND >>>>>>>>>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>>>>>>>>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>>>>>>>>> luthien/current -o >>>>>>>>>> >>>>>>>>>> Jay, did you change any config files recently? >>>>>>>>>> Regression tests seemed to have been running again for some >>>>>>>>>> days, >>>>>>>>>> and then >>>>>>>>>> stopped again. >>>>>>>>>> >>>>>>>>>> I'll try to investigate further this evening, but must leave >>>>>>>>>> now for >>>>>>>>>> other work... >>>>>>>>>> >>>>>>>>>> Olaf >>>>>>>>>> -- >>>>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>>>>>>>> Germany >>>>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>>>>>> 23 >>>>>>>>>> 45 86 95 >>>>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>>>>>>>> Berlin >>>>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>>>>>>> DE163214194 >>>>>>>>>> >>>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 28 13:49:32 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 28 Apr 2009 21:49:32 +1000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> Message-ID: <9AC96562-7045-418A-A069-84EE8613498A@cs.purdue.edu> Sounds about right. 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 28 Apr 2009, at 21:17, Jay wrote: > > The changes went in two weeks ago 4/14, were they definitely working? > I can try it again, hopefully without the full tinderbox stuff. > > - Jay > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Tue, 28 Apr 2009 21:11:42 +1000 >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: Re: [M3devel] CM3 release build regression tests not >> terminating >> >> What could possibly have changed here. It used to work fine on >> multiple platforms. >> >> On 28 Apr 2009, at 20:14, Jay wrote: >> >>> >>> It creates a file named "df-k" and hangs here: >>> >>> (gdb) where >>> #0 0x080f417f in select () >>> #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, >>> writefds=0x28127138, >>> exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ >>> FreeBSD4/select.c:13 >>> #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, >>> M3_CEtG8K_timeout=0xbfbfe6d8) >>> at ThreadPosix.m3:714 >>> #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 >>> #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, >>> M3_AicXUJ_alertable=0 '\0') >>> at ThreadPosix.m3:555 >>> #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at >>> ThreadPosix.m3:539 >>> #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at >>> ProcessPosix.m3:294 >>> #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at >>> System.m3:527 >>> #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, >>> M3_EkfbeH_env=0x0, >>> M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 >>> #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at >>> OSPOSIX.m3:19 >>> #10 0x0804c31c in Main__DoIt () at Main.m3:122 >>> #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 >>> #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at >>> RTLinker.m3:395 >>> #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at >>> RTLinker.m3:109 >>> #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at >>> RTLinker.m3:118 >>> #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at >>> _m3main.mc:4 >>> >>> Notice it using user threads, so old m3core/libm3. >>> df doesn't appear to be any longer running. >>> Why it prints about the backend mode, I don't know. >>> >>> (and yes, I get it -- df -k is directly related to GetDiskSpace..if >>> this is how one checks diskspace on Unix...I think we should punt, >>> unless posix actually specifies the precise output format of this >>> command it is very reliably parsed...) >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: wagner at elegosoft.com >>>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>>> Subject: RE: [M3devel] CM3 release build regression tests not >>>> terminating >>>> Date: Tue, 28 Apr 2009 09:58:56 +0000 >>>> >>>> >>>> Right, now it hangs having printed..I know this looks a bit of >>>> nonsense..stuff from right around: >>>> >>>> >>>> M3_BACKEND_MODE = "3" >>>> % -- defines how the frontend, backend, and assembler interact >>>> % "0" -- don't call m3_backend, M3CG produces object code >>>> % "1" -- don't call m3_backend, M3CG produces assembly code >>>> % "2" -- call m3_backend, it produces object code >>>> % "3" -- call m3_backend, it produces assembly code >>>> >>>> >>>> however, this is noticably pretty close to the last BEGIN_CONFIG. >>>> >>>> Maybe the carriage returns confused it. I'll see.. >>>> I did introduce them recently by accident. >>>> gdb reported some errors and no symbols in the callstack having >>>> connected to it, on FreeBSD. If need be I can try debugging it on >>>> another system.. >>>> >>>> >>>> (aside, philosophy: all text processing code should treat \n, \r, >>>> and \r\n in put the same, unless you are writing a terminal driver, >>>> then \r has a separate meaning useful for implementing spinners..) >>>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> Date: Tue, 28 Apr 2009 11:40:00 +0200 >>>>> From: wagner at elegosoft.com >>>>> To: jay.krell at cornell.edu >>>>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>>>> Subject: RE: [M3devel] CM3 release build regression tests not >>>>> terminating >>>>> >>>>> Quoting Jay : >>>>> >>>>>> >>>>>> Well, on FreeBSD 7.0, I get as far as: >>>>>> >>>>>> ew source -> compiling EnvUtils.i3 >>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>> required by "cm3cg" >>>>>> ew source -> compiling EnvUtils.m3 >>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>> required by "cm3cg" >>>>>> ew source -> compiling FingerprintFmt.i3 >>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>> required by "cm3cg" >>>>>> ew source -> compiling TextUtils.i3 >>>>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>>>> required by "cm3cg" >>>>>> >>>>>> Yeah, I understand, I have libc.so.7. >>>>> >>>>> You need to install the FreeBSD compat packages for backward >>>>> compatibility. Should work fine then (until cminstall hangs?). >>>>> >>>>> Olaf >>>>> >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>>>>>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>>>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>>>> terminating >>>>>>> >>>>>>> >>>>>>> I've never been able to get the tinderbox stuff to work for me. >>>>>>> I'll try again. >>>>>>> Nothing much from me lately -- pthreads movement to C, and then >>>>>>> back. >>>>>>> >>>>>>>>> Jay, did you change any config files recently? >>>>>>> >>>>>>> FreeBSD config file changes on 2009-04-13. >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: hosking at cs.purdue.edu >>>>>>>> To: wagner at elegosoft.com >>>>>>>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>>>>>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>>>>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>>>>>> terminating >>>>>>>> >>>>>>>> Yes, I had noticed this too. >>>>>>>> >>>>>>>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> does anybody know what's keeping the release-build tests for >>>>>>>>> tinderbox >>>>>>>>> from terminating? I've got lots of stalled regression process >>>>>>>>> trees on >>>>>>>>> my system, and the tinderbox display indicates that none of >>>>>>>>> the >>>>>>>>> release >>>>>>>>> builds seem to succeed. Has anybody changed anything in the >>>>>>>>> scripts? >>>>>>>>> >>>>>>>>> On a closer look, upgrade seems to be stuck in the installer: >>>>>>>>> >>>>>>>>> % ps -axwww 25310 >>>>>>>>> PID TT STAT TIME COMMAND >>>>>>>>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>>>>>>>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3- >>>>>>>>> inst/ >>>>>>>>> luthien/current -o >>>>>>>>> >>>>>>>>> Jay, did you change any config files recently? >>>>>>>>> Regression tests seemed to have been running again for some >>>>>>>>> days, >>>>>>>>> and then >>>>>>>>> stopped again. >>>>>>>>> >>>>>>>>> I'll try to investigate further this evening, but must leave >>>>>>>>> now for >>>>>>>>> other work... >>>>>>>>> >>>>>>>>> Olaf >>>>>>>>> -- >>>>>>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>>>>>>> Germany >>>>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>>>>>> 23 >>>>>>>>> 45 86 95 >>>>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | >>>>>>>>> Sitz: >>>>>>>>> Berlin >>>>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt- >>>>>>>>> IdNr: >>>>>>>>> DE163214194 >>>>>>>>> >>>>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Apr 28 14:13:17 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 12:13:17 +0000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <9AC96562-7045-418A-A069-84EE8613498A@cs.purdue.edu> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> <9AC96562-7045-418A-A069-84EE8613498A@cs.purdue.edu> Message-ID: Tony can you clarify? Things stopped working two weeks ago? Or things were working until more recently? It seems like the select call never returns. Whatever is going on, it troubles debugging tools. gdb won't follow the children..which is probably ok, they aren't the problem. truss can't be control-c'ed, but can be killed. "info locals" in gdb often hangs and I have to pkill gdb. Not that info locals ever works well, but it usually doesn't hang gdb. I started putting in RTIO calls. WaitForAll's finishes one Wait call but then hangs on the next. I think we should not run cminstall against 5.4 runtime. Enable user threads as some related scenario.. - Jay ________________________________ > CC: m3devel at elegosoft.com; manderson at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] CM3 release build regression tests not terminating > Date: Tue, 28 Apr 2009 21:49:32 +1000 > > Sounds about right. > > 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 28 Apr 2009, at 21:17, Jay wrote: > > > The changes went in two weeks ago 4/14, were they definitely working? > I can try it again, hopefully without the full tinderbox stuff. > > - Jay > > > ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 28 Apr 2009 21:11:42 +1000 > CC: m3devel at elegosoft.com; manderson at elegosoft.com > Subject: Re: [M3devel] CM3 release build regression tests not terminating > > What could possibly have changed here. It used to work fine on > multiple platforms. > > On 28 Apr 2009, at 20:14, Jay wrote: > > > It creates a file named "df-k" and hangs here: > > (gdb) where > #0 0x080f417f in select () > #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, > writefds=0x28127138, > exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ > FreeBSD4/select.c:13 > #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, > M3_CEtG8K_timeout=0xbfbfe6d8) > at ThreadPosix.m3:714 > #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 > #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, > M3_AicXUJ_alertable=0 '\0') > at ThreadPosix.m3:555 > #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at > ThreadPosix.m3:539 > #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at > ProcessPosix.m3:294 > #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at > System.m3:527 > #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, > M3_EkfbeH_env=0x0, > M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 > #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at > OSPOSIX.m3:19 > #10 0x0804c31c in Main__DoIt () at Main.m3:122 > #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 > #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at > RTLinker.m3:395 > #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at > RTLinker.m3:109 > #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at > RTLinker.m3:118 > #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at > _m3main.mc:4 > > Notice it using user threads, so old m3core/libm3. > df doesn't appear to be any longer running. > Why it prints about the backend mode, I don't know. > > (and yes, I get it -- df -k is directly related to GetDiskSpace..if > this is how one checks diskspace on Unix...I think we should punt, > unless posix actually specifies the precise output format of this > command it is very reliably parsed...) > > - Jay > > > ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com > Subject: RE: [M3devel] CM3 release build regression tests not > terminating > Date: Tue, 28 Apr 2009 09:58:56 +0000 > > > Right, now it hangs having printed..I know this looks a bit of > nonsense..stuff from right around: > > > M3_BACKEND_MODE = "3" > % -- defines how the frontend, backend, and assembler interact > % "0" -- don't call m3_backend, M3CG produces object code > % "1" -- don't call m3_backend, M3CG produces assembly code > % "2" -- call m3_backend, it produces object code > % "3" -- call m3_backend, it produces assembly code > > > however, this is noticably pretty close to the last BEGIN_CONFIG. > > Maybe the carriage returns confused it. I'll see.. > I did introduce them recently by accident. > gdb reported some errors and no symbols in the callstack having > connected to it, on FreeBSD. If need be I can try debugging it on > another system.. > > > (aside, philosophy: all text processing code should treat \n, \r, > and \r\n in put the same, unless you are writing a terminal driver, > then \r has a separate meaning useful for implementing spinners..) > > > - Jay > > > ---------------------------------------- > Date: Tue, 28 Apr 2009 11:40:00 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com > Subject: RE: [M3devel] CM3 release build regression tests not > terminating > > Quoting Jay : > > > Well, on FreeBSD 7.0, I get as far as: > > ew source -> compiling EnvUtils.i3 > libexec/ld-elf.so.1: Shared object "libc.so.6" not found, > required by "cm3cg" > ew source -> compiling EnvUtils.m3 > libexec/ld-elf.so.1: Shared object "libc.so.6" not found, > required by "cm3cg" > ew source -> compiling FingerprintFmt.i3 > libexec/ld-elf.so.1: Shared object "libc.so.6" not found, > required by "cm3cg" > ew source -> compiling TextUtils.i3 > libexec/ld-elf.so.1: Shared object "libc.so.6" not found, > required by "cm3cg" > > Yeah, I understand, I have libc.so.7. > > You need to install the FreeBSD compat packages for backward > compatibility. Should work fine then (until cminstall hangs?). > > Olaf > > > - Jay > > > ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; wagner at elegosoft.com > Date: Tue, 28 Apr 2009 07:45:14 +0000 > CC: m3devel at elegosoft.com; manderson at elegosoft.com > Subject: Re: [M3devel] CM3 release build regression tests not > terminating > > > I've never been able to get the tinderbox stuff to work for me. > I'll try again. > Nothing much from me lately -- pthreads movement to C, and then > back. > > Jay, did you change any config files recently? > > FreeBSD config file changes on 2009-04-13. > > - Jay > > ---------------------------------------- > From: hosking at cs.purdue.edu > To: wagner at elegosoft.com > Date: Tue, 28 Apr 2009 16:45:29 +1000 > CC: m3devel at elegosoft.com; manderson at elegosoft.com > Subject: Re: [M3devel] CM3 release build regression tests not > terminating > > Yes, I had noticed this too. > > On 28 Apr 2009, at 16:29, Olaf Wagner wrote: > > Hi, > > does anybody know what's keeping the release-build tests for > tinderbox > from terminating? I've got lots of stalled regression process > trees on > my system, and the tinderbox display indicates that none of the > release > builds seem to succeed. Has anybody changed anything in the > scripts? > > On a closer look, upgrade seems to be stuck in the installer: > > % ps -axwww 25310 > PID TT STAT TIME COMMAND > 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ > pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ > luthien/current -o > > Jay, did you change any config files recently? > Regression tests seemed to have been running again for some > days, > and then > stopped again. > > I'll try to investigate further this evening, but must leave > now for > other work... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 > 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > > From vapier at gentoo.org Tue Apr 28 15:00:26 2009 From: vapier at gentoo.org (Mike Frysinger) Date: Tue, 28 Apr 2009 09:00:26 -0400 Subject: [M3devel] how to find dependent .so files? In-Reply-To: References: Message-ID: <200904280900.27606.vapier@gentoo.org> On Tuesday 28 April 2009 04:03:13 Jay wrote: > Normally we have: > > /usr/local/cm3/bin/someexe > /usr/local/cm3/lib/libfoo.so symlink to ../pkg/foo/target/libfoo.so > /usr/local/cm3/lib/libbar.so symlink to ../pkg/bar/target/libbar.so > > Linking from someexe to $ORIGIN/../lib works, ok. > But from libfoo to libbar requires $ORIGIN/../../../lib. > or $ORIGIN/../../bar/target. what's wrong with just $ORIGIN ? they're in the same directory already. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From jay.krell at cornell.edu Tue Apr 28 15:15:06 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 13:15:06 +0000 Subject: [M3devel] how to find dependent .so files? In-Reply-To: <200904280900.27606.vapier@gentoo.org> References: <200904280900.27606.vapier@gentoo.org> Message-ID: If you take one of my suggestions, then yes you can do that for .sos. But $ORIGIN/../lib is one generic perhaps inefficient runpath for .sos and executables, and hypothetically also for non-public shipped executables (with my suggestion that they go to lib, if they don't already), that's why. The next step is just to smush lib and bin together, as is done on NT386. Probably people won't like that, keep files out of $PATH. I don't believe $ORIGIN works asis. if /cm3/lib/libfoo.so symlinks to /cm3/pkg/foo/target/libfoo.so then $ORIGIN is /cm3/pkg/foo/target, not /cm3/lib. I'd like to be wrong here but I don't think I am. So reversing the symlinks or making them hardlinks is ok? - Jay ---------------------------------------- > From: vapier at gentoo.org > To: m3devel at elegosoft.com > Date: Tue, 28 Apr 2009 09:00:26 -0400 > CC: jay.krell at cornell.edu > Subject: Re: [M3devel] how to find dependent .so files? > > On Tuesday 28 April 2009 04:03:13 Jay wrote: >> Normally we have: >> >> /usr/local/cm3/bin/someexe >> /usr/local/cm3/lib/libfoo.so symlink to ../pkg/foo/target/libfoo.so >> /usr/local/cm3/lib/libbar.so symlink to ../pkg/bar/target/libbar.so >> >> Linking from someexe to $ORIGIN/../lib works, ok. >> But from libfoo to libbar requires $ORIGIN/../../../lib. >> or $ORIGIN/../../bar/target. > > what's wrong with just $ORIGIN ? they're in the same directory already. > -mike From jay.krell at cornell.edu Tue Apr 28 16:15:50 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 14:15:50 +0000 Subject: [M3devel] manual initialization order? Message-ID: Um, if initializers are so acceptable (I'm skeptical, but everyone here disagrees with me..) and circularities are not allowed (that helps I guess..but is it really true? the garbage collector uses threads, the threading library allocates traced references..I sense circularity...)...why does RTLinker manually pick an initialization order? This is fragile. (* initialize the rest of the modules we'll be calling *) AddUnit (RTLinkerX.RTLinker_I3); (* myself! *) AddUnit (RTLinkerX.RT0_I3); AddUnit (RTLinkerX.RTSignal_I3); AddUnit (RTLinkerX.RTParams_I3); AddUnit (RTLinkerX.RTDebug_I3); AddUnit (RTLinkerX.RTError_I3); AddUnit (RTLinkerX.RTHeapRep_I3); AddUnit (RTLinkerX.ThreadF_I3); AddUnit (RTLinkerX.RTHeapInfo_I3); AddUnit (RTLinkerX.RTIO_I3); AddUnit (RTLinkerX.RTCollectorSRC_I3); AddUnit (RTLinkerX.Word_I3); (* finally, initialize the runtime. *) RTSignal.InstallHandlers (); RTParams.Init (); RTHeapRep.Init (); ThreadF.Init (); RTDebug.Init (); RTHeapInfo.Init (); IF RTParams.IsPresent("tracelinker") THEN traceInit := TRUE; END; AddUnit (RTLinkerX.RTDebug_M3); AddUnit (RTLinkerX.RTError_M3); AddUnit (RTLinkerX.RTType_M3); AddUnit (RTLinkerX.RTPacking_M3); AddUnit (RTLinkerX.RTTipe_M3); AddUnit (RTLinkerX.RTException_M3); From rcoleburn at scires.com Tue Apr 28 17:25:52 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 28 Apr 2009 11:25:52 -0400 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> Message-ID: <49F6E76E.1E75.00D7.1@scires.com> >>> Jay jay.krell at cornell.edu> 4/28/2009 5:58 AM >> ( mailto:jay.krell at cornell.edu> ) (aside, philosophy: all text processing code should treat \n, \r, and \r\n in put the same, unless you are writing a terminal driver, then \r has a separate meaning useful for implementing spinners..) - Jay That may be a nice philosophy, but we can't implement it because in practice not everybody adheres to it. I have written extensive text processing code that has to differentiate between these variants in order to properly interface with and interpret I/O from other systems. --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 mika at async.caltech.edu Tue Apr 28 17:36:44 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 28 Apr 2009 08:36:44 -0700 Subject: [M3devel] Text processing Message-ID: <200904281536.n3SFaiNs060605@camembert.async.caltech.edu> Speaking of text processing, I was very surprised at the bug I found in Wx the other day (and checked in a fix for). I'm 99% certain my fix is correct, but I'm very surprised no one found this bug before. Wx was inserting spurious nulls at the end of every generated TEXT. Is it possible someone is using this interface and depending on the buggy behavior? m3ide and m3browser import it. Mika From rcoleburn at scires.com Tue Apr 28 17:49:35 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 28 Apr 2009 11:49:35 -0400 Subject: [M3devel] Text processing In-Reply-To: <200904281536.n3SFaiNs060605@camembert.async.caltech.edu> References: <200904281536.n3SFaiNs060605@camembert.async.caltech.edu> Message-ID: <49F6ECFD.1E75.00D7.1@scires.com> There is a bug in CM3IDE that may be the result of this problem. I'll need to get your fix and try it. --Randy >>> Mika Nystrom 4/28/2009 11:36 AM >>> Speaking of text processing, I was very surprised at the bug I found in Wx the other day (and checked in a fix for). I'm 99% certain my fix is correct, but I'm very surprised no one found this bug before. Wx was inserting spurious nulls at the end of every generated TEXT. Is it possible someone is using this interface and depending on the buggy behavior? m3ide and m3browser import it. Mika 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 mika at async.caltech.edu Tue Apr 28 18:26:24 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 28 Apr 2009 09:26:24 -0700 Subject: [M3devel] Text processing In-Reply-To: Your message of "Tue, 28 Apr 2009 11:49:35 EDT." <49F6ECFD.1E75.00D7.1@scires.com> Message-ID: <200904281626.n3SGQO92063132@camembert.async.caltech.edu> Hmm cm3ide has its own Wx. It doesn't use that? It looks different from the standard one in cm3. In the *standard* one, that is, m3-libs/libbuf/src/Wx.m3, the fix is the following: PROCEDURE ToText (t: T): TEXT = VAR txt := Text8.Create(t.nFull * ChunkSize + t.next); c := t.head; n := 0; BEGIN There used to be a "+ 1" in the call to Text8.Create. It's crud from converting from the old array TEXTs. I've already checked this in to the cm3 distribution. Mika "Randy Coleburn" writes: >This is a MIME message. If you are reading this text, you may want to >consider changing to a mail reader or gateway that understands how to >properly handle MIME multipart messages. > >--=__Part6C44DF9F.0__= >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: quoted-printable > >There is a bug in CM3IDE that may be the result of this problem. I'll = >need to get your fix and try it. >--Randy > >>>> Mika Nystrom 4/28/2009 11:36 AM >>> > >Speaking of text processing, I was very surprised at the bug I found >in Wx the other day (and checked in a fix for). I'm 99% certain my >fix is correct, but I'm very surprised no one found this bug before. > >Wx was inserting spurious nulls at the end of every generated TEXT. > >Is it possible someone is using this interface and depending on the >buggy behavior? m3ide and m3browser import it. > > Mika > > >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. > > >--=__Part6C44DF9F.0__= >Content-Type: text/html; charset=US-ASCII >Content-Transfer-Encoding: quoted-printable >Content-Description: HTML > > >"> > > >
There is a bug in CM3IDE that may be the result of this problem. = > I'll need to get your fix and try it.
>
--Randy

>>> Mika Nystrom <mika at async.caltech.edu>= >; 4/28/2009 11:36 AM >>>

Speaking of text processing, I = >was very surprised at the bug I found
in Wx the other day (and checked = >in a fix for).  I'm 99% certain my
fix is correct, but I'm very = >surprised no one found this bug before.

Wx was inserting spurious = >nulls at the end of every generated TEXT.

Is it possible someone is = >using this interface and depending on the
buggy behavior?  m3ide = >and m3browser import it.

     Mika

= > > >--=__Part6C44DF9F.0__=-- From jay.krell at cornell.edu Tue Apr 28 18:30:11 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 16:30:11 +0000 Subject: [M3devel] Text processing In-Reply-To: <200904281626.n3SGQO92063132@camembert.async.caltech.edu> References: Your message of "Tue, 28 Apr 2009 11:49:35 EDT." <49F6ECFD.1E75.00D7.1@scires.com> <200904281626.n3SGQO92063132@camembert.async.caltech.edu> Message-ID: Are the nulls included in the length? If so, that'd be a likely bug. If not, it'd be a /possible/ feature. Seriously. I deal with "lengthed" strings a lot, but my "duplicate" and "concat" functions add them, and don't put them in the length, for interop with all the other code out there.. But it is a little sleazy my pattern and we do have explicit functions for C interop. - Jay ---------------------------------------- > To: rcoleburn at scires.com > Date: Tue, 28 Apr 2009 09:26:24 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Text processing > > Hmm cm3ide has its own Wx. It doesn't use that? It looks different > from the standard one in cm3. > > In the *standard* one, that is, m3-libs/libbuf/src/Wx.m3, > the fix is the following: > > PROCEDURE ToText (t: T): TEXT = > VAR txt := Text8.Create(t.nFull * ChunkSize + t.next); > c := t.head; n := 0; > BEGIN > > There used to be a "+ 1" in the call to Text8.Create. It's crud > from converting from the old array TEXTs. > > I've already checked this in to the cm3 distribution. > > Mika > > "Randy Coleburn" writes: >>This is a MIME message. If you are reading this text, you may want to >>consider changing to a mail reader or gateway that understands how to >>properly handle MIME multipart messages. >> >>--=__Part6C44DF9F.0__= >>Content-Type: text/plain; charset=US-ASCII >>Content-Transfer-Encoding: quoted-printable >> >>There is a bug in CM3IDE that may be the result of this problem. I'll = >>need to get your fix and try it. >>--Randy >> >>>>> Mika Nystrom 4/28/2009 11:36 AM>>> >> >>Speaking of text processing, I was very surprised at the bug I found >>in Wx the other day (and checked in a fix for). I'm 99% certain my >>fix is correct, but I'm very surprised no one found this bug before. >> >>Wx was inserting spurious nulls at the end of every generated TEXT. >> >>Is it possible someone is using this interface and depending on the >>buggy behavior? m3ide and m3browser import it. >> >> Mika >> >> >>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. >> >> >>--=__Part6C44DF9F.0__= >>Content-Type: text/html; charset=US-ASCII >>Content-Transfer-Encoding: quoted-printable >>Content-Description: HTML >> >> >>>>"> >> >> >> There is a bug in CM3IDE that may be the result of this problem. = >> I'll need to get your fix and try it. >> --Randy >>> Mika Nystrom = >>; 4/28/2009 11:36 AM>>> Speaking of text processing, I = >>was very surprised at the bug I found in Wx the other day (and checked = >>in a fix for). I'm 99% certain my fix is correct, but I'm very = >>surprised no one found this bug before. Wx was inserting spurious = >>nulls at the end of every generated TEXT. Is it possible someone is = >>using this interface and depending on the buggy behavior? m3ide = >>and m3browser import it. Mika = >> >> >>--=__Part6C44DF9F.0__=-- From jay.krell at cornell.edu Tue Apr 28 18:32:16 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 16:32:16 +0000 Subject: [M3devel] __thread? Message-ID: Mika, please let me know what this does for you, on the old FreeBSD 4.x? Probably it'll give some compiler errors, but if not, excellent. Our usess of pthread_get/setspecific should use __thread where it is available. Below is FreeBSD/i386 7.0. Nice and efficient (even better with -O2). Actually, "everyone", I'm interested in this. Probably we should do a little local autoconfery in the m3core m3makefile. If the below program compiles/links, use __thread, else pthread_get/setspecific. Another option is determine that it is widely supported and use #if or find out if there are specific #ifs associated with it. I know Cygwin doesn't support it. [jay at jkfbsd1 ~]$ cat 1.c #include __thread int a,b,c,d; int main() { printf("%p%p%p%p\n", &a,&b,&c,&d); return 0; } [jay at jkfbsd1 ~]$ gcc -S 1.c [jay at jkfbsd1 ~]$ cat 1.s .file "1.c" .section .rodata .LC0: .string "%p%p%p%p\n" .text .p2align 4,,15 .globl main .type main, @function main: leal 4(%esp), %ecx andl $-16, %esp pushl -4(%ecx) pushl %ebp movl %esp, %ebp pushl %ecx subl $20, %esp movl %gs:0, %eax leal d at NTPOFF(%eax), %eax movl %eax, 16(%esp) movl %gs:0, %eax leal c at NTPOFF(%eax), %eax movl %eax, 12(%esp) movl %gs:0, %eax leal b at NTPOFF(%eax), %eax movl %eax, 8(%esp) movl %gs:0, %eax leal a at NTPOFF(%eax), %eax movl %eax, 4(%esp) movl $.LC0, (%esp) call printf movl $0, %eax addl $20, %esp popl %ecx popl %ebp leal -4(%ecx), %esp ret .size main, .-main .globl a .section .tbss,"awT", at nobits ... - Jay From jay.krell at cornell.edu Tue Apr 28 18:38:09 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 16:38:09 +0000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <49F6E76E.1E75.00D7.1@scires.com> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <49F6E76E.1E75.00D7.1@scires.com> Message-ID: Randy just because everyone else does it poorly does not generally tie your hands. I said on input, not on output. Output does often tie your hands. Or do they actually have different meanings? That'd be wierd. The only useful semantic difference I've ever seen is that carriagereturn alone can be used to implement little spinnies. Otherwise, all three sequences have identical meaning. And various code out there does treat them identically, just not necessarily does one code treat them all the same, you have to at worst find three programs to find the same treatment. We /can/ implement it, anywhere we have text processing code. Reading quake files. I think it already does. It was just a red herring. Libraries that return "lines". You know, one common pattern is on Unix to split on \n and on NT to split on \r\n. Well, that means the same code deals in one format one platform, one on the other, and just acts wierdly when presented with the "wrong" format. There's no reason it can't just act platform independent and treat both formats always correctly. The compiler frontend must do this, based on experience and reasonable expectations. Most C compilers these days ditto. - Jay ________________________________ > Date: Tue, 28 Apr 2009 11:25:52 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 release build regression tests not terminating > > > > > > > >>>> Jay jay.krell at cornell.edu> 4/28/2009 5:58 AM>>%204/28/2009%205:58%20AM%20>>> > > (aside, philosophy: all text processing code should treat \n, \r, and \r\n in put the same, unless you are writing a terminal driver, then \r has a separate meaning useful for implementing spinners..) > - Jay > > That may be a nice philosophy, but we can't implement it because in practice not everybody adheres to it. I have written extensive text processing code that has to differentiate between these variants in order to properly interface with and interpret I/O from other systems. > > --Randy From jay.krell at cornell.edu Tue Apr 28 18:54:03 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 16:54:03 +0000 Subject: [M3devel] user threads Message-ID: User threads seem to work on on FreeBSD/x86 7.0. Mika can you report back the perf cm3 vs. pm3? Still, kernel threads have been around a long time and imho should be strongly favored.. Kernel threads should be a /little/ faster than they were -- PushEFrame removed from successful heap allocations. And should be further improvable via __thread where it is supported -- probably not FreeBSD 4.x, sometimes older is not better. :) I've temporarily switched FreeBSD/x86 to userthreads by default but I think that's just an experiment and should be undone shortly, maybe work out some other story for easily switching between them, or just keep the existing story of "you get to rebuild everything". Tony, can you look into GetGCRatio? I removed the call to it. The "fatal" pragma invokes PushEFrame apparently. We should now "fix" Win32 and pthreads to not have GetActivation initialize on-demand, just leave Init to initialize always. This should shave a few more cycles from PushEFrame. - Jay From mika at async.caltech.edu Tue Apr 28 18:55:00 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 28 Apr 2009 09:55:00 -0700 Subject: [M3devel] Text processing In-Reply-To: Your message of "Tue, 28 Apr 2009 16:30:11 -0000." Message-ID: <200904281655.n3SGt0iJ064555@camembert.async.caltech.edu> I think whenever Modula-3 TEXTs are represented as arrays (including *all* m3 TEXTs in SRC and P M3), there's a null at the end. It's not included in the "length of the string" but obviously it *is* included in the "length of the array". That's precisely the source of the bug. The old version allocates "length of string plus one", which is the wrong number to pass to the new interfaces (which don't expose the trailing zero, but keep it, just the same). Yes, the idea is you can pass Modula-3 TEXTs freely (cheaply) to C routines. Well, you used to be able to, before TEXTs were "improved" by Critical Mass. The code would have been something like this...? IMPORT TextF; VAR txt : TEXT; ... some_c_function(ADR(txt[0])) ... No I don't miss this feature much. There are other improvements that bug me a lot more. But this is all about to be fixed with the new Text implementation, right? :-) Mika Jay writes: > >Are the nulls included in the length? > >If so, that'd be a likely bug. If not, it'd be a /possible/ feature. Seriously >. >I deal with "lengthed" strings a lot, but my "duplicate" and "concat" function >s add them, and don't put them in the length, for interop with all the other c >ode out there.. >But it is a little sleazy my pattern and we do have explicit functions for C i >nterop. > > > - Jay > > >---------------------------------------- >> To: rcoleburn at scires.com >> Date: Tue, 28 Apr 2009 09:26:24 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Text processing >> >> Hmm cm3ide has its own Wx. It doesn't use that? It looks different >> from the standard one in cm3. >> >> In the *standard* one, that is, m3-libs/libbuf/src/Wx.m3, >> the fix is the following: >> >> PROCEDURE ToText (t: T): TEXT = >> VAR txt := Text8.Create(t.nFull * ChunkSize + t.next); >> c := t.head; n := 0; >> BEGIN >> >> There used to be a "+ 1" in the call to Text8.Create. It's crud >> from converting from the old array TEXTs. >> >> I've already checked this in to the cm3 distribution. >> >> Mika >> >> "Randy Coleburn" writes: >>>This is a MIME message. If you are reading this text, you may want to >>>consider changing to a mail reader or gateway that understands how to >>>properly handle MIME multipart messages. >>> >>>--=__Part6C44DF9F.0__= >>>Content-Type: text/plain; charset=US-ASCII >>>Content-Transfer-Encoding: quoted-printable >>> >>>There is a bug in CM3IDE that may be the result of this problem. I'll = >>>need to get your fix and try it. >>>--Randy >>> >>>>>> Mika Nystrom 4/28/2009 11:36 AM>>> >>> >>>Speaking of text processing, I was very surprised at the bug I found >>>in Wx the other day (and checked in a fix for). I'm 99% certain my >>>fix is correct, but I'm very surprised no one found this bug before. >>> >>>Wx was inserting spurious nulls at the end of every generated TEXT. >>> >>>Is it possible someone is using this interface and depending on the >>>buggy behavior? m3ide and m3browser import it. >>> >>> Mika >>> >>> >>>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. >>> >>> >>>--=__Part6C44DF9F.0__= >>>Content-Type: text/html; charset=US-ASCII >>>Content-Transfer-Encoding: quoted-printable >>>Content-Description: HTML >>> >>> >>>>>"> >>> > >>> >>> >There is a bug in CM3IDE that may be the result of this problem. = >>> I'll need to get your fix and try it. >>> >--Randy > >>>> Mika Nystrom = >>>; 4/28/2009 11:36 AM>>> > >Speaking of text processing, I = >>>was very surprised at the bug I found >in Wx the other day (and checked = >>>in a fix for). I'm 99% certain my >fix is correct, but I'm very = >>>surprised no one found this bug before. > >Wx was inserting spurious = >>>nulls at the end of every generated TEXT. > >Is it possible someone is = >>>using this interface and depending on the >buggy behavior? m3ide = >>>and m3browser import it. > > Mika > >= >>> >>> >>>--=__Part6C44DF9F.0__=-- From wagner at elegosoft.com Tue Apr 28 19:39:39 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 28 Apr 2009 19:39:39 +0200 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> <9AC96562-7045-418A-A069-84EE8613498A@cs.purdue.edu> Message-ID: <20090428193939.f037r1dkowg0ks4o@mail.elegosoft.com> Hi Jay, thanks for reverting the offending changes to the installer. I'm sure they were working OK when I tested them locally, and they looked innocent enough. Sigh. Perhaps not worth to pursue the installer issues further though. Have you found out why it hangs though? I haven't really understood the problem yet. Sorry for the disturbances, Olaf Quoting Jay : > Tony can you clarify? Things stopped working two weeks ago? > Or things were working until more recently? > > It seems like the select call never returns. > Whatever is going on, it troubles debugging tools. > gdb won't follow the children..which is probably ok, they aren't the problem. > truss can't be control-c'ed, but can be killed. > "info locals" in gdb often hangs and I have to pkill gdb. > Not that info locals ever works well, but it usually doesn't hang gdb. > I started putting in RTIO calls. > WaitForAll's finishes one Wait call but then hangs on the next. > > I think we should not run cminstall against 5.4 runtime. > Enable user threads as some related scenario.. > > > - Jay > > > ________________________________ >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Subject: Re: [M3devel] CM3 release build regression tests not terminating >> Date: Tue, 28 Apr 2009 21:49:32 +1000 >> >> Sounds about right. >> >> 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 28 Apr 2009, at 21:17, Jay wrote: >> >> >> The changes went in two weeks ago 4/14, were they definitely working? >> I can try it again, hopefully without the full tinderbox stuff. >> >> - Jay >> >> >> ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Tue, 28 Apr 2009 21:11:42 +1000 >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: Re: [M3devel] CM3 release build regression tests not terminating >> >> What could possibly have changed here. It used to work fine on >> multiple platforms. >> >> On 28 Apr 2009, at 20:14, Jay wrote: >> >> >> It creates a file named "df-k" and hangs here: >> >> (gdb) where >> #0 0x080f417f in select () >> #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, >> writefds=0x28127138, >> exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ >> FreeBSD4/select.c:13 >> #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, >> M3_CEtG8K_timeout=0xbfbfe6d8) >> at ThreadPosix.m3:714 >> #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 >> #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, >> M3_AicXUJ_alertable=0 '\0') >> at ThreadPosix.m3:555 >> #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at >> ThreadPosix.m3:539 >> #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at >> ProcessPosix.m3:294 >> #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at >> System.m3:527 >> #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, >> M3_EkfbeH_env=0x0, >> M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 >> #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at >> OSPOSIX.m3:19 >> #10 0x0804c31c in Main__DoIt () at Main.m3:122 >> #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 >> #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at >> RTLinker.m3:395 >> #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at >> RTLinker.m3:109 >> #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at >> RTLinker.m3:118 >> #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at >> _m3main.mc:4 >> >> Notice it using user threads, so old m3core/libm3. >> df doesn't appear to be any longer running. >> Why it prints about the backend mode, I don't know. >> >> (and yes, I get it -- df -k is directly related to GetDiskSpace..if >> this is how one checks diskspace on Unix...I think we should punt, >> unless posix actually specifies the precise output format of this >> command it is very reliably parsed...) >> >> - Jay >> >> >> ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: RE: [M3devel] CM3 release build regression tests not >> terminating >> Date: Tue, 28 Apr 2009 09:58:56 +0000 >> >> >> Right, now it hangs having printed..I know this looks a bit of >> nonsense..stuff from right around: >> >> >> M3_BACKEND_MODE = "3" >> % -- defines how the frontend, backend, and assembler interact >> % "0" -- don't call m3_backend, M3CG produces object code >> % "1" -- don't call m3_backend, M3CG produces assembly code >> % "2" -- call m3_backend, it produces object code >> % "3" -- call m3_backend, it produces assembly code >> >> >> however, this is noticably pretty close to the last BEGIN_CONFIG. >> >> Maybe the carriage returns confused it. I'll see.. >> I did introduce them recently by accident. >> gdb reported some errors and no symbols in the callstack having >> connected to it, on FreeBSD. If need be I can try debugging it on >> another system.. >> >> >> (aside, philosophy: all text processing code should treat \n, \r, >> and \r\n in put the same, unless you are writing a terminal driver, >> then \r has a separate meaning useful for implementing spinners..) >> >> >> - Jay >> >> >> ---------------------------------------- >> Date: Tue, 28 Apr 2009 11:40:00 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: RE: [M3devel] CM3 release build regression tests not >> terminating >> >> Quoting Jay : >> >> >> Well, on FreeBSD 7.0, I get as far as: >> >> ew source -> compiling EnvUtils.i3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >> required by "cm3cg" >> ew source -> compiling EnvUtils.m3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >> required by "cm3cg" >> ew source -> compiling FingerprintFmt.i3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >> required by "cm3cg" >> ew source -> compiling TextUtils.i3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >> required by "cm3cg" >> >> Yeah, I understand, I have libc.so.7. >> >> You need to install the FreeBSD compat packages for backward >> compatibility. Should work fine then (until cminstall hangs?). >> >> Olaf >> >> >> - Jay >> >> >> ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu; wagner at elegosoft.com >> Date: Tue, 28 Apr 2009 07:45:14 +0000 >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: Re: [M3devel] CM3 release build regression tests not >> terminating >> >> >> I've never been able to get the tinderbox stuff to work for me. >> I'll try again. >> Nothing much from me lately -- pthreads movement to C, and then >> back. >> >> Jay, did you change any config files recently? >> >> FreeBSD config file changes on 2009-04-13. >> >> - Jay >> >> ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: wagner at elegosoft.com >> Date: Tue, 28 Apr 2009 16:45:29 +1000 >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: Re: [M3devel] CM3 release build regression tests not >> terminating >> >> Yes, I had noticed this too. >> >> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >> >> Hi, >> >> does anybody know what's keeping the release-build tests for >> tinderbox >> from terminating? I've got lots of stalled regression process >> trees on >> my system, and the tinderbox display indicates that none of the >> release >> builds seem to succeed. Has anybody changed anything in the >> scripts? >> >> On a closer look, upgrade seems to be stuck in the installer: >> >> % ps -axwww 25310 >> PID TT STAT TIME COMMAND >> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >> luthien/current -o >> >> Jay, did you change any config files recently? >> Regression tests seemed to have been running again for some >> days, >> and then >> stopped again. >> >> I'll try to investigate further this evening, but must leave >> now for >> other work... >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >> Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >> 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> >> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 hendrik at topoi.pooq.com Tue Apr 28 19:59:17 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 28 Apr 2009 13:59:17 -0400 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <49F6E76E.1E75.00D7.1@scires.com> Message-ID: <20090428175916.GA9048@topoi.pooq.com> On Tue, Apr 28, 2009 at 04:38:09PM +0000, Jay wrote: > > Randy just because everyone else does it poorly does not generally tie your hands. > I said on input, not on output. > Output does often tie your hands. There are situations wheere you need to recognize multiple ways of representing newline without normalizing them. If you are writing an editor for text that is under revision control, and you standardize newlines on input, and then write it out in any consistent convention, you run the risk that revision control will think that huge numbers of lines have been changed. Of course, they have been, but not intentionally. -- hendrik From neels at elego.de Tue Apr 28 21:14:18 2009 From: neels at elego.de (Neels J Hofmeyr) Date: Tue, 28 Apr 2009 21:14:18 +0200 Subject: [M3devel] Modula-2 to Modula-3 translator by Aachen University In-Reply-To: <3d6568a70904252357u3c69dc3do136fcb2a27ffd9ea@mail.gmail.com> References: <3d6568a70904252354n2688dee9k3459399ab59b2495@mail.gmail.com> <3d6568a70904252357u3c69dc3do136fcb2a27ffd9ea@mail.gmail.com> Message-ID: <49F7558A.8060904@elego.de> Benjamin Kowarsch wrote: > Dear Sirs, > > I am trying to get the Modula-2 section in the Catalog of Compilers > updated and there is one entry of a Modula-2 to Modula-3 translator by > Peter Klein at University of Aachen for which all links and email > addresses seem to be dead. University of Aachen was unable to give me > any information either. > > I wonder if you know whether this translator is still availabe and if > so at which URL, or where his author Peter Klein can be contacted. > > thank you > regards > benjamin Sorry, don't know anything about it/him. Anyone else? ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From hosking at cs.purdue.edu Tue Apr 28 23:41:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 29 Apr 2009 07:41:19 +1000 Subject: [M3devel] manual initialization order? In-Reply-To: References: Message-ID: <557AEC0D-E50B-4A74-95B3-37AC2123878D@cs.purdue.edu> Indeed it is fragile, but necessary to bootstrap the system. On 29 Apr 2009, at 00:15, Jay wrote: > > Um, if initializers are so acceptable (I'm skeptical, but everyone > here disagrees with me..) and circularities are not allowed (that > helps I guess..but is it really true? the garbage collector uses > threads, the threading library allocates traced references..I sense > circularity...)...why does RTLinker manually pick an initialization > order? This is fragile. > > > (* initialize the rest of the modules we'll be calling *) > AddUnit (RTLinkerX.RTLinker_I3); (* myself! *) > AddUnit (RTLinkerX.RT0_I3); > AddUnit (RTLinkerX.RTSignal_I3); > AddUnit (RTLinkerX.RTParams_I3); > AddUnit (RTLinkerX.RTDebug_I3); > AddUnit (RTLinkerX.RTError_I3); > AddUnit (RTLinkerX.RTHeapRep_I3); > AddUnit (RTLinkerX.ThreadF_I3); > AddUnit (RTLinkerX.RTHeapInfo_I3); > AddUnit (RTLinkerX.RTIO_I3); > AddUnit (RTLinkerX.RTCollectorSRC_I3); > AddUnit (RTLinkerX.Word_I3); > > > > (* finally, initialize the runtime. *) > RTSignal.InstallHandlers (); > RTParams.Init (); > RTHeapRep.Init (); > ThreadF.Init (); > RTDebug.Init (); > RTHeapInfo.Init (); > IF RTParams.IsPresent("tracelinker") THEN > traceInit := TRUE; > END; > > > AddUnit (RTLinkerX.RTDebug_M3); > AddUnit (RTLinkerX.RTError_M3); > AddUnit (RTLinkerX.RTType_M3); > AddUnit (RTLinkerX.RTPacking_M3); > AddUnit (RTLinkerX.RTTipe_M3); > AddUnit (RTLinkerX.RTException_M3); From hosking at cs.purdue.edu Tue Apr 28 23:51:49 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 29 Apr 2009 07:51:49 +1000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> <9AC96562-7045-418A-A069-84EE8613498A@cs.purdue.edu> Message-ID: <2565931E-F3F3-4832-8582-C1D227B556DA@cs.purdue.edu> Whatever changed in the last 24 hours has my tinderbox runs completing now. On 28 Apr 2009, at 22:13, Jay wrote: > > Tony can you clarify? Things stopped working two weeks ago? > Or things were working until more recently? > > > > It seems like the select call never returns. > Whatever is going on, it troubles debugging tools. > gdb won't follow the children..which is probably ok, they aren't the > problem. > truss can't be control-c'ed, but can be killed. > "info locals" in gdb often hangs and I have to pkill gdb. > Not that info locals ever works well, but it usually doesn't hang gdb. > I started putting in RTIO calls. > WaitForAll's finishes one Wait call but then hangs on the next. > > > I think we should not run cminstall against 5.4 runtime. > Enable user threads as some related scenario.. > > > - Jay > > > ________________________________ >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Subject: Re: [M3devel] CM3 release build regression tests not >> terminating >> Date: Tue, 28 Apr 2009 21:49:32 +1000 >> >> Sounds about right. >> >> 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 28 Apr 2009, at 21:17, Jay wrote: >> >> >> The changes went in two weeks ago 4/14, were they definitely working? >> I can try it again, hopefully without the full tinderbox stuff. >> >> - Jay >> >> >> ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Tue, 28 Apr 2009 21:11:42 +1000 >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: Re: [M3devel] CM3 release build regression tests not >> terminating >> >> What could possibly have changed here. It used to work fine on >> multiple platforms. >> >> On 28 Apr 2009, at 20:14, Jay wrote: >> >> >> It creates a file named "df-k" and hangs here: >> >> (gdb) where >> #0 0x080f417f in select () >> #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, >> writefds=0x28127138, >> exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ >> FreeBSD4/select.c:13 >> #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, >> M3_CEtG8K_timeout=0xbfbfe6d8) >> at ThreadPosix.m3:714 >> #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 >> #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, >> M3_AicXUJ_alertable=0 '\0') >> at ThreadPosix.m3:555 >> #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at >> ThreadPosix.m3:539 >> #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at >> ProcessPosix.m3:294 >> #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at >> System.m3:527 >> #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, >> M3_EkfbeH_env=0x0, >> M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 >> #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at >> OSPOSIX.m3:19 >> #10 0x0804c31c in Main__DoIt () at Main.m3:122 >> #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 >> #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at >> RTLinker.m3:395 >> #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at >> RTLinker.m3:109 >> #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at >> RTLinker.m3:118 >> #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at >> _m3main.mc:4 >> >> Notice it using user threads, so old m3core/libm3. >> df doesn't appear to be any longer running. >> Why it prints about the backend mode, I don't know. >> >> (and yes, I get it -- df -k is directly related to GetDiskSpace..if >> this is how one checks diskspace on Unix...I think we should punt, >> unless posix actually specifies the precise output format of this >> command it is very reliably parsed...) >> >> - Jay >> >> >> ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: RE: [M3devel] CM3 release build regression tests not >> terminating >> Date: Tue, 28 Apr 2009 09:58:56 +0000 >> >> >> Right, now it hangs having printed..I know this looks a bit of >> nonsense..stuff from right around: >> >> >> M3_BACKEND_MODE = "3" >> % -- defines how the frontend, backend, and assembler interact >> % "0" -- don't call m3_backend, M3CG produces object code >> % "1" -- don't call m3_backend, M3CG produces assembly code >> % "2" -- call m3_backend, it produces object code >> % "3" -- call m3_backend, it produces assembly code >> >> >> however, this is noticably pretty close to the last BEGIN_CONFIG. >> >> Maybe the carriage returns confused it. I'll see.. >> I did introduce them recently by accident. >> gdb reported some errors and no symbols in the callstack having >> connected to it, on FreeBSD. If need be I can try debugging it on >> another system.. >> >> >> (aside, philosophy: all text processing code should treat \n, \r, >> and \r\n in put the same, unless you are writing a terminal driver, >> then \r has a separate meaning useful for implementing spinners..) >> >> >> - Jay >> >> >> ---------------------------------------- >> Date: Tue, 28 Apr 2009 11:40:00 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: RE: [M3devel] CM3 release build regression tests not >> terminating >> >> Quoting Jay : >> >> >> Well, on FreeBSD 7.0, I get as far as: >> >> ew source -> compiling EnvUtils.i3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >> required by "cm3cg" >> ew source -> compiling EnvUtils.m3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >> required by "cm3cg" >> ew source -> compiling FingerprintFmt.i3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >> required by "cm3cg" >> ew source -> compiling TextUtils.i3 >> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >> required by "cm3cg" >> >> Yeah, I understand, I have libc.so.7. >> >> You need to install the FreeBSD compat packages for backward >> compatibility. Should work fine then (until cminstall hangs?). >> >> Olaf >> >> >> - Jay >> >> >> ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu; wagner at elegosoft.com >> Date: Tue, 28 Apr 2009 07:45:14 +0000 >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: Re: [M3devel] CM3 release build regression tests not >> terminating >> >> >> I've never been able to get the tinderbox stuff to work for me. >> I'll try again. >> Nothing much from me lately -- pthreads movement to C, and then >> back. >> >> Jay, did you change any config files recently? >> >> FreeBSD config file changes on 2009-04-13. >> >> - Jay >> >> ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: wagner at elegosoft.com >> Date: Tue, 28 Apr 2009 16:45:29 +1000 >> CC: m3devel at elegosoft.com; manderson at elegosoft.com >> Subject: Re: [M3devel] CM3 release build regression tests not >> terminating >> >> Yes, I had noticed this too. >> >> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >> >> Hi, >> >> does anybody know what's keeping the release-build tests for >> tinderbox >> from terminating? I've got lots of stalled regression process >> trees on >> my system, and the tinderbox display indicates that none of the >> release >> builds seem to succeed. Has anybody changed anything in the >> scripts? >> >> On a closer look, upgrade seems to be stuck in the installer: >> >> % ps -axwww 25310 >> PID TT STAT TIME COMMAND >> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >> luthien/current -o >> >> Jay, did you change any config files recently? >> Regression tests seemed to have been running again for some >> days, >> and then >> stopped again. >> >> I'll try to investigate further this evening, but must leave >> now for >> other work... >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >> Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >> 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> >> >> >> >> >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 29 01:10:47 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 23:10:47 +0000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <20090428193939.f037r1dkowg0ks4o@mail.elegosoft.com> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> <9AC96562-7045-418A-A069-84EE8613498A@cs.purdue.edu> <20090428193939.f037r1dkowg0ks4o@mail.elegosoft.com> Message-ID: > Have you found out why it hangs though? I haven't really understood > the problem yet. No. But you understand this is against a 5.4 runtime, right? Is that really so interesting? Can you consider: a) using system() and/or b) removing "bootstrapped cminstall" from the automation. Just make it work with current and don't worry about 5.4 or lastrel. and/or c) Or wait and put it back after current release when lastrel becomes 5.8. You know, I think you'd want to exercise lastrel/5.4 as little as possible in getting current working and I think using cminstall goes past that. It is subjective though. I haven't actually tested the code with current yet, oops. - Jay ---------------------------------------- > Date: Tue, 28 Apr 2009 19:39:39 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 release build regression tests not terminating > > Hi Jay, > > thanks for reverting the offending changes to the installer. > I'm sure they were working OK when I tested them locally, and they > looked innocent enough. Sigh. Perhaps not worth to pursue the installer > issues further though. > > Have you found out why it hangs though? I haven't really understood > the problem yet. > > Sorry for the disturbances, > > Olaf > > Quoting Jay : > >> Tony can you clarify? Things stopped working two weeks ago? >> Or things were working until more recently? >> >> It seems like the select call never returns. >> Whatever is going on, it troubles debugging tools. >> gdb won't follow the children..which is probably ok, they aren't the problem. >> truss can't be control-c'ed, but can be killed. >> "info locals" in gdb often hangs and I have to pkill gdb. >> Not that info locals ever works well, but it usually doesn't hang gdb. >> I started putting in RTIO calls. >> WaitForAll's finishes one Wait call but then hangs on the next. >> >> I think we should not run cminstall against 5.4 runtime. >> Enable user threads as some related scenario.. >> >> >> - Jay >> >> >> ________________________________ >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>> Date: Tue, 28 Apr 2009 21:49:32 +1000 >>> >>> Sounds about right. >>> >>> 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 28 Apr 2009, at 21:17, Jay wrote: >>> >>> >>> The changes went in two weeks ago 4/14, were they definitely working? >>> I can try it again, hopefully without the full tinderbox stuff. >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Tue, 28 Apr 2009 21:11:42 +1000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>> >>> What could possibly have changed here. It used to work fine on >>> multiple platforms. >>> >>> On 28 Apr 2009, at 20:14, Jay wrote: >>> >>> >>> It creates a file named "df-k" and hangs here: >>> >>> (gdb) where >>> #0 0x080f417f in select () >>> #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, >>> writefds=0x28127138, >>> exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ >>> FreeBSD4/select.c:13 >>> #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, >>> M3_CEtG8K_timeout=0xbfbfe6d8) >>> at ThreadPosix.m3:714 >>> #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 >>> #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, >>> M3_AicXUJ_alertable=0 '\0') >>> at ThreadPosix.m3:555 >>> #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at >>> ThreadPosix.m3:539 >>> #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at >>> ProcessPosix.m3:294 >>> #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at >>> System.m3:527 >>> #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, >>> M3_EkfbeH_env=0x0, >>> M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 >>> #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at >>> OSPOSIX.m3:19 >>> #10 0x0804c31c in Main__DoIt () at Main.m3:122 >>> #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 >>> #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at >>> RTLinker.m3:395 >>> #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at >>> RTLinker.m3:109 >>> #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at >>> RTLinker.m3:118 >>> #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at >>> _m3main.mc:4 >>> >>> Notice it using user threads, so old m3core/libm3. >>> df doesn't appear to be any longer running. >>> Why it prints about the backend mode, I don't know. >>> >>> (and yes, I get it -- df -k is directly related to GetDiskSpace..if >>> this is how one checks diskspace on Unix...I think we should punt, >>> unless posix actually specifies the precise output format of this >>> command it is very reliably parsed...) >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com >>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: RE: [M3devel] CM3 release build regression tests not >>> terminating >>> Date: Tue, 28 Apr 2009 09:58:56 +0000 >>> >>> >>> Right, now it hangs having printed..I know this looks a bit of >>> nonsense..stuff from right around: >>> >>> >>> M3_BACKEND_MODE = "3" >>> % -- defines how the frontend, backend, and assembler interact >>> % "0" -- don't call m3_backend, M3CG produces object code >>> % "1" -- don't call m3_backend, M3CG produces assembly code >>> % "2" -- call m3_backend, it produces object code >>> % "3" -- call m3_backend, it produces assembly code >>> >>> >>> however, this is noticably pretty close to the last BEGIN_CONFIG. >>> >>> Maybe the carriage returns confused it. I'll see.. >>> I did introduce them recently by accident. >>> gdb reported some errors and no symbols in the callstack having >>> connected to it, on FreeBSD. If need be I can try debugging it on >>> another system.. >>> >>> >>> (aside, philosophy: all text processing code should treat \n, \r, >>> and \r\n in put the same, unless you are writing a terminal driver, >>> then \r has a separate meaning useful for implementing spinners..) >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> Date: Tue, 28 Apr 2009 11:40:00 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: RE: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> Quoting Jay : >>> >>> >>> Well, on FreeBSD 7.0, I get as far as: >>> >>> ew source -> compiling EnvUtils.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> ew source -> compiling EnvUtils.m3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> ew source -> compiling FingerprintFmt.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> ew source -> compiling TextUtils.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> >>> Yeah, I understand, I have libc.so.7. >>> >>> You need to install the FreeBSD compat packages for backward >>> compatibility. Should work fine then (until cminstall hangs?). >>> >>> Olaf >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> >>> I've never been able to get the tinderbox stuff to work for me. >>> I'll try again. >>> Nothing much from me lately -- pthreads movement to C, and then >>> back. >>> >>> Jay, did you change any config files recently? >>> >>> FreeBSD config file changes on 2009-04-13. >>> >>> - Jay >>> >>> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: wagner at elegosoft.com >>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> Yes, I had noticed this too. >>> >>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>> >>> Hi, >>> >>> does anybody know what's keeping the release-build tests for >>> tinderbox >>> from terminating? I've got lots of stalled regression process >>> trees on >>> my system, and the tinderbox display indicates that none of the >>> release >>> builds seem to succeed. Has anybody changed anything in the >>> scripts? >>> >>> On a closer look, upgrade seems to be stuck in the installer: >>> >>> % ps -axwww 25310 >>> PID TT STAT TIME COMMAND >>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>> luthien/current -o >>> >>> Jay, did you change any config files recently? >>> Regression tests seemed to have been running again for some >>> days, >>> and then >>> stopped again. >>> >>> I'll try to investigate further this evening, but must leave >>> now for >>> other work... >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>> 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> >>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Apr 29 01:11:47 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 28 Apr 2009 23:11:47 +0000 Subject: [M3devel] __thread? Message-ID: Angle brackets tend to get broken in my emails, very annoying, that should have stdio.h. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: __thread? > Date: Tue, 28 Apr 2009 16:32:16 +0000 > > > Mika, please let me know what this does for you, on the old FreeBSD 4.x? > > [jay at jkfbsd1 ~]$ cat 1.c > #include From jay.krell at cornell.edu Wed Apr 29 03:20:36 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 28 Apr 2009 18:20:36 -0700 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <20090428175916.GA9048@topoi.pooq.com> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <49F6E76E.1E75.00D7.1@scires.com> <20090428175916.GA9048@topoi.pooq.com> Message-ID: <9D57919B-69BA-4BEC-9319-5AC51E6CB6F1@hotmail.com> You can normalize the 'presentation' while maintaining the multiple forms..just because two things look the same on screen does mean they are the same, for better and worse. Most but not all code can be 'reasonable' and allow either or a mix. Just giving guidance for folks, subjective, as a user and implementer.. - Jay (phone) On Apr 28, 2009, at 10:59 AM, hendrik at topoi.pooq.com wrote: > On Tue, Apr 28, 2009 at 04:38:09PM +0000, Jay wrote: >> >> Randy just because everyone else does it poorly does not generally >> tie your hands. >> I said on input, not on output. >> Output does often tie your hands. > > There are situations wheere you need to recognize multiple ways of > representing newline without normalizing them. > > If you are writing an editor for text that is under revision control, > and you standardize newlines on input, and then write it out in any > consistent convention, you run the risk that revision control will > think > that huge numbers of lines have been changed. Of course, they have > been, but not intentionally. > > -- hendrik > From jay.krell at cornell.edu Wed Apr 29 03:57:23 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 28 Apr 2009 18:57:23 -0700 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <2565931E-F3F3-4832-8582-C1D227B556DA@cs.purdue.edu> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> <9AC96562-7045-418A-A069-84EE8613498A@cs.purdue.edu> <2565931E-F3F3-4832-8582-C1D227B556DA@cs.purdue.edu> Message-ID: <4FBC0000-EF60-4890-B125-7CB566813931@hotmail.com> Was it broken for two weeks, or shorter? - Jay (phone) On Apr 28, 2009, at 2:51 PM, Tony Hosking wrote: > Whatever changed in the last 24 hours has my tinderbox runs > completing now. > > On 28 Apr 2009, at 22:13, Jay wrote: > >> >> Tony can you clarify? Things stopped working two weeks ago? >> Or things were working until more recently? >> >> >> >> It seems like the select call never returns. >> Whatever is going on, it troubles debugging tools. >> gdb won't follow the children..which is probably ok, they aren't >> the problem. >> truss can't be control-c'ed, but can be killed. >> "info locals" in gdb often hangs and I have to pkill gdb. >> Not that info locals ever works well, but it usually doesn't hang >> gdb. >> I started putting in RTIO calls. >> WaitForAll's finishes one Wait call but then hangs on the next. >> >> >> I think we should not run cminstall against 5.4 runtime. >> Enable user threads as some related scenario.. >> >> >> - Jay >> >> >> ________________________________ >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Subject: Re: [M3devel] CM3 release build regression tests not >>> terminating >>> Date: Tue, 28 Apr 2009 21:49:32 +1000 >>> >>> Sounds about right. >>> >>> 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 28 Apr 2009, at 21:17, Jay wrote: >>> >>> >>> The changes went in two weeks ago 4/14, were they definitely >>> working? >>> I can try it again, hopefully without the full tinderbox stuff. >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Tue, 28 Apr 2009 21:11:42 +1000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> What could possibly have changed here. It used to work fine on >>> multiple platforms. >>> >>> On 28 Apr 2009, at 20:14, Jay wrote: >>> >>> >>> It creates a file named "df-k" and hangs here: >>> >>> (gdb) where >>> #0 0x080f417f in select () >>> #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, >>> writefds=0x28127138, >>> exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ >>> FreeBSD4/select.c:13 >>> #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, >>> M3_CEtG8K_timeout=0xbfbfe6d8) >>> at ThreadPosix.m3:714 >>> #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 >>> #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, >>> M3_AicXUJ_alertable=0 '\0') >>> at ThreadPosix.m3:555 >>> #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at >>> ThreadPosix.m3:539 >>> #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at >>> ProcessPosix.m3:294 >>> #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at >>> System.m3:527 >>> #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, >>> M3_EkfbeH_env=0x0, >>> M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 >>> #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at >>> OSPOSIX.m3:19 >>> #10 0x0804c31c in Main__DoIt () at Main.m3:122 >>> #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 >>> #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at >>> RTLinker.m3:395 >>> #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at >>> RTLinker.m3:109 >>> #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at >>> RTLinker.m3:118 >>> #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at >>> _m3main.mc:4 >>> >>> Notice it using user threads, so old m3core/libm3. >>> df doesn't appear to be any longer running. >>> Why it prints about the backend mode, I don't know. >>> >>> (and yes, I get it -- df -k is directly related to GetDiskSpace..if >>> this is how one checks diskspace on Unix...I think we should punt, >>> unless posix actually specifies the precise output format of this >>> command it is very reliably parsed...) >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com >>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: RE: [M3devel] CM3 release build regression tests not >>> terminating >>> Date: Tue, 28 Apr 2009 09:58:56 +0000 >>> >>> >>> Right, now it hangs having printed..I know this looks a bit of >>> nonsense..stuff from right around: >>> >>> >>> M3_BACKEND_MODE = "3" >>> % -- defines how the frontend, backend, and assembler interact >>> % "0" -- don't call m3_backend, M3CG produces object code >>> % "1" -- don't call m3_backend, M3CG produces assembly code >>> % "2" -- call m3_backend, it produces object code >>> % "3" -- call m3_backend, it produces assembly code >>> >>> >>> however, this is noticably pretty close to the last BEGIN_CONFIG. >>> >>> Maybe the carriage returns confused it. I'll see.. >>> I did introduce them recently by accident. >>> gdb reported some errors and no symbols in the callstack having >>> connected to it, on FreeBSD. If need be I can try debugging it on >>> another system.. >>> >>> >>> (aside, philosophy: all text processing code should treat \n, \r, >>> and \r\n in put the same, unless you are writing a terminal driver, >>> then \r has a separate meaning useful for implementing spinners..) >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> Date: Tue, 28 Apr 2009 11:40:00 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: RE: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> Quoting Jay : >>> >>> >>> Well, on FreeBSD 7.0, I get as far as: >>> >>> ew source -> compiling EnvUtils.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> ew source -> compiling EnvUtils.m3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> ew source -> compiling FingerprintFmt.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> ew source -> compiling TextUtils.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> >>> Yeah, I understand, I have libc.so.7. >>> >>> You need to install the FreeBSD compat packages for backward >>> compatibility. Should work fine then (until cminstall hangs?). >>> >>> Olaf >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> >>> I've never been able to get the tinderbox stuff to work for me. >>> I'll try again. >>> Nothing much from me lately -- pthreads movement to C, and then >>> back. >>> >>> Jay, did you change any config files recently? >>> >>> FreeBSD config file changes on 2009-04-13. >>> >>> - Jay >>> >>> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: wagner at elegosoft.com >>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> Yes, I had noticed this too. >>> >>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>> >>> Hi, >>> >>> does anybody know what's keeping the release-build tests for >>> tinderbox >>> from terminating? I've got lots of stalled regression process >>> trees on >>> my system, and the tinderbox display indicates that none of the >>> release >>> builds seem to succeed. Has anybody changed anything in the >>> scripts? >>> >>> On a closer look, upgrade seems to be stuck in the installer: >>> >>> % ps -axwww 25310 >>> PID TT STAT TIME COMMAND >>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>> luthien/current -o >>> >>> Jay, did you change any config files recently? >>> Regression tests seemed to have been running again for some >>> days, >>> and then >>> stopped again. >>> >>> I'll try to investigate further this evening, but must leave >>> now for >>> other work... >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>> 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> >>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 29 03:35:28 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 28 Apr 2009 18:35:28 -0700 Subject: [M3devel] manual initialization order? In-Reply-To: <557AEC0D-E50B-4A74-95B3-37AC2123878D@cs.purdue.edu> References: <557AEC0D-E50B-4A74-95B3-37AC2123878D@cs.purdue.edu> Message-ID: Ok I figured it might be. These modules should probably be disallowed from having any initializers, via a pragma. Require it all to be more explicit, in init. - Jay (phone) On Apr 28, 2009, at 2:41 PM, Tony Hosking wrote: > Indeed it is fragile, but necessary to bootstrap the system. > > On 29 Apr 2009, at 00:15, Jay wrote: > >> >> Um, if initializers are so acceptable (I'm skeptical, but everyone >> here disagrees with me..) and circularities are not allowed (that >> helps I guess..but is it really true? the garbage collector uses >> threads, the threading library allocates traced references..I sense >> circularity...)...why does RTLinker manually pick an initialization >> order? This is fragile. >> >> >> (* initialize the rest of the modules we'll be calling *) >> AddUnit (RTLinkerX.RTLinker_I3); (* myself! *) >> AddUnit (RTLinkerX.RT0_I3); >> AddUnit (RTLinkerX.RTSignal_I3); >> AddUnit (RTLinkerX.RTParams_I3); >> AddUnit (RTLinkerX.RTDebug_I3); >> AddUnit (RTLinkerX.RTError_I3); >> AddUnit (RTLinkerX.RTHeapRep_I3); >> AddUnit (RTLinkerX.ThreadF_I3); >> AddUnit (RTLinkerX.RTHeapInfo_I3); >> AddUnit (RTLinkerX.RTIO_I3); >> AddUnit (RTLinkerX.RTCollectorSRC_I3); >> AddUnit (RTLinkerX.Word_I3); >> >> >> >> (* finally, initialize the runtime. *) >> RTSignal.InstallHandlers (); >> RTParams.Init (); >> RTHeapRep.Init (); >> ThreadF.Init (); >> RTDebug.Init (); >> RTHeapInfo.Init (); >> IF RTParams.IsPresent("tracelinker") THEN >> traceInit := TRUE; >> END; >> >> >> AddUnit (RTLinkerX.RTDebug_M3); >> AddUnit (RTLinkerX.RTError_M3); >> AddUnit (RTLinkerX.RTType_M3); >> AddUnit (RTLinkerX.RTPacking_M3); >> AddUnit (RTLinkerX.RTTipe_M3); >> AddUnit (RTLinkerX.RTException_M3); > > From wagner at elegosoft.com Wed Apr 29 08:20:06 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 29 Apr 2009 08:20:06 +0200 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <2565931E-F3F3-4832-8582-C1D227B556DA@cs.purdue.edu> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> <9AC96562-7045-418A-A069-84EE8613498A@cs.purdue.edu> <2565931E-F3F3-4832-8582-C1D227B556DA@cs.purdue.edu> Message-ID: <20090429082006.pchddoojkw8kckgk@mail.elegosoft.com> Quoting Tony Hosking : > Whatever changed in the last 24 hours has my tinderbox runs completing now. Hm. The process doesn't hang anymore; I get the following errors though: (1) === package m3-libs/unittest-numeric === +++ /home/wagner/tmp/cm3/luthien/cm3/bin/cm3 -build -override -DROOT='/u/cm3/cm 3-ws/luthien-2009-04-29-01-30-32/cm3' +++ --- building in FreeBSD4 --- unable to read ../src/m3overrides, options "-override" and "-x" ignored. "/u/cm3/cm3-ws/luthien-2009-04-29-01-30-32/cm3/m3-libs/unittest-numeric/src/m3ma kefile", line 1: quake runtime error: unable to open "/home/wagner/tmp/cm3/luthi en/cm3/pkg/libm3/FreeBSD4/.M3EXPORTS" for reading --procedure-- -line- -file--- import -- include_dir 1 /u/cm3/cm3-ws/luthien-2009-04-29-01-30-32/cm3/m3-libs/uni ttest-numeric/src/m3makefile 5 /u/cm3/cm3-ws/luthien-2009-04-29-01-30-32/cm3/m3-libs/uni ttest-numeric/FreeBSD4/m3make.args Fatal Error: package build failed ==> m3-libs/unittest-numeric done (2) === package m3-sys/cm3ide === +++ /home/wagner/tmp/cm3/luthien/cm3/bin/cm3 -build -override -DROOT='/u/cm3/cm 3-ws/luthien-2009-04-29-01-30-32/cm3' +++ --- building in FreeBSD4 --- "/u/cm3/cm3-ws/luthien-2009-04-29-01-30-32/cm3/m3-sys/cm3ide/src/m3makefile", li ne 9: quake runtime error: unable to open "/u/cm3/cm3-ws/luthien-2009-04-29-01-3 0-32/cm3/m3-libs/tcp/FreeBSD4/.M3EXPORTS" for reading --procedure-- -line- -file--- import -- include_dir 9 /u/cm3/cm3-ws/luthien-2009-04-29-01-30-32/cm3/m3-sys/cm3i de/src/m3makefile 6 /u/cm3/cm3-ws/luthien-2009-04-29-01-30-32/cm3/m3-sys/cm3i de/FreeBSD4/m3make.args Fatal Error: package build failed ==> m3-sys/cm3ide done (3) === package m3-comm/stubgen === +++ /home/wagner/tmp/cm3/luthien/cm3/bin/cm3 -build -override -DROOT='/u/cm3/cm 3-ws/luthien-2009-04-29-01-30-32/cm3' +++ --- building in FreeBSD4 --- new source -> compiling Value.i3 new source -> compiling Type.i3 new source -> compiling ValueProc.i3 new source -> compiling Protocol.i3 new source -> compiling TypeNames.i3 new source -> compiling TypeNames.m3 new source -> compiling StubUtils.i3 new source -> compiling Type.m3 "../src/Type.m3", line 291: types are not assignable 1 error encountered new source -> compiling Value.m3 new source -> compiling AstToType.i3 new source -> compiling AstToVal.i3 new source -> compiling AstToVal.m3 new source -> compiling StubCode.i3 new source -> compiling FRefRefTbl.i3 new source -> compiling AstToType.m3 new source -> compiling ModuleStubCode.i3 new source -> compiling IntfStubCode.i3 new source -> compiling CodeForType.i3 new source -> compiling StubCode.m3 new source -> compiling CodeForType.m3 new source -> compiling ModuleStubCode.m3 new source -> compiling IntfStubCode.m3 new source -> compiling StubGenTool.i3 new source -> compiling StubGenTool.m3 new source -> compiling StubUtils.m3 new source -> compiling FRefRefTbl.m3 new source -> compiling Main.m3 new exporters -> recompiling ValueProc.i3 new exporters -> recompiling Type.i3 new opaque info -> recompiling TypeNames.m3 new opaque info -> recompiling AstToVal.m3 new opaque info -> recompiling AstToType.m3 new opaque info -> recompiling StubGenTool.m3 compilation failed => not building program "stubgen" Fatal Error: package build failed *** execution of /home/wagner/tmp/cm3/luthien/cm3/bin/cm3 -build -override -DROOT='/u/cm3/cm3-ws/luthien-2009-04-29-01-30-32/cm3' failed *** real 82m36.775s user 25m38.739s sys 14m12.884s Tinderbox currently does not show any success, too. It seems that still more is amiss. Olaf > > On 28 Apr 2009, at 22:13, Jay wrote: > >> >> Tony can you clarify? Things stopped working two weeks ago? >> Or things were working until more recently? >> >> >> >> It seems like the select call never returns. >> Whatever is going on, it troubles debugging tools. >> gdb won't follow the children..which is probably ok, they aren't >> the problem. >> truss can't be control-c'ed, but can be killed. >> "info locals" in gdb often hangs and I have to pkill gdb. >> Not that info locals ever works well, but it usually doesn't hang gdb. >> I started putting in RTIO calls. >> WaitForAll's finishes one Wait call but then hangs on the next. >> >> >> I think we should not run cminstall against 5.4 runtime. >> Enable user threads as some related scenario.. >> >> >> - Jay >> >> >> ________________________________ >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>> Date: Tue, 28 Apr 2009 21:49:32 +1000 >>> >>> Sounds about right. >>> >>> 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 28 Apr 2009, at 21:17, Jay wrote: >>> >>> >>> The changes went in two weeks ago 4/14, were they definitely working? >>> I can try it again, hopefully without the full tinderbox stuff. >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Tue, 28 Apr 2009 21:11:42 +1000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not terminating >>> >>> What could possibly have changed here. It used to work fine on >>> multiple platforms. >>> >>> On 28 Apr 2009, at 20:14, Jay wrote: >>> >>> >>> It creates a file named "df-k" and hangs here: >>> >>> (gdb) where >>> #0 0x080f417f in select () >>> #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, >>> writefds=0x28127138, >>> exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ >>> FreeBSD4/select.c:13 >>> #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, >>> M3_CEtG8K_timeout=0xbfbfe6d8) >>> at ThreadPosix.m3:714 >>> #3 0x080c993b in ThreadPosix__InternalYield () at ThreadPosix.m3:985 >>> #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, >>> M3_AicXUJ_alertable=0 '\0') >>> at ThreadPosix.m3:555 >>> #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at >>> ThreadPosix.m3:539 >>> #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at >>> ProcessPosix.m3:294 >>> #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at >>> System.m3:527 >>> #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, >>> M3_EkfbeH_env=0x0, >>> M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 >>> #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at >>> OSPOSIX.m3:19 >>> #10 0x0804c31c in Main__DoIt () at Main.m3:122 >>> #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 >>> #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at >>> RTLinker.m3:395 >>> #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at >>> RTLinker.m3:109 >>> #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at >>> RTLinker.m3:118 >>> #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) at >>> _m3main.mc:4 >>> >>> Notice it using user threads, so old m3core/libm3. >>> df doesn't appear to be any longer running. >>> Why it prints about the backend mode, I don't know. >>> >>> (and yes, I get it -- df -k is directly related to GetDiskSpace..if >>> this is how one checks diskspace on Unix...I think we should punt, >>> unless posix actually specifies the precise output format of this >>> command it is very reliably parsed...) >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: wagner at elegosoft.com >>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: RE: [M3devel] CM3 release build regression tests not >>> terminating >>> Date: Tue, 28 Apr 2009 09:58:56 +0000 >>> >>> >>> Right, now it hangs having printed..I know this looks a bit of >>> nonsense..stuff from right around: >>> >>> >>> M3_BACKEND_MODE = "3" >>> % -- defines how the frontend, backend, and assembler interact >>> % "0" -- don't call m3_backend, M3CG produces object code >>> % "1" -- don't call m3_backend, M3CG produces assembly code >>> % "2" -- call m3_backend, it produces object code >>> % "3" -- call m3_backend, it produces assembly code >>> >>> >>> however, this is noticably pretty close to the last BEGIN_CONFIG. >>> >>> Maybe the carriage returns confused it. I'll see.. >>> I did introduce them recently by accident. >>> gdb reported some errors and no symbols in the callstack having >>> connected to it, on FreeBSD. If need be I can try debugging it on >>> another system.. >>> >>> >>> (aside, philosophy: all text processing code should treat \n, \r, >>> and \r\n in put the same, unless you are writing a terminal driver, >>> then \r has a separate meaning useful for implementing spinners..) >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> Date: Tue, 28 Apr 2009 11:40:00 +0200 >>> From: wagner at elegosoft.com >>> To: jay.krell at cornell.edu >>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: RE: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> Quoting Jay : >>> >>> >>> Well, on FreeBSD 7.0, I get as far as: >>> >>> ew source -> compiling EnvUtils.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> ew source -> compiling EnvUtils.m3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> ew source -> compiling FingerprintFmt.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> ew source -> compiling TextUtils.i3 >>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>> required by "cm3cg" >>> >>> Yeah, I understand, I have libc.so.7. >>> >>> You need to install the FreeBSD compat packages for backward >>> compatibility. Should work fine then (until cminstall hangs?). >>> >>> Olaf >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> >>> I've never been able to get the tinderbox stuff to work for me. >>> I'll try again. >>> Nothing much from me lately -- pthreads movement to C, and then >>> back. >>> >>> Jay, did you change any config files recently? >>> >>> FreeBSD config file changes on 2009-04-13. >>> >>> - Jay >>> >>> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: wagner at elegosoft.com >>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>> Subject: Re: [M3devel] CM3 release build regression tests not >>> terminating >>> >>> Yes, I had noticed this too. >>> >>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>> >>> Hi, >>> >>> does anybody know what's keeping the release-build tests for >>> tinderbox >>> from terminating? I've got lots of stalled regression process >>> trees on >>> my system, and the tinderbox display indicates that none of the >>> release >>> builds seem to succeed. Has anybody changed anything in the >>> scripts? >>> >>> On a closer look, upgrade seems to be stuck in the installer: >>> >>> % ps -axwww 25310 >>> PID TT STAT TIME COMMAND >>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>> luthien/current -o >>> >>> Jay, did you change any config files recently? >>> Regression tests seemed to have been running again for some >>> days, >>> and then >>> stopped again. >>> >>> I'll try to investigate further this evening, but must leave >>> now for >>> other work... >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>> 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> >>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 mika at async.caltech.edu Wed Apr 29 08:22:35 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 28 Apr 2009 23:22:35 -0700 Subject: [M3devel] [M3commit] how to switch userthreads on/off In-Reply-To: Your message of "Wed, 29 Apr 2009 00:06:02 -0000." Message-ID: <200904290622.n3T6MZBR003219@camembert.async.caltech.edu> Jay writes: ... > >Maybe just leave it as an option in m3core's m3makefile and people can twiddle it if they want and rebuild the entire system like it is today? >That is a bit onerous, but maybe it's all userthreads deserve? >? > > >Anyone who actually wanted to switch back and forth (Mika) would just have two installs and two source trees? > > > - Jay I just want to clarify. I'm not really that interested in switching back and forth. I'm just a little disturbed by the sometimes huge performance loss due to the introduction of kernel threads. I knew that this would happen in certain highly multithreaded applications, but I'm surprised it happens in a more or less single-threaded application. I think I've just been spoiled by 10 years of using SRCM3 and PM3 for FreeBSD w/o kernel threads in the sense that I've learned that using LOCK has essentially no cost. On a shared-memory multiprocessor, I really don't expect that to remain the case... physics won't allow it. So now I just have to go through my code and find all the places where I lock too much and remove them. But the memory allocator and garbage collector do it too, no? I also think that this idea of being able to use either is great. Mainly single-threaded programs should definitely not use kernel threads! As for reaching the "thread locals", there is one slightly crazy idea that one could borrow from Sussman and Steele: add another implicit argument to every Modula-3 routine. In that argument, pass a pointer to the thread locals. For EXTERNAL calls (in or out), make it NIL (somehow, maybe involving pragmas), and in that case (only), use the pthreads routines to access the thread locals. Ok so it sounds kind of nuts, but with this approach you could avoid locking or even calling into the pthreads libs almost entirely for a single-threaded program. You could even have a thread-local memory allocator that would only lock when it needs to request memory from the "global allocator"... in fact there are lots of things you can do with this sort of thing. Dynamically scoped variables in Scheme (a la MacLisp?) is what they originally proposed it for but then they suggested all kinds of tricks related to continuations with it. Mika From mika at async.caltech.edu Wed Apr 29 08:53:32 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 28 Apr 2009 23:53:32 -0700 Subject: [M3devel] user threads In-Reply-To: Your message of "Tue, 28 Apr 2009 16:54:03 -0000." Message-ID: <200904290653.n3T6rW8b004699@camembert.async.caltech.edu> Ok, it works! Numbers: Timings in milliseconds, three samples, filesystem "warmed up" by doing one dummy run before launching the real ones. -unsafe means that I use non-locking Scheme environments, otherwise they lock for every variable update. ave CM3 last week, kernel threads, -unsafe 1460 1482 1437 1460 CM3 last week, kernel threads, 2392 2402 2376 2390 CM3 this week, kernel threads, -unsafe 1455 1458 1490 1468 (*) CM3 this week, user threads, -unsafe 914 934 914 921 CM3 this week, user threads, 967 965 986 973 PM3 -unsafe 678 657 682 672 PM3 709 714 700 708 (*) not entirely sure this got linked correctly. Mika Jay writes: > >User threads seem to work on on FreeBSD/x86 7.0. >Mika can you report back the perf cm3 vs. pm3? >Still, kernel threads have been around a long time and imho should be strongly favored.. > > >Kernel threads should be a /little/ faster than they were -- PushEFrame removed from successful heap allocations. And should be further improvable via __thread where it is supported -- probably not FreeBSD 4. >x, sometimes older is not better. :) > > >I've temporarily switched FreeBSD/x86 to userthreads by default but I think that's just an experiment and should be undone shortly, maybe work out some other story for easily switching between them, or just k >eep the existing story of "you get to rebuild everything". > > >Tony, can you look into GetGCRatio? I removed the call to it. The "fatal" pragma invokes PushEFrame apparently. > > >We should now "fix" Win32 and pthreads to not have GetActivation initialize on-demand, just leave Init to initialize always. This should shave a few more cycles from PushEFrame. > > > - Jay From mika at async.caltech.edu Wed Apr 29 08:58:16 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 28 Apr 2009 23:58:16 -0700 Subject: [M3devel] user threads In-Reply-To: Your message of "Tue, 28 Apr 2009 23:53:32 PDT." <200904290653.n3T6rW8b004699@camembert.async.caltech.edu> Message-ID: <200904290658.n3T6wGl3004945@camembert.async.caltech.edu> By the way, *all* my CM3 timings have my Typecase modification, which isn't checked in to the distribution. I think they would all be about 400 ms slower if they didn't have that. A bit of "poor man's profiling" shows the program still spending quite some time in RTType.IsSubtype (called from CheckIsType). I think that accounts for most of the remaining difference between PM3 and CM3. Mika Mika Nystrom writes: >Ok, it works! > >Numbers: > >Timings in milliseconds, three samples, filesystem "warmed up" by >doing one dummy run before launching the real ones. > >-unsafe means that I use non-locking Scheme environments, otherwise >they lock for every variable update. > ave >CM3 last week, kernel threads, -unsafe 1460 1482 1437 1460 >CM3 last week, kernel threads, 2392 2402 2376 2390 >CM3 this week, kernel threads, -unsafe 1455 1458 1490 1468 (*) >CM3 this week, user threads, -unsafe 914 934 914 921 >CM3 this week, user threads, 967 965 986 973 >PM3 -unsafe 678 657 682 672 >PM3 709 714 700 708 > >(*) not entirely sure this got linked correctly. > > Mika > > >Jay writes: >> >>User threads seem to work on on FreeBSD/x86 7.0. >>Mika can you report back the perf cm3 vs. pm3? >>Still, kernel threads have been around a long time and imho should be strongly favored.. >> >> >>Kernel threads should be a /little/ faster than they were -- PushEFrame removed from successful heap allocations. And should be further improvable via __thread where it is supported -- probably not FreeBSD 4 >. >>x, sometimes older is not better. :) >> >> >>I've temporarily switched FreeBSD/x86 to userthreads by default but I think that's just an experiment and should be undone shortly, maybe work out some other story for easily switching between them, or just >k >>eep the existing story of "you get to rebuild everything". >> >> >>Tony, can you look into GetGCRatio? I removed the call to it. The "fatal" pragma invokes PushEFrame apparently. >> >> >>We should now "fix" Win32 and pthreads to not have GetActivation initialize on-demand, just leave Init to initialize always. This should shave a few more cycles from PushEFrame. >> >> >> - Jay From jay.krell at cornell.edu Wed Apr 29 09:05:10 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 29 Apr 2009 07:05:10 +0000 Subject: [M3devel] user threads In-Reply-To: <200904290653.n3T6rW8b004699@camembert.async.caltech.edu> References: Your message of "Tue, 28 Apr 2009 16:54:03 -0000." <200904290653.n3T6rW8b004699@camembert.async.caltech.edu> Message-ID: Mika, thanks. Want to try the next variation? look at m3-libs/m3core/src/thread/PTHREAD/ThreadPThreadC.c. See THREAD_LOCAL, THREAD_LOCAL_SLOW, THREAD_LOCAL_FAST? Try switching THREAD_LOCAL to use THREAD_LOCAL_FAST instead of _SLOW. On FreeBSD 5.x or newer. It won't compile for 4.x we know. Thanks, - Jay > To: jay.krell at cornell.edu > Date: Tue, 28 Apr 2009 23:53:32 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] user threads > > Ok, it works! > > Numbers: > > Timings in milliseconds, three samples, filesystem "warmed up" by > doing one dummy run before launching the real ones. > > -unsafe means that I use non-locking Scheme environments, otherwise > they lock for every variable update. > ave > CM3 last week, kernel threads, -unsafe 1460 1482 1437 1460 > CM3 last week, kernel threads, 2392 2402 2376 2390 > CM3 this week, kernel threads, -unsafe 1455 1458 1490 1468 (*) > CM3 this week, user threads, -unsafe 914 934 914 921 > CM3 this week, user threads, 967 965 986 973 > PM3 -unsafe 678 657 682 672 > PM3 709 714 700 708 > > (*) not entirely sure this got linked correctly. > > Mika > > > Jay writes: > > > >User threads seem to work on on FreeBSD/x86 7.0. > >Mika can you report back the perf cm3 vs. pm3? > >Still, kernel threads have been around a long time and imho should be strongly favored.. > > > > > >Kernel threads should be a /little/ faster than they were -- PushEFrame removed from successful heap allocations. And should be further improvable via __thread where it is supported -- probably not FreeBSD 4. > >x, sometimes older is not better. :) > > > > > >I've temporarily switched FreeBSD/x86 to userthreads by default but I think that's just an experiment and should be undone shortly, maybe work out some other story for easily switching between them, or just k > >eep the existing story of "you get to rebuild everything". > > > > > >Tony, can you look into GetGCRatio? I removed the call to it. The "fatal" pragma invokes PushEFrame apparently. > > > > > >We should now "fix" Win32 and pthreads to not have GetActivation initialize on-demand, just leave Init to initialize always. This should shave a few more cycles from PushEFrame. > > > > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Apr 29 09:18:42 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 29 Apr 2009 00:18:42 -0700 Subject: [M3devel] user threads In-Reply-To: Your message of "Tue, 28 Apr 2009 23:58:16 PDT." <200904290658.n3T6wGl3004945@camembert.async.caltech.edu> Message-ID: <200904290718.n3T7Ig6b005836@camembert.async.caltech.edu> Of course I just realized this typecase business doesn't work. Not thread-safe. The numbers for CM3 are worse than I write... sigh, ok, back to the drawing board. Mika Nystrom writes: >By the way, *all* my CM3 timings have my Typecase modification, >which isn't checked in to the distribution. I think they would all >be about 400 ms slower if they didn't have that. > >A bit of "poor man's profiling" shows the program still spending >quite some time in RTType.IsSubtype (called from CheckIsType). >I think that accounts for most of the remaining difference between >PM3 and CM3. > > Mika > >Mika Nystrom writes: >>Ok, it works! >> >>Numbers: >> >>Timings in milliseconds, three samples, filesystem "warmed up" by >>doing one dummy run before launching the real ones. >> >>-unsafe means that I use non-locking Scheme environments, otherwise >>they lock for every variable update. >> ave >>CM3 last week, kernel threads, -unsafe 1460 1482 1437 1460 >>CM3 last week, kernel threads, 2392 2402 2376 2390 >>CM3 this week, kernel threads, -unsafe 1455 1458 1490 1468 (*) >>CM3 this week, user threads, -unsafe 914 934 914 921 >>CM3 this week, user threads, 967 965 986 973 >>PM3 -unsafe 678 657 682 672 >>PM3 709 714 700 708 >> >>(*) not entirely sure this got linked correctly. >> >> Mika >> >> >>Jay writes: >>> >>>User threads seem to work on on FreeBSD/x86 7.0. >>>Mika can you report back the perf cm3 vs. pm3? >>>Still, kernel threads have been around a long time and imho should be strongly favored.. >>> >>> >>>Kernel threads should be a /little/ faster than they were -- PushEFrame removed from successful heap allocations. And should be further improvable via __thread where it is supported -- probably not FreeBSD >4 >>. >>>x, sometimes older is not better. :) >>> >>> >>>I've temporarily switched FreeBSD/x86 to userthreads by default but I think that's just an experiment and should be undone shortly, maybe work out some other story for easily switching between them, or just > >>k >>>eep the existing story of "you get to rebuild everything". >>> >>> >>>Tony, can you look into GetGCRatio? I removed the call to it. The "fatal" pragma invokes PushEFrame apparently. >>> >>> >>>We should now "fix" Win32 and pthreads to not have GetActivation initialize on-demand, just leave Init to initialize always. This should shave a few more cycles from PushEFrame. >>> >>> >>> - Jay From jay.krell at cornell.edu Wed Apr 29 09:26:05 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 29 Apr 2009 07:26:05 +0000 Subject: [M3devel] [M3commit] how to switch userthreads on/off In-Reply-To: <200904290622.n3T6MZBR003219@camembert.async.caltech.edu> References: Your message of "Wed, 29 Apr 2009 00:06:02 -0000." <200904290622.n3T6MZBR003219@camembert.async.caltech.edu> Message-ID: > But the memory allocator and garbage collector do it too, no? Right, the garbage collector runs a separate thread. > As for reaching the "thread locals", there is one slightly crazy > idea that one could borrow from Sussman and Steele: add another > implicit argument to every Modula-3 routine. In that argument, > pass a pointer to the thread locals. For EXTERNAL calls (in or This is basically how it works already on many systems. Just not FreeBSD <5, where there's no kernel thread support for managing the register at thread switch time. Look at the assembly code for __thread on FreeBSD 5. Notice that they do dedicate a register to thread locals. So it is about the same as what you propose, but better because they use a wierdo (segment) register that otherwise was unused. (Most other architectures can afford to give up a regular register. The "better" part is specific to x86 having so few registers.) I'm hoping to lay most of the blame on FreeBSD 4.x pthread_get/setspecific. But there is still setjmp lurking in there, even on PM3, no matter user or pthreads. Do you have numbers for FreeBSD 5 PM3 vs. CM3 pthreads? __thread should be faster than pthread_get/setspecific, but pthread_get/setspecific are probably also way better with kernel threads vs. FreeBSD 4 usermode pthreads.. Olaf, your recall that FreeBSD userthreads were "fast"..is that based on FreeBSD 4.x by chance? Maybe they don't have much advantage on any other system? You know...FreeBSD 4.x pthreads are also userthreads, not really a fair comparison maybe with other pthreads implementations and maybe give pthreads a bad name? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 29 14:27:48 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 29 Apr 2009 12:27:48 +0000 Subject: [M3devel] coping with low memory/resources? Message-ID: coping with low memory/resources? We have code that does like r := pthread_do_something() assert(r == 0); where for example: [EAGAIN] The system lacked the necessary resources (other than memory) to initialise another mutex. [ENOMEM] Insufficient memory exists to initialise the mutex. I'll fix it to raise an out of memory exception for ENOMEM. Ok. But what about EAGAIN? Retry? That is what "again" means, right? In an infinite loop? Or just a few times? You know -- overall system might be low but other parts might reduce, or the Modula-3 code itself might be hogging resources and retry might just sit there forever. Raise some other exception? For now I'll leave it asserting. - Jay From jay.krell at cornell.edu Wed Apr 29 16:12:37 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 29 Apr 2009 14:12:37 +0000 Subject: [M3devel] any limitations on __thread? Message-ID: Anyone have expertise on __thread? In particular, on Windows there is a close analog __declspec(thread) that generally would seem to work and work well, except that, per documentation, prior to Vista, it doesn't work if you are loaded with LoadLibrary (dlopen), only if the main executable uses your .so, directly or indirectly. To me that's a pretty big limitation so I wouldn't use it. I haven't seen any documentation on __thread giving this caveat though so it seems ok to use. I changed m3core to use it if sample code seems to compile, link, and execute correctly with it. - Jay From mika at async.caltech.edu Wed Apr 29 18:22:36 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 29 Apr 2009 09:22:36 -0700 Subject: [M3devel] [M3commit] how to switch userthreads on/off In-Reply-To: Your message of "Wed, 29 Apr 2009 07:26:05 -0000." Message-ID: <200904291622.n3TGMaEA031447@camembert.async.caltech.edu> Jay: I understand now. I should do more research first. libc_r is a user-level threads package, and not a very good one at that. The built-into-Modula-3 threads offer all the same facilities as FreeBSD's libc_r, as well as much higher performance. In view of that, I think it's great that you've resurrected CM3's user threads. No reason not to use them on FreeBSD4. Now to test on FreeBSD5. I still don't quite understand why kernel threads should be faster than user threads. But since all I have at the moment is libc_r, I can't back up my doubts with any numbers. Mika Jay writes: >--_2ce3dd88-b4b7-4b0b-8d3d-405d9122c9e1_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > But the memory allocator and garbage collector do it too=2C no?=20 > >=20 > >=20 > >Right=2C the garbage collector runs a separate thread. > >=20 > > > > As for reaching the "thread locals"=2C there is one slightly crazy=20 > > idea that one could borrow from Sussman and Steele: add another=20 > > implicit argument to every Modula-3 routine. In that argument=2C=20 > > pass a pointer to the thread locals. For EXTERNAL calls (in or=20 > > >=20 > >This is basically how it works already on many systems. > >Just not FreeBSD <5=2C where there's no kernel thread support for managing > >the register at thread switch time. > >=20 > >Look at the assembly code for __thread on FreeBSD 5. > >=20 > >Notice that they do dedicate a register to thread locals. > >So it is about the same as what you propose=2C but better because they use = >a wierdo (segment) register that otherwise was unused. (Most other architec= >tures can afford to give up a regular register. The "better" part is specif= >ic to x86 having so few registers.) > >=20 > >=20 > >I'm hoping to lay most of the blame on FreeBSD 4.x pthread_get/setspecific. > >But there is still setjmp lurking in there=2C even on PM3=2C no matter user= > or pthreads. > >=20 > >=20 > >Do you have numbers for FreeBSD 5 PM3 vs. CM3 pthreads? > >__thread should be faster than pthread_get/setspecific=2C but pthread_get/s= >etspecific are probably also way better with kernel threads vs. FreeBSD 4 u= >sermode pthreads.. > >=20 > >=20 > >Olaf=2C your recall that FreeBSD userthreads were "fast"..is that based on = >FreeBSD 4.x by chance? Maybe they don't have much advantage on any other sy= >stem? > >You know...FreeBSD 4.x pthreads are also userthreads=2C not really a fair c= >omparison maybe with other pthreads implementations and maybe give pthreads= > a bad name? > >=20 > >=20 > > - Jay > >=20 > >--_2ce3dd88-b4b7-4b0b-8d3d-405d9122c9e1_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > > =3B>=3B But the memory allocator and garbage collector do it too=2C = >no?
> =3B
> =3B
>Right=2C the garbage collector runs a separate thread.
> =3B
>
 =3B>=3B As for reaching the "thread locals"=2C there is one slig= >htly crazy
 =3B>=3B idea that one could borrow from Sussman and S= >teele: add another
 =3B>=3B implicit argument to every Modula-3 r= >outine. In that argument=2C
 =3B>=3B pass a pointer to the thread= > locals. For EXTERNAL calls (in or

> =3B
>This is basically how it works already on many systems.
>Just not FreeBSD <=3B5=2C where there's no kernel thread support for mana= >ging
>the register at thread switch time.
> =3B
>Look at the assembly code for __thread on FreeBSD 5.
> =3B
>Notice that they do dedicate a register to thread locals.
>So it is about the same as what you propose=2C but better because they = >=3Buse a wierdo (segment) register that otherwise was unused. (Most other a= >rchitectures can afford to give up a regular register. The "better" part is= > specific to x86 having so few registers.)
> =3B
> =3B
>I'm hoping to lay most of the blame on FreeBSD 4.x pthread_get/setspecific.= >
>But there is still setjmp lurking in there=2C even on PM3=2C no matter user= > or pthreads.
> =3B
> =3B
>Do you have numbers for FreeBSD 5 PM3 vs. CM3 pthreads?
>__thread should be faster than pthread_get/setspecific=2C but pthread_get/s= >etspecific are probably also way better with kernel threads vs. =3BFree= >BSD 4 usermode pthreads..
> =3B
> =3B
>Olaf=2C =3Byour recall that FreeBSD userthreads were =3B"fast"..is = >that based on FreeBSD 4.x by chance? Maybe they don't have much advantage o= >n any other system?
>You know...FreeBSD 4.x pthreads are also userthreads=2C not really a fair c= >omparison maybe with other pthreads implementations and maybe give pthreads= > a bad name?
> =3B
> =3B
> =3B- Jay
> =3B
>= > >--_2ce3dd88-b4b7-4b0b-8d3d-405d9122c9e1_-- From hosking at cs.purdue.edu Wed Apr 29 20:00:09 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 30 Apr 2009 04:00:09 +1000 Subject: [M3devel] CM3 release build regression tests not terminating In-Reply-To: <4FBC0000-EF60-4890-B125-7CB566813931@hotmail.com> References: <20090428082937.rd0se2lwys0ckwwo@mail.elegosoft.com> <4FD1B26E-88F1-410A-9F9B-3F5B1C34CE3E@cs.purdue.edu> <20090428114000.kghi05wbw484cook@mail.elegosoft.com> <11F4B327-CCF9-4D3D-A8C3-FF5A144F5DB0@cs.purdue.edu> <9AC96562-7045-418A-A069-84EE8613498A@cs.purdue.edu> <2565931E-F3F3-4832-8582-C1D227B556DA@cs.purdue.edu> <4FBC0000-EF60-4890-B125-7CB566813931@hotmail.com> Message-ID: I'd say about 2 weeks. On 29 Apr 2009, at 11:57, jay.krell at cornell.edu wrote: > Was it broken for two weeks, or shorter? > > - Jay (phone) > > On Apr 28, 2009, at 2:51 PM, Tony Hosking > wrote: > >> Whatever changed in the last 24 hours has my tinderbox runs >> completing now. >> >> On 28 Apr 2009, at 22:13, Jay wrote: >> >>> >>> Tony can you clarify? Things stopped working two weeks ago? >>> Or things were working until more recently? >>> >>> >>> >>> It seems like the select call never returns. >>> Whatever is going on, it troubles debugging tools. >>> gdb won't follow the children..which is probably ok, they aren't >>> the problem. >>> truss can't be control-c'ed, but can be killed. >>> "info locals" in gdb often hangs and I have to pkill gdb. >>> Not that info locals ever works well, but it usually doesn't hang >>> gdb. >>> I started putting in RTIO calls. >>> WaitForAll's finishes one Wait call but then hangs on the next. >>> >>> >>> I think we should not run cminstall against 5.4 runtime. >>> Enable user threads as some related scenario.. >>> >>> >>> - Jay >>> >>> >>> ________________________________ >>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>> From: hosking at cs.purdue.edu >>>> To: jay.krell at cornell.edu >>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>> terminating >>>> Date: Tue, 28 Apr 2009 21:49:32 +1000 >>>> >>>> Sounds about right. >>>> >>>> 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 28 Apr 2009, at 21:17, Jay wrote: >>>> >>>> >>>> The changes went in two weeks ago 4/14, were they definitely >>>> working? >>>> I can try it again, hopefully without the full tinderbox stuff. >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> To: jay.krell at cornell.edu >>>> Date: Tue, 28 Apr 2009 21:11:42 +1000 >>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>> terminating >>>> >>>> What could possibly have changed here. It used to work fine on >>>> multiple platforms. >>>> >>>> On 28 Apr 2009, at 20:14, Jay wrote: >>>> >>>> >>>> It creates a file named "df-k" and hangs here: >>>> >>>> (gdb) where >>>> #0 0x080f417f in select () >>>> #1 0x080e0567 in m3_select (nfds=0, readfds=0x28127128, >>>> writefds=0x28127138, >>>> exceptfds=0x28127148, timeout=0xbfbfe6d8) at ../src/runtime/ >>>> FreeBSD4/select.c:13 >>>> #2 0x080c840e in ThreadPosix__CallSelect (M3_Cwb5VA_nfd=0, >>>> M3_CEtG8K_timeout=0xbfbfe6d8) >>>> at ThreadPosix.m3:714 >>>> #3 0x080c993b in ThreadPosix__InternalYield () at >>>> ThreadPosix.m3:985 >>>> #4 0x080c755f in ThreadPosix__XPause (M3_DZQH1o_until=0xbfbfe770, >>>> M3_AicXUJ_alertable=0 '\0') >>>> at ThreadPosix.m3:555 >>>> #5 0x080c746b in Thread__Pause (M3_CtKayy_n=0.10000000000000001) at >>>> ThreadPosix.m3:539 >>>> #6 0x0808c8d4 in Process__Wait (M3_AUwVTW_p=0x2813ae94) at >>>> ProcessPosix.m3:294 >>>> #7 0x08080b31 in System__ExecuteList__WaitForAll.1 () at >>>> System.m3:527 >>>> #8 0x08082013 in System__ExecuteList (M3_Bd56fi_cmd=0x2813a564, >>>> M3_EkfbeH_env=0x0, >>>> M3_DLmMvC_msgif=0x0, M3_Bd56fi_wd=0x0) at System.m3:737 >>>> #9 0x0804bc1e in OS__GetDiskSpace (M3_Bd56fi_dir=0x28136f14) at >>>> OSPOSIX.m3:19 >>>> #10 0x0804c31c in Main__DoIt () at Main.m3:122 >>>> #11 0x0805107c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:1078 >>>> #12 0x080bb77e in RTLinker__RunMainBody (M3_DjPxE3_m=0x81270a0) at >>>> RTLinker.m3:395 >>>> #13 0x080bad24 in RTLinker__AddUnitI (M3_DjPxE3_m=0x81270a0) at >>>> RTLinker.m3:109 >>>> #14 0x080badaa in RTLinker__AddUnit (M3_DjPxE5_b=0x8051031) at >>>> RTLinker.m3:118 >>>> #15 0x08048220 in main (argc=4, argv=0xbfbfec78, envp=0xbfbfec8c) >>>> at >>>> _m3main.mc:4 >>>> >>>> Notice it using user threads, so old m3core/libm3. >>>> df doesn't appear to be any longer running. >>>> Why it prints about the backend mode, I don't know. >>>> >>>> (and yes, I get it -- df -k is directly related to GetDiskSpace..if >>>> this is how one checks diskspace on Unix...I think we should punt, >>>> unless posix actually specifies the precise output format of this >>>> command it is very reliably parsed...) >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: wagner at elegosoft.com >>>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>>> Subject: RE: [M3devel] CM3 release build regression tests not >>>> terminating >>>> Date: Tue, 28 Apr 2009 09:58:56 +0000 >>>> >>>> >>>> Right, now it hangs having printed..I know this looks a bit of >>>> nonsense..stuff from right around: >>>> >>>> >>>> M3_BACKEND_MODE = "3" >>>> % -- defines how the frontend, backend, and assembler interact >>>> % "0" -- don't call m3_backend, M3CG produces object code >>>> % "1" -- don't call m3_backend, M3CG produces assembly code >>>> % "2" -- call m3_backend, it produces object code >>>> % "3" -- call m3_backend, it produces assembly code >>>> >>>> >>>> however, this is noticably pretty close to the last BEGIN_CONFIG. >>>> >>>> Maybe the carriage returns confused it. I'll see.. >>>> I did introduce them recently by accident. >>>> gdb reported some errors and no symbols in the callstack having >>>> connected to it, on FreeBSD. If need be I can try debugging it on >>>> another system.. >>>> >>>> >>>> (aside, philosophy: all text processing code should treat \n, \r, >>>> and \r\n in put the same, unless you are writing a terminal driver, >>>> then \r has a separate meaning useful for implementing spinners..) >>>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>> Date: Tue, 28 Apr 2009 11:40:00 +0200 >>>> From: wagner at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com; manderson at elegosoft.com >>>> Subject: RE: [M3devel] CM3 release build regression tests not >>>> terminating >>>> >>>> Quoting Jay : >>>> >>>> >>>> Well, on FreeBSD 7.0, I get as far as: >>>> >>>> ew source -> compiling EnvUtils.i3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> ew source -> compiling EnvUtils.m3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> ew source -> compiling FingerprintFmt.i3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> ew source -> compiling TextUtils.i3 >>>> libexec/ld-elf.so.1: Shared object "libc.so.6" not found, >>>> required by "cm3cg" >>>> >>>> Yeah, I understand, I have libc.so.7. >>>> >>>> You need to install the FreeBSD compat packages for backward >>>> compatibility. Should work fine then (until cminstall hangs?). >>>> >>>> Olaf >>>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: hosking at cs.purdue.edu; wagner at elegosoft.com >>>> Date: Tue, 28 Apr 2009 07:45:14 +0000 >>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>> terminating >>>> >>>> >>>> I've never been able to get the tinderbox stuff to work for me. >>>> I'll try again. >>>> Nothing much from me lately -- pthreads movement to C, and then >>>> back. >>>> >>>> Jay, did you change any config files recently? >>>> >>>> FreeBSD config file changes on 2009-04-13. >>>> >>>> - Jay >>>> >>>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> To: wagner at elegosoft.com >>>> Date: Tue, 28 Apr 2009 16:45:29 +1000 >>>> CC: m3devel at elegosoft.com; manderson at elegosoft.com >>>> Subject: Re: [M3devel] CM3 release build regression tests not >>>> terminating >>>> >>>> Yes, I had noticed this too. >>>> >>>> On 28 Apr 2009, at 16:29, Olaf Wagner wrote: >>>> >>>> Hi, >>>> >>>> does anybody know what's keeping the release-build tests for >>>> tinderbox >>>> from terminating? I've got lots of stalled regression process >>>> trees on >>>> my system, and the tinderbox display indicates that none of the >>>> release >>>> builds seem to succeed. Has anybody changed anything in the >>>> scripts? >>>> >>>> On a closer look, upgrade seems to be stuck in the installer: >>>> >>>> % ps -axwww 25310 >>>> PID TT STAT TIME COMMAND >>>> 25310 ?? S 2:15.61 /home/wagner/work/cm3-inst/luthien/current/ >>>> pkg/cminstall/FreeBSD4/cminstall -c /home/wagner/work/cm3-inst/ >>>> luthien/current -o >>>> >>>> Jay, did you change any config files recently? >>>> Regression tests seemed to have been running again for some >>>> days, >>>> and then >>>> stopped again. >>>> >>>> I'll try to investigate further this evening, but must leave >>>> now for >>>> other work... >>>> >>>> Olaf >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>> Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>> 23 >>>> 45 86 95 >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>>> Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>> DE163214194 >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Wed Apr 29 20:04:22 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 30 Apr 2009 04:04:22 +1000 Subject: [M3devel] user threads In-Reply-To: <200904290653.n3T6rW8b004699@camembert.async.caltech.edu> References: <200904290653.n3T6rW8b004699@camembert.async.caltech.edu> Message-ID: <736196D3-6AA1-49C4-80E8-4EEB05B38CFC@cs.purdue.edu> Mika, it is not surprising that your lock-on-every variable update will cost a lot in any non-user-level threading scheme. You should consider using different mechanisms for this degree of locking in Scheme (based on some of the non-blocking lock implementations for Java perhaps). I don't expect any implementation of locking for a multi-core/-processor will ever perform as well as user-level threads. On 29 Apr 2009, at 16:53, Mika Nystrom wrote: > Ok, it works! > > Numbers: > > Timings in milliseconds, three samples, filesystem "warmed up" by > doing one dummy run before launching the real ones. > > -unsafe means that I use non-locking Scheme environments, otherwise > they lock for every variable update. > ave > CM3 last week, kernel threads, -unsafe 1460 1482 1437 1460 > CM3 last week, kernel threads, 2392 2402 2376 2390 > CM3 this week, kernel threads, -unsafe 1455 1458 1490 1468 (*) > CM3 this week, user threads, -unsafe 914 934 914 921 > CM3 this week, user threads, 967 965 986 973 > PM3 -unsafe 678 657 682 672 > PM3 709 714 700 708 > > (*) not entirely sure this got linked correctly. > > Mika > > > Jay writes: >> >> User threads seem to work on on FreeBSD/x86 7.0. >> Mika can you report back the perf cm3 vs. pm3? >> Still, kernel threads have been around a long time and imho should >> be strongly favored.. >> >> >> Kernel threads should be a /little/ faster than they were -- >> PushEFrame removed from successful heap allocations. And should be >> further improvable via __thread where it is supported -- probably >> not FreeBSD 4. >> x, sometimes older is not better. :) >> >> >> I've temporarily switched FreeBSD/x86 to userthreads by default but >> I think that's just an experiment and should be undone shortly, >> maybe work out some other story for easily switching between them, >> or just k >> eep the existing story of "you get to rebuild everything". >> >> >> Tony, can you look into GetGCRatio? I removed the call to it. The >> "fatal" pragma invokes PushEFrame apparently. >> >> >> We should now "fix" Win32 and pthreads to not have GetActivation >> initialize on-demand, just leave Init to initialize always. This >> should shave a few more cycles from PushEFrame. >> >> >> - Jay From hosking at cs.purdue.edu Wed Apr 29 20:05:22 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 30 Apr 2009 04:05:22 +1000 Subject: [M3devel] user threads In-Reply-To: References: Your message of "Tue, 28 Apr 2009 16:54:03 -0000." <200904290653.n3T6rW8b004699@camembert.async.caltech.edu> Message-ID: <92CEDBEA-5C93-402F-A3C0-6AEAFAB4665B@cs.purdue.edu> Jay, I think you are trying to optimize the unoptimizable if I understand that Mika uses locking as heavily as he seems to. On 29 Apr 2009, at 17:05, Jay wrote: > Mika, thanks. Want to try the next variation? look at m3-libs/m3core/ > src/thread/PTHREAD/ThreadPThreadC.c. > See THREAD_LOCAL, THREAD_LOCAL_SLOW, THREAD_LOCAL_FAST? Try > switching THREAD_LOCAL to use THREAD_LOCAL_FAST instead of _SLOW. On > FreeBSD 5.x or newer. > It won't compile for 4.x we know. > > Thanks, > - Jay > > > > To: jay.krell at cornell.edu > > Date: Tue, 28 Apr 2009 23:53:32 -0700 > > From: mika at async.caltech.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] user threads > > > > Ok, it works! > > > > Numbers: > > > > Timings in milliseconds, three samples, filesystem "warmed up" by > > doing one dummy run before launching the real ones. > > > > -unsafe means that I use non-locking Scheme environments, otherwise > > they lock for every variable update. > > ave > > CM3 last week, kernel threads, -unsafe 1460 1482 1437 1460 > > CM3 last week, kernel threads, 2392 2402 2376 2390 > > CM3 this week, kernel threads, -unsafe 1455 1458 1490 1468 (*) > > CM3 this week, user threads, -unsafe 914 934 914 921 > > CM3 this week, user threads, 967 965 986 973 > > PM3 -unsafe 678 657 682 672 > > PM3 709 714 700 708 > > > > (*) not entirely sure this got linked correctly. > > > > Mika > > > > > > Jay writes: > > > > > >User threads seem to work on on FreeBSD/x86 7.0. > > >Mika can you report back the perf cm3 vs. pm3? > > >Still, kernel threads have been around a long time and imho > should be strongly favored.. > > > > > > > > >Kernel threads should be a /little/ faster than they were -- > PushEFrame removed from successful heap allocations. And should be > further improvable via __thread where it is supported -- probably > not FreeBSD 4. > > >x, sometimes older is not better. :) > > > > > > > > >I've temporarily switched FreeBSD/x86 to userthreads by default > but I think that's just an experiment and should be undone shortly, > maybe work out some other story for easily switching between them, > or just k > > >eep the existing story of "you get to rebuild everything". > > > > > > > > >Tony, can you look into GetGCRatio? I removed the call to it. The > "fatal" pragma invokes PushEFrame apparently. > > > > > > > > >We should now "fix" Win32 and pthreads to not have GetActivation > initialize on-demand, just leave Init to initialize always. This > should shave a few more cycles from PushEFrame. > > > > > > > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Apr 29 20:12:12 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 30 Apr 2009 04:12:12 +1000 Subject: [M3devel] Fwd: Output from "cron" command References: <200904291321.n3TDLGNt022671@niagara.cs.purdue.edu> Message-ID: Now I am getting compile errors. Recent checkins are culpable. Begin forwarded message: > From: Tony Hosking > Date: 29 April 2009 23:21:16 GMT+10:00 > To: hosking at cs.purdue.edu > Subject: Output from "cron" command > > Your "cron" job on niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/cron.sh > > produced the following output: > > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-10-30-05 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSUSER= > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara release-build" > > creating log file /tmp/build-cm3-20090429-063007-_Laq8F/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.04.29 06:30:07 -- checkout in progress. > [start checkout 2009.04.29 06:30:09] > cd /tmp/build-cm3-20090429-063007-_Laq8F/build > cvs return value: 0 > [end checkout 2009.04.29 06:49:37] > CHECKOUT_RETURN = 0 > -- > 2009.04.29 06:49:41 -- compile in progress. > [start compile 2009.04.29 06:49:41] > compile return value: 0 > [end compile 2009.04.29 08:10:32] > COMPILE_RETURN = 1 > *** COMPILE FAILED > removing build tree /tmp/build-cm3-20090429-063007-_Laq8F ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-12-12-22 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSUSER= > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" > > creating log file /tmp/build-cm3-20090429-081224-i9aWYM/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.04.29 08:12:24 -- checkout in progress. > [start checkout 2009.04.29 08:12:26] > cd /tmp/build-cm3-20090429-081224-i9aWYM/build > cvs return value: 0 > [end checkout 2009.04.29 08:32:34] > CHECKOUT_RETURN = 0 > -- > 2009.04.29 08:32:38 -- compile in progress. > [start compile 2009.04.29 08:32:38] > compile return value: 0 > [end compile 2009.04.29 09:19:20] > COMPILE_RETURN = 0 > 2009.04.29 09:19:24 -- tests in progress. > [start run-tests 2009.04.29 09:19:24] > cd /tmp/build-cm3-20090429-081224-i9aWYM/build > [end run-tests 2009.04.29 09:19:24] > TESTS_RETURN = 0 > 2009.04.29 09:19:24 -- checkout, compile and test run done. > > --- > > removing build tree /tmp/build-cm3-20090429-081224-i9aWYM ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > done. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Apr 29 20:32:25 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 29 Apr 2009 11:32:25 -0700 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: Your message of "Thu, 30 Apr 2009 04:12:12 +1000." Message-ID: <200904291832.n3TIWPNo038139@camembert.async.caltech.edu> I found I had made a typo in my m3tk check-in. Is there an easy way to see what the error is? Mika Tony Hosking writes: > >--Apple-Mail-6-728527402 >Content-Type: text/plain; > charset=US-ASCII; > format=flowed >Content-Transfer-Encoding: 7bit > >Now I am getting compile errors. Recent checkins are culpable. > >Begin forwarded message: > >> From: Tony Hosking >> Date: 29 April 2009 23:21:16 GMT+10:00 >> To: hosking at cs.purdue.edu >> Subject: Output from "cron" command >> >> Your "cron" job on niagara.cs.purdue.edu >> $HOME/cm3/scripts/regression/cron.sh >> >> produced the following output: >> >> TESTHOSTNAME=niagara >> WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-10-30-05 >> LASTREL=5.4.0 >> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >> CM3_OSTYPE=POSIX >> CM3_TARGET=SOLgnu >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> CM3CVSSERVER=birch.elegosoft.com >> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> CM3CVSUSER= >> testing ssh birch.elegosoft.com.. >> ssh birch.elegosoft.com ok >> Building cm3. >> Tinderbox Tree: "cm3" >> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >> >> creating log file /tmp/build-cm3-20090429-063007-_Laq8F/log.txt >> >> --- >> >> checkout, compile and test of cm3 ... >> 2009.04.29 06:30:07 -- checkout in progress. >> [start checkout 2009.04.29 06:30:09] >> cd /tmp/build-cm3-20090429-063007-_Laq8F/build >> cvs return value: 0 >> [end checkout 2009.04.29 06:49:37] >> CHECKOUT_RETURN = 0 >> -- >> 2009.04.29 06:49:41 -- compile in progress. >> [start compile 2009.04.29 06:49:41] >> compile return value: 0 >> [end compile 2009.04.29 08:10:32] >> COMPILE_RETURN = 1 >> *** COMPILE FAILED >> removing build tree /tmp/build-cm3-20090429-063007-_Laq8F ... >> cleaning CM3 workspaces... >> /homes/hosking/work/cm3-ws/niagara-* >> >> cleaning regression test log files... >> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >> >> cleaning m3test log files... >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >> >> cleaning snapshot files... >> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >> >> cleaning package reports... >> /tmp/cm3-pkg-report-SOLgnu-*.html >> >> TESTHOSTNAME=niagara >> WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-12-12-22 >> LASTREL=5.4.0 >> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >> CM3_OSTYPE=POSIX >> CM3_TARGET=SOLgnu >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> CM3CVSSERVER=birch.elegosoft.com >> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> CM3CVSUSER= >> testing ssh birch.elegosoft.com.. >> ssh birch.elegosoft.com ok >> Building cm3. >> Tinderbox Tree: "cm3" >> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >> >> creating log file /tmp/build-cm3-20090429-081224-i9aWYM/log.txt >> >> --- >> >> checkout, compile and test of cm3 ... >> 2009.04.29 08:12:24 -- checkout in progress. >> [start checkout 2009.04.29 08:12:26] >> cd /tmp/build-cm3-20090429-081224-i9aWYM/build >> cvs return value: 0 >> [end checkout 2009.04.29 08:32:34] >> CHECKOUT_RETURN = 0 >> -- >> 2009.04.29 08:32:38 -- compile in progress. >> [start compile 2009.04.29 08:32:38] >> compile return value: 0 >> [end compile 2009.04.29 09:19:20] >> COMPILE_RETURN = 0 >> 2009.04.29 09:19:24 -- tests in progress. >> [start run-tests 2009.04.29 09:19:24] >> cd /tmp/build-cm3-20090429-081224-i9aWYM/build >> [end run-tests 2009.04.29 09:19:24] >> TESTS_RETURN = 0 >> 2009.04.29 09:19:24 -- checkout, compile and test run done. >> >> --- >> >> removing build tree /tmp/build-cm3-20090429-081224-i9aWYM ... >> cleaning CM3 workspaces... >> /homes/hosking/work/cm3-ws/niagara-* >> >> cleaning regression test log files... >> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >> >> cleaning m3test log files... >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >> >> cleaning snapshot files... >> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >> >> cleaning package reports... >> /tmp/cm3-pkg-report-SOLgnu-*.html >> >> done. > > >--Apple-Mail-6-728527402 >Content-Type: text/html; > charset=US-ASCII >Content-Transfer-Encoding: quoted-printable > >-webkit-line-break: after-white-space; ">
apple-content-edited=3D"true">style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >normal; font-variant: normal; font-weight: normal; letter-spacing: = >normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; = >-khtml-line-break: after-white-space; ">style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >normal; font-variant: normal; font-weight: normal; letter-spacing: = >normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">class=3D"Apple-style-span" style=3D"border-collapse: separate; = >border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; = >font-size: 12px; font-style: normal; font-variant: normal; font-weight: = >normal; letter-spacing: normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">class=3D"Apple-style-span" style=3D"border-collapse: separate; = >border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; = >font-size: 12px; font-style: normal; font-variant: normal; font-weight: = >normal; letter-spacing: normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">class=3D"Apple-style-span" style=3D"border-collapse: separate; = >border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; = >font-size: 12px; font-style: normal; font-variant: normal; font-weight: = >normal; letter-spacing: normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">class=3D"Apple-style-span" style=3D"border-collapse: separate; = >border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; = >font-size: 12px; font-style: normal; font-variant: normal; font-weight: = >normal; letter-spacing: normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">class=3D"Apple-style-span" style=3D"border-collapse: separate; = >border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; = >font-size: 12px; font-style: normal; font-variant: normal; font-weight: = >normal; letter-spacing: normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">class=3D"Apple-style-span" style=3D"border-collapse: separate; = >border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; = >font-size: 12px; font-style: normal; font-variant: normal; font-weight: = >normal; letter-spacing: normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">class=3D"Apple-style-span" style=3D"border-collapse: separate; = >border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; = >font-size: 12px; font-style: normal; font-variant: normal; font-weight: = >normal; letter-spacing: normal; line-height: normal; text-align: auto; = >-khtml-text-decorations-in-effect: none; text-indent: 0px; = >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >white-space: normal; widows: 2; word-spacing: 0px; ">
Now I am = >getting compile errors.  Recent checkins are = >culpable.
iv>

Begin forwarded message:

class=3D"Apple-interchange-newline">
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >margin-left: 0px; ">style=3D"font: 12.0px Helvetica; color: #000000">From: = >Helvetica">Tony Hosking <href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu>iv>
margin-left: 0px; ">style=3D"font: 12.0px Helvetica; color: #000000">Date: = >Helvetica">29 April 2009 23:21:16 GMT+10:00
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >margin-left: 0px; ">style=3D"font: 12.0px Helvetica; color: #000000">To: face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.eduv>
margin-left: 0px; ">style=3D"font: 12.0px Helvetica; color: #000000">Subject: = >Helvetica">Output from "cron" command
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >margin-left: 0px; min-height: 14px; ">
Your "cron" = >job on = >niagara.cs.purdue.edu
$HOME/cm3/scripts/regression/cron.sh

produ= >ced the following = >output:

TESTHOSTNAME=3Dniagara
WS=3D/homes/hosking/work/cm3-ws/n= >iagara-2009-04-29-10-30-05
LASTREL=3D5.4.0
INSTROOT_REL=3D/homes/hos= >king/work/cm3-inst/niagara/rel-5.4.0
INSTROOT_POK=3D/homes/hosking/work= >/cm3-inst/niagara/prev-ok
INSTROOT_LOK=3D/homes/hosking/work/cm3-inst/n= >iagara/last-ok
INSTROOT_CUR=3D/homes/hosking/work/cm3-inst/niagara/curr= >ent
CM3_OSTYPE=3DPOSIX
CM3_TARGET=3DSOLgnu
BINDISTMIN=3D/homes/ho= >sking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
CM3CVSSERVER=3Dbirch.elegosof= >t.com
CM3CVSROOT=3Dbirch.elegosoft.com:/usr/cvs
BINDISTMIN_NAME=3Dcm= >3-min-POSIX-SOLgnu-5.4.0.tgz
BINDISTMIN=3D/homes/hosking/work/cm3-min-P= >OSIX-SOLgnu-5.4.0.tgz
CM3CVSUSER=3D
testing ssh = >birch.elegosoft.com..
ssh birch.elegosoft.com ok
Building = >cm3.
Tinderbox Tree:   "cm3"
Buildname: = >       "SOLgnu SunOS 5.10 niagara = >release-build"

creating log file = >/tmp/build-cm3-20090429-063007-_Laq8F/log.txt

---

checkout, = >compile and test of cm3 ...
2009.04.29 06:30:07 -- checkout in = >progress.
[start checkout 2009.04.29 06:30:09]
cd = >/tmp/build-cm3-20090429-063007-_Laq8F/build
cvs return value: = >0
[end checkout 2009.04.29 06:49:37]
CHECKOUT_RETURN =3D = 0
--
2009.04.29 06:49:41 -- compile in progress.
[start compile = >2009.04.29 06:49:41]
compile return value: 0
[end compile = >2009.04.29 08:10:32]
COMPILE_RETURN =3D 1
*** COMPILE = >FAILED
removing build tree /tmp/build-cm3-20090429-063007-_Laq8F = >...
cleaning CM3 = >workspaces...
/homes/hosking/work/cm3-ws/niagara-*

cleaning = >regression test log = >files...
/homes/hosking/tmp/cm3/niagara/cm3-rlog-*

cleaning = >m3test log = >files...
/homes/hosking/tmp/cm3/niagara/m3tests-*.stdout

/homes/= >hosking/tmp/cm3/niagara/m3tests-*.stderr

/homes/hosking/tmp/cm3/nia= >gara/m3tests-*.stderr.extract

cleaning snapshot = >files...
/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz>
cleaning package = >reports...
/tmp/cm3-pkg-report-SOLgnu-*.html

TESTHOSTNAME=3Dniag= >ara
WS=3D/homes/hosking/work/cm3-ws/niagara-2009-04-29-12-12-22
LAST= >REL=3D5.4.0
INSTROOT_REL=3D/homes/hosking/work/cm3-inst/niagara/rel-5.4= >.0
INSTROOT_POK=3D/homes/hosking/work/cm3-inst/niagara/prev-ok
INSTR= >OOT_LOK=3D/homes/hosking/work/cm3-inst/niagara/last-ok
INSTROOT_CUR=3D/= >homes/hosking/work/cm3-inst/niagara/current
CM3_OSTYPE=3DPOSIX
CM3_T= >ARGET=3DSOLgnu
BINDISTMIN=3D/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.= >4.0.tgz
CM3CVSSERVER=3Dbirch.elegosoft.com
CM3CVSROOT=3Dbirch.elegos= >oft.com:/usr/cvs
BINDISTMIN_NAME=3Dcm3-min-POSIX-SOLgnu-5.4.0.tgz
BI= >NDISTMIN=3D/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
CM3CVSUSE= >R=3D
testing ssh birch.elegosoft.com..
ssh birch.elegosoft.com = >ok
Building cm3.
Tinderbox Tree:   "cm3"
Buildname: = >       "SOLgnu SunOS 5.10 niagara = >lastok-build"

creating log file = >/tmp/build-cm3-20090429-081224-i9aWYM/log.txt

---

checkout, = >compile and test of cm3 ...
2009.04.29 08:12:24 -- checkout in = >progress.
[start checkout 2009.04.29 08:12:26]
cd = >/tmp/build-cm3-20090429-081224-i9aWYM/build
cvs return value: = >0
[end checkout 2009.04.29 08:32:34]
CHECKOUT_RETURN =3D = >0
--
2009.04.29 08:32:38 -- compile in progress.
[start compile = >2009.04.29 08:32:38]
compile return value: 0
[end compile = >2009.04.29 09:19:20]
COMPILE_RETURN =3D 0
2009.04.29 09:19:24 -- = >tests in progress.
[start run-tests 2009.04.29 09:19:24]
cd = >/tmp/build-cm3-20090429-081224-i9aWYM/build
[end run-tests 2009.04.29 = >09:19:24]
TESTS_RETURN =3D 0
2009.04.29 09:19:24 -- checkout, = compile and test run done.

---

removing build tree = >/tmp/build-cm3-20090429-081224-i9aWYM ...
cleaning CM3 = >workspaces...
/homes/hosking/work/cm3-ws/niagara-*

cleaning = >regression test log = >files...
/homes/hosking/tmp/cm3/niagara/cm3-rlog-*

cleaning = >m3test log = >files...
/homes/hosking/tmp/cm3/niagara/m3tests-*.stdout

/homes/= >hosking/tmp/cm3/niagara/m3tests-*.stderr

/homes/hosking/tmp/cm3/nia= >gara/m3tests-*.stderr.extract

cleaning snapshot = >files...
/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz>
cleaning package = >reports...
/tmp/cm3-pkg-report-SOLgnu-*.html

done.
ockquote>

= > >--Apple-Mail-6-728527402-- From hosking at cs.purdue.edu Wed Apr 29 20:33:01 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 30 Apr 2009 04:33:01 +1000 Subject: [M3devel] [M3commit] how to switch userthreads on/off In-Reply-To: <200904290622.n3T6MZBR003219@camembert.async.caltech.edu> References: <200904290622.n3T6MZBR003219@camembert.async.caltech.edu> Message-ID: <69291A6D-E915-41C9-B4FB-AB7F5CF398EE@cs.purdue.edu> Mika, With the current implementation of M3 MUTEX 1-1 as pthread mutex you are bound to have significant overhead for any locking code even in single-threaded apps. We need to move towards a thin-lock implementation for mutex (as used in modern Java implementations) to avoid overhead for uncontended locks. It's not too hard to implement. The idea is to represent a mutex as a tagged word. The word contains either NIL, the thread holding the lock, or a pointer to a full-blown (inflated) pthread mutex. We can use GC and other opportunities to deflate locks as needs. Checking the tag requires a CAS. There are other techniques that further eliminate the CAS for the uncontended case. But, generally, you should consider LOCK to be a fairly high-overhead operation for now. 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 29 Apr 2009, at 16:22, Mika Nystrom wrote: > Jay writes: > ... >> >> Maybe just leave it as an option in m3core's m3makefile and people >> can twiddle it if they want and rebuild the entire system like it >> is today? >> That is a bit onerous, but maybe it's all userthreads deserve? >> ? >> >> >> Anyone who actually wanted to switch back and forth (Mika) would >> just have two installs and two source trees? >> >> >> - Jay > > I just want to clarify. I'm not really that interested in switching > back and forth. I'm just a little disturbed by the sometimes huge > performance loss due to the introduction of kernel threads. I knew > that this would happen in certain highly multithreaded applications, > but I'm surprised it happens in a more or less single-threaded > application. > > I think I've just been spoiled by 10 years of using SRCM3 and PM3 > for FreeBSD w/o kernel threads in the sense that I've learned that > using LOCK has essentially no cost. On a shared-memory > multiprocessor, > I really don't expect that to remain the case... physics won't allow > it. So now I just have to go through my code and find all the places > where I lock too much and remove them. > > But the memory allocator and garbage collector do it too, no? > > I also think that this idea of being able to use either is great. > Mainly single-threaded programs should definitely not use kernel > threads! > > As for reaching the "thread locals", there is one slightly crazy > idea that one could borrow from Sussman and Steele: add another > implicit argument to every Modula-3 routine. In that argument, > pass a pointer to the thread locals. For EXTERNAL calls (in or > out), make it NIL (somehow, maybe involving pragmas), and in that > case (only), use the pthreads routines to access the thread locals. > Ok so it sounds kind of nuts, but with this approach you could avoid > locking or even calling into the pthreads libs almost entirely for > a single-threaded program. You could even have a thread-local > memory allocator that would only lock when it needs to request > memory from the "global allocator"... in fact there are lots of > things you can do with this sort of thing. Dynamically scoped > variables in Scheme (a la MacLisp?) is what they originally proposed > it for but then they suggested all kinds of tricks related to > continuations with it. > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Apr 29 20:34:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 30 Apr 2009 04:34:07 +1000 Subject: [M3devel] [M3commit] how to switch userthreads on/off In-Reply-To: <200904290622.n3T6MZBR003219@camembert.async.caltech.edu> References: <200904290622.n3T6MZBR003219@camembert.async.caltech.edu> Message-ID: <6F6E80BC-1DF9-4121-834B-370567EA21D5@cs.purdue.edu> There is no lock in the fast path for traced allocation. GC has some locking that I am working on improving/eliminating. Watch this space. On 29 Apr 2009, at 16:22, Mika Nystrom wrote: > Jay writes: > ... >> >> Maybe just leave it as an option in m3core's m3makefile and people >> can twiddle it if they want and rebuild the entire system like it >> is today? >> That is a bit onerous, but maybe it's all userthreads deserve? >> ? >> >> >> Anyone who actually wanted to switch back and forth (Mika) would >> just have two installs and two source trees? >> >> >> - Jay > > I just want to clarify. I'm not really that interested in switching > back and forth. I'm just a little disturbed by the sometimes huge > performance loss due to the introduction of kernel threads. I knew > that this would happen in certain highly multithreaded applications, > but I'm surprised it happens in a more or less single-threaded > application. > > I think I've just been spoiled by 10 years of using SRCM3 and PM3 > for FreeBSD w/o kernel threads in the sense that I've learned that > using LOCK has essentially no cost. On a shared-memory > multiprocessor, > I really don't expect that to remain the case... physics won't allow > it. So now I just have to go through my code and find all the places > where I lock too much and remove them. > > But the memory allocator and garbage collector do it too, no? > > I also think that this idea of being able to use either is great. > Mainly single-threaded programs should definitely not use kernel > threads! > > As for reaching the "thread locals", there is one slightly crazy > idea that one could borrow from Sussman and Steele: add another > implicit argument to every Modula-3 routine. In that argument, > pass a pointer to the thread locals. For EXTERNAL calls (in or > out), make it NIL (somehow, maybe involving pragmas), and in that > case (only), use the pthreads routines to access the thread locals. > Ok so it sounds kind of nuts, but with this approach you could avoid > locking or even calling into the pthreads libs almost entirely for > a single-threaded program. You could even have a thread-local > memory allocator that would only lock when it needs to request > memory from the "global allocator"... in fact there are lots of > things you can do with this sort of thing. Dynamically scoped > variables in Scheme (a la MacLisp?) is what they originally proposed > it for but then they suggested all kinds of tricks related to > continuations with it. > > Mika From hosking at cs.purdue.edu Wed Apr 29 20:35:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 30 Apr 2009 04:35:07 +1000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <200904291832.n3TIWPNo038139@camembert.async.caltech.edu> References: <200904291832.n3TIWPNo038139@camembert.async.caltech.edu> Message-ID: Tinderbox... On 30 Apr 2009, at 04:32, Mika Nystrom wrote: > > I found I had made a typo in my m3tk check-in. Is there an easy > way to see what the error is? > > Mika > > Tony Hosking writes: >> >> --Apple-Mail-6-728527402 >> Content-Type: text/plain; >> charset=US-ASCII; >> format=flowed >> Content-Transfer-Encoding: 7bit >> >> Now I am getting compile errors. Recent checkins are culpable. >> >> Begin forwarded message: >> >>> From: Tony Hosking >>> Date: 29 April 2009 23:21:16 GMT+10:00 >>> To: hosking at cs.purdue.edu >>> Subject: Output from "cron" command >>> >>> Your "cron" job on niagara.cs.purdue.edu >>> $HOME/cm3/scripts/regression/cron.sh >>> >>> produced the following output: >>> >>> TESTHOSTNAME=niagara >>> WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-10-30-05 >>> LASTREL=5.4.0 >>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>> CM3_OSTYPE=POSIX >>> CM3_TARGET=SOLgnu >>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> CM3CVSSERVER=birch.elegosoft.com >>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> CM3CVSUSER= >>> testing ssh birch.elegosoft.com.. >>> ssh birch.elegosoft.com ok >>> Building cm3. >>> Tinderbox Tree: "cm3" >>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>> >>> creating log file /tmp/build-cm3-20090429-063007-_Laq8F/log.txt >>> >>> --- >>> >>> checkout, compile and test of cm3 ... >>> 2009.04.29 06:30:07 -- checkout in progress. >>> [start checkout 2009.04.29 06:30:09] >>> cd /tmp/build-cm3-20090429-063007-_Laq8F/build >>> cvs return value: 0 >>> [end checkout 2009.04.29 06:49:37] >>> CHECKOUT_RETURN = 0 >>> -- >>> 2009.04.29 06:49:41 -- compile in progress. >>> [start compile 2009.04.29 06:49:41] >>> compile return value: 0 >>> [end compile 2009.04.29 08:10:32] >>> COMPILE_RETURN = 1 >>> *** COMPILE FAILED >>> removing build tree /tmp/build-cm3-20090429-063007-_Laq8F ... >>> cleaning CM3 workspaces... >>> /homes/hosking/work/cm3-ws/niagara-* >>> >>> cleaning regression test log files... >>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>> >>> cleaning m3test log files... >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>> >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>> >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>> >>> cleaning snapshot files... >>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>> >>> cleaning package reports... >>> /tmp/cm3-pkg-report-SOLgnu-*.html >>> >>> TESTHOSTNAME=niagara >>> WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-12-12-22 >>> LASTREL=5.4.0 >>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>> CM3_OSTYPE=POSIX >>> CM3_TARGET=SOLgnu >>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> CM3CVSSERVER=birch.elegosoft.com >>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>> CM3CVSUSER= >>> testing ssh birch.elegosoft.com.. >>> ssh birch.elegosoft.com ok >>> Building cm3. >>> Tinderbox Tree: "cm3" >>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>> >>> creating log file /tmp/build-cm3-20090429-081224-i9aWYM/log.txt >>> >>> --- >>> >>> checkout, compile and test of cm3 ... >>> 2009.04.29 08:12:24 -- checkout in progress. >>> [start checkout 2009.04.29 08:12:26] >>> cd /tmp/build-cm3-20090429-081224-i9aWYM/build >>> cvs return value: 0 >>> [end checkout 2009.04.29 08:32:34] >>> CHECKOUT_RETURN = 0 >>> -- >>> 2009.04.29 08:32:38 -- compile in progress. >>> [start compile 2009.04.29 08:32:38] >>> compile return value: 0 >>> [end compile 2009.04.29 09:19:20] >>> COMPILE_RETURN = 0 >>> 2009.04.29 09:19:24 -- tests in progress. >>> [start run-tests 2009.04.29 09:19:24] >>> cd /tmp/build-cm3-20090429-081224-i9aWYM/build >>> [end run-tests 2009.04.29 09:19:24] >>> TESTS_RETURN = 0 >>> 2009.04.29 09:19:24 -- checkout, compile and test run done. >>> >>> --- >>> >>> removing build tree /tmp/build-cm3-20090429-081224-i9aWYM ... >>> cleaning CM3 workspaces... >>> /homes/hosking/work/cm3-ws/niagara-* >>> >>> cleaning regression test log files... >>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>> >>> cleaning m3test log files... >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>> >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>> >>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>> >>> cleaning snapshot files... >>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>> >>> cleaning package reports... >>> /tmp/cm3-pkg-report-SOLgnu-*.html >>> >>> done. >> >> >> --Apple-Mail-6-728527402 >> Content-Type: text/html; >> charset=US-ASCII >> Content-Transfer-Encoding: quoted-printable >> >> > space; = >> -webkit-line-break: after-white-space; ">
> apple-content-edited=3D"true">> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >> normal; font-variant: normal; font-weight: normal; letter-spacing: = >> normal; line-height: normal; text-align: auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">
> style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; = >> -khtml-line-break: after-white-space; ">> span" = >> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >> normal; font-variant: normal; font-weight: normal; letter-spacing: = >> normal; line-height: normal; text-align: auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >> Helvetica; = >> font-size: 12px; font-style: normal; font-variant: normal; font- >> weight: = >> normal; letter-spacing: normal; line-height: normal; text-align: >> auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >> Helvetica; = >> font-size: 12px; font-style: normal; font-variant: normal; font- >> weight: = >> normal; letter-spacing: normal; line-height: normal; text-align: >> auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >> Helvetica; = >> font-size: 12px; font-style: normal; font-variant: normal; font- >> weight: = >> normal; letter-spacing: normal; line-height: normal; text-align: >> auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >> Helvetica; = >> font-size: 12px; font-style: normal; font-variant: normal; font- >> weight: = >> normal; letter-spacing: normal; line-height: normal; text-align: >> auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >> Helvetica; = >> font-size: 12px; font-style: normal; font-variant: normal; font- >> weight: = >> normal; letter-spacing: normal; line-height: normal; text-align: >> auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >> Helvetica; = >> font-size: 12px; font-style: normal; font-variant: normal; font- >> weight: = >> normal; letter-spacing: normal; line-height: normal; text-align: >> auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >> Helvetica; = >> font-size: 12px; font-style: normal; font-variant: normal; font- >> weight: = >> normal; letter-spacing: normal; line-height: normal; text-align: >> auto; = >> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >> white-space: normal; widows: 2; word-spacing: 0px; ">
Now I am = >> getting compile errors.  Recent checkins are = >> culpable.
> span>> iv>

Begin forwarded message:

> class=3D"Apple-interchange-newline">
> type=3D"cite">
> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >> margin-left: 0px; ">> color=3D"#000000" = >> style=3D"font: 12.0px Helvetica; color: #000000">From: = >> > 12.0px = >> Helvetica">Tony Hosking <> href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu>> font>> iv>
> 0px; = >> margin-left: 0px; ">> color=3D"#000000" = >> style=3D"font: 12.0px Helvetica; color: #000000">Date: = >> > 12.0px = >> Helvetica">29 April 2009 23:21:16 GMT+10:00
> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >> margin-left: 0px; ">> color=3D"#000000" = >> style=3D"font: 12.0px Helvetica; color: #000000">To: > font>> face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">> href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu> font>> v>
> 0px; = >> margin-left: 0px; ">> color=3D"#000000" = >> style=3D"font: 12.0px Helvetica; color: #000000">Subject: = >> > 12.0px = >> Helvetica">Output from "cron" command
> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >> margin-left: 0px; min-height: 14px; ">
Your >> "cron" = >> job on = >> niagara.cs.purdue.edu
$HOME/cm3/scripts/regression/ >> cron.sh

produ= >> ced the following = >> output:

TESTHOSTNAME=3Dniagara
WS=3D/homes/hosking/work/ >> cm3-ws/n= >> iagara-2009-04-29-10-30-05
LASTREL=3D5.4.0
INSTROOT_REL=3D/ >> homes/hos= >> king/work/cm3-inst/niagara/rel-5.4.0
INSTROOT_POK=3D/homes/ >> hosking/work= >> /cm3-inst/niagara/prev-ok
INSTROOT_LOK=3D/homes/hosking/work/cm3- >> inst/n= >> iagara/last-ok
INSTROOT_CUR=3D/homes/hosking/work/cm3-inst/ >> niagara/curr= >> ent
CM3_OSTYPE=3DPOSIX
CM3_TARGET=3DSOLgnu
BINDISTMIN=3D/ >> homes/ho= >> sking/work/cm3-min-POSIX- >> SOLgnu-5.4.0.tgz
CM3CVSSERVER=3Dbirch.elegosof= >> t.com
CM3CVSROOT=3Dbirch.elegosoft.com:/usr/ >> cvs
BINDISTMIN_NAME=3Dcm= >> 3-min-POSIX-SOLgnu-5.4.0.tgz
BINDISTMIN=3D/homes/hosking/work/ >> cm3-min-P= >> OSIX-SOLgnu-5.4.0.tgz
CM3CVSUSER=3D
testing ssh = >> birch.elegosoft.com..
ssh birch.elegosoft.com ok
Building = >> cm3.
Tinderbox Tree:   "cm3"
Buildname: = >>        "SOLgnu SunOS 5.10 >> niagara = >> release-build"

creating log file = >> /tmp/build-cm3-20090429-063007-_Laq8F/log.txt

--- >>

checkout, = >> compile and test of cm3 ...
2009.04.29 06:30:07 -- checkout in = >> progress.
[start checkout 2009.04.29 06:30:09]
cd = >> /tmp/build-cm3-20090429-063007-_Laq8F/build
cvs return value: = >> 0
[end checkout 2009.04.29 06:49:37]
CHECKOUT_RETURN =3D = > 0
--
2009.04.29 06:49:41 -- compile in progress.
[start > compile = >> 2009.04.29 06:49:41]
compile return value: 0
[end compile = >> 2009.04.29 08:10:32]
COMPILE_RETURN =3D 1
*** COMPILE = >> FAILED
removing build tree /tmp/build-cm3-20090429-063007-_Laq8F = >> ...
cleaning CM3 = >> workspaces...
/homes/hosking/work/cm3-ws/niagara- >> *

cleaning = >> regression test log = >> files...
/homes/hosking/tmp/cm3/niagara/cm3-rlog- >> *

cleaning = >> m3test log = >> files...
/homes/hosking/tmp/cm3/niagara/m3tests-*.stdout

/ >> homes/= >> hosking/tmp/cm3/niagara/m3tests-*.stderr

/homes/hosking/tmp/ >> cm3/nia= >> gara/m3tests-*.stderr.extract

cleaning snapshot = >> files...
/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >> *.tgz>>
cleaning package = >> reports...
/tmp/cm3-pkg-report-SOLgnu- >> *.html

TESTHOSTNAME=3Dniag= >> ara
WS=3D/homes/hosking/work/cm3-ws/ >> niagara-2009-04-29-12-12-22
LAST= >> REL=3D5.4.0
INSTROOT_REL=3D/homes/hosking/work/cm3-inst/niagara/ >> rel-5.4= >> .0
INSTROOT_POK=3D/homes/hosking/work/cm3-inst/niagara/prev- >> ok
INSTR= >> OOT_LOK=3D/homes/hosking/work/cm3-inst/niagara/last- >> ok
INSTROOT_CUR=3D/= >> homes/hosking/work/cm3-inst/niagara/ >> current
CM3_OSTYPE=3DPOSIX
CM3_T= >> ARGET=3DSOLgnu
BINDISTMIN=3D/homes/hosking/work/cm3-min-POSIX- >> SOLgnu-5.= >> 4.0 >> .tgz >>
CM3CVSSERVER=3Dbirch.elegosoft.com
CM3CVSROOT=3Dbirch.elegos= >> oft.com:/usr/cvs
BINDISTMIN_NAME=3Dcm3-min-POSIX- >> SOLgnu-5.4.0.tgz
BI= >> NDISTMIN=3D/homes/hosking/work/cm3-min-POSIX- >> SOLgnu-5.4.0.tgz
CM3CVSUSE= >> R=3D
testing ssh birch.elegosoft.com..
ssh >> birch.elegosoft.com = >> ok
Building cm3.
Tinderbox Tree: >>   "cm3"
Buildname: = >>        "SOLgnu SunOS 5.10 >> niagara = >> lastok-build"

creating log file = >> /tmp/build-cm3-20090429-081224-i9aWYM/log.txt

--- >>

checkout, = >> compile and test of cm3 ...
2009.04.29 08:12:24 -- checkout in = >> progress.
[start checkout 2009.04.29 08:12:26]
cd = >> /tmp/build-cm3-20090429-081224-i9aWYM/build
cvs return value: = >> 0
[end checkout 2009.04.29 08:32:34]
CHECKOUT_RETURN =3D = >> 0
--
2009.04.29 08:32:38 -- compile in progress.
[start >> compile = >> 2009.04.29 08:32:38]
compile return value: 0
[end compile = >> 2009.04.29 09:19:20]
COMPILE_RETURN =3D 0
2009.04.29 09:19:24 >> -- = >> tests in progress.
[start run-tests 2009.04.29 09:19:24]
cd = >> /tmp/build-cm3-20090429-081224-i9aWYM/build
[end run-tests >> 2009.04.29 = >> 09:19:24]
TESTS_RETURN =3D 0
2009.04.29 09:19:24 -- checkout, = > compile and test run done.

---

removing build tree = >> /tmp/build-cm3-20090429-081224-i9aWYM ...
cleaning CM3 = >> workspaces...
/homes/hosking/work/cm3-ws/niagara- >> *

cleaning = >> regression test log = >> files...
/homes/hosking/tmp/cm3/niagara/cm3-rlog- >> *

cleaning = >> m3test log = >> files...
/homes/hosking/tmp/cm3/niagara/m3tests-*.stdout

/ >> homes/= >> hosking/tmp/cm3/niagara/m3tests-*.stderr

/homes/hosking/tmp/ >> cm3/nia= >> gara/m3tests-*.stderr.extract

cleaning snapshot = >> files...
/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >> *.tgz>>
cleaning package = >> reports...
/tmp/cm3-pkg-report-SOLgnu-*.html

done.
> div>> ockquote>

= >> >> --Apple-Mail-6-728527402-- From mika at async.caltech.edu Wed Apr 29 20:46:03 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 29 Apr 2009 11:46:03 -0700 Subject: [M3devel] user threads In-Reply-To: Your message of "Thu, 30 Apr 2009 04:04:22 +1000." <736196D3-6AA1-49C4-80E8-4EEB05B38CFC@cs.purdue.edu> Message-ID: <200904291846.n3TIk3F6038926@camembert.async.caltech.edu> Tony, no of course it's not surprising. -unsafe removes the lock-on-every update (in the global environment---pushed environments are always "unsafe"). In fact since there are hardly any updates in the global environment, it's locking on reading that's hurting. [Tony, I'm curious how you'd go about implementing the sort of "non-blocking lock" you mention.] But what Jay has pointed out is that what I labeled as "kernel threads" in the attached table aren't kernel threads at all but libc_r threads, which provide the same facilities (as far as I know) as M3's "user threads". In this case M3's user threads are simply superior to what the system provides. Much superior. I think if possible "M3 user threads" should definitely be the default on FreeBSD4 and earlier, rather than "system user threads". I think people who want to implement coroutines and occam-like things with threads would also be happy if user threads were very easy to enable. Although I agree they should certainly not normally be the default and it is probably unnecessary to be able to enable them at runtime. A compile/link-time option would be nice though.... Rather than having to recompile the whole M3 distribution, that is. I know of two important classes of applications where user threads are likely to be superior to kernel threads: 1. occam-like things, as described above. Not uncommon in hardware circles! 2. applications that use RMI (e.g., Network Objects) to communicate between separate runtimes that are mapped exactly one runtime to each physical core. For case 2, readers may be interested in the following report: http://caltechcstr.library.caltech.edu/218/ Mika Tony Hosking writes: >Mika, it is not surprising that your lock-on-every variable update >will cost a lot in any non-user-level threading scheme. You should >consider using different mechanisms for this degree of locking in >Scheme (based on some of the non-blocking lock implementations for >Java perhaps). I don't expect any implementation of locking for a >multi-core/-processor will ever perform as well as user-level threads. > >On 29 Apr 2009, at 16:53, Mika Nystrom wrote: > >> Ok, it works! >> >> Numbers: >> >> Timings in milliseconds, three samples, filesystem "warmed up" by >> doing one dummy run before launching the real ones. >> >> -unsafe means that I use non-locking Scheme environments, otherwise >> they lock for every variable update. >> ave >> CM3 last week, kernel threads, -unsafe 1460 1482 1437 1460 >> CM3 last week, kernel threads, 2392 2402 2376 2390 >> CM3 this week, kernel threads, -unsafe 1455 1458 1490 1468 (*) >> CM3 this week, user threads, -unsafe 914 934 914 921 >> CM3 this week, user threads, 967 965 986 973 >> PM3 -unsafe 678 657 682 672 >> PM3 709 714 700 708 >> >> (*) not entirely sure this got linked correctly. >> >> Mika >> >> >> Jay writes: >>> >>> User threads seem to work on on FreeBSD/x86 7.0. >>> Mika can you report back the perf cm3 vs. pm3? >>> Still, kernel threads have been around a long time and imho should >>> be strongly favored.. >>> >>> >>> Kernel threads should be a /little/ faster than they were -- >>> PushEFrame removed from successful heap allocations. And should be >>> further improvable via __thread where it is supported -- probably >>> not FreeBSD 4. >>> x, sometimes older is not better. :) >>> >>> >>> I've temporarily switched FreeBSD/x86 to userthreads by default but >>> I think that's just an experiment and should be undone shortly, >>> maybe work out some other story for easily switching between them, >>> or just k >>> eep the existing story of "you get to rebuild everything". >>> >>> >>> Tony, can you look into GetGCRatio? I removed the call to it. The >>> "fatal" pragma invokes PushEFrame apparently. >>> >>> >>> We should now "fix" Win32 and pthreads to not have GetActivation >>> initialize on-demand, just leave Init to initialize always. This >>> should shave a few more cycles from PushEFrame. >>> >>> >>> - Jay From hosking at cs.purdue.edu Wed Apr 29 20:58:06 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 30 Apr 2009 04:58:06 +1000 Subject: [M3devel] user threads In-Reply-To: <200904291846.n3TIk3F6038926@camembert.async.caltech.edu> References: <200904291846.n3TIk3F6038926@camembert.async.caltech.edu> Message-ID: On 30 Apr 2009, at 04:46, Mika Nystrom wrote: > Tony, no of course it's not surprising. -unsafe removes the > lock-on-every update (in the global environment---pushed environments > are always "unsafe"). In fact since there are hardly any updates > in the global environment, it's locking on reading that's hurting. > > [Tony, I'm curious how you'd go about implementing the sort of > "non-blocking lock" you mention.] > > But what Jay has pointed out is that what I labeled as "kernel > threads" in the attached table aren't kernel threads at all but > libc_r threads, which provide the same facilities (as far as I know) > as M3's "user threads". In this case M3's user threads are simply > superior to what the system provides. Much superior. Ah, understood. > I think if possible "M3 user threads" should definitely be the > default on FreeBSD4 and earlier, rather than "system user threads". Fair enough. Old thread libraries were pretty substandard. > I think people who want to implement coroutines and occam-like > things with threads would also be happy if user threads were very > easy to enable. Although I agree they should certainly not normally > be the default and it is probably unnecessary to be able to enable > them at runtime. A compile/link-time option would be nice though.... > Rather than having to recompile the whole M3 distribution, that is. For a systems programming language like Modula-3 I think the general expectation should be that m3-thread = system thread (i.e., something scheduled on a physical processor by the operating system). Anyone wanting Occam-like things and co-routines should think hard about what they need and devise a scheme for multi-plexing them on each of the processors. Perhaps it could be made available as a library. > I know of two important classes of applications where user threads > are likely to be superior to kernel threads: > > 1. occam-like things, as described above. Not uncommon in hardware > circles! But on modern hardware we'd need them to be scheduled across multiple processors. > 2. applications that use RMI (e.g., Network Objects) to communicate > between separate runtimes that are mapped exactly one runtime > to each physical core. Hmm, perhaps... > > > For case 2, readers may be interested in the following report: > > http://caltechcstr.library.caltech.edu/218/ > > Mika > > Tony Hosking writes: >> Mika, it is not surprising that your lock-on-every variable update >> will cost a lot in any non-user-level threading scheme. You should >> consider using different mechanisms for this degree of locking in >> Scheme (based on some of the non-blocking lock implementations for >> Java perhaps). I don't expect any implementation of locking for a >> multi-core/-processor will ever perform as well as user-level >> threads. >> >> On 29 Apr 2009, at 16:53, Mika Nystrom wrote: >> >>> Ok, it works! >>> >>> Numbers: >>> >>> Timings in milliseconds, three samples, filesystem "warmed up" by >>> doing one dummy run before launching the real ones. >>> >>> -unsafe means that I use non-locking Scheme environments, otherwise >>> they lock for every variable update. >>> ave >>> CM3 last week, kernel threads, -unsafe 1460 1482 1437 1460 >>> CM3 last week, kernel threads, 2392 2402 2376 2390 >>> CM3 this week, kernel threads, -unsafe 1455 1458 1490 1468 (*) >>> CM3 this week, user threads, -unsafe 914 934 914 921 >>> CM3 this week, user threads, 967 965 986 973 >>> PM3 -unsafe 678 657 682 672 >>> PM3 709 714 700 708 >>> >>> (*) not entirely sure this got linked correctly. >>> >>> Mika >>> >>> >>> Jay writes: >>>> >>>> User threads seem to work on on FreeBSD/x86 7.0. >>>> Mika can you report back the perf cm3 vs. pm3? >>>> Still, kernel threads have been around a long time and imho should >>>> be strongly favored.. >>>> >>>> >>>> Kernel threads should be a /little/ faster than they were -- >>>> PushEFrame removed from successful heap allocations. And should be >>>> further improvable via __thread where it is supported -- probably >>>> not FreeBSD 4. >>>> x, sometimes older is not better. :) >>>> >>>> >>>> I've temporarily switched FreeBSD/x86 to userthreads by default but >>>> I think that's just an experiment and should be undone shortly, >>>> maybe work out some other story for easily switching between them, >>>> or just k >>>> eep the existing story of "you get to rebuild everything". >>>> >>>> >>>> Tony, can you look into GetGCRatio? I removed the call to it. The >>>> "fatal" pragma invokes PushEFrame apparently. >>>> >>>> >>>> We should now "fix" Win32 and pthreads to not have GetActivation >>>> initialize on-demand, just leave Init to initialize always. This >>>> should shave a few more cycles from PushEFrame. >>>> >>>> >>>> - Jay From jay.krell at cornell.edu Wed Apr 29 22:01:14 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 29 Apr 2009 20:01:14 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: References: <200904291832.n3TIWPNo038139@camembert.async.caltech.edu> Message-ID: Add this to your favorites or bookmarks or whatever: http://tinderbox.elegosoft.com/tinderbox/cm3/status.html It's not the most friendly but it is ok. Unfortunately the error is just: 12067 NEXT Bus Error - core dumped I'll undo stuff, like __thread mainly. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: mika at async.caltech.edu > Date: Thu, 30 Apr 2009 04:35:07 +1000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Fwd: Output from "cron" command > > Tinderbox... > > On 30 Apr 2009, at 04:32, Mika Nystrom wrote: > >> >> I found I had made a typo in my m3tk check-in. Is there an easy >> way to see what the error is? >> >> Mika >> >> Tony Hosking writes: >>> >>> --Apple-Mail-6-728527402 >>> Content-Type: text/plain; >>> charset=US-ASCII; >>> format=flowed >>> Content-Transfer-Encoding: 7bit >>> >>> Now I am getting compile errors. Recent checkins are culpable. >>> >>> Begin forwarded message: >>> >>>> From: Tony Hosking >>>> Date: 29 April 2009 23:21:16 GMT+10:00 >>>> To: hosking at cs.purdue.edu >>>> Subject: Output from "cron" command >>>> >>>> Your "cron" job on niagara.cs.purdue.edu >>>> $HOME/cm3/scripts/regression/cron.sh >>>> >>>> produced the following output: >>>> >>>> TESTHOSTNAME=niagara >>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-10-30-05 >>>> LASTREL=5.4.0 >>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>> CM3_OSTYPE=POSIX >>>> CM3_TARGET=SOLgnu >>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> CM3CVSSERVER=birch.elegosoft.com >>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> CM3CVSUSER= >>>> testing ssh birch.elegosoft.com.. >>>> ssh birch.elegosoft.com ok >>>> Building cm3. >>>> Tinderbox Tree: "cm3" >>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>> >>>> creating log file /tmp/build-cm3-20090429-063007-_Laq8F/log.txt >>>> >>>> --- >>>> >>>> checkout, compile and test of cm3 ... >>>> 2009.04.29 06:30:07 -- checkout in progress. >>>> [start checkout 2009.04.29 06:30:09] >>>> cd /tmp/build-cm3-20090429-063007-_Laq8F/build >>>> cvs return value: 0 >>>> [end checkout 2009.04.29 06:49:37] >>>> CHECKOUT_RETURN = 0 >>>> -- >>>> 2009.04.29 06:49:41 -- compile in progress. >>>> [start compile 2009.04.29 06:49:41] >>>> compile return value: 0 >>>> [end compile 2009.04.29 08:10:32] >>>> COMPILE_RETURN = 1 >>>> *** COMPILE FAILED >>>> removing build tree /tmp/build-cm3-20090429-063007-_Laq8F ... >>>> cleaning CM3 workspaces... >>>> /homes/hosking/work/cm3-ws/niagara-* >>>> >>>> cleaning regression test log files... >>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>> >>>> cleaning m3test log files... >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>> >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>> >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>> >>>> cleaning snapshot files... >>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>> >>>> cleaning package reports... >>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>> >>>> TESTHOSTNAME=niagara >>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-12-12-22 >>>> LASTREL=5.4.0 >>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>> CM3_OSTYPE=POSIX >>>> CM3_TARGET=SOLgnu >>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> CM3CVSSERVER=birch.elegosoft.com >>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>> CM3CVSUSER= >>>> testing ssh birch.elegosoft.com.. >>>> ssh birch.elegosoft.com ok >>>> Building cm3. >>>> Tinderbox Tree: "cm3" >>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>> >>>> creating log file /tmp/build-cm3-20090429-081224-i9aWYM/log.txt >>>> >>>> --- >>>> >>>> checkout, compile and test of cm3 ... >>>> 2009.04.29 08:12:24 -- checkout in progress. >>>> [start checkout 2009.04.29 08:12:26] >>>> cd /tmp/build-cm3-20090429-081224-i9aWYM/build >>>> cvs return value: 0 >>>> [end checkout 2009.04.29 08:32:34] >>>> CHECKOUT_RETURN = 0 >>>> -- >>>> 2009.04.29 08:32:38 -- compile in progress. >>>> [start compile 2009.04.29 08:32:38] >>>> compile return value: 0 >>>> [end compile 2009.04.29 09:19:20] >>>> COMPILE_RETURN = 0 >>>> 2009.04.29 09:19:24 -- tests in progress. >>>> [start run-tests 2009.04.29 09:19:24] >>>> cd /tmp/build-cm3-20090429-081224-i9aWYM/build >>>> [end run-tests 2009.04.29 09:19:24] >>>> TESTS_RETURN = 0 >>>> 2009.04.29 09:19:24 -- checkout, compile and test run done. >>>> >>>> --- >>>> >>>> removing build tree /tmp/build-cm3-20090429-081224-i9aWYM ... >>>> cleaning CM3 workspaces... >>>> /homes/hosking/work/cm3-ws/niagara-* >>>> >>>> cleaning regression test log files... >>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>> >>>> cleaning m3test log files... >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>> >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>> >>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>> >>>> cleaning snapshot files... >>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>> >>>> cleaning package reports... >>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>> >>>> done. >>> >>> >>> --Apple-Mail-6-728527402 >>> Content-Type: text/html; >>> charset=US-ASCII >>> Content-Transfer-Encoding: quoted-printable >>> >>>>>> space; = >>> -webkit-line-break: after-white-space; "> >>> apple-content-edited=3D"true">>>> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >>> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >>> normal; font-variant: normal; font-weight: normal; letter-spacing: = >>> normal; line-height: normal; text-align: auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; "> >>> style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; = >>> -khtml-line-break: after-white-space; ">>>> span" = >>> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >>> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >>> normal; font-variant: normal; font-weight: normal; letter-spacing: = >>> normal; line-height: normal; text-align: auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>> Helvetica; = >>> font-size: 12px; font-style: normal; font-variant: normal; font- >>> weight: = >>> normal; letter-spacing: normal; line-height: normal; text-align: >>> auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>> Helvetica; = >>> font-size: 12px; font-style: normal; font-variant: normal; font- >>> weight: = >>> normal; letter-spacing: normal; line-height: normal; text-align: >>> auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>> Helvetica; = >>> font-size: 12px; font-style: normal; font-variant: normal; font- >>> weight: = >>> normal; letter-spacing: normal; line-height: normal; text-align: >>> auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>> Helvetica; = >>> font-size: 12px; font-style: normal; font-variant: normal; font- >>> weight: = >>> normal; letter-spacing: normal; line-height: normal; text-align: >>> auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>> Helvetica; = >>> font-size: 12px; font-style: normal; font-variant: normal; font- >>> weight: = >>> normal; letter-spacing: normal; line-height: normal; text-align: >>> auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>> Helvetica; = >>> font-size: 12px; font-style: normal; font-variant: normal; font- >>> weight: = >>> normal; letter-spacing: normal; line-height: normal; text-align: >>> auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>> Helvetica; = >>> font-size: 12px; font-style: normal; font-variant: normal; font- >>> weight: = >>> normal; letter-spacing: normal; line-height: normal; text-align: >>> auto; = >>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>> white-space: normal; widows: 2; word-spacing: 0px; "> Now I am = >>> getting compile errors. Recent checkins are = >>> culpable.>>> span>>>> iv> Begin forwarded message: >>> class=3D"Apple-interchange-newline">>>> type=3D"cite"> >>> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >>> margin-left: 0px; ">>>> color=3D"#000000" = >>> style=3D"font: 12.0px Helvetica; color: #000000">From: = >>>>>> 12.0px = >>> Helvetica">Tony Hosking <>>> href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu>>>> font>>>> iv> >>> 0px; = >>> margin-left: 0px; ">>>> color=3D"#000000" = >>> style=3D"font: 12.0px Helvetica; color: #000000">Date: = >>>>>> 12.0px = >>> Helvetica">29 April 2009 23:21:16 GMT+10:00 >>> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >>> margin-left: 0px; ">>>> color=3D"#000000" = >>> style=3D"font: 12.0px Helvetica; color: #000000">To:>>> font>>>> face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">>>> href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu>>> font>>>> v> >>> 0px; = >>> margin-left: 0px; ">>>> color=3D"#000000" = >>> style=3D"font: 12.0px Helvetica; color: #000000">Subject: = >>>>>> 12.0px = >>> Helvetica">Output from "cron" command >>> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >>> margin-left: 0px; min-height: 14px; "> Your >>> "cron" = >>> job on = >>> niagara.cs.purdue.edu $HOME/cm3/scripts/regression/ >>> cron.sh produ= >>> ced the following = >>> output: TESTHOSTNAME=3Dniagara WS=3D/homes/hosking/work/ >>> cm3-ws/n= >>> iagara-2009-04-29-10-30-05 LASTREL=3D5.4.0 INSTROOT_REL=3D/ >>> homes/hos= >>> king/work/cm3-inst/niagara/rel-5.4.0 INSTROOT_POK=3D/homes/ >>> hosking/work= >>> /cm3-inst/niagara/prev-ok INSTROOT_LOK=3D/homes/hosking/work/cm3- >>> inst/n= >>> iagara/last-ok INSTROOT_CUR=3D/homes/hosking/work/cm3-inst/ >>> niagara/curr= >>> ent CM3_OSTYPE=3DPOSIX CM3_TARGET=3DSOLgnu BINDISTMIN=3D/ >>> homes/ho= >>> sking/work/cm3-min-POSIX- >>> SOLgnu-5.4.0.tgz CM3CVSSERVER=3Dbirch.elegosof= >>> t.com CM3CVSROOT=3Dbirch.elegosoft.com:/usr/ >>> cvs BINDISTMIN_NAME=3Dcm= >>> 3-min-POSIX-SOLgnu-5.4.0.tgz BINDISTMIN=3D/homes/hosking/work/ >>> cm3-min-P= >>> OSIX-SOLgnu-5.4.0.tgz CM3CVSUSER=3D testing ssh = >>> birch.elegosoft.com.. ssh birch.elegosoft.com ok Building = >>> cm3. Tinderbox Tree: "cm3" Buildname: = >>> "SOLgnu SunOS 5.10 >>> niagara = >>> release-build" creating log file = >>> /tmp/build-cm3-20090429-063007-_Laq8F/log.txt --- >>> checkout, = >>> compile and test of cm3 ... 2009.04.29 06:30:07 -- checkout in = >>> progress. [start checkout 2009.04.29 06:30:09] cd = >>> /tmp/build-cm3-20090429-063007-_Laq8F/build cvs return value: = >>> 0 [end checkout 2009.04.29 06:49:37] CHECKOUT_RETURN =3D = >> 0 -- 2009.04.29 06:49:41 -- compile in progress. [start >> compile = >>> 2009.04.29 06:49:41] compile return value: 0 [end compile = >>> 2009.04.29 08:10:32] COMPILE_RETURN =3D 1 *** COMPILE = >>> FAILED removing build tree /tmp/build-cm3-20090429-063007-_Laq8F = >>> ... cleaning CM3 = >>> workspaces... /homes/hosking/work/cm3-ws/niagara- >>> * cleaning = >>> regression test log = >>> files... /homes/hosking/tmp/cm3/niagara/cm3-rlog- >>> * cleaning = >>> m3test log = >>> files... /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout / >>> homes/= >>> hosking/tmp/cm3/niagara/m3tests-*.stderr /homes/hosking/tmp/ >>> cm3/nia= >>> gara/m3tests-*.stderr.extract cleaning snapshot = >>> files... /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >>> *.tgz>>>> cleaning package = >>> reports... /tmp/cm3-pkg-report-SOLgnu- >>> *.html TESTHOSTNAME=3Dniag= >>> ara WS=3D/homes/hosking/work/cm3-ws/ >>> niagara-2009-04-29-12-12-22 LAST= >>> REL=3D5.4.0 INSTROOT_REL=3D/homes/hosking/work/cm3-inst/niagara/ >>> rel-5.4= >>> .0 INSTROOT_POK=3D/homes/hosking/work/cm3-inst/niagara/prev- >>> ok INSTR= >>> OOT_LOK=3D/homes/hosking/work/cm3-inst/niagara/last- >>> ok INSTROOT_CUR=3D/= >>> homes/hosking/work/cm3-inst/niagara/ >>> current CM3_OSTYPE=3DPOSIX CM3_T= >>> ARGET=3DSOLgnu BINDISTMIN=3D/homes/hosking/work/cm3-min-POSIX- >>> SOLgnu-5.= >>> 4.0 >>> .tgz >>> CM3CVSSERVER=3Dbirch.elegosoft.com CM3CVSROOT=3Dbirch.elegos= >>> oft.com:/usr/cvs BINDISTMIN_NAME=3Dcm3-min-POSIX- >>> SOLgnu-5.4.0.tgz BI= >>> NDISTMIN=3D/homes/hosking/work/cm3-min-POSIX- >>> SOLgnu-5.4.0.tgz CM3CVSUSE= >>> R=3D testing ssh birch.elegosoft.com.. ssh >>> birch.elegosoft.com = >>> ok Building cm3. Tinderbox Tree: >>> "cm3" Buildname: = >>> "SOLgnu SunOS 5.10 >>> niagara = >>> lastok-build" creating log file = >>> /tmp/build-cm3-20090429-081224-i9aWYM/log.txt --- >>> checkout, = >>> compile and test of cm3 ... 2009.04.29 08:12:24 -- checkout in = >>> progress. [start checkout 2009.04.29 08:12:26] cd = >>> /tmp/build-cm3-20090429-081224-i9aWYM/build cvs return value: = >>> 0 [end checkout 2009.04.29 08:32:34] CHECKOUT_RETURN =3D = >>> 0 -- 2009.04.29 08:32:38 -- compile in progress. [start >>> compile = >>> 2009.04.29 08:32:38] compile return value: 0 [end compile = >>> 2009.04.29 09:19:20] COMPILE_RETURN =3D 0 2009.04.29 09:19:24 >>> -- = >>> tests in progress. [start run-tests 2009.04.29 09:19:24] cd = >>> /tmp/build-cm3-20090429-081224-i9aWYM/build [end run-tests >>> 2009.04.29 = >>> 09:19:24] TESTS_RETURN =3D 0 2009.04.29 09:19:24 -- checkout, = >> compile and test run done. --- removing build tree = >>> /tmp/build-cm3-20090429-081224-i9aWYM ... cleaning CM3 = >>> workspaces... /homes/hosking/work/cm3-ws/niagara- >>> * cleaning = >>> regression test log = >>> files... /homes/hosking/tmp/cm3/niagara/cm3-rlog- >>> * cleaning = >>> m3test log = >>> files... /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout / >>> homes/= >>> hosking/tmp/cm3/niagara/m3tests-*.stderr /homes/hosking/tmp/ >>> cm3/nia= >>> gara/m3tests-*.stderr.extract cleaning snapshot = >>> files... /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >>> *.tgz>>>> cleaning package = >>> reports... /tmp/cm3-pkg-report-SOLgnu-*.html done. >>> div>>>> ockquote> = >>> >>> --Apple-Mail-6-728527402-- > From jay.krell at cornell.edu Wed Apr 29 22:07:48 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 29 Apr 2009 20:07:48 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: References: <200904291832.n3TIWPNo038139@camembert.async.caltech.edu> Message-ID: Actually it looks like I missed I didn't change ThreadPThreadC.c to turn on __thread. Anyway I'll look a bit, did make other changes. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; mika at async.caltech.edu > Date: Wed, 29 Apr 2009 20:01:14 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Fwd: Output from "cron" command > > > Add this to your favorites or bookmarks or whatever: > > > http://tinderbox.elegosoft.com/tinderbox/cm3/status.html > > It's not the most friendly but it is ok. > > > Unfortunately the error is just: > > 12067 NEXT Bus Error - core dumped > > I'll undo stuff, like __thread mainly. > > - Jay > > > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: mika at async.caltech.edu >> Date: Thu, 30 Apr 2009 04:35:07 +1000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Fwd: Output from "cron" command >> >> Tinderbox... >> >> On 30 Apr 2009, at 04:32, Mika Nystrom wrote: >> >>> >>> I found I had made a typo in my m3tk check-in. Is there an easy >>> way to see what the error is? >>> >>> Mika >>> >>> Tony Hosking writes: >>>> >>>> --Apple-Mail-6-728527402 >>>> Content-Type: text/plain; >>>> charset=US-ASCII; >>>> format=flowed >>>> Content-Transfer-Encoding: 7bit >>>> >>>> Now I am getting compile errors. Recent checkins are culpable. >>>> >>>> Begin forwarded message: >>>> >>>>> From: Tony Hosking >>>>> Date: 29 April 2009 23:21:16 GMT+10:00 >>>>> To: hosking at cs.purdue.edu >>>>> Subject: Output from "cron" command >>>>> >>>>> Your "cron" job on niagara.cs.purdue.edu >>>>> $HOME/cm3/scripts/regression/cron.sh >>>>> >>>>> produced the following output: >>>>> >>>>> TESTHOSTNAME=niagara >>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-10-30-05 >>>>> LASTREL=5.4.0 >>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>> CM3_OSTYPE=POSIX >>>>> CM3_TARGET=SOLgnu >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSSERVER=birch.elegosoft.com >>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSUSER= >>>>> testing ssh birch.elegosoft.com.. >>>>> ssh birch.elegosoft.com ok >>>>> Building cm3. >>>>> Tinderbox Tree: "cm3" >>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>> >>>>> creating log file /tmp/build-cm3-20090429-063007-_Laq8F/log.txt >>>>> >>>>> --- >>>>> >>>>> checkout, compile and test of cm3 ... >>>>> 2009.04.29 06:30:07 -- checkout in progress. >>>>> [start checkout 2009.04.29 06:30:09] >>>>> cd /tmp/build-cm3-20090429-063007-_Laq8F/build >>>>> cvs return value: 0 >>>>> [end checkout 2009.04.29 06:49:37] >>>>> CHECKOUT_RETURN = 0 >>>>> -- >>>>> 2009.04.29 06:49:41 -- compile in progress. >>>>> [start compile 2009.04.29 06:49:41] >>>>> compile return value: 0 >>>>> [end compile 2009.04.29 08:10:32] >>>>> COMPILE_RETURN = 1 >>>>> *** COMPILE FAILED >>>>> removing build tree /tmp/build-cm3-20090429-063007-_Laq8F ... >>>>> cleaning CM3 workspaces... >>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>> >>>>> cleaning regression test log files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>> >>>>> cleaning m3test log files... >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>> >>>>> cleaning snapshot files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>> >>>>> cleaning package reports... >>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>> >>>>> TESTHOSTNAME=niagara >>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-12-12-22 >>>>> LASTREL=5.4.0 >>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>> CM3_OSTYPE=POSIX >>>>> CM3_TARGET=SOLgnu >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSSERVER=birch.elegosoft.com >>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSUSER= >>>>> testing ssh birch.elegosoft.com.. >>>>> ssh birch.elegosoft.com ok >>>>> Building cm3. >>>>> Tinderbox Tree: "cm3" >>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>> >>>>> creating log file /tmp/build-cm3-20090429-081224-i9aWYM/log.txt >>>>> >>>>> --- >>>>> >>>>> checkout, compile and test of cm3 ... >>>>> 2009.04.29 08:12:24 -- checkout in progress. >>>>> [start checkout 2009.04.29 08:12:26] >>>>> cd /tmp/build-cm3-20090429-081224-i9aWYM/build >>>>> cvs return value: 0 >>>>> [end checkout 2009.04.29 08:32:34] >>>>> CHECKOUT_RETURN = 0 >>>>> -- >>>>> 2009.04.29 08:32:38 -- compile in progress. >>>>> [start compile 2009.04.29 08:32:38] >>>>> compile return value: 0 >>>>> [end compile 2009.04.29 09:19:20] >>>>> COMPILE_RETURN = 0 >>>>> 2009.04.29 09:19:24 -- tests in progress. >>>>> [start run-tests 2009.04.29 09:19:24] >>>>> cd /tmp/build-cm3-20090429-081224-i9aWYM/build >>>>> [end run-tests 2009.04.29 09:19:24] >>>>> TESTS_RETURN = 0 >>>>> 2009.04.29 09:19:24 -- checkout, compile and test run done. >>>>> >>>>> --- >>>>> >>>>> removing build tree /tmp/build-cm3-20090429-081224-i9aWYM ... >>>>> cleaning CM3 workspaces... >>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>> >>>>> cleaning regression test log files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>> >>>>> cleaning m3test log files... >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>> >>>>> cleaning snapshot files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>> >>>>> cleaning package reports... >>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>> >>>>> done. >>>> >>>> >>>> --Apple-Mail-6-728527402 >>>> Content-Type: text/html; >>>> charset=US-ASCII >>>> Content-Transfer-Encoding: quoted-printable >>>> >>>>>>> space; = >>>> -webkit-line-break: after-white-space; "> >>>> apple-content-edited=3D"true">>>> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >>>> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >>>> normal; font-variant: normal; font-weight: normal; letter-spacing: = >>>> normal; line-height: normal; text-align: auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; "> >>>> style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; = >>>> -khtml-line-break: after-white-space; ">>>> span" = >>>> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >>>> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >>>> normal; font-variant: normal; font-weight: normal; letter-spacing: = >>>> normal; line-height: normal; text-align: auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; "> > Now I am = >>>> getting compile errors. Recent checkins are = >>>> culpable.>>> span>>>> iv> > > > Begin forwarded message: >>>> class=3D"Apple-interchange-newline">>>> type=3D"cite"> > >>>> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >>>> margin-left: 0px; ">>>> color=3D"#000000" = >>>> style=3D"font: 12.0px Helvetica; color: #000000">From: = >>>>>>> 12.0px = >>>> Helvetica">Tony Hosking <>>> href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu>>>> font>>>> iv> >>>> 0px; = >>>> margin-left: 0px; ">>>> color=3D"#000000" = >>>> style=3D"font: 12.0px Helvetica; color: #000000">Date: = >>>>>>> 12.0px = >>>> Helvetica">29 April 2009 23:21:16 GMT+10:00 >>>> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >>>> margin-left: 0px; ">>>> color=3D"#000000" = >>>> style=3D"font: 12.0px Helvetica; color: #000000">To:>>> font>>>> face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">>>> href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu>>> font>>>> v> >>>> 0px; = >>>> margin-left: 0px; ">>>> color=3D"#000000" = >>>> style=3D"font: 12.0px Helvetica; color: #000000">Subject: = >>>>>>> 12.0px = >>>> Helvetica">Output from "cron" command >>>> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >>>> margin-left: 0px; min-height: 14px; "> > > Your >>>> "cron" = >>>> job on = >>>> niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/ >>>> cron.sh > > produ= >>>> ced the following = >>>> output: > > TESTHOSTNAME=3Dniagara > WS=3D/homes/hosking/work/ >>>> cm3-ws/n= >>>> iagara-2009-04-29-10-30-05 > LASTREL=3D5.4.0 > INSTROOT_REL=3D/ >>>> homes/hos= >>>> king/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=3D/homes/ >>>> hosking/work= >>>> /cm3-inst/niagara/prev-ok > INSTROOT_LOK=3D/homes/hosking/work/cm3- >>>> inst/n= >>>> iagara/last-ok > INSTROOT_CUR=3D/homes/hosking/work/cm3-inst/ >>>> niagara/curr= >>>> ent > CM3_OSTYPE=3DPOSIX > CM3_TARGET=3DSOLgnu > BINDISTMIN=3D/ >>>> homes/ho= >>>> sking/work/cm3-min-POSIX- >>>> SOLgnu-5.4.0.tgz > CM3CVSSERVER=3Dbirch.elegosof= >>>> t.com > CM3CVSROOT=3Dbirch.elegosoft.com:/usr/ >>>> cvs > BINDISTMIN_NAME=3Dcm= >>>> 3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=3D/homes/hosking/work/ >>>> cm3-min-P= >>>> OSIX-SOLgnu-5.4.0.tgz > CM3CVSUSER=3D > testing ssh = >>>> birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building = >>>> cm3. > Tinderbox Tree: "cm3" > Buildname: = >>>> "SOLgnu SunOS 5.10 >>>> niagara = >>>> release-build" > > creating log file = >>>> /tmp/build-cm3-20090429-063007-_Laq8F/log.txt > > --- >>>> > > checkout, = >>>> compile and test of cm3 ... > 2009.04.29 06:30:07 -- checkout in = >>>> progress. > [start checkout 2009.04.29 06:30:09] > cd = >>>> /tmp/build-cm3-20090429-063007-_Laq8F/build > cvs return value: = >>>> 0 > [end checkout 2009.04.29 06:49:37] > CHECKOUT_RETURN =3D = >>> 0 > -- > 2009.04.29 06:49:41 -- compile in progress. > [start >>> compile = >>>> 2009.04.29 06:49:41] > compile return value: 0 > [end compile = >>>> 2009.04.29 08:10:32] > COMPILE_RETURN =3D 1 > *** COMPILE = >>>> FAILED > removing build tree /tmp/build-cm3-20090429-063007-_Laq8F = >>>> ... > cleaning CM3 = >>>> workspaces... > /homes/hosking/work/cm3-ws/niagara- >>>> * > > cleaning = >>>> regression test log = >>>> files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog- >>>> * > > cleaning = >>>> m3test log = >>>> files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > / >>>> homes/= >>>> hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/ >>>> cm3/nia= >>>> gara/m3tests-*.stderr.extract > > cleaning snapshot = >>>> files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >>>> *.tgz>>>> > cleaning package = >>>> reports... > /tmp/cm3-pkg-report-SOLgnu- >>>> *.html > > TESTHOSTNAME=3Dniag= >>>> ara > WS=3D/homes/hosking/work/cm3-ws/ >>>> niagara-2009-04-29-12-12-22 > LAST= >>>> REL=3D5.4.0 > INSTROOT_REL=3D/homes/hosking/work/cm3-inst/niagara/ >>>> rel-5.4= >>>> .0 > INSTROOT_POK=3D/homes/hosking/work/cm3-inst/niagara/prev- >>>> ok > INSTR= >>>> OOT_LOK=3D/homes/hosking/work/cm3-inst/niagara/last- >>>> ok > INSTROOT_CUR=3D/= >>>> homes/hosking/work/cm3-inst/niagara/ >>>> current > CM3_OSTYPE=3DPOSIX > CM3_T= >>>> ARGET=3DSOLgnu > BINDISTMIN=3D/homes/hosking/work/cm3-min-POSIX- >>>> SOLgnu-5.= >>>> 4.0 >>>> .tgz >>>> > CM3CVSSERVER=3Dbirch.elegosoft.com > CM3CVSROOT=3Dbirch.elegos= >>>> oft.com:/usr/cvs > BINDISTMIN_NAME=3Dcm3-min-POSIX- >>>> SOLgnu-5.4.0.tgz > BI= >>>> NDISTMIN=3D/homes/hosking/work/cm3-min-POSIX- >>>> SOLgnu-5.4.0.tgz > CM3CVSUSE= >>>> R=3D > testing ssh birch.elegosoft.com.. > ssh >>>> birch.elegosoft.com = >>>> ok > Building cm3. > Tinderbox Tree: >>>> "cm3" > Buildname: = >>>> "SOLgnu SunOS 5.10 >>>> niagara = >>>> lastok-build" > > creating log file = >>>> /tmp/build-cm3-20090429-081224-i9aWYM/log.txt > > --- >>>> > > checkout, = >>>> compile and test of cm3 ... > 2009.04.29 08:12:24 -- checkout in = >>>> progress. > [start checkout 2009.04.29 08:12:26] > cd = >>>> /tmp/build-cm3-20090429-081224-i9aWYM/build > cvs return value: = >>>> 0 > [end checkout 2009.04.29 08:32:34] > CHECKOUT_RETURN =3D = >>>> 0 > -- > 2009.04.29 08:32:38 -- compile in progress. > [start >>>> compile = >>>> 2009.04.29 08:32:38] > compile return value: 0 > [end compile = >>>> 2009.04.29 09:19:20] > COMPILE_RETURN =3D 0 > 2009.04.29 09:19:24 >>>> -- = >>>> tests in progress. > [start run-tests 2009.04.29 09:19:24] > cd = >>>> /tmp/build-cm3-20090429-081224-i9aWYM/build > [end run-tests >>>> 2009.04.29 = >>>> 09:19:24] > TESTS_RETURN =3D 0 > 2009.04.29 09:19:24 -- checkout, = >>> compile and test run done. > > --- > > removing build tree = >>>> /tmp/build-cm3-20090429-081224-i9aWYM ... > cleaning CM3 = >>>> workspaces... > /homes/hosking/work/cm3-ws/niagara- >>>> * > > cleaning = >>>> regression test log = >>>> files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog- >>>> * > > cleaning = >>>> m3test log = >>>> files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > / >>>> homes/= >>>> hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/ >>>> cm3/nia= >>>> gara/m3tests-*.stderr.extract > > cleaning snapshot = >>>> files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >>>> *.tgz>>>> > cleaning package = >>>> reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > done. >>>> div>>>> ockquote> > = >>>> >>>> --Apple-Mail-6-728527402-- >> From mika at async.caltech.edu Wed Apr 29 22:12:09 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 29 Apr 2009 13:12:09 -0700 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: Your message of "Wed, 29 Apr 2009 20:01:14 -0000." Message-ID: <200904292012.n3TKC93h043346@camembert.async.caltech.edu> This one is my fault: 27146 new source -> compiling Type.m3 27147 "../src/Type.m3", line 291: types are not assignable 27148 NEXT 1 error encountered I think I already fixed it, though. Mika Jay writes: > >Add this to your favorites or bookmarks or whatever: > > >http://tinderbox.elegosoft.com/tinderbox/cm3/status.html > >It's not the most friendly but it is ok. > > >Unfortunately the error is just: > >12067 NEXT Bus Error - core dumped > >I'll undo stuff, like __thread mainly. > > - Jay > > > > >---------------------------------------- >> From: hosking at cs.purdue.edu >> To: mika at async.caltech.edu >> Date: Thu, 30 Apr 2009 04:35:07 +1000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Fwd: Output from "cron" command >> >> Tinderbox... >> >> On 30 Apr 2009, at 04:32, Mika Nystrom wrote: >> >>> >>> I found I had made a typo in my m3tk check-in. Is there an easy >>> way to see what the error is? >>> >>> Mika >>> >>> Tony Hosking writes: >>>> >>>> --Apple-Mail-6-728527402 >>>> Content-Type: text/plain; >>>> charset=US-ASCII; >>>> format=flowed >>>> Content-Transfer-Encoding: 7bit >>>> >>>> Now I am getting compile errors. Recent checkins are culpable. >>>> >>>> Begin forwarded message: >>>> >>>>> From: Tony Hosking >>>>> Date: 29 April 2009 23:21:16 GMT+10:00 >>>>> To: hosking at cs.purdue.edu >>>>> Subject: Output from "cron" command >>>>> >>>>> Your "cron" job on niagara.cs.purdue.edu >>>>> $HOME/cm3/scripts/regression/cron.sh >>>>> >>>>> produced the following output: >>>>> >>>>> TESTHOSTNAME=niagara >>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-10-30-05 >>>>> LASTREL=5.4.0 >>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>> CM3_OSTYPE=POSIX >>>>> CM3_TARGET=SOLgnu >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSSERVER=birch.elegosoft.com >>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSUSER= >>>>> testing ssh birch.elegosoft.com.. >>>>> ssh birch.elegosoft.com ok >>>>> Building cm3. >>>>> Tinderbox Tree: "cm3" >>>>> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >>>>> >>>>> creating log file /tmp/build-cm3-20090429-063007-_Laq8F/log.txt >>>>> >>>>> --- >>>>> >>>>> checkout, compile and test of cm3 ... >>>>> 2009.04.29 06:30:07 -- checkout in progress. >>>>> [start checkout 2009.04.29 06:30:09] >>>>> cd /tmp/build-cm3-20090429-063007-_Laq8F/build >>>>> cvs return value: 0 >>>>> [end checkout 2009.04.29 06:49:37] >>>>> CHECKOUT_RETURN = 0 >>>>> -- >>>>> 2009.04.29 06:49:41 -- compile in progress. >>>>> [start compile 2009.04.29 06:49:41] >>>>> compile return value: 0 >>>>> [end compile 2009.04.29 08:10:32] >>>>> COMPILE_RETURN = 1 >>>>> *** COMPILE FAILED >>>>> removing build tree /tmp/build-cm3-20090429-063007-_Laq8F ... >>>>> cleaning CM3 workspaces... >>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>> >>>>> cleaning regression test log files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>> >>>>> cleaning m3test log files... >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>> >>>>> cleaning snapshot files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>> >>>>> cleaning package reports... >>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>> >>>>> TESTHOSTNAME=niagara >>>>> WS=/homes/hosking/work/cm3-ws/niagara-2009-04-29-12-12-22 >>>>> LASTREL=5.4.0 >>>>> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >>>>> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >>>>> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >>>>> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >>>>> CM3_OSTYPE=POSIX >>>>> CM3_TARGET=SOLgnu >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSSERVER=birch.elegosoft.com >>>>> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >>>>> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >>>>> CM3CVSUSER= >>>>> testing ssh birch.elegosoft.com.. >>>>> ssh birch.elegosoft.com ok >>>>> Building cm3. >>>>> Tinderbox Tree: "cm3" >>>>> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >>>>> >>>>> creating log file /tmp/build-cm3-20090429-081224-i9aWYM/log.txt >>>>> >>>>> --- >>>>> >>>>> checkout, compile and test of cm3 ... >>>>> 2009.04.29 08:12:24 -- checkout in progress. >>>>> [start checkout 2009.04.29 08:12:26] >>>>> cd /tmp/build-cm3-20090429-081224-i9aWYM/build >>>>> cvs return value: 0 >>>>> [end checkout 2009.04.29 08:32:34] >>>>> CHECKOUT_RETURN = 0 >>>>> -- >>>>> 2009.04.29 08:32:38 -- compile in progress. >>>>> [start compile 2009.04.29 08:32:38] >>>>> compile return value: 0 >>>>> [end compile 2009.04.29 09:19:20] >>>>> COMPILE_RETURN = 0 >>>>> 2009.04.29 09:19:24 -- tests in progress. >>>>> [start run-tests 2009.04.29 09:19:24] >>>>> cd /tmp/build-cm3-20090429-081224-i9aWYM/build >>>>> [end run-tests 2009.04.29 09:19:24] >>>>> TESTS_RETURN = 0 >>>>> 2009.04.29 09:19:24 -- checkout, compile and test run done. >>>>> >>>>> --- >>>>> >>>>> removing build tree /tmp/build-cm3-20090429-081224-i9aWYM ... >>>>> cleaning CM3 workspaces... >>>>> /homes/hosking/work/cm3-ws/niagara-* >>>>> >>>>> cleaning regression test log files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >>>>> >>>>> cleaning m3test log files... >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >>>>> >>>>> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >>>>> >>>>> cleaning snapshot files... >>>>> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >>>>> >>>>> cleaning package reports... >>>>> /tmp/cm3-pkg-report-SOLgnu-*.html >>>>> >>>>> done. >>>> >>>> >>>> --Apple-Mail-6-728527402 >>>> Content-Type: text/html; >>>> charset=US-ASCII >>>> Content-Transfer-Encoding: quoted-printable >>>> >>>>>>> space; = >>>> -webkit-line-break: after-white-space; "> >>>> apple-content-edited=3D"true">>>> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >>>> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >>>> normal; font-variant: normal; font-weight: normal; letter-spacing: = >>>> normal; line-height: normal; text-align: auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; "> >>>> style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; = >>>> -khtml-line-break: after-white-space; ">>>> span" = >>>> style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = >>>> rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = >>>> normal; font-variant: normal; font-weight: normal; letter-spacing: = >>>> normal; line-height: normal; text-align: auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; ">>>> class=3D"Apple-style-span" style=3D"border-collapse: separate; = >>>> border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: >>>> Helvetica; = >>>> font-size: 12px; font-style: normal; font-variant: normal; font- >>>> weight: = >>>> normal; letter-spacing: normal; line-height: normal; text-align: >>>> auto; = >>>> -khtml-text-decorations-in-effect: none; text-indent: 0px; = >>>> -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = >>>> white-space: normal; widows: 2; word-spacing: 0px; "> >Now I am = >>>> getting compile errors. Recent checkins are = >>>> culpable.>>> span>>>> iv> > > >Begin forwarded message: >>>> class=3D"Apple-interchange-newline">>>> type=3D"cite"> > >>>> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >>>> margin-left: 0px; ">>>> color=3D"#000000" = >>>> style=3D"font: 12.0px Helvetica; color: #000000">From: = >>>>>>> 12.0px = >>>> Helvetica">Tony Hosking <>>> href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu>>>> font>>>> iv> >>>> 0px; = >>>> margin-left: 0px; ">>>> color=3D"#000000" = >>>> style=3D"font: 12.0px Helvetica; color: #000000">Date: = >>>>>>> 12.0px = >>>> Helvetica">29 April 2009 23:21:16 GMT+10:00 >>>> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >>>> margin-left: 0px; ">>>> color=3D"#000000" = >>>> style=3D"font: 12.0px Helvetica; color: #000000">To:>>> font>>>> face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">>>> href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu>>> font>>>> >v> >>>> 0px; = >>>> margin-left: 0px; ">>>> color=3D"#000000" = >>>> style=3D"font: 12.0px Helvetica; color: #000000">Subject: = >>>>>>> 12.0px = >>>> Helvetica">Output from "cron" command >>>> style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = >>>> margin-left: 0px; min-height: 14px; "> > >Your >>>> "cron" = >>>> job on = >>>> niagara.cs.purdue.edu >$HOME/cm3/scripts/regression/ >>>> cron.sh > >produ= >>>> ced the following = >>>> output: > >TESTHOSTNAME=3Dniagara >WS=3D/homes/hosking/work/ >>>> cm3-ws/n= >>>> iagara-2009-04-29-10-30-05 >LASTREL=3D5.4.0 >INSTROOT_REL=3D/ >>>> homes/hos= >>>> king/work/cm3-inst/niagara/rel-5.4.0 >INSTROOT_POK=3D/homes/ >>>> hosking/work= >>>> /cm3-inst/niagara/prev-ok >INSTROOT_LOK=3D/homes/hosking/work/cm3- >>>> inst/n= >>>> iagara/last-ok >INSTROOT_CUR=3D/homes/hosking/work/cm3-inst/ >>>> niagara/curr= >>>> ent >CM3_OSTYPE=3DPOSIX >CM3_TARGET=3DSOLgnu >BINDISTMIN=3D/ >>>> homes/ho= >>>> sking/work/cm3-min-POSIX- >>>> SOLgnu-5.4.0.tgz >CM3CVSSERVER=3Dbirch.elegosof= >>>> t.com >CM3CVSROOT=3Dbirch.elegosoft.com:/usr/ >>>> cvs >BINDISTMIN_NAME=3Dcm= >>>> 3-min-POSIX-SOLgnu-5.4.0.tgz >BINDISTMIN=3D/homes/hosking/work/ >>>> cm3-min-P= >>>> OSIX-SOLgnu-5.4.0.tgz >CM3CVSUSER=3D >testing ssh = >>>> birch.elegosoft.com.. >ssh birch.elegosoft.com ok >Building = >>>> cm3. >Tinderbox Tree: "cm3" >Buildname: = >>>> "SOLgnu SunOS 5.10 >>>> niagara = >>>> release-build" > >creating log file = >>>> /tmp/build-cm3-20090429-063007-_Laq8F/log.txt > >--- >>>> > >checkout, = >>>> compile and test of cm3 ... >2009.04.29 06:30:07 -- checkout in = >>>> progress. >[start checkout 2009.04.29 06:30:09] >cd = >>>> /tmp/build-cm3-20090429-063007-_Laq8F/build >cvs return value: = >>>> 0 >[end checkout 2009.04.29 06:49:37] >CHECKOUT_RETURN =3D = >>> 0 >-- >2009.04.29 06:49:41 -- compile in progress. >[start >>> compile = >>>> 2009.04.29 06:49:41] >compile return value: 0 >[end compile = >>>> 2009.04.29 08:10:32] >COMPILE_RETURN =3D 1 >*** COMPILE = >>>> FAILED >removing build tree /tmp/build-cm3-20090429-063007-_Laq8F = >>>> ... >cleaning CM3 = >>>> workspaces... >/homes/hosking/work/cm3-ws/niagara- >>>> * > >cleaning = >>>> regression test log = >>>> files... >/homes/hosking/tmp/cm3/niagara/cm3-rlog- >>>> * > >cleaning = >>>> m3test log = >>>> files... >/homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > >/ >>>> homes/= >>>> hosking/tmp/cm3/niagara/m3tests-*.stderr > >/homes/hosking/tmp/ >>>> cm3/nia= >>>> gara/m3tests-*.stderr.extract > >cleaning snapshot = >>>> files... >/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >>>> *.tgz>>>> >cleaning package = >>>> reports... >/tmp/cm3-pkg-report-SOLgnu- >>>> *.html > >TESTHOSTNAME=3Dniag= >>>> ara >WS=3D/homes/hosking/work/cm3-ws/ >>>> niagara-2009-04-29-12-12-22 >LAST= >>>> REL=3D5.4.0 >INSTROOT_REL=3D/homes/hosking/work/cm3-inst/niagara/ >>>> rel-5.4= >>>> .0 >INSTROOT_POK=3D/homes/hosking/work/cm3-inst/niagara/prev- >>>> ok >INSTR= >>>> OOT_LOK=3D/homes/hosking/work/cm3-inst/niagara/last- >>>> ok >INSTROOT_CUR=3D/= >>>> homes/hosking/work/cm3-inst/niagara/ >>>> current >CM3_OSTYPE=3DPOSIX >CM3_T= >>>> ARGET=3DSOLgnu >BINDISTMIN=3D/homes/hosking/work/cm3-min-POSIX- >>>> SOLgnu-5.= >>>> 4.0 >>>> .tgz >>>> >CM3CVSSERVER=3Dbirch.elegosoft.com >CM3CVSROOT=3Dbirch.elegos= >>>> oft.com:/usr/cvs >BINDISTMIN_NAME=3Dcm3-min-POSIX- >>>> SOLgnu-5.4.0.tgz >BI= >>>> NDISTMIN=3D/homes/hosking/work/cm3-min-POSIX- >>>> SOLgnu-5.4.0.tgz >CM3CVSUSE= >>>> R=3D >testing ssh birch.elegosoft.com.. >ssh >>>> birch.elegosoft.com = >>>> ok >Building cm3. >Tinderbox Tree: >>>> "cm3" >Buildname: = >>>> "SOLgnu SunOS 5.10 >>>> niagara = >>>> lastok-build" > >creating log file = >>>> /tmp/build-cm3-20090429-081224-i9aWYM/log.txt > >--- >>>> > >checkout, = >>>> compile and test of cm3 ... >2009.04.29 08:12:24 -- checkout in = >>>> progress. >[start checkout 2009.04.29 08:12:26] >cd = >>>> /tmp/build-cm3-20090429-081224-i9aWYM/build >cvs return value: = >>>> 0 >[end checkout 2009.04.29 08:32:34] >CHECKOUT_RETURN =3D = >>>> 0 >-- >2009.04.29 08:32:38 -- compile in progress. >[start >>>> compile = >>>> 2009.04.29 08:32:38] >compile return value: 0 >[end compile = >>>> 2009.04.29 09:19:20] >COMPILE_RETURN =3D 0 >2009.04.29 09:19:24 >>>> -- = >>>> tests in progress. >[start run-tests 2009.04.29 09:19:24] >cd = >>>> /tmp/build-cm3-20090429-081224-i9aWYM/build >[end run-tests >>>> 2009.04.29 = >>>> 09:19:24] >TESTS_RETURN =3D 0 >2009.04.29 09:19:24 -- checkout, = >>> compile and test run done. > >--- > >removing build tree = >>>> /tmp/build-cm3-20090429-081224-i9aWYM ... >cleaning CM3 = >>>> workspaces... >/homes/hosking/work/cm3-ws/niagara- >>>> * > >cleaning = >>>> regression test log = >>>> files... >/homes/hosking/tmp/cm3/niagara/cm3-rlog- >>>> * > >cleaning = >>>> m3test log = >>>> files... >/homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > >/ >>>> homes/= >>>> hosking/tmp/cm3/niagara/m3tests-*.stderr > >/homes/hosking/tmp/ >>>> cm3/nia= >>>> gara/m3tests-*.stderr.extract > >cleaning snapshot = >>>> files... >/homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*- >>>> *.tgz>>>> >cleaning package = >>>> reports... >/tmp/cm3-pkg-report-SOLgnu-*.html > >done. >>>> div>>>> ockquote> >= >>>> >>>> --Apple-Mail-6-728527402-- >> From jay.krell at cornell.edu Wed Apr 29 23:16:24 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 29 Apr 2009 21:16:24 +0000 Subject: [M3devel] [M3commit] how to switch userthreads on/off In-Reply-To: <69291A6D-E915-41C9-B4FB-AB7F5CF398EE@cs.purdue.edu> References: <200904290622.n3T6MZBR003219@camembert.async.caltech.edu> <69291A6D-E915-41C9-B4FB-AB7F5CF398EE@cs.purdue.edu> Message-ID: Really? I mean, partly, definitely. And I was looking at the "inflating" to see how they do conditionv variables. But, as I understand: The first time you enter a lock will be slow in that it will be heap allocate and pthread_mutex_init. (untraced; with implied use of a lock for the untraced heap). (plus pthread_mutex_lock(&init)). The subsequent times you enter a lock will be "slow" in that they will always call pthread_mutex_lock, but that might not be particularly slow, right? It is a function call, granted, but the implementation might/should be very quick in the case of no contention. Like, you know, presumably the pthread implementer, except on the case of FreeBSD 4.x :) is trying to do a pretty good job for everyone. "But I don't have numbers." - Jay ________________________________ > From: hosking at cs.purdue.edu > To: mika at async.caltech.edu > Date: Thu, 30 Apr 2009 04:33:01 +1000 > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] [M3commit] how to switch userthreads on/off > > Mika, > > With the current implementation of M3 MUTEX 1-1 as pthread mutex you are bound to have significant overhead for any locking code even in single-threaded apps. We need to move towards a thin-lock implementation for mutex (as used in modern Java implementations) to avoid overhead for uncontended locks. It's not too hard to implement. The idea is to represent a mutex as a tagged word. The word contains either NIL, the thread holding the lock, or a pointer to a full-blown (inflated) pthread mutex. We can use GC and other opportunities to deflate locks as needs. Checking the tag requires a CAS. There are other techniques that further eliminate the CAS for the uncontended case. But, generally, you should consider LOCK to be a fairly high-overhead operation for now. > > 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 29 Apr 2009, at 16:22, Mika Nystrom wrote: > > Jay writes: > ... > > Maybe just leave it as an option in m3core's m3makefile and people can twiddle it if they want and rebuild the entire system like it is today? > That is a bit onerous, but maybe it's all userthreads deserve? > ? > > > Anyone who actually wanted to switch back and forth (Mika) would just have two installs and two source trees? > > > - Jay > > I just want to clarify. I'm not really that interested in switching > back and forth. I'm just a little disturbed by the sometimes huge > performance loss due to the introduction of kernel threads. I knew > that this would happen in certain highly multithreaded applications, > but I'm surprised it happens in a more or less single-threaded > application. > > I think I've just been spoiled by 10 years of using SRCM3 and PM3 > for FreeBSD w/o kernel threads in the sense that I've learned that > using LOCK has essentially no cost. On a shared-memory multiprocessor, > I really don't expect that to remain the case... physics won't allow > it. So now I just have to go through my code and find all the places > where I lock too much and remove them. > > But the memory allocator and garbage collector do it too, no? > > I also think that this idea of being able to use either is great. > Mainly single-threaded programs should definitely not use kernel > threads! > > As for reaching the "thread locals", there is one slightly crazy > idea that one could borrow from Sussman and Steele: add another > implicit argument to every Modula-3 routine. In that argument, > pass a pointer to the thread locals. For EXTERNAL calls (in or > out), make it NIL (somehow, maybe involving pragmas), and in that > case (only), use the pthreads routines to access the thread locals. > Ok so it sounds kind of nuts, but with this approach you could avoid > locking or even calling into the pthreads libs almost entirely for > a single-threaded program. You could even have a thread-local > memory allocator that would only lock when it needs to request > memory from the "global allocator"... in fact there are lots of > things you can do with this sort of thing. Dynamically scoped > variables in Scheme (a la MacLisp?) is what they originally proposed > it for but then they suggested all kinds of tricks related to > continuations with it. > > Mika > From jay.krell at cornell.edu Wed Apr 29 23:26:42 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 29 Apr 2009 21:26:42 +0000 Subject: [M3devel] user threads In-Reply-To: <200904291846.n3TIk3F6038926@camembert.async.caltech.edu> References: Your message of "Thu, 30 Apr 2009 04:04:22 +1000." <736196D3-6AA1-49C4-80E8-4EEB05B38CFC@cs.purdue.edu> <200904291846.n3TIk3F6038926@camembert.async.caltech.edu> Message-ID: > I think if possible "M3 user threads" should definitely be the > default on FreeBSD4 and earlier, rather than "system user threads". I'm tempted to add FreeBSD5 and possibly 6,7,8. Or I386_FREEBSD to imply>=5 (though it'd also work, slowly, for 4) They would all use the same Unix/*.i3 files (not even copies), take the same code in Target.m3. The only difference would be the default threading model in thread.quake and probably a line in the config file to use -lpthread vs. -lc_r. And the default archive/distribution names, if nothing else is done about them. And MAYBE restore the global for pusheframe -- though that precludes I think leaving FreeBSD1-4 able to use their usermode pthreads. That's a microptimization though, for a dying system(s). On the other hand, there might not be more than one FreeBSD 4 user and he can just edit hits m3core/thread.quake?? Mika maybe you'll collect some pthread numbers on FreeBSD 5 soon and dump 4? - Jay From wagner at elegosoft.com Thu Apr 30 08:42:00 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Apr 2009 08:42:00 +0200 Subject: [M3devel] user threads In-Reply-To: References: <200904291846.n3TIk3F6038926@camembert.async.caltech.edu> Message-ID: <20090430084200.7e7jwrb9pck0wwsk@mail.elegosoft.com> Quoting Tony Hosking : > On 30 Apr 2009, at 04:46, Mika Nystrom wrote: > >> But what Jay has pointed out is that what I labeled as "kernel >> threads" in the attached table aren't kernel threads at all but >> libc_r threads, which provide the same facilities (as far as I know) >> as M3's "user threads". In this case M3's user threads are simply >> superior to what the system provides. Much superior. > > Ah, understood. Threading on FreeBSD has been a sad topic for many years. Actually I think I was among the first who ever got a threading library working on FreeBSD (was it still 1.5 or some 2.x?) for the company I worked for in the 1990s (Point-of-Sale applications). Unfortunately, that system was never sold nor could it be released as open source. There was no official FreeBSD thread support then. Later official solutions were always wanting in functionality or performance. I think in FreeBSD 6 there are not less than three different implementations, all of which have some advantages and disadvantages. But M3 threads were always much faster than any of the FreeBSD libraries. I think the situation may have got better in FreeBSD 7, but I haven't really tried that. >> I think if possible "M3 user threads" should definitely be the >> default on FreeBSD4 and earlier, rather than "system user threads". > > Fair enough. Old thread libraries were pretty substandard. Indeed. And that's exactly why I'm still a `fan' of the M3 threads and think they should not be abandoned and be available for certain applications. Sorry, I couldn't resist to comment on this again :-) I'll return to serious work now and will not feed the M3 mail flood (which is really a good thing as it shows the interest and activity) any more, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 30 10:58:58 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 30 Apr 2009 01:58:58 -0700 Subject: [M3devel] user threads In-Reply-To: Your message of "Wed, 29 Apr 2009 07:05:10 -0000." Message-ID: <200904300858.n3U8wwAM078186@camembert.async.caltech.edu> I have to re-build everything again? It segfaults on my 5.5 system with that change. Btw, here are timings on FreeBSD 5.5 libc_r 1642 ms pthread 1646 ms PM3 504 ms Roughly the same program as before. Slightly different hardware (AM2 I think). Mika Jay writes: >--_57af40c5-3867-4a47-915e-00f808c2e343_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Mika=2C thanks. Want to try the next variation? look at m3-libs/m3core/src/= >thread/PTHREAD/ThreadPThreadC.c. > >See THREAD_LOCAL=2C THREAD_LOCAL_SLOW=2C THREAD_LOCAL_FAST? Try switching T= >HREAD_LOCAL to use THREAD_LOCAL_FAST instead of _SLOW. On FreeBSD 5.x or ne= >wer. > >It won't compile for 4.x we know. > >=20 > >Thanks=2C > > - Jay > >=20 >> To: jay.krell at cornell.edu >> Date: Tue=2C 28 Apr 2009 23:53:32 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] user threads >>=20 >> Ok=2C it works! >>=20 >> Numbers: >>=20 >> Timings in milliseconds=2C three samples=2C filesystem "warmed up" by >> doing one dummy run before launching the real ones. >>=20 >> -unsafe means that I use non-locking Scheme environments=2C otherwise >> they lock for every variable update. >> ave=20 >> CM3 last week=2C kernel threads=2C -unsafe 1460 1482 1437 1460 >> CM3 last week=2C kernel threads=2C 2392 2402 2376 2390 >> CM3 this week=2C kernel threads=2C -unsafe 1455 1458 1490 1468 (*) >> CM3 this week=2C user threads=2C -unsafe 914 934 914 921 >> CM3 this week=2C user threads=2C 967 965 986 973 >> PM3 -unsafe 678 657 682 672 >> PM3 709 714 700 708 >>=20 >> (*) not entirely sure this got linked correctly. >>=20 >> Mika >>=20 >>=20 >> Jay writes: >> > >> >User threads seem to work on on FreeBSD/x86 7.0. >> >Mika can you report back the perf cm3 vs. pm3? >> >Still=2C kernel threads have been around a long time and imho should be = >strongly favored.. >> >=20 >> >=20 >> >Kernel threads should be a /little/ faster than they were -- PushEFrame = >removed from successful heap allocations. And should be further improvable = >via __thread where it is supported -- probably not FreeBSD 4. >> >x=2C sometimes older is not better. :) >> >=20 >> >=20 >> >I've temporarily switched FreeBSD/x86 to userthreads by default but I th= >ink that's just an experiment and should be undone shortly=2C maybe work ou= >t some other story for easily switching between them=2C or just k >> >eep the existing story of "you get to rebuild everything". >> >=20 >> >=20 >> >Tony=2C can you look into GetGCRatio? I removed the call to it. The "fat= >al" pragma invokes PushEFrame apparently. >> >=20 >> >=20 >> >We should now "fix" Win32 and pthreads to not have GetActivation initial= >ize on-demand=2C just leave Init to initialize always. This should shave a = >few more cycles from PushEFrame. >> >=20 >> >=20 >> > - Jay > >--_57af40c5-3867-4a47-915e-00f808c2e343_ >Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > > > > > >Mika=2C =3Bthanks. Want to try the next variation? look at m3-libs/m3co= >re/src/thread/PTHREAD/ThreadPThreadC.c.
>See THREAD_LOCAL=2C THREAD_LOCAL_SLOW=2C THREAD_LOCAL_FAST? Try switching T= >HREAD_LOCAL to use THREAD_LOCAL_FAST instead of _SLOW. On FreeBSD 5.x or&nb= >sp=3Bnewer.
>It won't compile for 4.x we know.
> =3B
>Thanks=2C
> =3B- Jay

 =3B
>=3B To: jay.krell at cornell.edu
>=3B= > Date: Tue=2C 28 Apr 2009 23:53:32 -0700
>=3B From: mika at async.caltech= >.edu
>=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] u= >ser threads
>=3B
>=3B Ok=2C it works!
>=3B
>=3B Numbe= >rs:
>=3B
>=3B Timings in milliseconds=2C three samples=2C filesy= >stem "warmed up" by
>=3B doing one dummy run before launching the real= > ones.
>=3B
>=3B -unsafe means that I use non-locking Scheme env= >ironments=2C otherwise
>=3B they lock for every variable update.
&g= >t=3B ave
>=3B CM3 last week=2C kernel threads=2C -unsafe 1460 1482 14= >37 1460
>=3B CM3 last week=2C kernel threads=2C 2392 2402 2376 2390>>=3B CM3 this week=2C kernel threads=2C -unsafe 1455 1458 1490 1468 (*)<= >BR>>=3B CM3 this week=2C user threads=2C -unsafe 914 934 914 921
>= >=3B CM3 this week=2C user threads=2C 967 965 986 973
>=3B PM3 -unsafe = >678 657 682 672
>=3B PM3 709 714 700 708
>=3B
>=3B (*) not = >entirely sure this got linked correctly.
>=3B
>=3B Mika
>= >=3B
>=3B
>=3B Jay writes:
>=3B >=3B
>=3B >=3BUser= > threads seem to work on on FreeBSD/x86 7.0.
>=3B >=3BMika can you r= >eport back the perf cm3 vs. pm3?
>=3B >=3BStill=2C kernel threads ha= >ve been around a long time and imho should be strongly favored..
>=3B = >>=3B
>=3B >=3B
>=3B >=3BKernel threads should be a /littl= >e/ faster than they were -- PushEFrame removed from successful heap allocat= >ions. And should be further improvable via __thread where it is supported -= >- probably not FreeBSD 4.
>=3B >=3Bx=2C sometimes older is not bette= >r. :)
>=3B >=3B
>=3B >=3B
>=3B >=3BI've temporarily = >switched FreeBSD/x86 to userthreads by default but I think that's just an e= >xperiment and should be undone shortly=2C maybe work out some other story f= >or easily switching between them=2C or just k
>=3B >=3Beep the exist= >ing story of "you get to rebuild everything".
>=3B >=3B
>=3B &= >gt=3B
>=3B >=3BTony=2C can you look into GetGCRatio? I removed the = >call to it. The "fatal" pragma invokes PushEFrame apparently.
>=3B >= >=3B
>=3B >=3B
>=3B >=3BWe should now "fix" Win32 and pthrea= >ds to not have GetActivation initialize on-demand=2C just leave Init to ini= >tialize always. This should shave a few more cycles from PushEFrame.
>= >=3B >=3B
>=3B >=3B
>=3B >=3B - Jay
>= > >--_57af40c5-3867-4a47-915e-00f808c2e343_-- From wagner at elegosoft.com Thu Apr 30 11:05:15 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Apr 2009 11:05:15 +0200 Subject: [M3devel] [M3commit] how to switch userthreads on/off In-Reply-To: References: Your message of "Wed, 29 Apr 2009 00:06:02 -0000." <200904290622.n3T6MZBR003219@camembert.async.caltech.edu> Message-ID: <20090430110515.lnlfuu02v4sso0wo@mail.elegosoft.com> Quoting Jay : > Olaf, your recall that FreeBSD userthreads were "fast"..is that > based on FreeBSD 4.x by chance? Maybe they don't have much advantage > on any other system? > > You know...FreeBSD 4.x pthreads are also userthreads, not really a > fair comparison maybe with other pthreads implementations and maybe > give pthreads a bad name? I'm afraid I cannot provide any exact numbers or test results any more, so the validity of all my comments must be treated very carefully. AFAIR M3 user threads on FreeBSD were fast compared to the system implementation of pthreads even in 4.x. FreeBSD system threads that are `real' kernel threads were introduced later, when the system was incrementally made ready for multi-CPU-support. I think this change has not been completed until 7.0. (All systems after 4.x were much less stable due to this transition.). One of the bottlenecks _may_ have been the malloc implementation. The FreeBSD pthreads implementation in 4.x were indeed user-level threads, but they were not very performant compared to what would have been possible IIRC. There was also an implementation which used process structures as threads ported from Linux (known as Linux-threads). Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Apr 30 11:18:47 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Apr 2009 11:18:47 +0200 Subject: [M3devel] any limitations on __thread? In-Reply-To: References: Message-ID: <20090430111847.0vqnqf8yrs4gkkw4@mail.elegosoft.com> Quoting Jay : > > Anyone have expertise on __thread? > In particular, on Windows there is a close analog __declspec(thread) > that generally would seem to work and work well, except that, per > documentation, prior to Vista, it doesn't work if you are loaded > with LoadLibrary (dlopen), only if the main executable uses your > .so, directly or indirectly. To me that's a pretty big limitation so > I wouldn't use it. I haven't seen any documentation on __thread > giving this caveat though so it seems ok to use. > > I changed m3core to use it if sample code seems to compile, link, > and execute correctly with it. This is done at installation time, I assume? Where is this test located? > > > - 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 Thu Apr 30 12:14:47 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 30 Apr 2009 03:14:47 -0700 Subject: [M3devel] any limitations on __thread? In-Reply-To: <20090430111847.0vqnqf8yrs4gkkw4@mail.elegosoft.com> References: <20090430111847.0vqnqf8yrs4gkkw4@mail.elegosoft.com> Message-ID: <454BD710-4008-4045-B7EB-EF76D823BD49@hotmail.com> It was to be done every time building m3core. Fast enough. I removed it for now. Pic makes it a smaller win, I have no numbers, and broke Tony's build. It would also reduce but not eliminate leak upon dynamic unload, which we should consider anyway. It was in m3core/src/thread/pthread/m3makefile. - Jay (phone) On Apr 30, 2009, at 2:18 AM, Olaf Wagner wrote: > Quoting Jay : > >> >> Anyone have expertise on __thread? >> In particular, on Windows there is a close analog >> __declspec(thread) that generally would seem to work and work >> well, except that, per documentation, prior to Vista, it doesn't >> work if you are loaded with LoadLibrary (dlopen), only if the main >> executable uses your .so, directly or indirectly. To me that's a >> pretty big limitation so I wouldn't use it. I haven't seen any >> documentation on __thread giving this caveat though so it seems ok >> to use. >> >> I changed m3core to use it if sample code seems to compile, link, >> and execute correctly with it. > > This is done at installation time, I assume? > Where is this test located? > >> >> >> - 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 Thu Apr 30 12:17:58 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Thu, 30 Apr 2009 03:17:58 -0700 Subject: [M3devel] user threads In-Reply-To: <200904300858.n3U8wwAM078186@camembert.async.caltech.edu> References: <200904300858.n3U8wwAM078186@camembert.async.caltech.edu> Message-ID: <840816F3-68FF-4B8B-A52A-2B6ED8A8BBB1@hotmail.com> No need for clean here. Lets punt threads for now and look at typecase. - Jay (phone) On Apr 30, 2009, at 1:58 AM, Mika Nystrom wrote: > I have to re-build everything again? It segfaults on my 5.5 system > with that > change. > > Btw, here are timings on FreeBSD 5.5 > > libc_r 1642 ms > pthread 1646 ms > PM3 504 ms > > Roughly the same program as before. Slightly different hardware > (AM2 I think). > > Mika > > Jay writes: >> --_57af40c5-3867-4a47-915e-00f808c2e343_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> Mika=2C thanks. Want to try the next variation? look at m3-libs/ >> m3core/src/= >> thread/PTHREAD/ThreadPThreadC.c. >> >> See THREAD_LOCAL=2C THREAD_LOCAL_SLOW=2C THREAD_LOCAL_FAST? Try >> switching T= >> HREAD_LOCAL to use THREAD_LOCAL_FAST instead of _SLOW. On FreeBSD >> 5.x or ne= >> wer. >> >> It won't compile for 4.x we know. >> >> =20 >> >> Thanks=2C >> >> - Jay >> >> =20 >>> To: jay.krell at cornell.edu >>> Date: Tue=2C 28 Apr 2009 23:53:32 -0700 >>> From: mika at async.caltech.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] user threads >>> =20 >>> Ok=2C it works! >>> =20 >>> Numbers: >>> =20 >>> Timings in milliseconds=2C three samples=2C filesystem "warmed up" >>> by >>> doing one dummy run before launching the real ones. >>> =20 >>> -unsafe means that I use non-locking Scheme environments=2C >>> otherwise >>> they lock for every variable update. >>> ave=20 >>> CM3 last week=2C kernel threads=2C -unsafe 1460 1482 1437 1460 >>> CM3 last week=2C kernel threads=2C 2392 2402 2376 2390 >>> CM3 this week=2C kernel threads=2C -unsafe 1455 1458 1490 1468 (*) >>> CM3 this week=2C user threads=2C -unsafe 914 934 914 921 >>> CM3 this week=2C user threads=2C 967 965 986 973 >>> PM3 -unsafe 678 657 682 672 >>> PM3 709 714 700 708 >>> =20 >>> (*) not entirely sure this got linked correctly. >>> =20 >>> Mika >>> =20 >>> =20 >>> Jay writes: >>>> >>>> User threads seem to work on on FreeBSD/x86 7.0. >>>> Mika can you report back the perf cm3 vs. pm3? >>>> Still=2C kernel threads have been around a long time and imho >>>> should be = >> strongly favored.. >>>> =20 >>>> =20 >>>> Kernel threads should be a /little/ faster than they were -- >>>> PushEFrame = >> removed from successful heap allocations. And should be further >> improvable = >> via __thread where it is supported -- probably not FreeBSD 4. >>>> x=2C sometimes older is not better. :) >>>> =20 >>>> =20 >>>> I've temporarily switched FreeBSD/x86 to userthreads by default >>>> but I th= >> ink that's just an experiment and should be undone shortly=2C maybe >> work ou= >> t some other story for easily switching between them=2C or just k >>>> eep the existing story of "you get to rebuild everything". >>>> =20 >>>> =20 >>>> Tony=2C can you look into GetGCRatio? I removed the call to it. >>>> The "fat= >> al" pragma invokes PushEFrame apparently. >>>> =20 >>>> =20 >>>> We should now "fix" Win32 and pthreads to not have GetActivation >>>> initial= >> ize on-demand=2C just leave Init to initialize always. This should >> shave a = >> few more cycles from PushEFrame. >>>> =20 >>>> =20 >>>> - Jay >> >> --_57af40c5-3867-4a47-915e-00f808c2e343_ >> Content-Type: text/html; charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable >> >> >> >> >> >> >> Mika=2C =3Bthanks. Want to try the next variation? look at m3- >> libs/m3co= >> re/src/thread/PTHREAD/ThreadPThreadC.c.
>> See THREAD_LOCAL=2C THREAD_LOCAL_SLOW=2C THREAD_LOCAL_FAST? Try >> switching T= >> HREAD_LOCAL to use THREAD_LOCAL_FAST instead of _SLOW. On FreeBSD >> 5.x or&nb= >> sp=3Bnewer.
>> It won't compile for 4.x we know.
>>  =3B
>> Thanks=2C
>>  =3B- Jay

 =3B
>=3B To: >> jay.krell at cornell.edu
>=3B= >> Date: Tue=2C 28 Apr 2009 23:53:32 -0700
>=3B From: mika at async.caltech >> = >> .edu
>=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: >> [M3devel] u= >> ser threads
>=3B
>=3B Ok=2C it works!
>=3B >>
>=3B Numbe= >> rs:
>=3B
>=3B Timings in milliseconds=2C three >> samples=2C filesy= >> stem "warmed up" by
>=3B doing one dummy run before launching >> the real= >> ones.
>=3B
>=3B -unsafe means that I use non-locking >> Scheme env= >> ironments=2C otherwise
>=3B they lock for every variable >> update.
&g= >> t=3B ave
>=3B CM3 last week=2C kernel threads=2C -unsafe 1460 1482 14 >> = >> 37 1460
>=3B CM3 last week=2C kernel threads=2C 2392 2402 2376 >> 2390>> >=3B CM3 this week=2C kernel threads=2C -unsafe 1455 1458 1490 >>> 1468 (*)<= >> BR>>=3B CM3 this week=2C user threads=2C -unsafe 914 934 914 >> 921
>= >> =3B CM3 this week=2C user threads=2C 967 965 986 973
>=3B PM3 - >> unsafe = >> 678 657 682 672
>=3B PM3 709 714 700 708
>=3B
>=3B >> (*) not = >> entirely sure this got linked correctly.
>=3B
>=3B >> Mika
>= >> =3B
>=3B
>=3B Jay writes:
>=3B >=3B
>=3B >> >=3BUser= >> threads seem to work on on FreeBSD/x86 7.0.
>=3B >=3BMika >> can you r= >> eport back the perf cm3 vs. pm3?
>=3B >=3BStill=2C kernel >> threads ha= >> ve been around a long time and imho should be strongly >> favored..
>=3B = >> >=3B
>=3B >=3B
>=3B >=3BKernel threads should be >> a /littl= >> e/ faster than they were -- PushEFrame removed from successful heap >> allocat= >> ions. And should be further improvable via __thread where it is >> supported -= >> - probably not FreeBSD 4.
>=3B >=3Bx=2C sometimes older is >> not bette= >> r. :)
>=3B >=3B
>=3B >=3B
>=3B >=3BI've >> temporarily = >> switched FreeBSD/x86 to userthreads by default but I think that's >> just an e= >> xperiment and should be undone shortly=2C maybe work out some other >> story f= >> or easily switching between them=2C or just k
>=3B >=3Beep >> the exist= >> ing story of "you get to rebuild everything".
>=3B >=3B >>
>=3B &= >> gt=3B
>=3B >=3BTony=2C can you look into GetGCRatio? I >> removed the = >> call to it. The "fatal" pragma invokes PushEFrame >> apparently.
>=3B >= >> =3B
>=3B >=3B
>=3B >=3BWe should now "fix" Win32 >> and pthrea= >> ds to not have GetActivation initialize on-demand=2C just leave >> Init to ini= >> tialize always. This should shave a few more cycles from >> PushEFrame.
>= >> =3B >=3B
>=3B >=3B
>=3B >=3B - Jay
>> = >> >> --_57af40c5-3867-4a47-915e-00f808c2e343_-- > From hosking at cs.purdue.edu Thu Apr 30 19:35:23 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 1 May 2009 03:35:23 +1000 Subject: [M3devel] Fwd: Output from "cron" command References: <200904301321.n3UDL5s4029847@niagara.cs.purdue.edu> Message-ID: Something is still broken with builds on SOLgnu: Begin forwarded message: > From: Tony Hosking > Date: 30 April 2009 23:21:05 GMT+10:00 > To: hosking at cs.purdue.edu > Subject: Output from "cron" command > > Your "cron" job on niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/cron.sh > > produced the following output: > > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-04-30-10-30-04 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSUSER= > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara release-build" > > creating log file /tmp/build-cm3-20090430-063006-xlaG7T/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.04.30 06:30:06 -- checkout in progress. > [start checkout 2009.04.30 06:30:09] > cd /tmp/build-cm3-20090430-063006-xlaG7T/build > cvs return value: 0 > [end checkout 2009.04.30 06:49:48] > CHECKOUT_RETURN = 0 > -- > 2009.04.30 06:49:51 -- compile in progress. > [start compile 2009.04.30 06:49:51] > compile return value: 0 > [end compile 2009.04.30 08:10:52] > COMPILE_RETURN = 1 > *** COMPILE FAILED > removing build tree /tmp/build-cm3-20090430-063006-xlaG7T ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-04-30-12-12-43 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSUSER= > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" > > creating log file /tmp/build-cm3-20090430-081245-KRaGZ0/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.04.30 08:12:45 -- checkout in progress. > [start checkout 2009.04.30 08:12:47] > cd /tmp/build-cm3-20090430-081245-KRaGZ0/build > cvs return value: 0 > [end checkout 2009.04.30 08:32:38] > CHECKOUT_RETURN = 0 > -- > 2009.04.30 08:32:41 -- compile in progress. > [start compile 2009.04.30 08:32:41] > compile return value: 0 > [end compile 2009.04.30 09:19:11] > COMPILE_RETURN = 0 > 2009.04.30 09:19:15 -- tests in progress. > [start run-tests 2009.04.30 09:19:15] > cd /tmp/build-cm3-20090430-081245-KRaGZ0/build > [end run-tests 2009.04.30 09:19:15] > TESTS_RETURN = 0 > 2009.04.30 09:19:15 -- checkout, compile and test run done. > > --- > > removing build tree /tmp/build-cm3-20090430-081245-KRaGZ0 ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > done. -------------- next part -------------- An HTML attachment was scrubbed... URL: