[M3commit] [M3devel] LONGINT used by m3quake/cm3 packages

[Tony Hosking]

That's fine.

On 16 Jan 2010, at 00:14, Jay K wrote:

> 
> No. They have File.T.status().size is INTEGER, and then m3quake/m3scanner call VAL(x, INTEGER) on that. I guess that is legal though.
> It doesn't matter if x is INTEGER or not, right?
> (In newer libraries, it is LONGINT).
> 
> 
> - Jay
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Fri, 15 Jan 2010 23:29:27 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>> Subject: Re: [M3commit] [M3devel] LONGINT used by m3quake/cm3 packages
>> 
>> The old (release) libraries don't have the VAL stuff do they?
>> 
>> On 15 Jan 2010, at 23:15, Jay K wrote:
>> 
>>> 
>>> I strongly suspect(ed) this bootstrapping is broken, by my changing libm3.File.T.status().size to LONGINT, and then using VAL(LONGINT, INTEGER) in m3quake/m3scanner. However, with the older libraries, duh, it is VAL(INTEGER, INTEGER). Is that legal? Ok, probably, sorry, I was confused.
>>> 
>>> - Jay
>>> 
>>> 
>>> ----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> Date: Fri, 15 Jan 2010 18:57:30 -0500
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>>>> Subject: Re: [M3commit] [M3devel] LONGINT used by m3quake/cm3 packages
>>>> 
>>>> You can bootstrap (non-Windows) from pre-LONGINT, building and shipping in the following order:
>>>> 
>>>> Using old (release) cm3
>>>> 
>>>> m3middle
>>>> m3linker
>>>> m3front
>>>> m3quake
>>>> cm3
>>>> 
>>>> This cm3 uses old run-time libraries, but now understands LONGINT and LONGCARD.
>>>> 
>>>> m3core (new, with LONGINT/LONGCARD)
>>>> libm3 (new, with LONGINT/LONGCARD)
>>>> sysutils
>>>> m3middle
>>>> m3linker
>>>> m3front
>>>> m3quake
>>>> cm3
>>>> 
>>>> This cm3 uses new run-time libraries.
>>>> 
>>>> On 15 Jan 2010, at 18:45, Jay K wrote:
>>>> 
>>>>> 
>>>>> I'm able to bootstrap the current system from pre-LONGINT using upgrade.py.
>>>>> I'm not sure, but our regular builds might do that.
>>>>> Not so now though.
>>>>> I think you might be saying however that such a compiler might have bugs in it?
>>>>> 
>>>>> - Jay
>>>>> 
>>>>> 
>>>>> 
>>>>> ________________________________
>>>>>> From: hosking at cs.purdue.edu
>>>>>> Date: Fri, 15 Jan 2010 17:50:17 -0500
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>>>>>> Subject: Re: [M3devel] LONGINT used by m3quake/cm3 packages
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 15 Jan 2010, at 16:56, Jay K wrote:
>>>>>> 
>>>>>> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
>>>>>> but I think what I had is the way to go.
>>>>>> The bootstrapping pain is otherwise novel.
>>>>>> 
>>>>>> The bootstrapping pain is now no more novel than when LONGINT was first introduced...
>>>>>> 
>>>>>> The compiler doesn't otherwise use LONGINT.
>>>>>> (My doing that it started using it.)
>>>>>> It ought not until after the current release?
>>>>>> 
>>>>>> ... so it is pointless trying to build new libraries with an old compiler because the old compiler is built to compile files against old libraries.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> - Jay
>>>>>> 
>>>>>> 
>>>>>>> Date: Fri, 15 Jan 2010 22:51:15 +0000
>>>>>>> To: m3commit at elegosoft.com
>>>>>>> From: hosking at elego.de
>>>>>>> Subject: [M3commit] CVS Update: cm3
>>>>>>> 
>>>>>>> CVSROOT: /usr/cvs
>>>>>>> Changes by: hosking at birch. 10/01/15 22:51:15
>>>>>>> 
>>>>>>> Modified files:
>>>>>>> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3
>>>>>>> 
>>>>>>> Log message:
>>>>>>> Revert to VAL.
>>>>>>> 
>>>>>> 
>>>> 
>> 		 	   		  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20100116/42a67f46/attachment-0002.html>