[M3devel] [M3commit] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)

[Jay K]

cm3.exe from a few days ago doesn't understand the VAL(LONGINT, INTEGER) used in Convert.m3.

 I had "fixed" Convert.m3 that but Tony put it back.

 

cm3/m3quake packages from a period this week only work with current libm3.

  That is fixed.

 

Normally you can either use an old cm3 and skip libm3/m3core or you can use a fairly recent cm3 and not stop skip them.

Neither was the case for a short time, but I restored the first option.

 

 - Jay

 


From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Fri, 15 Jan 2010 16:45:42 -0500
Subject: Re: [M3devel] [M3commit] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)







Jay:
 
Not sure about your statement that recent cm3.exe can’t be used to bootstrap new compiler.
 
I haven’t done an update in last 2 days, but up until then, I’ve been using my then current cm3.exe to bootstrap the new stuff on Windows without any trouble.
 
Are you saying that if I get current update (I’m only a couple of days out of sync with HEAD) that I won’t be able to bootstrap anymore?
 
Regards,
Randy Coleburn
 


From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Friday, January 15, 2010 4:34 PM
To: Tony
Cc: m3devel; m3commit at elegosoft.com
Subject: Re: [M3commit] [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)
 
We were in a state where neither m3core nor cm3/m3quake could be built with old tools/libraries.
That is more ok for m3core, less ok for cm3/m3quake.
As well, m3core also couldn't be built with recent but slightly old compiler.
    See, I didn't remove the use of LONGINT, just the use of VAL(LONGINT, INTEGER).
    As well, maybe cm3/m3quake couldn't be built with recent tools/libraries.
 
 
The sysutils/m3quake/cm3 changes should stand?
Ok removing "32" from the name and letting it return >4GB on 64bit platforms.
But I think either it can't use libm3.File.T.status().size, OR we have to
make status().size more compatible such as by introducing statusL or sizeL.
32bit code wouldn't see >4GB file sizes unless actively changed.
Maybe not a bad idea.
 
 
 - Jay

 



From: hosking at cs.purdue.edu
Date: Fri, 15 Jan 2010 16:17:15 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com; m3commit at elegosoft.com
Subject: Re: [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)



On 15 Jan 2010, at 15:57, Jay K wrote:


 

I at least did move the hacks to one place.
I agree it isn't nice.
This is due to my changes, not yours -- changing File.T.status().size to LONGINT.
There's no way to use that in the "compiler" and still support old compiler/libm3, right?

 

RIght.  Except we should not try to maintain compatibility between among trunk versions.  If you want to build as of a particular version then use libraries that match that version.

 

My next set of commits for LONGCARD make this even more critical because the library has hardwired stuff that that makes it require a particular version of the compiler to compile it.  ;-)

 

Ok now that I centralized it to sysutils?
 
 
Leave status() alone as using INTEGER and introduce statusL()?
 
 
Or leave size alone and introduce sizeL?
 That's not a complete solution because you have to set size to something.
  -1 if it doesn't fit?
 
 
Or just get past the bootstrapping and put it back using VAL?

 

Yes.

 

It seems a tough situation..the compiler is otherwise I believe
very compatible with old compiler/libm3.

 

It very soon will not be.

 

 
 
 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 10:13:06 -0500
> To: jkrell at elego.de
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> Jay, all of these changes seem unnecessary (and worse, clutter the source with a variety of hacks). I had no problem building against both versions of m3core and libm3 in order to bootstrap a new compiler. What is going on here?
> 
> On 15 Jan 2010, at 14:41, Jay Krell wrote:
> 
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/01/15 14:41:00
> > 
> > Modified files:
> > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > m3makefile 
> > Added files:
> > cm3/m3-sys/m3quake/src/: QScannerC.c 
> > 
> > Log message:
> > m3quake also can't use libm3 File.T.status().size and be compatible
> > with both old and new libm3 (INTEGER vs. LONGINT)
> 
  		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100115/ddee77a0/attachment-0002.html>