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

Jay K jay.krell at cornell.edu
Sat Jan 16 06:14:16 CET 2010


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


More information about the M3commit mailing list