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>
	<COL101-W488DE4572978F5DEFEC7E6E6900@phx.gbl>
	<20090325225421.GB17118@topoi.pooq.com>
	<COL101-W60AF173A0E3788ECC9B7B4E6910@phx.gbl>
	<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 <hosking at cs.purdue.edu>:

> 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>
	<COL101-W60AF173A0E3788ECC9B7B4E6910@phx.gbl>
	<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 <hosking at cs.purdue.edu>:
> 
> >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: <COL101-W15A74A7B5AE41C2BE10A3DE6930@phx.gbl>
	<20090325083158.hkinn8yjkksocw4c@mail.elegosoft.com>
	<20090325135234.GA16351@topoi.pooq.com>
	<20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com>
	<20090325144505.GA16526@topoi.pooq.com>
	<COL101-W488DE4572978F5DEFEC7E6E6900@phx.gbl>
	<20090325225421.GB17118@topoi.pooq.com>
	<COL101-W60AF173A0E3788ECC9B7B4E6910@phx.gbl>
	<20090330131918.GA6921@topoi.pooq.com>
	<20090331133910.flci659jockgo04c@mail.elegosoft.com>
	<20090331135610.GA9539@topoi.pooq.com> 
	<20090331161908.3pferzf9c08oso40@mail.elegosoft.com>
Message-ID: <COL101-W71BC7D8270B02DA7893E50E68A0@phx.gbl>


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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090331/06bfc397/attachment.html>

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>
	<COL101-W60AF173A0E3788ECC9B7B4E6910@phx.gbl>
	<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: <COL101-W5325AB02A1592D857153B5E68A0@phx.gbl>


 > 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 <hosking at cs.purdue.edu>:
> > 
> > >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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090331/472d9c27/attachment.html>

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: <COL101-W2679EC2C588AA376933729E68A0@phx.gbl>


 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090331/92a02526/attachment.html>

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."
	<COL101-W2679EC2C588AA376933729E68A0@phx.gbl> 
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
>
><html>
><head>
><style>
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Verdana
>}
></style>
></head>
><body class=3D'hmmessage'>
>&nbsp=3B<A href=3D"http://modula3.elegosoft.com/cm3/uploaded-archives" targ=
>et=3D_blank><FONT color=3D#0068cf>http://modula3.elegosoft.com/cm3/uploaded=
>-archives</FONT></A><BR>
>?<BR>
>&nbsp=3B<BR>
>I can make another later this week.<BR>
>&nbsp=3B<BR>
>All you need is a working cm3 on any system.<BR>
>>From there you can build the whole system=2C targeting any system.<BR>
>As long as that cm3 understands LONGINT and your target system.<BR>
>And it is easier=2C but not necessary=2C if you have Python. :)<BR>
>&nbsp=3B<BR>
>&nbsp=3B- Jay<BR><BR>&nbsp=3B<BR>&gt=3B Date: Tue=2C 31 Mar 2009 15:43:41 -=
>0500<BR>&gt=3B From: martinbishop at bellsouth.net<BR>&gt=3B To: mika at async.ca=
>ltech.edu<BR>&gt=3B CC: m3devel at elegosoft.com<BR>&gt=3B Subject: Re: [M3dev=
>el] Help finding CM3 compiler for Linux?<BR>&gt=3B <BR>&gt=3B Not sure if t=
>his helps=2C but on my linux system:<BR>&gt=3B <BR>&gt=3B Critical Mass Mod=
>ula-3 version d5.7.0<BR>&gt=3B last updated: 2008-03-16<BR>&gt=3B compiled:=
> 2008-08-14 00:56:14<BR>&gt=3B configuration: /usr/local/cm3/bin/cm3.cfg<BR=
>>&gt=3B <BR>&gt=3B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24=
>:39 UTC 2009<BR>&gt=3B i686 GNU/Linux<BR>&gt=3B <BR>&gt=3B <BR>&gt=3B I don=
>'t have the cm3 tarball=2C but I do have the sources in cm3/ still.<BR>&gt=
>=3B <BR>&gt=3B Mika Nystrom wrote:<BR>&gt=3B &gt=3B Hello everyone=2C<BR>&g=
>t=3B &gt=3B <BR>&gt=3B &gt=3B This is=2C for me=2C a most unfortunate time =
>for the CM3 servers to<BR>&gt=3B &gt=3B have crashed. I'm teaching a class =
>using Modula-3=2C and we need a<BR>&gt=3B &gt=3B compiler... here's the una=
>me of the system I'm trying to use:<BR>&gt=3B &gt=3B <BR>&gt=3B &gt=3B Linu=
>x lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Linux<BR>&g=
>t=3B &gt=3B <BR>&gt=3B &gt=3B The most recent archives I have for Linux are=
>:<BR>&gt=3B &gt=3B <BR>&gt=3B &gt=3B cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3=
>-src-all-5.4.0.tgz <BR>&gt=3B &gt=3B <BR>&gt=3B &gt=3B And they don't seem =
>to work on this system: I can compile a program<BR>&gt=3B &gt=3B but when I=
> try to run it=2C it says "Segmentation fault". Can anyone<BR>&gt=3B &gt=3B=
> help? (My understanding is that I need 5.5.1 or later...)<BR>&gt=3B &gt=3B=
> <BR>&gt=3B &gt=3B Mika<BR>&gt=3B &gt=3B <BR>&gt=3B <BR></body>
></html>=
>
>--_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: <COL101-W71BC7D8270B02DA7893E50E68A0@phx.gbl>
References: <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com>
	<20090325144505.GA16526@topoi.pooq.com>
	<COL101-W488DE4572978F5DEFEC7E6E6900@phx.gbl>
	<20090325225421.GB17118@topoi.pooq.com>
	<COL101-W60AF173A0E3788ECC9B7B4E6910@phx.gbl>
	<20090330131918.GA6921@topoi.pooq.com>
	<20090331133910.flci659jockgo04c@mail.elegosoft.com>
	<20090331135610.GA9539@topoi.pooq.com>
	<20090331161908.3pferzf9c08oso40@mail.elegosoft.com>
	<COL101-W71BC7D8270B02DA7893E50E68A0@phx.gbl>
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: <COL101-W5325AB02A1592D857153B5E68A0@phx.gbl>
References: <20090325225421.GB17118@topoi.pooq.com>
	<COL101-W60AF173A0E3788ECC9B7B4E6910@phx.gbl>
	<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>
	<COL101-W5325AB02A1592D857153B5E68A0@phx.gbl>
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 <hosking at cs.purdue.edu>:
> > >
> > > >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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090401/faaa0d61/attachment.html>

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."
	<COL101-W13CCB4F28AEA577B1F0BEDE68B0@phx.gbl> 
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            --  <builtin>
                    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
