[M3commit] LONGINT used by m3quake/cm3 packages

[Tony Hosking]

It's not the presence of LONGINT in the libraries or not.  It is the presence of changes type type-map information (see RTTipe and its correspondence with TipeMap) which mean that the new libraries are incompatible with old compilers.

On 15 Jan 2010, at 17:42, Jay K wrote:

> The compiler is not very dependent on newer compiler/libraries, until now, that I changed File.T.status().size to LONGINT.
>  
> I was just able to upgrade.py from cm3-min-WIN32-NT386-5.2.6 for example. 5.1.3a failed though.
> (It's still in progress, but far long.)
>  
> m3core/libm3 can depend on current compiler, agreed.
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 17:13:38 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3commit] LONGINT used by m3quake/cm3 packages
> 
> Jay, the bootstrapping pain is inherent.  The compiler and libraries are bound together.  Currently, the old library and new libraries are incompatible with their respective compilers.  Both ways.
> 
> 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 compiler doesn't otherwise use LONGINT.
>  (My doing that it started using it.)
> It ought not until after the current release?
>  
>  
>  - 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/20100115/f44cddfe/attachment-0002.html>