>> >
>> ><html>
>> ><head>
>> ><style>
>> >.hmmessage P
>> >{
>> >margin:0px=3D3B
>> >padding:0px
>> >}
>> >body.hmmessage
>> >{
>> >font-size: 10pt=3D3B
>> >font-family:Verdana
>> >}
>> ></style>
>> ></head>
>> ><body class=3D3D'hmmessage'>
>> >&nbsp=3D3B<A href=3D3D"http://modula3.elegosoft.com/cm3/uploaded-archive=
>s" targ=3D
>> >et=3D3D_blank><FONT color=3D3D#0068cf>http://modula3.elegosoft.com/cm3/u=
>ploaded=3D
>> >-archives</FONT></A><BR>
>> >?<BR>
>> >&nbsp=3D3B<BR>
>> >I can make another later this week.<BR>
>> >&nbsp=3D3B<BR>
>> >All you need is a working cm3 on any system.<BR>
>> >>From there you can build the whole system=3D2C targeting any system.<BR=
>>
>> >As long as that cm3 understands LONGINT and your target system.<BR>
>> >And it is easier=3D2C but not necessary=3D2C if you have Python. :)<BR>
>> >&nbsp=3D3B<BR>
>> >&nbsp=3D3B- Jay<BR><BR>&nbsp=3D3B<BR>&gt=3D3B Date: Tue=3D2C 31 Mar 2009=
> 15:43:41 -=3D
>> >0500<BR>&gt=3D3B From: martinbishop at bellsouth.net<BR>&gt=3D3B To: mika at a=
>sync.ca=3D
>> >ltech.edu<BR>&gt=3D3B CC: m3devel at elegosoft.com<BR>&gt=3D3B Subject: Re:=
> [M3dev=3D
>> >el] Help finding CM3 compiler for Linux?<BR>&gt=3D3B <BR>&gt=3D3B Not su=
>re if t=3D
>> >his helps=3D2C but on my linux system:<BR>&gt=3D3B <BR>&gt=3D3B Critical=
> Mass Mod=3D
>> >ula-3 version d5.7.0<BR>&gt=3D3B last updated: 2008-03-16<BR>&gt=3D3B co=
>mpiled:=3D
>> > 2008-08-14 00:56:14<BR>&gt=3D3B configuration: /usr/local/cm3/bin/cm3.c=
>fg<BR=3D
>> >>&gt=3D3B <BR>&gt=3D3B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 2=
>9 19:24=3D
>> >:39 UTC 2009<BR>&gt=3D3B i686 GNU/Linux<BR>&gt=3D3B <BR>&gt=3D3B <BR>&gt=
>=3D3B I don=3D
>> >'t have the cm3 tarball=3D2C but I do have the sources in cm3/ still.<BR=
>>&gt=3D
>> >=3D3B <BR>&gt=3D3B Mika Nystrom wrote:<BR>&gt=3D3B &gt=3D3B Hello everyo=
>ne=3D2C<BR>&g=3D
>> >t=3D3B &gt=3D3B <BR>&gt=3D3B &gt=3D3B This is=3D2C for me=3D2C a most un=
>fortunate time =3D
>> >for the CM3 servers to<BR>&gt=3D3B &gt=3D3B have crashed. I'm teaching a=
> class =3D
>> >using Modula-3=3D2C and we need a<BR>&gt=3D3B &gt=3D3B compiler... here'=
>s the una=3D
>> >me of the system I'm trying to use:<BR>&gt=3D3B &gt=3D3B <BR>&gt=3D3B &g=
>t=3D3B Linu=3D
>> >x lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Linux<BR=
>>&g=3D
>> >t=3D3B &gt=3D3B <BR>&gt=3D3B &gt=3D3B The most recent archives I have fo=
>r Linux are=3D
>> >:<BR>&gt=3D3B &gt=3D3B <BR>&gt=3D3B &gt=3D3B cm3-min-POSIX-LINUXLIBC6-5.=
>4.0.tgz cm3=3D
>> >-src-all-5.4.0.tgz <BR>&gt=3D3B &gt=3D3B <BR>&gt=3D3B &gt=3D3B And they =
>don't seem =3D
>> >to work on this system: I can compile a program<BR>&gt=3D3B &gt=3D3B but=
> when I=3D
>> > try to run it=3D2C it says "Segmentation fault". Can anyone<BR>&gt=3D3B=
> &gt=3D3B=3D
>> > help? (My understanding is that I need 5.5.1 or later...)<BR>&gt=3D3B &=
>gt=3D3B=3D
>> > <BR>&gt=3D3B &gt=3D3B Mika<BR>&gt=3D3B &gt=3D3B <BR>&gt=3D3B <BR></body=
>>
>> ></html>=3D
>> >
>> >--_806446ae-8d10-4d74-8eea-51aa365e9204_--
>
>--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style>
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Verdana
>}
></style>
></head>
><body class=3D'hmmessage'>
>These archives do have a different format=2C yes.<BR>
>But it isn't a bad format.<BR>
>cminstall is pretty worthless imho.<BR>
>Extract=2C rename=2C set PATH and LD_LIBRARY_PATH.<BR>
>&nbsp=3B<BR>
>&nbsp=3B- Jay<BR><BR>&nbsp=3B<BR>&gt=3B To: jay.krell at cornell.edu<BR>&gt=3B=
> Subject: Re: [M3devel] Help finding CM3 compiler for Linux? <BR>&gt=3B Dat=
>e: Tue=2C 31 Mar 2009 15:56:11 -0700<BR>&gt=3B From: mika at async.caltech.edu=
><BR>&gt=3B <BR>&gt=3B No=2C I'm sorry...<BR>&gt=3B <BR>&gt=3B the archives =
>do not have the usual format. I'm expecting to unpack<BR>&gt=3B and run "cm=
>install" and then unpack the big source tar on top and <BR>&gt=3B build tha=
>t. But there's no cminstall in the archive on this page.<BR>&gt=3B This is =
>"the normal procedure" for installing CM3=2C no? It's what<BR>&gt=3B the in=
>structions say to do=2C as well...<BR>&gt=3B <BR>&gt=3B And the link from t=
>he "Download" page is broken (to -d5.5.0.tgz).<BR>&gt=3B <BR>&gt=3B Mika<BR=
>>&gt=3B <BR>&gt=3B Jay writes:<BR>&gt=3B &gt=3B--_806446ae-8d10-4d74-8eea-5=
>1aa365e9204_<BR>&gt=3B &gt=3BContent-Type: text/plain=3B charset=3D"iso-885=
>9-1"<BR>&gt=3B &gt=3BContent-Transfer-Encoding: quoted-printable<BR>&gt=3B =
>&gt=3B<BR>&gt=3B &gt=3B<BR>&gt=3B &gt=3B http://modula3.elegosoft.com/cm3/u=
>ploaded-archives<BR>&gt=3B &gt=3B<BR>&gt=3B &gt=3B?<BR>&gt=3B &gt=3B<BR>&gt=
>=3B &gt=3B=3D20<BR>&gt=3B &gt=3B<BR>&gt=3B &gt=3BI can make another later t=
>his week.<BR>&gt=3B &gt=3B<BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B<BR>&gt=3B=
> &gt=3BAll you need is a working cm3 on any system.<BR>&gt=3B &gt=3B<BR>&gt=
>=3B &gt=3B&gt=3BFrom there you can build the whole system=3D2C targeting an=
>y system.<BR>&gt=3B &gt=3B<BR>&gt=3B &gt=3BAs long as that cm3 understands =
>LONGINT and your target system.<BR>&gt=3B &gt=3B<BR>&gt=3B &gt=3BAnd it is =
>easier=3D2C but not necessary=3D2C if you have Python. :)<BR>&gt=3B &gt=3B<=
>BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B<BR>&gt=3B &gt=3B - Jay<BR>&gt=3B &gt=
>=3B<BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B&gt=3B Date: Tue=3D2C 31 Mar 2009=
> 15:43:41 -0500<BR>&gt=3B &gt=3B&gt=3B From: martinbishop at bellsouth.net<BR>=
>&gt=3B &gt=3B&gt=3B To: mika at async.caltech.edu<BR>&gt=3B &gt=3B&gt=3B CC: m=
>3devel at elegosoft.com<BR>&gt=3B &gt=3B&gt=3B Subject: Re: [M3devel] Help fin=
>ding CM3 compiler for Linux?<BR>&gt=3B &gt=3B&gt=3B=3D20<BR>&gt=3B &gt=3B&g=
>t=3B Not sure if this helps=3D2C but on my linux system:<BR>&gt=3B &gt=3B&g=
>t=3B=3D20<BR>&gt=3B &gt=3B&gt=3B Critical Mass Modula-3 version d5.7.0<BR>&=
>gt=3B &gt=3B&gt=3B last updated: 2008-03-16<BR>&gt=3B &gt=3B&gt=3B compiled=
>: 2008-08-14 00:56:14<BR>&gt=3B &gt=3B&gt=3B configuration: /usr/local/cm3/=
>bin/cm3.cfg<BR>&gt=3B &gt=3B&gt=3B=3D20<BR>&gt=3B &gt=3B&gt=3B Linux thinkp=
>ad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009<BR>&gt=3B &gt=3B&g=
>t=3B i686 GNU/Linux<BR>&gt=3B &gt=3B&gt=3B=3D20<BR>&gt=3B &gt=3B&gt=3B=3D20=
><BR>&gt=3B &gt=3B&gt=3B I don't have the cm3 tarball=3D2C but I do have the=
> sources in cm3/ still.<BR>&gt=3B &gt=3B&gt=3B=3D20<BR>&gt=3B &gt=3B&gt=3B =
>Mika Nystrom wrote:<BR>&gt=3B &gt=3B&gt=3B &gt=3B Hello everyone=3D2C<BR>&g=
>t=3B &gt=3B&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B&gt=3B &gt=3B This is=3D2C fo=
>r me=3D2C a most unfortunate time for the CM3 servers to<BR>&gt=3B &gt=3B&g=
>t=3B &gt=3B have crashed. I'm teaching a class using Modula-3=3D2C and we n=
>eed a<BR>&gt=3B &gt=3B&gt=3B &gt=3B compiler... here's the uname of the sys=
>tem I'm trying to use:<BR>&gt=3B &gt=3B&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B&=
>gt=3B &gt=3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i68=
>6 GNU/Lin=3D<BR>&gt=3B &gt=3Bux<BR>&gt=3B &gt=3B&gt=3B &gt=3B=3D20<BR>&gt=
>=3B &gt=3B&gt=3B &gt=3B The most recent archives I have for Linux are:<BR>&=
>gt=3B &gt=3B&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B&gt=3B &gt=3B cm3-min-POSIX-=
>LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D20<BR>&gt=3B &gt=3B&gt=3B &gt=
>=3B=3D20<BR>&gt=3B &gt=3B&gt=3B &gt=3B And they don't seem to work on this =
>system: I can compile a program<BR>&gt=3B &gt=3B&gt=3B &gt=3B but when I tr=
>y to run it=3D2C it says "Segmentation fault". Can anyone<BR>&gt=3B &gt=3B&=
>gt=3B &gt=3B help? (My understanding is that I need 5.5.1 or later...)<BR>&=
>gt=3B &gt=3B&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B&gt=3B &gt=3B Mika<BR>&gt=3B=
> &gt=3B&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B&gt=3B=3D20<BR>&gt=3B &gt=3B<BR>&=
>gt=3B &gt=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_<BR>&gt=3B &gt=3BConten=
>t-Type: text/html=3B charset=3D"iso-8859-1"<BR>&gt=3B &gt=3BContent-Transfe=
>r-Encoding: quoted-printable<BR>&gt=3B &gt=3B<BR>&gt=3B &gt=3B&lt=3Bhtml&gt=
>=3B<BR>&gt=3B &gt=3B&lt=3Bhead&gt=3B<BR>&gt=3B &gt=3B&lt=3Bstyle&gt=3B<BR>&=
>gt=3B &gt=3B.hmmessage P<BR>&gt=3B &gt=3B{<BR>&gt=3B &gt=3Bmargin:0px=3D3B<=
>BR>&gt=3B &gt=3Bpadding:0px<BR>&gt=3B &gt=3B}<BR>&gt=3B &gt=3Bbody.hmmessag=
>e<BR>&gt=3B &gt=3B{<BR>&gt=3B &gt=3Bfont-size: 10pt=3D3B<BR>&gt=3B &gt=3Bfo=
>nt-family:Verdana<BR>&gt=3B &gt=3B}<BR>&gt=3B &gt=3B&lt=3B/style&gt=3B<BR>&=
>gt=3B &gt=3B&lt=3B/head&gt=3B<BR>&gt=3B &gt=3B&lt=3Bbody class=3D3D'hmmessa=
>ge'&gt=3B<BR>&gt=3B &gt=3B&amp=3Bnbsp=3D3B&lt=3BA href=3D3D"http://modula3.=
>elegosoft.com/cm3/uploaded-archives" targ=3D<BR>&gt=3B &gt=3Bet=3D3D_blank&=
>gt=3B&lt=3BFONT color=3D3D#0068cf&gt=3Bhttp://modula3.elegosoft.com/cm3/upl=
>oaded=3D<BR>&gt=3B &gt=3B-archives&lt=3B/FONT&gt=3B&lt=3B/A&gt=3B&lt=3BBR&g=
>t=3B<BR>&gt=3B &gt=3B?&lt=3BBR&gt=3B<BR>&gt=3B &gt=3B&amp=3Bnbsp=3D3B&lt=3B=
>BR&gt=3B<BR>&gt=3B &gt=3BI can make another later this week.&lt=3BBR&gt=3B<=
>BR>&gt=3B &gt=3B&amp=3Bnbsp=3D3B&lt=3BBR&gt=3B<BR>&gt=3B &gt=3BAll you need=
> is a working cm3 on any system.&lt=3BBR&gt=3B<BR>&gt=3B &gt=3B&gt=3BFrom t=
>here you can build the whole system=3D2C targeting any system.&lt=3BBR&gt=
>=3B<BR>&gt=3B &gt=3BAs long as that cm3 understands LONGINT and your target=
> system.&lt=3BBR&gt=3B<BR>&gt=3B &gt=3BAnd it is easier=3D2C but not necess=
>ary=3D2C if you have Python. :)&lt=3BBR&gt=3B<BR>&gt=3B &gt=3B&amp=3Bnbsp=
>=3D3B&lt=3BBR&gt=3B<BR>&gt=3B &gt=3B&amp=3Bnbsp=3D3B- Jay&lt=3BBR&gt=3B&lt=
>=3BBR&gt=3B&amp=3Bnbsp=3D3B&lt=3BBR&gt=3B&amp=3Bgt=3D3B Date: Tue=3D2C 31 M=
>ar 2009 15:43:41 -=3D<BR>&gt=3B &gt=3B0500&lt=3BBR&gt=3B&amp=3Bgt=3D3B From=
>: martinbishop at bellsouth.net&lt=3BBR&gt=3B&amp=3Bgt=3D3B To: mika at async.ca=
>=3D<BR>&gt=3B &gt=3Bltech.edu&lt=3BBR&gt=3B&amp=3Bgt=3D3B CC: m3devel at elego=
>soft.com&lt=3BBR&gt=3B&amp=3Bgt=3D3B Subject: Re: [M3dev=3D<BR>&gt=3B &gt=
>=3Bel] Help finding CM3 compiler for Linux?&lt=3BBR&gt=3B&amp=3Bgt=3D3B &lt=
>=3BBR&gt=3B&amp=3Bgt=3D3B Not sure if t=3D<BR>&gt=3B &gt=3Bhis helps=3D2C b=
>ut on my linux system:&lt=3BBR&gt=3B&amp=3Bgt=3D3B &lt=3BBR&gt=3B&amp=3Bgt=
>=3D3B Critical Mass Mod=3D<BR>&gt=3B &gt=3Bula-3 version d5.7.0&lt=3BBR&gt=
>=3B&amp=3Bgt=3D3B last updated: 2008-03-16&lt=3BBR&gt=3B&amp=3Bgt=3D3B comp=
>iled:=3D<BR>&gt=3B &gt=3B 2008-08-14 00:56:14&lt=3BBR&gt=3B&amp=3Bgt=3D3B c=
>onfiguration: /usr/local/cm3/bin/cm3.cfg&lt=3BBR=3D<BR>&gt=3B &gt=3B&gt=3B&=
>amp=3Bgt=3D3B &lt=3BBR&gt=3B&amp=3Bgt=3D3B Linux thinkpad 2.6.27-11-generic=
> #1 SMP Thu Jan 29 19:24=3D<BR>&gt=3B &gt=3B:39 UTC 2009&lt=3BBR&gt=3B&amp=
>=3Bgt=3D3B i686 GNU/Linux&lt=3BBR&gt=3B&amp=3Bgt=3D3B &lt=3BBR&gt=3B&amp=3B=
>gt=3D3B &lt=3BBR&gt=3B&amp=3Bgt=3D3B I don=3D<BR>&gt=3B &gt=3B't have the c=
>m3 tarball=3D2C but I do have the sources in cm3/ still.&lt=3BBR&gt=3B&amp=
>=3Bgt=3D<BR>&gt=3B &gt=3B=3D3B &lt=3BBR&gt=3B&amp=3Bgt=3D3B Mika Nystrom wr=
>ote:&lt=3BBR&gt=3B&amp=3Bgt=3D3B &amp=3Bgt=3D3B Hello everyone=3D2C&lt=3BBR=
>&gt=3B&amp=3Bg=3D<BR>&gt=3B &gt=3Bt=3D3B &amp=3Bgt=3D3B &lt=3BBR&gt=3B&amp=
>=3Bgt=3D3B &amp=3Bgt=3D3B This is=3D2C for me=3D2C a most unfortunate time =
>=3D<BR>&gt=3B &gt=3Bfor the CM3 servers to&lt=3BBR&gt=3B&amp=3Bgt=3D3B &amp=
>=3Bgt=3D3B have crashed. I'm teaching a class =3D<BR>&gt=3B &gt=3Busing Mod=
>ula-3=3D2C and we need a&lt=3BBR&gt=3B&amp=3Bgt=3D3B &amp=3Bgt=3D3B compile=
>r... here's the una=3D<BR>&gt=3B &gt=3Bme of the system I'm trying to use:&=
>lt=3BBR&gt=3B&amp=3Bgt=3D3B &amp=3Bgt=3D3B &lt=3BBR&gt=3B&amp=3Bgt=3D3B &am=
>p=3Bgt=3D3B Linu=3D<BR>&gt=3B &gt=3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10=
>:53:03 PST 2008 i686 GNU/Linux&lt=3BBR&gt=3B&amp=3Bg=3D<BR>&gt=3B &gt=3Bt=
>=3D3B &amp=3Bgt=3D3B &lt=3BBR&gt=3B&amp=3Bgt=3D3B &amp=3Bgt=3D3B The most r=
>ecent archives I have for Linux are=3D<BR>&gt=3B &gt=3B:&lt=3BBR&gt=3B&amp=
>=3Bgt=3D3B &amp=3Bgt=3D3B &lt=3BBR&gt=3B&amp=3Bgt=3D3B &amp=3Bgt=3D3B cm3-m=
>in-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D<BR>&gt=3B &gt=3B-src-all-5.4.0.tgz &lt=
=3BBR&gt=3B&amp=3Bgt=3D3B &amp=3Bgt=3D3B &lt=3BBR&gt=3B&amp=3Bgt=3D3B &amp=
>=3Bgt=3D3B And they don't seem =3D<BR>&gt=3B &gt=3Bto work on this system: =
>I can compile a program&lt=3BBR&gt=3B&amp=3Bgt=3D3B &amp=3Bgt=3D3B but when=
> I=3D<BR>&gt=3B &gt=3B try to run it=3D2C it says "Segmentation fault". Can=
> anyone&lt=3BBR&gt=3B&amp=3Bgt=3D3B &amp=3Bgt=3D3B=3D<BR>&gt=3B &gt=3B help=
>? (My understanding is that I need 5.5.1 or later...)&lt=3BBR&gt=3B&amp=3Bg=
>t=3D3B &amp=3Bgt=3D3B=3D<BR>&gt=3B &gt=3B &lt=3BBR&gt=3B&amp=3Bgt=3D3B &amp=
>=3Bgt=3D3B Mika&lt=3BBR&gt=3B&amp=3Bgt=3D3B &amp=3Bgt=3D3B &lt=3BBR&gt=3B&a=
>mp=3Bgt=3D3B &lt=3BBR&gt=3B&lt=3B/body&gt=3B<BR>&gt=3B &gt=3B&lt=3B/html&gt=
>=3B=3D<BR>&gt=3B &gt=3B<BR>&gt=3B &gt=3B--_806446ae-8d10-4d74-8eea-51aa365e=
>9204_--<BR></body>
></html>=
>
>--_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."
	<COL101-W13CCB4F28AEA577B1F0BEDE68B0@phx.gbl>  
	<200904010559.n315xIBx071256@camembert.async.caltech.edu>
Message-ID: <COL101-W339A6B1571D87422F30FE1E68B0@phx.gbl>


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 -- <builtin>
> 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
> >> >
> >> ><html>
> >> ><head>
> >> ><style>
> >> >.hmmessage P
> >> >{
> >> >margin:0px=3D3B
> >> >padding:0px
> >> >}
> >> >body.hmmessage
> >> >{
> >> >font-size: 10pt=3D3B
> >> >font-family:Verdana
> >> >}
> >> ></style>
> >> ></head>
> >> ><body class=3D3D'hmmessage'>
> >> >&nbsp=3D3B<A href=3D3D"http://modula3.elegosoft.com/cm3/uploaded-archive=
> >s" targ=3D
> >> >et=3D3D_blank><FONT color=3D3D#0068cf>http://modula3.elegosoft.com/cm3/u=
> >ploaded=3D
> >> >-archives</FONT></A><BR>
> >> >?<BR>
> >> >&nbsp=3D3B<BR>
> >> >I can make another later this week.<BR>
> >> >&nbsp=3D3B<BR>
> >> >All you need is a working cm3 on any system.<BR>
> >> >>From there you can build the whole system=3D2C targeting any system.<BR=
> >>
> >> >As long as that cm3 understands LONGINT and your target system.<BR>
> >> >And it is easier=3D2C but not necessary=3D2C if you have Python. :)<BR>
> >> >&nbsp=3D3B<BR>
> >> >&nbsp=3D3B- Jay<BR><BR>&nbsp=3D3B<BR>&gt=3D3B Date: Tue=3D2C 31 Mar 2009=
> > 15:43:41 -=3D
> >> >0500<BR>&gt=3D3B From: martinbishop at bellsouth.net<BR>&gt=3D3B To: mika at a=
> >sync.ca=3D
> >> >ltech.edu<BR>&gt=3D3B CC: m3devel at elegosoft.com<BR>&gt=3D3B Subject: Re:=
> > [M3dev=3D
> >> >el] Help finding CM3 compiler for Linux?<BR>&gt=3D3B <BR>&gt=3D3B Not su=
> >re if t=3D
> >> >his helps=3D2C but on my linux system:<BR>&gt=3D3B <BR>&gt=3D3B Critical=
> > Mass Mod=3D
> >> >ula-3 version d5.7.0<BR>&gt=3D3B last updated: 2008-03-16<BR>&gt=3D3B co=
> >mpiled:=3D
> >> > 2008-08-14 00:56:14<BR>&gt=3D3B configuration: /usr/local/cm3/bin/cm3.c=
> >fg<BR=3D
> >> >>&gt=3D3B <BR>&gt=3D3B Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 2=
> >9 19:24=3D
> >> >:39 UTC 2009<BR>&gt=3D3B i686 GNU/Linux<BR>&gt=3D3B <BR>&gt=3D3B <BR>&gt=
> >=3D3B I don=3D
> >> >'t have the cm3 tarball=3D2C but I do have the sources in cm3/ still.<BR=
> >>&gt=3D
> >> >=3D3B <BR>&gt=3D3B Mika Nystrom wrote:<BR>&gt=3D3B &gt=3D3B Hello everyo=
> >ne=3D2C<BR>&g=3D
> >> >t=3D3B &gt=3D3B <BR>&gt=3D3B &gt=3D3B This is=3D2C for me=3D2C a most un=
> >fortunate time =3D
> >> >for the CM3 servers to<BR>&gt=3D3B &gt=3D3B have crashed. I'm teaching a=
> > class =3D
> >> >using Modula-3=3D2C and we need a<BR>&gt=3D3B &gt=3D3B compiler... here'=
> >s the una=3D
> >> >me of the system I'm trying to use:<BR>&gt=3D3B &gt=3D3B <BR>&gt=3D3B &g=
> >t=3D3B Linu=3D
> >> >x lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Linux<BR=
> >>&g=3D
> >> >t=3D3B &gt=3D3B <BR>&gt=3D3B &gt=3D3B The most recent archives I have fo=
> >r Linux are=3D
> >> >:<BR>&gt=3D3B &gt=3D3B <BR>&gt=3D3B &gt=3D3B cm3-min-POSIX-LINUXLIBC6-5.=
> >4.0.tgz cm3=3D
> >> >-src-all-5.4.0.tgz <BR>&gt=3D3B &gt=3D3B <BR>&gt=3D3B &gt=3D3B And they =
> >don't seem =3D
> >> >to work on this system: I can compile a program<BR>&gt=3D3B &gt=3D3B but=
> > when I=3D
> >> > try to run it=3D2C it says "Segmentation fault". Can anyone<BR>&gt=3D3B=
> > &gt=3D3B=3D
> >> > help? (My understanding is that I need 5.5.1 or later...)<BR>&gt=3D3B &=
> >gt=3D3B=3D
> >> > <BR>&gt=3D3B &gt=3D3B Mika<BR>&gt=3D3B &gt=3D3B <BR>&gt=3D3B <BR></body=
> >>
> >> ></html>=3D
> >> >
> >> >--_806446ae-8d10-4d74-8eea-51aa365e9204_--
> >
> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_
> >Content-Type: text/html; charset="iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
> >
> ><html>
> ><head>
> ><style>
> >.hmmessage P
> >{
> >margin:0px=3B
> >padding:0px
> >}
> >body.hmmessage
> >{
> >font-size: 10pt=3B
> >font-family:Verdana
> >}
> ></style>
> ></head>
> ><body class=3D'hmmessage'>
> >These archives do have a different format=2C yes.<BR>
> >But it isn't a bad format.<BR>
> >cminstall is pretty worthless imho.<BR>
> >Extract=2C rename=2C set PATH and LD_LIBRARY_PATH.<BR>
> >&nbsp=3B<BR>
> >&nbsp=3B- Jay<BR><BR>&nbsp=3B<BR>&gt=3B To: jay.krell at cornell.edu<BR>&gt=3B=
> > Subject: Re: [M3devel] Help finding CM3 compiler for Linux? <BR>&gt=3B Dat=
> >e: Tue=2C 31 Mar 2009 15:56:11 -0700<BR>&gt=3B From: mika at async.caltech.edu=
> ><BR>&gt=3B <BR>&gt=3B No=2C I'm sorry...<BR>&gt=3B <BR>&gt=3B the archives =
> >do not have the usual format. I'm expecting to unpack<BR>&gt=3B and run "cm=
> >install" and then unpack the big source tar on top and <BR>&gt=3B build tha=
> >t. But there's no cminstall in the archive on this page.<BR>&gt=3B This is =
> >"the normal procedure" for installing CM3=2C no? It's what<BR>&gt=3B the in=
> >structions say to do=2C as well...<BR>&gt=3B <BR>&gt=3B And the link from t=
> >he "Download" page is broken (to -d5.5.0.tgz).<BR>&gt=3B <BR>&gt=3B Mika<BR=
> >>&gt=3B <BR>&gt=3B Jay writes:<BR>&gt=3B &gt=3B--_806446ae-8d10-4d74-8eea-5=
> >1aa365e9204_<BR>&gt=3B &gt=3BContent-Type: text/plain=3B charset=3D"iso-885=
> >9-1"<BR>&gt=3B &gt=3BContent-Transfer-Encoding: quoted-printable<BR>&gt=3B =
> >&gt=3B<BR>&gt=3B &gt=3B<BR>&gt=3B &gt=3B http://modula3.elegosoft.com/cm3/u=
> >ploaded-archives<BR>&gt=3B &gt=3B<BR>&gt=3B &gt=3B?<BR>&gt=3B &gt=3B<BR>&gt=
> >=3B &gt=3B=3D20<BR>&gt=3B &gt=3B<BR>&gt=3B &gt=3BI can make another later t=
> >his week.<BR>&gt=3B &gt=3B<BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B<BR>&gt=3B=
> > &gt=3BAll you need is a working cm3 on any system.<BR>&gt=3B &gt=3B<BR>&gt=
> >=3B &gt=3B&gt=3BFrom there you can build the whole system=3D2C targeting an=
> >y system.<BR>&gt=3B &gt=3B<BR>&gt=3B &gt=3BAs long as that cm3 understands =
> >LONGINT and your target system.<BR>&gt=3B &gt=3B<BR>&gt=3B &gt=3BAnd it is =
> >easier=3D2C but not necessary=3D2C if you have Python. :)<BR>&gt=3B &gt=3B<=
> >BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B<BR>&gt=3B &gt=3B - Jay<BR>&gt=3B &gt=
> >=3B<BR>&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B&gt=3B Date: Tue=3D2C 31 Mar 2009=
> > 15:43:41 -0500<BR>&gt=3B &gt=3B&gt=3B From: martinbishop at bellsouth.net<BR>=
> >&gt=3B &gt=3B&gt=3B To: mika at async.caltech.edu<BR>&gt=3B &gt=3B&gt=3B CC: m=
> >3devel at elegosoft.com<BR>&gt=3B &gt=3B&gt=3B Subject: Re: [M3devel] Help fin=
> >ding CM3 compiler for Linux?<BR>&gt=3B &gt=3B&gt=3B=3D20<BR>&gt=3B &gt=3B&g=
> >t=3B Not sure if this helps=3D2C but on my linux system:<BR>&gt=3B &gt=3B&g=
> >t=3B=3D20<BR>&gt=3B &gt=3B&gt=3B Critical Mass Modula-3 version d5.7.0<BR>&=
> >gt=3B &gt=3B&gt=3B last updated: 2008-03-16<BR>&gt=3B &gt=3B&gt=3B compiled=
> >: 2008-08-14 00:56:14<BR>&gt=3B &gt=3B&gt=3B configuration: /usr/local/cm3/=
> >bin/cm3.cfg<BR>&gt=3B &gt=3B&gt=3B=3D20<BR>&gt=3B &gt=3B&gt=3B Linux thinkp=
> >ad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009<BR>&gt=3B &gt=3B&g=
> >t=3B i686 GNU/Linux<BR>&gt=3B &gt=3B&gt=3B=3D20<BR>&gt=3B &gt=3B&gt=3B=3D20=
> ><BR>&gt=3B &gt=3B&gt=3B I don't have the cm3 tarball=3D2C but I do have the=
> > sources in cm3/ still.<BR>&gt=3B &gt=3B&gt=3B=3D20<BR>&gt=3B &gt=3B&gt=3B =
> >Mika Nystrom wrote:<BR>&gt=3B &gt=3B&gt=3B &gt=3B Hello everyone=3D2C<BR>&g=
> >t=3B &gt=3B&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B&gt=3B &gt=3B This is=3D2C fo=
> >r me=3D2C a most unfortunate time for the CM3 servers to<BR>&gt=3B &gt=3B&g=
> >t=3B &gt=3B have crashed. I'm teaching a class using Modula-3=3D2C and we n=
> >eed a<BR>&gt=3B &gt=3B&gt=3B &gt=3B compiler... here's the uname of the sys=
> >tem I'm trying to use:<BR>&gt=3B &gt=3B&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B&=
> >gt=3B &gt=3B Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i68=
> >6 GNU/Lin=3D<BR>&gt=3B &gt=3Bux<BR>&gt=3B &gt=3B&gt=3B &gt=3B=3D20<BR>&gt=
> >=3B &gt=3B&gt=3B &gt=3B The most recent archives I have for Linux are:<BR>&=
> >gt=3B &gt=3B&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B&gt=3B &gt=3B cm3-min-POSIX-=
> >LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz=3D20<BR>&gt=3B &gt=3B&gt=3B &gt=
> >=3B=3D20<BR>&gt=3B &gt=3B&gt=3B &gt=3B And they don't seem to work on this =
> >system: I can compile a program<BR>&gt=3B &gt=3B&gt=3B &gt=3B but when I tr=
> >y to run it=3D2C it says "Segmentation fault". Can anyone<BR>&gt=3B &gt=3B&=
> >gt=3B &gt=3B help? (My understanding is that I need 5.5.1 or later...)<BR>&=
> >gt=3B &gt=3B&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B&gt=3B &gt=3B Mika<BR>&gt=3B=
> > &gt=3B&gt=3B &gt=3B=3D20<BR>&gt=3B &gt=3B&gt=3B=3D20<BR>&gt=3B &gt=3B<BR>&=
> >gt=3B &gt=3B--_806446ae-8d10-4d74-8eea-51aa365e9204_<BR>&gt=3B &gt=3BConten=
> >t-Type: text/html=3B charset=3D"iso-8859-1"<BR>&gt=3B &gt=3BContent-Transfe=
> >r-Encoding: quoted-printable<BR>&gt=3B &gt=3B<BR>&gt=3B &gt=3B&lt=3Bhtml&gt=
> >=3B<BR>&gt=3B &gt=3B&lt=3Bhead&gt=3B<BR>&gt=3B &gt=3B&lt=3Bstyle&gt=3B<BR>&=
> >gt=3B &gt=3B.hmmessage P<BR>&gt=3B &gt=3B{<BR>&gt=3B &gt=3Bmargin:0px=3D3B<=
> >BR>&gt=3B &gt=3Bpadding:0px<BR>&gt=3B &gt=3B}<BR>&gt=3B &gt=3Bbody.hmmessag=
> >e<BR>&gt=3B &gt=3B{<BR>&gt=3B &gt=3Bfont-size: 10pt=3D3B<BR>&gt=3B &gt=3Bfo=
> >nt-family:Verdana<BR>&gt=3B &gt=3B}<BR>&gt=3B &gt=3B&lt=3B/style&gt=3B<BR>&=
> >gt=3B &gt=3B&lt=3B/head&gt=3B<BR>&gt=3B &gt=3B&lt=3Bbody class=3D3D'hmmessa=
> >ge'&gt=3B<BR>&gt=3B &gt=3B&amp=3Bnbsp=3D3B&lt=3BA href=3D3D"http://modula3.=
> >elegosoft.com/cm3/uploaded-archives" targ=3D<BR>&gt=3B &gt=3Bet=3D3D_blank&=
> >gt=3B&lt=3BFONT color=3D3D#0068cf&gt=3Bhttp://modula3.elegosoft.com/cm3/upl=
> >oaded=3D<BR>&gt=3B &gt=3B-archives&lt=3B/FONT&gt=3B&lt=3B/A&gt=3B&lt=3BBR&g=
> >t=3B<BR>&gt=3B &gt=3B?&lt=3BBR&gt=3B<BR>&gt=3B &gt=3B&amp=3Bnbsp=3D3B&lt=3B=
> >BR&gt=3B<BR>&gt=3B &gt=3BI can make another later this week.&lt=3BBR&gt=3B<=
> >BR>&gt=3B &gt=3B&amp=3Bnbsp=3D3B&lt=3BBR&gt=3B<BR>&gt=3B &gt=3BAll you need=
> > is a working cm3 on any system.&lt=3BBR&gt=3B<BR>&gt=3B &gt=3B&gt=3BFrom t=
> >here you can build the whole system=3D2C targeting any system.&lt=3BBR&gt=
> >=3B<BR>&gt=3B &gt=3BAs long as that cm3 understands LONGINT and your target=
> > system.&lt=3BBR&gt=3B<BR>&gt=3B &gt=3BAnd it is easier=3D2C but not necess=
> >ary=3D2C if you have Python. :)&lt=3BBR&gt=3B<BR>&gt=3B &gt=3B&amp=3Bnbsp=
> >=3D3B&lt=3BBR&gt=3B<BR>&gt=3B &gt=3B&amp=3Bnbsp=3D3B- Jay&lt=3BBR&gt=3B&lt=
> >=3BBR&gt=3B&amp=3Bnbsp=3D3B&lt=3BBR&gt=3B&amp=3Bgt=3D3B Date: Tue=3D2C 31 M=
> >ar 2009 15:43:41 -=3D<BR>&gt=3B &gt=3B0500&lt=3BBR&gt=3B&amp=3Bgt=3D3B From=
> >: martinbishop at bellsouth.net&lt=3BBR&gt=3B&amp=3Bgt=3D3B To: mika at async.ca=
> >=3D<BR>&gt=3B &gt=3Bltech.edu&lt=3BBR&gt=3B&amp=3Bgt=3D3B CC: m3devel at elego=
> >soft.com&lt=3BBR&gt=3B&amp=3Bgt=3D3B Subject: Re: [M3dev=3D<BR>&gt=3B &gt=
> >=3Bel] Help finding CM3 compiler for Linux?&lt=3BBR&gt=3B&amp=3Bgt=3D3B &lt=
> >=3BBR&gt=3B&amp=3Bgt=3D3B Not sure if t=3D<BR>&gt=3B &gt=3Bhis helps=3D2C b=
> >ut on my linux system:&lt=3BBR&gt=3B&amp=3Bgt=3D3B &lt=3BBR&gt=3B&amp=3Bgt=
> >=3D3B Critical Mass Mod=3D<BR>&gt=3B &gt=3Bula-3 version d5.7.0&lt=3BBR&gt=
> >=3B&amp=3Bgt=3D3B last updated: 2008-03-16&lt=3BBR&gt=3B&amp=3Bgt=3D3B comp=
> >iled:=3D<BR>&gt=3B &gt=3B 2008-08-14 00:56:14&lt=3BBR&gt=3B&amp=3Bgt=3D3B c=
> >onfiguration: /usr/local/cm3/bin/cm3.cfg&lt=3BBR=3D<BR>&gt=3B &gt=3B&gt=3B&=
> >amp=3Bgt=3D3B &lt=3BBR&gt=3B&amp=3Bgt=3D3B Linux thinkpad 2.6.27-11-generic=
> > #1 SMP Thu Jan 29 19:24=3D<BR>&gt=3B &gt=3B:39 UTC 2009&lt=3BBR&gt=3B&amp=
> >=3Bgt=3D3B i686 GNU/Linux&lt=3BBR&gt=3B&amp=3Bgt=3D3B &lt=3BBR&gt=3B&amp=3B=
> >gt=3D3B &lt=3BBR&gt=3B&amp=3Bgt=3D3B I don=3D<BR>&gt=3B &gt=3B't have the c=
> >m3 tarball=3D2C but I do have the sources in cm3/ still.&lt=3BBR&gt=3B&amp=
> >=3Bgt=3D<BR>&gt=3B &gt=3B=3D3B &lt=3BBR&gt=3B&amp=3Bgt=3D3B Mika Nystrom wr=
> >ote:&lt=3BBR&gt=3B&amp=3Bgt=3D3B &amp=3Bgt=3D3B Hello everyone=3D2C&lt=3BBR=
> >&gt=3B&amp=3Bg=3D<BR>&gt=3B &gt=3Bt=3D3B &amp=3Bgt=3D3B &lt=3BBR&gt=3B&amp=
> >=3Bgt=3D3B &amp=3Bgt=3D3B This is=3D2C for me=3D2C a most unfortunate time =
> >=3D<BR>&gt=3B &gt=3Bfor the CM3 servers to&lt=3BBR&gt=3B&amp=3Bgt=3D3B &amp=
> >=3Bgt=3D3B have crashed. I'm teaching a class =3D<BR>&gt=3B &gt=3Busing Mod=
> >ula-3=3D2C and we need a&lt=3BBR&gt=3B&amp=3Bgt=3D3B &amp=3Bgt=3D3B compile=
> >r... here's the una=3D<BR>&gt=3B &gt=3Bme of the system I'm trying to use:&=
> >lt=3BBR&gt=3B&amp=3Bgt=3D3B &amp=3Bgt=3D3B &lt=3BBR&gt=3B&amp=3Bgt=3D3B &am=
> >p=3Bgt=3D3B Linu=3D<BR>&gt=3B &gt=3Bx lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10=
> >:53:03 PST 2008 i686 GNU/Linux&lt=3BBR&gt=3B&amp=3Bg=3D<BR>&gt=3B &gt=3Bt=
> >=3D3B &amp=3Bgt=3D3B &lt=3BBR&gt=3B&amp=3Bgt=3D3B &amp=3Bgt=3D3B The most r=
> >ecent archives I have for Linux are=3D<BR>&gt=3B &gt=3B:&lt=3BBR&gt=3B&amp=
> >=3Bgt=3D3B &amp=3Bgt=3D3B &lt=3BBR&gt=3B&amp=3Bgt=3D3B &amp=3Bgt=3D3B cm3-m=
> >in-POSIX-LINUXLIBC6-5.4.0.tgz cm3=3D<BR>&gt=3B &gt=3B-src-all-5.4.0.tgz &lt=
> =3BBR&gt=3B&amp=3Bgt=3D3B &amp=3Bgt=3D3B &lt=3BBR&gt=3B&amp=3Bgt=3D3B &amp=
> >=3Bgt=3D3B And they don't seem =3D<BR>&gt=3B &gt=3Bto work on this system: =
> >I can compile a program&lt=3BBR&gt=3B&amp=3Bgt=3D3B &amp=3Bgt=3D3B but when=
> > I=3D<BR>&gt=3B &gt=3B try to run it=3D2C it says "Segmentation fault". Can=
> > anyone&lt=3BBR&gt=3B&amp=3Bgt=3D3B &amp=3Bgt=3D3B=3D<BR>&gt=3B &gt=3B help=
> >? (My understanding is that I need 5.5.1 or later...)&lt=3BBR&gt=3B&amp=3Bg=
> >t=3D3B &amp=3Bgt=3D3B=3D<BR>&gt=3B &gt=3B &lt=3BBR&gt=3B&amp=3Bgt=3D3B &amp=
> >=3Bgt=3D3B Mika&lt=3BBR&gt=3B&amp=3Bgt=3D3B &amp=3Bgt=3D3B &lt=3BBR&gt=3B&a=
> >mp=3Bgt=3D3B &lt=3BBR&gt=3B&lt=3B/body&gt=3B<BR>&gt=3B &gt=3B&lt=3B/html&gt=
> >=3B=3D<BR>&gt=3B &gt=3B<BR>&gt=3B &gt=3B--_806446ae-8d10-4d74-8eea-51aa365e=
> >9204_--<BR></body>
> ></html>=
> >
> >--_777fdc4e-3c29-40b4-a3dd-e6243f796cee_--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090401/01a8411a/attachment.html>

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

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


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

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."
	<COL101-W339A6B1571D87422F30FE1E68B0@phx.gbl>  
	<200904010653.n316rcZs073236@camembert.async.caltech.edu>
Message-ID: <COL101-W75B9E14EAE0B8FD066EB56E68B0@phx.gbl>


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

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."
	<COL101-W60D8F7B0BD2E4241BD7A4CE68B0@phx.gbl> 
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 <mika at async.caltech.edu>:

>
> 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: <COL101-W83616BD410D0687E9E965FE68B0@phx.gbl>


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 <mika at async.caltech.edu>:
> 
> >
> > 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090401/1cd39a77/attachment.html>

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: <COL101-W7157BBD565ADED3ACC238AE68B0@phx.gbl>


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: <COL101-W7157BBD565ADED3ACC238AE68B0@phx.gbl>
References: <COL101-W7157BBD565ADED3ACC238AE68B0@phx.gbl>
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: <COL101-W7157BBD565ADED3ACC238AE68B0@phx.gbl>
	<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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090401/3eece9c8/attachment.sig>

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."
	<COL101-W83616BD410D0687E9E965FE68B0@phx.gbl> 
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 <mika at async.caltech.edu>:
>>=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
>
><html>
><head>
><style>
>.hmmessage P
>{
margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Verdana
>}
></style>
></head>
><body class=3D'hmmessage'>
>Olaf=2C in the LINUXLIBC6 configuration=2C try putting --32 on the as/gas i=
>nvocations.<BR>
>You mentioned --32 on cm3=2C but I wonder if you meant -m32 on cm3.<BR>
>&nbsp=3Bcm3 -m32 <BR>
>&nbsp=3Bas --32 <BR>
>&nbsp=3B<BR>
>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).<BR>
>&nbsp=3B<BR>
>&nbsp=3B&gt=3B probably be easiest to use a real 32 bit system and start fr=
>om 5.4.0<BR>&nbsp=3B&gt=3B again.<BR><BR>
>Using any current system should be plenty easy too.<BR>
>e.g. the distributions I put up. :)<BR>
>&nbsp=3B<BR>
>AMD64_LINUX should be a good starting point=2C but I haven't tried it in a =
>bit.<BR>
>&nbsp=3B<BR>
>I should be able to build a current LINUXLIBC6 very very soon.<BR>
>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.<BR>
>&nbsp=3B<BR>
>I'll be using python/make-dist.py though.<BR>
>I do need to get more packages into it though=2C e.g. cm3ide and m3gdb.<BR>
>&nbsp=3B<BR>
>&nbsp=3B- Jay<BR>&nbsp=3B<BR>&gt=3B Date: Wed=2C 1 Apr 2009 11:11:53 +0200<=
>BR>&gt=3B From: wagner at elegosoft.com<BR>&gt=3B To: m3devel at elegosoft.com<BR=
>>&gt=3B CC: mand at elego.de=3B m3-support at elego.de<BR>&gt=3B Subject: Re: [M3=
>devel] Help finding CM3 compiler for Linux?<BR>&gt=3B <BR>&gt=3B Quoting Mi=
>ka Nystrom &lt=3Bmika at async.caltech.edu&gt=3B:<BR>&gt=3B <BR>&gt=3B &gt=3B<=
>BR>&gt=3B &gt=3B Is there any documentation for this format beyond what you=
> just<BR>&gt=3B &gt=3B wrote? Where?<BR>&gt=3B <BR>&gt=3B Well=2C yes=2C th=
>at's the problem with these kinds of archives:<BR>&gt=3B <BR>&gt=3B (1) the=
>y're not well tested and<BR>&gt=3B (2) there's no documentation user's can =
>rely on<BR>&gt=3B <BR>&gt=3B This doesn't mean that I disapprove or want to=
> criticise the contributors=2C<BR>&gt=3B but an official well-documented re=
>lease with installation notes etc.<BR>&gt=3B has some advantages. Unfortuna=
>tely=2C the official releases are really<BR>&gt=3B outdated now.<BR>&gt=3B =
><BR>&gt=3B I succeeded in building current AMD64_LINUX and FreeBSD4 install=
>ations<BR>&gt=3B on our servers for d5.7.1 tonight and was able to build ar=
>chives for<BR>&gt=3B FreeBSD binaries and sources=2C but the tooling failed=
> for AMD64_KINUX<BR>&gt=3B due to changed and missing configuration files. =
I'll need to have a<BR>&gt=3B closer look at that=2C some extensions seem t=
>o be needed. Anybody who<BR>&gt=3B feels he can do that faster than me is o=
>f course encouraged (I'll have<BR>&gt=3B little time as usual :-/).<BR>&gt=
>=3B <BR>&gt=3B It may also turn out to be difficult to produce LINUXLIBC6 b=
>inaries=2C<BR>&gt=3B as birch and other Elego servers are now 64 bit machin=
>es=2C and trying<BR>&gt=3B to use current CM3 with --32 produced lots of as=
>sembler errors about<BR>&gt=3B unsupported instructions on this architectur=
>e. As the old installation<BR>&gt=3B on birch seems to be gone without a ch=
>ance of being restored=2C it will<BR>&gt=3B probably be easiest to use a re=
>al 32 bit system and start from 5.4.0<BR>&gt=3B again.<BR>&gt=3B <BR>&gt=3B=
> Anybody who wants to help should be able to build the binary<BR>&gt=3B arc=
>hives for LINUXLIBC with cm3/scripts/make-bin-dist-min.sh<BR>&gt=3B easily =
>and upload them to birch at<BR>&gt=3B <BR>&gt=3B /var/www/modula3.elegosoft=
>.com/cm3/uploaded-archives<BR>&gt=3B <BR>&gt=3B My guess is that tinderbox =
>will take some time to run smoothly again=2C<BR>&gt=3B as it was highly cus=
>tomized=2C and I'm not sure if these customizations<BR>&gt=3B survied the c=
>rash.<BR>&gt=3B <BR>&gt=3B Please stay tuned and thanks for all your patien=
>ce=2C<BR>&gt=3B <BR>&gt=3B Olaf<BR>&gt=3B -- <BR>&gt=3B Olaf Wagner -- eleg=
>o Software Solutions GmbH<BR>&gt=3B Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C=
> 13355 Berlin=2C Germany<BR>&gt=3B phone: +49 30 23 45 86 96 mobile: +49 17=
>7 2345 869 fax: +49 30 23 45 86 95<BR>&gt=3B http://www.elegosoft.com | Ges=
>ch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berlin<BR>&gt=3B Handelregister: Amts=
>gericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR>&gt=3B <BR></bo=
>dy>
></html>=
>
>--_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: <COL101-W7157BBD565ADED3ACC238AE68B0@phx.gbl>
	<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."
	<COL101-W83616BD410D0687E9E965FE68B0@phx.gbl>  
	<200904011659.n31GxkMW094881@camembert.async.caltech.edu>
Message-ID: <COL101-W75E35DF5EB9198D1B37108E68B0@phx.gbl>


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."
	<COL101-W83616BD410D0687E9E965FE68B0@phx.gbl>  
	<200904011659.n31GxkMW094881@camembert.async.caltech.edu> 
Message-ID: <COL101-W78349A932A62435D1A8F9BE68B0@phx.gbl>


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."
	<COL101-W75E35DF5EB9198D1B37108E68B0@phx.gbl> 
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."
	<COL101-W75E35DF5EB9198D1B37108E68B0@phx.gbl>
	<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 <mika at async.caltech.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090401/237b0685/attachment.html>

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."
	<COL101-W75E35DF5EB9198D1B37108E68B0@phx.gbl>
	<200904012225.n31MPPDd007216@camembert.async.caltech.edu> 
	<49D3BAD7.1E75.00D7.1@scires.com>
Message-ID: <COL101-W5E03B25D231F307B524CFE68B0@phx.gbl>


"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 <mika at async.caltech.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090401/496607aa/attachment.html>

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 <rcoleburn at scires.com> escribi?:
De: Randy Coleburn <rcoleburn at scires.com>
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 <mika at async.caltech.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090401/3ea5b95f/attachment.html>

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."
	<COL101-W75E35DF5EB9198D1B37108E68B0@phx.gbl>
	<200904012225.n31MPPDd007216@camembert.async.caltech.edu>
	<49D3BAD7.1E75.00D7.1@scires.com>
Message-ID: <20090402085754.wpgiv2sgg800c0c4@mail.elegosoft.com>

Quoting Randy Coleburn <rcoleburn at scires.com>:

> 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 <mika at async.caltech.edu> 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."
	<COL101-W75E35DF5EB9198D1B37108E68B0@phx.gbl>  
	<200904012225.n31MPPDd007216@camembert.async.caltech.edu>
Message-ID: <COL101-W112685B5C942FEBFE185ADE6890@phx.gbl>


"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: <COL101-W500C63B298B002854D0D7EE6870@phx.gbl>


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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090405/e8fa151d/attachment.html>

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: <COL101-W523BA8414A81D3D25E86E9E6870@phx.gbl>


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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090405/f1abd6f3/attachment.html>

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: <B7E25542-379C-4AB4-AFB6-022AC8B62D49@cs.purdue.edu>
References: <200903300333.n2U3XBME062502@camembert.async.caltech.edu>
	<B7E25542-379C-4AB4-AFB6-022AC8B62D49@cs.purdue.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: <COL101-W500C63B298B002854D0D7EE6870@phx.gbl>
References: <COL101-W500C63B298B002854D0D7EE6870@phx.gbl>
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: <COL101-W500C63B298B002854D0D7EE6870@phx.gbl>
	<49D9742E.6080100@taltos.org>
Message-ID: <COL101-W101C682B980D8F8E34F1F5E6840@phx.gbl>


 
- 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>
	<B7E25542-379C-4AB4-AFB6-022AC8B62D49@cs.purdue.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: <COL101-W500C63B298B002854D0D7EE6870@phx.gbl>
	<49D9742E.6080100@taltos.org> 
Message-ID: <COL101-W29723A60E3988205911496E6840@phx.gbl>


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: <COL101-W101C682B980D8F8E34F1F5E6840@phx.gbl>
References: <COL101-W500C63B298B002854D0D7EE6870@phx.gbl>
	<49D9742E.6080100@taltos.org>
	<COL101-W101C682B980D8F8E34F1F5E6840@phx.gbl>
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: <COL101-W29723A60E3988205911496E6840@phx.gbl>
References: <COL101-W500C63B298B002854D0D7EE6870@phx.gbl>
	<49D9742E.6080100@taltos.org>
	<COL101-W29723A60E3988205911496E6840@phx.gbl>
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: <COL101-W500C63B298B002854D0D7EE6870@phx.gbl>
	<49D9742E.6080100@taltos.org>
	<COL101-W101C682B980D8F8E34F1F5E6840@phx.gbl> 
	<49D9A708.1050101@taltos.org>
Message-ID: <COL101-W1432298186AA4E306CF35DE6840@phx.gbl>


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: <COL101-W1432298186AA4E306CF35DE6840@phx.gbl>
References: <COL101-W500C63B298B002854D0D7EE6870@phx.gbl>	<49D9742E.6080100@taltos.org>
	<COL101-W101C682B980D8F8E34F1F5E6840@phx.gbl>
	<49D9A708.1050101@taltos.org>
	<COL101-W1432298186AA4E306CF35DE6840@phx.gbl>
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: <COL101-W500C63B298B002854D0D7EE6870@phx.gbl>
	<49D9742E.6080100@taltos.org>
	<COL101-W101C682B980D8F8E34F1F5E6840@phx.gbl> 
	<49D9A708.1050101@taltos.org> 
Message-ID: <COL101-W736073B7832ABF70F8DC7BE6840@phx.gbl>


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: <COL101-W500C63B298B002854D0D7EE6870@phx.gbl>
	<49D9742E.6080100@taltos.org>	<COL101-W101C682B980D8F8E34F1F5E6840@phx.gbl>
	<49D9A708.1050101@taltos.org>
	<COL101-W1432298186AA4E306CF35DE6840@phx.gbl>
	<49D9BEDE.1010603@taltos.org>
Message-ID: <COL101-W945C75D919B83D8FCB4E5E6840@phx.gbl>


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: <COL101-W945C75D919B83D8FCB4E5E6840@phx.gbl>
References: <COL101-W500C63B298B002854D0D7EE6870@phx.gbl>	<49D9742E.6080100@taltos.org>	<COL101-W101C682B980D8F8E34F1F5E6840@phx.gbl>
	<49D9A708.1050101@taltos.org>
	<COL101-W1432298186AA4E306CF35DE6840@phx.gbl>
	<49D9BEDE.1010603@taltos.org>
	<COL101-W945C75D919B83D8FCB4E5E6840@phx.gbl>
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: <COL101-W34A96E20A0E01C252854ACE6840@phx.gbl>


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: <COL101-W736073B7832ABF70F8DC7BE6840@phx.gbl>
References: <COL101-W500C63B298B002854D0D7EE6870@phx.gbl>
	<49D9742E.6080100@taltos.org>
	<COL101-W101C682B980D8F8E34F1F5E6840@phx.gbl>
	<49D9A708.1050101@taltos.org>
	<COL101-W736073B7832ABF70F8DC7BE6840@phx.gbl>
Message-ID: <20090406144242.almwq5chwgo04kwo@mail.elegosoft.com>

Quoting Jay <jay.krell at cornell.edu>:

> 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 <jay.krell at cornell.edu>:
>
>> 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 <mika at 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?

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 <jay.krell at cornell.edu>:
>>
>>> 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 <mika at 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?
>
>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 <jay.krell at cornell.edu>:
>>>
>>>> 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: <DEA77023-7DE3-4CEF-B414-16A2175A9E94@cs.purdue.edu>

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: <DF33A66B-5339-4190-B915-E53F3D4E1022@cs.purdue.edu>

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 <hosking at cs.purdue.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090406/f71603e8/attachment.html>

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 <hosking at cs.purdue.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090407/50d49c10/attachment.html>

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."
	<DF33A66B-5339-4190-B915-E53F3D4E1022@cs.purdue.edu> 
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: <EB97B02E-EC52-486C-8258-2A79C8D879F1@cs.purdue.edu>

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: <EB97B02E-EC52-486C-8258-2A79C8D879F1@cs.purdue.edu>
References: <200904062039.n36KdIsY095003@camembert.async.caltech.edu>
	<EB97B02E-EC52-486C-8258-2A79C8D879F1@cs.purdue.edu>
Message-ID: <F2BF7A45-B36E-4298-8F12-B45D1FD350B8@cs.purdue.edu>

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."
	<F2BF7A45-B36E-4298-8F12-B45D1FD350B8@cs.purdue.edu> 
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090407/103291d7/attachment.html>

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: <EB97B02E-EC52-486C-8258-2A79C8D879F1@cs.purdue.edu>
References: <200904062039.n36KdIsY095003@camembert.async.caltech.edu>
	<EB97B02E-EC52-486C-8258-2A79C8D879F1@cs.purdue.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: <F2BF7A45-B36E-4298-8F12-B45D1FD350B8@cs.purdue.edu>
	<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>
	<EB97B02E-EC52-486C-8258-2A79C8D879F1@cs.purdue.edu>
	<20090407121217.GB27695@topoi.pooq.com>
Message-ID: <FDD78A87-F1D8-4FA5-97D6-7B17F4A5BB08@cs.purdue.edu>

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."
	<FDD78A87-F1D8-4FA5-97D6-7B17F4A5BB08@cs.purdue.edu> 
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>	<B7E25542-379C-4AB4-AFB6-022AC8B62D49@cs.purdue.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: <FDD78A87-F1D8-4FA5-97D6-7B17F4A5BB08@cs.purdue.edu>
	<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>
	<B7E25542-379C-4AB4-AFB6-022AC8B62D49@cs.purdue.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: <COL101-W55E396FAD3C7A870D73A49E6820@phx.gbl>


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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090408/abcaa187/attachment.html>

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: <COL101-W762CF625BE7A4077AC70FEE6820@phx.gbl>


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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090408/22f7643f/attachment.html>

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: <COL101-W762CF625BE7A4077AC70FEE6820@phx.gbl>
References: <49DC70C6.1000600@taltos.org>
	<COL101-W762CF625BE7A4077AC70FEE6820@phx.gbl>
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: <COL101-W334B2B46C588411F9845E3E6820@phx.gbl>


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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090408/a639c2ab/attachment.html>

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: <COL101-W334B2B46C588411F9845E3E6820@phx.gbl>
References: <49DC70C6.1000600@taltos.org> <49DC8307.7060906@taltos.org>
	<COL101-W334B2B46C588411F9845E3E6820@phx.gbl>
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: <COL101-W55E396FAD3C7A870D73A49E6820@phx.gbl>
References: <200904061532.n36FWunc087102@camembert.async.caltech.edu>
	<20090406175119.5nknbzf9dwkcwkks@mail.elegosoft.com>
	<COL101-W55E396FAD3C7A870D73A49E6820@phx.gbl>
Message-ID: <20090408145115.hgx4t0to0o4s0gg0@mail.elegosoft.com>

Quoting Jay <jay.krell at cornell.edu>:

>
> 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: <COL101-W334B2B46C588411F9845E3E6820@phx.gbl>
References: <49DC70C6.1000600@taltos.org> <49DC8307.7060906@taltos.org>
	<COL101-W334B2B46C588411F9845E3E6820@phx.gbl>
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>
	<COL101-W334B2B46C588411F9845E3E6820@phx.gbl>
	<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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090409/a0f2ae2d/attachment.html>

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: <A01006AA-9C1C-4A0D-B47B-2916A5B75B66@cs.purdue.edu>

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: <COL101-W620B56527B6C3560B4C50CE6830@phx.gbl>


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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090409/4dceea84/attachment.html>

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: <COL101-W620B56527B6C3560B4C50CE6830@phx.gbl>
References: <200904090038.n390cNsg097270@camembert.async.caltech.edu>
	<49DD59DB.4050404@cox.net>
	<7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu>
	<COL101-W620B56527B6C3560B4C50CE6830@phx.gbl>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090409/9e2e30a7/attachment.html>

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>
	<COL101-W620B56527B6C3560B4C50CE6830@phx.gbl> 
	<6DADF96B-7A17-45E8-8084-48A66372ED2D@cs.purdue.edu>
Message-ID: <COL101-W73B53681148CB157FBDEC9E6830@phx.gbl>


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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090409/ad539b2d/attachment.html>

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: <COL101-W73B53681148CB157FBDEC9E6830@phx.gbl>
References: <200904090038.n390cNsg097270@camembert.async.caltech.edu>
	<49DD59DB.4050404@cox.net>
	<7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu>
	<COL101-W620B56527B6C3560B4C50CE6830@phx.gbl>
	<6DADF96B-7A17-45E8-8084-48A66372ED2D@cs.purdue.edu>
	<COL101-W73B53681148CB157FBDEC9E6830@phx.gbl>
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."
	<COL101-W620B56527B6C3560B4C50CE6830@phx.gbl> 
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
>
><html>
><head>
><style>
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Verdana
>}
></style>
></head>
><body class=3D'hmmessage'>
>Um=2C what do folks think of=2C like:<BR>
>&nbsp=3B<BR>
>struct<BR>
>{<BR>&nbsp=3B&nbsp=3B&nbsp=3B void* Type=3B<BR>
>&nbsp=3B&nbsp=3B&nbsp=3B union<BR>
>&nbsp=3B&nbsp=3B&nbsp=3B {<BR>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
>=3B size_t&nbsp=3BInteger=3B<BR>
>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B void* Pointer=3B<BR>
>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B } Value=3B<BR>
>}&nbsp=3BVariant=3B<BR>
>&nbsp=3B<BR>
>?<BR>
>You know -- something that is two pointers=2C one pointer for the type=2C o=
>ne for the value or integer?<BR>
>void* Type would actually be a pointer to something actually defined and el=
>aborate.<BR>
>&nbsp=3B<BR>
>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.<BR>
>&nbsp=3B<BR>
>And hope/assume for perf that such a small struct is passed in registers.<B=
>R>
>On x86/NT 4 and 8 byte structs I think are.<BR>
>&nbsp=3B<BR>
>Type could also be an integer=2C index into some table=2C with some predefi=
>ned values.<BR>
>#define TYPE_INTEGER 0<BR>
>#define TYPE_FLOAT 1<BR>
>#define TYPE_DOUBLE 2<BR>
>#define TYPE_ADDRESS 3<BR>
>&nbsp=3B<BR>
>more generally the union would have a float=2C and maybe a double on 64bit =
>platforms.<BR>
>&nbsp=3B<BR>
>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?<BR>
>&nbsp=3B<BR>
>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.<BR>
>&nbsp=3B<BR>
>&nbsp=3B- Jay<BR><BR>&nbsp=3B<BR>&gt=3B From: hosking at cs.purdue.edu<BR>&gt=
>=3B To: rodney.m.bates at cox.net<BR>&gt=3B Date: Thu=2C 9 Apr 2009 13:01:13 +=
>1000<BR>&gt=3B CC: m3devel at elegosoft.com<BR>&gt=3B Subject: Re: [M3devel] s=
>mall objects<BR>&gt=3B <BR>&gt=3B Sounds like you want something like:<BR>&=
>gt=3B <BR>&gt=3B TAGGED REFANY FOR T<BR>&gt=3B <BR>&gt=3B where T must be a=
> type that fits into BITS(REFANY)-1?<BR>&gt=3B <BR>&gt=3B Branding could be=
> used to prevent mixing otherwise structurally <BR>&gt=3B equivalent TAGGED=
> REFANY.<BR>&gt=3B <BR>&gt=3B TAGGED BRANDED REFANY FOR T<BR>&gt=3B <BR>&gt=
>=3B Where this breaks down is what are the subtyping rules=2C since I assum=
>e <BR>&gt=3B you'd like to store these in a REFANY and dynamically test for=
> the <BR>&gt=3B appropriate tagged type:<BR>&gt=3B <BR>&gt=3B TAGGED REFANY=
> FOR T &lt=3B: REFANY<BR>&gt=3B <BR>&gt=3B But then how do we distinguish a=
>ll the different TAGGED REFANY from <BR>&gt=3B each other at run-time?<BR>&=
>gt=3B <BR>&gt=3B On 9 Apr 2009=2C at 12:13=2C Rodney M. Bates wrote:<BR>&gt=
>=3B <BR>&gt=3B &gt=3B Mika Nystrom wrote:<BR>&gt=3B &gt=3B&gt=3B Hmm=2C ok=
>=2C there's one big difference between what you're saying and<BR>&gt=3B &gt=
>=3B&gt=3B what Tony and I have been talking about. (I think your understand=
>ing<BR>&gt=3B &gt=3B&gt=3B sounds pretty correct.)<BR>&gt=3B &gt=3B&gt=3B<B=
>R>&gt=3B &gt=3B&gt=3B You want to do objects other than small integers. Lik=
>e what? And <BR>&gt=3B &gt=3B&gt=3B why?<BR>&gt=3B &gt=3B&gt=3B I was think=
>ing the trick would apply only to one specific type of <BR>&gt=3B &gt=3B&gt=
>=3B integer.<BR>&gt=3B &gt=3B&gt=3B<BR>&gt=3B &gt=3B<BR>&gt=3B &gt=3B Yes=
>=2C I want a language mechanism that can be used by various<BR>&gt=3B &gt=
>=3B modules to implement various abstract data types=2C each of which<BR>&g=
>t=3B &gt=3B can perform the sometimes dramatic space optimization of puttin=
>g<BR>&gt=3B &gt=3B values that are common and will fit directly in the word=
>.<BR>&gt=3B &gt=3B One module I spoke of implements general sets of integer=
>s with<BR>&gt=3B &gt=3B dynamically variable and sometimes large range. Thi=
>s differs from<BR>&gt=3B &gt=3B the builtin SET OF..=2C which must have a s=
>tatic (and probably <BR>&gt=3B &gt=3B relatively<BR>&gt=3B &gt=3B small) ba=
>se subrange. Thus the general=2C heap-allocated values contain<BR>&gt=3B &g=
>t=3B open arrays of Word.T=2C treated as sets=2C or if you prefer=2C packed=
> <BR>&gt=3B &gt=3B arrays<BR>&gt=3B &gt=3B of booleans=2C although I manipu=
>late them with bit-twiddling operations<BR>&gt=3B &gt=3B from Word.<BR>&gt=
>=3B &gt=3B There is another=2C static-sized=2C heap-allocated object in fro=
>nt of <BR>&gt=3B &gt=3B each array=2C<BR>&gt=3B &gt=3B containing biases on=
> what bits correspond to what integers in the<BR>&gt=3B &gt=3B abstract set=
>=2C etc. It all works fine now=2C but the usage pattern of <BR>&gt=3B &gt=
>=3B some<BR>&gt=3B &gt=3B clients has a high percentage very small sets tha=
>t would fit in a <BR>&gt=3B &gt=3B word=2C<BR>&gt=3B &gt=3B and there would=
> be an 11-to-1 space savings if that could be done.<BR>&gt=3B &gt=3B BTW=2C=
> there are also two different kinds of heap objects=2C one that<BR>&gt=3B &=
>gt=3B represents a range set by just its bounds. So I am TYPECASEing<BR>&gt=
>=3B &gt=3B these already. It would be very convenient if I could just add <=
>BR>&gt=3B &gt=3B another<BR>&gt=3B &gt=3B alternative to the TYPECASE for i=
>n-word values.<BR>&gt=3B &gt=3B<BR>&gt=3B &gt=3B In another case=2C I need =
>truly dynamically variable sized arrays of<BR>&gt=3B &gt=3B integers in [0.=
>.15]=2C and the great majority are 7 elements or less=2C<BR>&gt=3B &gt=3B w=
>hich would fit directly in the word=2C but I still the need full <BR>&gt=3B=
> &gt=3B generality<BR>&gt=3B &gt=3B to be available=2C so it's open arrays =
>all the time=2C with three <BR>&gt=3B &gt=3B additional<BR>&gt=3B &gt=3B wo=
>rds each.<BR>&gt=3B &gt=3B<BR>&gt=3B &gt=3B If you can pack a union of a po=
>inter and an integer into a word and<BR>&gt=3B &gt=3B can separate them wit=
>h runtime checks=2C then you can use the<BR>&gt=3B &gt=3B separated integer=
> any way you want=2C with bit twiddling=2C type <BR>&gt=3B &gt=3B conversio=
>ns=2C<BR>&gt=3B &gt=3B LOOPHOLE=2C or whatever. That is what I am trying to=
> get=2C not just<BR>&gt=3B &gt=3B Smalltalk-like integers.<BR>&gt=3B &gt=3B=
> Note that Smalltalk has zero static typing=2C so only one internal<BR>&gt=
>=3B &gt=3B representation must do for the union of all possible values in<B=
>R>&gt=3B &gt=3B the language. In Modula-3=2C it would be very inconsistent =
>with<BR>&gt=3B &gt=3B the language's philosophy to be this restricted.<BR>&=
>gt=3B &gt=3B&gt=3B Hmm=2C so your idea is to statically determine what type=
> the references<BR>&gt=3B &gt=3B&gt=3B can have if they are non-references.=
> So you are thinking to put <BR>&gt=3B &gt=3B&gt=3B various<BR>&gt=3B &gt=
>=3B&gt=3B kinds of subranges into the "TAGGED" types. But you have to be <B=
>R>&gt=3B &gt=3B&gt=3B able to<BR>&gt=3B &gt=3B&gt=3B determine=2C staticall=
>y=2C which subrange it is... am I understanding <BR>&gt=3B &gt=3B&gt=3B thi=
>s<BR>&gt=3B &gt=3B&gt=3B correctly?<BR>&gt=3B &gt=3B&gt=3B<BR>&gt=3B &gt=3B=
><BR>&gt=3B &gt=3B From the language=2C all I want is to be able to dynamica=
>lly determine<BR>&gt=3B &gt=3B whether it is a true pointer to a heap objec=
>t or a value stored<BR>&gt=3B &gt=3B directly in the word=2C while preservi=
>ng the safety principles and<BR>&gt=3B &gt=3B the semantics of everything a=
>lready there. So I want some new<BR>&gt=3B &gt=3B types=2C different from a=
>ny existing types=2C that statically are known<BR>&gt=3B &gt=3B to hold thi=
>s kind of valueset union and can be converted/assigned<BR>&gt=3B &gt=3B to =
>a variable of existing type that is statically known to be either a<BR>&gt=
>=3B &gt=3B pointer or an integer (but not both)=2C with a suitable runtime =
>check.<BR>&gt=3B &gt=3B It is also necessary to have a way to do this witho=
>ut risking a <BR>&gt=3B &gt=3B runtime<BR>&gt=3B &gt=3B error=2C if your co=
>de doesn't know yet which kind of value it has.<BR>&gt=3B &gt=3B Various AD=
>T modules can take it from there.<BR>&gt=3B &gt=3B&gt=3B Mika<BR>&gt=3B &gt=
>=3B&gt=3B<BR>&gt=3B &gt=3B&gt=3B "Rodney M. Bates" writes:<BR>&gt=3B &gt=3B=
>&gt=3B<BR>&gt=3B &gt=3B&gt=3B&gt=3B Tony Hosking wrote:<BR>&gt=3B &gt=3B&gt=
>=3B&gt=3B<BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B On 8 Apr 2009=2C at 11:49=2C R=
>odney M. Bates wrote:<BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B<BR>&gt=3B &gt=3B&g=
>t=3B&gt=3B&gt=3B<BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B&gt=3B Mika Nystrom wrot=
>e:<BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B&gt=3B<BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=
>=3B&gt=3B&gt=3B Hendrik=2C I think Tony's and my arguments that you can't b=
>reak any<BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B&gt=3B&gt=3B existing code by al=
>lowing the squirreling away of integers into<BR>&gt=3B &gt=3B&gt=3B&gt=3B&g=
>t=3B&gt=3B&gt=3B REFANYs are pretty solid. Pre-existing code simply can't d=
>o <BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B&gt=3B&gt=3B anything<BR>&gt=3B &gt=3B=
>&gt=3B&gt=3B&gt=3B&gt=3B&gt=3B useful with unrevealed REFANYs.<BR>&gt=3B &g=
>t=3B&gt=3B&gt=3B&gt=3B&gt=3B&gt=3B<BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B&gt=3B=
> This is only true of _unrevealed opaque subtypes_ of REFANY=2C<BR>&gt=3B &=
>gt=3B&gt=3B&gt=3B&gt=3B&gt=3B not of REFANY itself. There is lots of existi=
>ng code that uses <BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B&gt=3B REFANY=2C<BR>&g=
>t=3B &gt=3B&gt=3B&gt=3B&gt=3B&gt=3B and there=2C ISTYPE=2C NARROW=2C TYPECA=
>SE=2C and assigment can be and<BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B&gt=3B reg=
>ularly are used on it. It is essential not to alter the <BR>&gt=3B &gt=3B&g=
>t=3B&gt=3B&gt=3B&gt=3B semantics there.<BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B&=
>gt=3B<BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B Pre-existing code won't be able to=
> do anything useful with tagged <BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B REFANYs=
>:<BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B<BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B Sup=
>pose we have<BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B<BR>&gt=3B &gt=3B&gt=3B&gt=
>=3B&gt=3B VAR r: REFANY =3D SmallInteger.FromInt(0)=3B<BR>&gt=3B &gt=3B&gt=
>=3B&gt=3B&gt=3B<BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B then<BR>&gt=3B &gt=3B&gt=
>=3B&gt=3B&gt=3B<BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B ISTYPE(r=2C REFANY) =3D&=
>gt=3B TRUE<BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B ISTYPE(r=2C T) =3D&gt=3B FALS=
>E for any T # REFANY<BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B<BR>&gt=3B &gt=3B&gt=
>=3B&gt=3B&gt=3B Similarly=2C for TYPECASE=2C r will only trigger the REFANY=
> branch.<BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B<BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=
>=3B NARROW(r=2C REFANY) =3D&gt=3B r<BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B NARR=
>OW(r=2C T) =3D&gt=3B run-time error for any T #REFANY<BR>&gt=3B &gt=3B&gt=
>=3B&gt=3B&gt=3B<BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B VAR x: REFANY =3D&gt=3B =
>assignment succeeds<BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B VAR x: T :=3D r =3D&=
>gt=3B run-time error for any T # REFANY (because of <BR>&gt=3B &gt=3B&gt=3B=
>&gt=3B&gt=3B implicit NARROW)<BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B<BR>&gt=3B =
>&gt=3B&gt=3B&gt=3B I think I am getting a bit lost in all the proposals=2C =
>variations=2C <BR>&gt=3B &gt=3B&gt=3B&gt=3B counterproposals=2C etc.=2C but=
><BR>&gt=3B &gt=3B&gt=3B&gt=3B<BR>&gt=3B &gt=3B&gt=3B &gt=3Bfrom this argume=
>nt I am inferring that your plan is that only <BR>&gt=3B &gt=3B&gt=3B varia=
>bles<BR>&gt=3B &gt=3B&gt=3B&gt=3B declared REFANY<BR>&gt=3B &gt=3B&gt=3B&gt=
>=3B and not any proper subtype of REFANY can ever have a value with a <BR>&=
>gt=3B &gt=3B&gt=3B&gt=3B tag bit set? Then<BR>&gt=3B &gt=3B&gt=3B&gt=3B the=
> 4 narrowing operations=2C when and only when applied to an <BR>&gt=3B &gt=
>=3B&gt=3B&gt=3B expression of static<BR>&gt=3B &gt=3B&gt=3B&gt=3B type REFA=
>NY=2C would change to make a runtime check for a tag bit <BR>&gt=3B &gt=3B&=
>gt=3B&gt=3B and fail if it's set?<BR>&gt=3B &gt=3B&gt=3B&gt=3B It would tak=
>e this to prevent a tagged value from getting into a <BR>&gt=3B &gt=3B&gt=
>=3B&gt=3B variable declared a<BR>&gt=3B &gt=3B&gt=3B&gt=3B proper subtype o=
>f REFANY=2C which can be dereferenced.<BR>&gt=3B &gt=3B&gt=3B&gt=3B<BR>&gt=
>=3B &gt=3B&gt=3B&gt=3B This would preclude making your abstract data type a=
>n opaque <BR>&gt=3B &gt=3B&gt=3B&gt=3B subtype of REFANY=2C<BR>&gt=3B &gt=
>=3B&gt=3B&gt=3B and would mean all supposedly unrelated ADT modules that us=
>ed the <BR>&gt=3B &gt=3B&gt=3B&gt=3B tag technique<BR>&gt=3B &gt=3B&gt=3B&g=
>t=3B could be broken by client code that mixed up the REFANY values of <BR>=
>&gt=3B &gt=3B&gt=3B&gt=3B one of them with<BR>&gt=3B &gt=3B&gt=3B&gt=3B tho=
>se of another. I consider this a definite breach of Modula-3's <BR>&gt=3B &=
>gt=3B&gt=3B&gt=3B otherwise bulletproof<BR>&gt=3B &gt=3B&gt=3B&gt=3B type s=
>afety.<BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B It is impossible to dereference a=
>n expression statically typed as <BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B REFANY=
>=2C so there is no need for a "tagged" check on dereference.<BR>&gt=3B &gt=
>=3B&gt=3B&gt=3B&gt=3B Because a tagged REFANY cannot be assigned to anythin=
>g other than <BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B something typed REFANY=2C =
>it can never propagate to a place where <BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B=
> it can be dereferenced.<BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B<BR>&gt=3B &gt=
>=3B&gt=3B&gt=3B&gt=3B<BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B&gt=3B Aside from a=
>ctual semantic changes=2C I agree with Tony that we <BR>&gt=3B &gt=3B&gt=3B=
>&gt=3B&gt=3B&gt=3B should<BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B&gt=3B not burd=
>en any existing type with additional runtime work. Even <BR>&gt=3B &gt=3B&g=
>t=3B&gt=3B&gt=3B&gt=3B though<BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B&gt=3B I ex=
>pect small objects to support big performance gains in certain<BR>&gt=3B &g=
>t=3B&gt=3B&gt=3B&gt=3B&gt=3B important cases=2C non-tagged references will =
>still greatly <BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B&gt=3B predominate<BR>&gt=
>=3B &gt=3B&gt=3B&gt=3B&gt=3B&gt=3B in most code. Create new type(s) for tag=
>ged references.<BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B&gt=3B<BR>&gt=3B &gt=3B&g=
>t=3B&gt=3B&gt=3B I'm not sure that we are seeing any semantic changes at al=
>l. And <BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B with Mika's definition of SmallI=
>nteger.T as a "boxed" INTEGER <BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B object (a=
>ctually it would be a subrange for values that fit into <BR>&gt=3B &gt=3B&g=
>t=3B&gt=3B&gt=3B BITSIZE(Word.T)-1 bits)=2C it is essentially transparent. =
>It just <BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B happens to be a run-time optimi=
>zation that unboxes the INTEGER <BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B value.<=
>BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B<BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B<BR>&g=
>t=3B &gt=3B&gt=3B&gt=3B&gt=3B I think I can implement the compiler and run-=
>time support for <BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B this very quickly.<BR>=
>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B<BR>&gt=3B &gt=3B&gt=3B&gt=3B&gt=3B<BR>&gt=
>=3B &gt=3B&gt=3B&gt=3B&gt=3B<BR>&gt=3B &gt=3B&gt=3B<BR>&gt=3B &gt=3B&gt=3B<=
>BR>&gt=3B <BR></body>
></html>=
>
>--_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: <COL101-W86168B24BD25824377487E6830@phx.gbl>


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: <COL101-W3568620605606FC8ABE446E6830@phx.gbl>


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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090409/c632299f/attachment.html>

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: <COL101-W620B56527B6C3560B4C50CE6830@phx.gbl>
References: <200904090038.n390cNsg097270@camembert.async.caltech.edu>	<49DD59DB.4050404@cox.net>
	<7F020149-A73D-403A-835A-1A2E85E3FDA4@cs.purdue.edu>
	<COL101-W620B56527B6C3560B4C50CE6830@phx.gbl>
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: <COL101-W86168B24BD25824377487E6830@phx.gbl>
References: <20090409170205.0D1CF60C150@birch.elegosoft.com>
	<COL101-W86168B24BD25824377487E6830@phx.gbl>
Message-ID: <20090410200731.nho013ykaowwc4s0@mail.elegosoft.com>

Quoting Jay <jay.krell at cornell.edu>:

>
> 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 <hosking at cs.purdue.edu>
> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090411/b3400d13/attachment.html>

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: <COL101-W3002E7B8AC5E3FA1C6FBB9E6800@phx.gbl>


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: <COL101-W7175BB349E67C7046AE57DE6800@phx.gbl>


[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: <COL101-W55009C972401F0D6F20576E6800@phx.gbl>


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: <COL101-W24C62F77965AF4D5CC137EE6800@phx.gbl>


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: <COL101-W24C62F77965AF4D5CC137EE6800@phx.gbl>
References: <COL101-W24C62F77965AF4D5CC137EE6800@phx.gbl>
Message-ID: <20090411104640.7cm9u7utc40oscoc@mail.elegosoft.com>

Quoting Jay <jay.krell at cornell.edu>:

>
> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 <martinbishop at bellsouth.net>:

> 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 ar