From wagner at elegosoft.com Thu Nov 19 20:42:05 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 19 Nov 2015 20:42:05 +0100 Subject: [M3devel] upgrade fails with compilation error in m3quake Message-ID: <20151119204205.0f728aaf2004e30402cc87e7@elegosoft.com> Anybody feels guilty? Or do I just need an intermediate step now to upgrade from a compiler from 2009? === package m3-sys/m3quake === +++ cm3 -build -DROOT='/home/wagner/work/cm3-github-ssh' $RARGS && cm3 -ship $RARGS -DROOT='/home/wagner/work/cm3-github-ssh' +++ --- building in FreeBSD4 --- ignoring ../src/m3overrides new source -> compiling Quake.i3 new source -> compiling QCompiler.i3 new source -> compiling QCode.i3 new source -> compiling QValue.i3 new source -> compiling QVSeq.i3 new source -> compiling QVTbl.i3 new source -> compiling QVal.i3 new source -> compiling QPromise.i3 new source -> compiling QPromiseSeq.i3 new source -> compiling QMachine.i3 new source -> compiling QToken.i3 new source -> compiling QIdent.i3 new source -> compiling Quake.m3 new source -> compiling QToken.m3 new source -> compiling QIdent.m3 new source -> compiling QScanner.i3 new source -> compiling QScanner.m3 "../src/QScanner.m3", line 47: VAL: first argument must be an INTEGER 1 error encountered Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com 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 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney_bates at lcwb.coop Thu Nov 19 22:03:00 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 19 Nov 2015 15:03:00 -0600 Subject: [M3devel] upgrade fails with compilation error in m3quake In-Reply-To: <20151119204205.0f728aaf2004e30402cc87e7@elegosoft.com> References: <20151119204205.0f728aaf2004e30402cc87e7@elegosoft.com> Message-ID: <564E3904.7080506@lcwb.coop> It looks like a bootstrap barrier. My installed compiler does not complain. The first argument has type LONGCARD, declared at m3-libs/libm3/src/os/Common/File.i3:34 This was changed from CARDINAL in 2010, no doubt to handle big files on 32-bit systems. The compiler was changed to allow this at similar time. I made changes to the failing code in QScanner in June of 2014, but it would have had the same failure even before. I'm not sure of the easiest way to proceed. Figuring out what the intermediate step would be could be tedious. You might consider just editing the type in File.i3 to CARDINAL temporarily, to build a compiler, then change it back and recompile with that. But then, there could possibly be other such problems. But in general, we should have an upgrade procedure that anybody can use, starting with the release compiler, and no such manual stuff. I suppose trying to compile the current libm3 before the current compiler is the source of the problem. Can you easily recompile the compiler with your old libraries? We seem to have had some bootstrap barriers that require doing the libraries before the compiler and others the other way around, which makes having a general procedure problematic. Any ideas, Jay? On 11/19/2015 01:42 PM, Olaf Wagner wrote: > Anybody feels guilty? > Or do I just need an intermediate step now to upgrade from a compiler > from 2009? > > === package m3-sys/m3quake === > +++ cm3 -build -DROOT='/home/wagner/work/cm3-github-ssh' $RARGS && cm3 -ship $RARGS -DROOT='/home/wagner/work/cm3-github-ssh' +++ > --- building in FreeBSD4 --- > > ignoring ../src/m3overrides > > new source -> compiling Quake.i3 > new source -> compiling QCompiler.i3 > new source -> compiling QCode.i3 > new source -> compiling QValue.i3 > new source -> compiling QVSeq.i3 > new source -> compiling QVTbl.i3 > new source -> compiling QVal.i3 > new source -> compiling QPromise.i3 > new source -> compiling QPromiseSeq.i3 > new source -> compiling QMachine.i3 > new source -> compiling QToken.i3 > new source -> compiling QIdent.i3 > new source -> compiling Quake.m3 > new source -> compiling QToken.m3 > new source -> compiling QIdent.m3 > new source -> compiling QScanner.i3 > new source -> compiling QScanner.m3 > "../src/QScanner.m3", line 47: VAL: first argument must be an INTEGER > 1 error encountered > > Olaf > -- Rodney Bates rodney.m.bates at acm.org From wagner at elegosoft.com Thu Nov 19 22:52:11 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 19 Nov 2015 22:52:11 +0100 Subject: [M3devel] upgrade fails with compilation error in m3quake In-Reply-To: <564E3904.7080506@lcwb.coop> References: <20151119204205.0f728aaf2004e30402cc87e7@elegosoft.com> <564E3904.7080506@lcwb.coop> Message-ID: <20151119225211.a9469a3932dd23289731ff3f@elegosoft.com> On Thu, 19 Nov 2015 15:03:00 -0600 "Rodney M. Bates" wrote: > It looks like a bootstrap barrier. My installed compiler does not complain. > The first argument has type LONGCARD, declared at m3-libs/libm3/src/os/Common/File.i3:34 > This was changed from CARDINAL in 2010, no doubt to handle big files on 32-bit systems. > The compiler was changed to allow this at similar time. > > I made changes to the failing code in QScanner in June of 2014, but it would have had > the same failure even before. > > I'm not sure of the easiest way to proceed. Figuring out what the intermediate step > would be could be tedious. You might consider just editing the type in File.i3 > to CARDINAL temporarily, to build a compiler, then change it back and recompile with > that. But then, there could possibly be other such problems. > > But in general, we should have an upgrade procedure that anybody can use, starting with > the release compiler, and no such manual stuff. I suppose trying to compile the > current libm3 before the current compiler is the source of the problem. Can you easily > recompile the compiler with your old libraries? We seem to have had some bootstrap > barriers that require doing the libraries before the compiler and others the other > way around, which makes having a general procedure problematic. Perhaps I should give up on upgrading this old 32-bit FreeBSD system and just try to setup a current cm3 on another system at Elego. I just started it because there seemed to be a still working version. It's probably not worth the efforts. Thanks for your help anyway; I'll try to download something newer for booting from github. Olaf > Any ideas, Jay? > > On 11/19/2015 01:42 PM, Olaf Wagner wrote: > > Anybody feels guilty? > > Or do I just need an intermediate step now to upgrade from a compiler > > from 2009? > > > > === package m3-sys/m3quake === > > +++ cm3 -build -DROOT='/home/wagner/work/cm3-github-ssh' $RARGS && cm3 -ship $RARGS -DROOT='/home/wagner/work/cm3-github-ssh' +++ > > --- building in FreeBSD4 --- > > > > ignoring ../src/m3overrides > > > > new source -> compiling Quake.i3 > > new source -> compiling QCompiler.i3 > > new source -> compiling QCode.i3 > > new source -> compiling QValue.i3 > > new source -> compiling QVSeq.i3 > > new source -> compiling QVTbl.i3 > > new source -> compiling QVal.i3 > > new source -> compiling QPromise.i3 > > new source -> compiling QPromiseSeq.i3 > > new source -> compiling QMachine.i3 > > new source -> compiling QToken.i3 > > new source -> compiling QIdent.i3 > > new source -> compiling Quake.m3 > > new source -> compiling QToken.m3 > > new source -> compiling QIdent.m3 > > new source -> compiling QScanner.i3 > > new source -> compiling QScanner.m3 > > "../src/QScanner.m3", line 47: VAL: first argument must be an INTEGER > > 1 error encountered > > > > Olaf > > > > -- > Rodney Bates > rodney.m.bates at acm.org -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com 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 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Nov 24 06:31:58 2015 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Nov 2015 05:31:58 +0000 Subject: [M3devel] upgrade fails with compilation error in m3quake In-Reply-To: <20151119225211.a9469a3932dd23289731ff3f@elegosoft.com> References: <20151119204205.0f728aaf2004e30402cc87e7@elegosoft.com>, <564E3904.7080506@lcwb.coop>, <20151119225211.a9469a3932dd23289731ff3f@elegosoft.com> Message-ID: I had written up something here. It is kind of embarassing, but there is also no perfect solution. The rest of the computing world has had 64bit integers and 64 bit file sizes on 32bit platforms for 20+ years. However, many 32bit platforms did make the same initial mistake of having 32bit file sizes. And when they fixed it, they generally left all source and binaries having the same meaning, and all sources continuing to compile. And existing 32bit code would possibly error on large files, or possibly work, depending on details. And what they often did is introduce parallel interfaces. For every: SetFilePositio(int32) and GetFileSize:int32, there is usually a SetFilePosition(int64) and GetFileSize:int64. Every one, and every wrapper library, gets to update their code. And every library keeps both sets of function calls. It is messy. I believe there used to be 16bit interfaces as we well. So what should we do? Introduce parallel interfaces? Tedious but compatible. Probably. Ignore large files on 32bit platforms? Tempting but also embararassing. I'll try to look & see how bad the problem is of having parallel interfaces, so that existing code works, and new code can use "long" or "64" everywhere. - Jay > Date: Thu, 19 Nov 2015 22:52:11 +0100 > From: wagner at elegosoft.com > To: rodney.m.bates at acm.org > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] upgrade fails with compilation error in m3quake > > On Thu, 19 Nov 2015 15:03:00 -0600 > "Rodney M. Bates" wrote: > > > It looks like a bootstrap barrier. My installed compiler does not complain. > > The first argument has type LONGCARD, declared at m3-libs/libm3/src/os/Common/File.i3:34 > > This was changed from CARDINAL in 2010, no doubt to handle big files on 32-bit systems. > > The compiler was changed to allow this at similar time. > > > > I made changes to the failing code in QScanner in June of 2014, but it would have had > > the same failure even before. > > > > I'm not sure of the easiest way to proceed. Figuring out what the intermediate step > > would be could be tedious. You might consider just editing the type in File.i3 > > to CARDINAL temporarily, to build a compiler, then change it back and recompile with > > that. But then, there could possibly be other such problems. > > > > But in general, we should have an upgrade procedure that anybody can use, starting with > > the release compiler, and no such manual stuff. I suppose trying to compile the > > current libm3 before the current compiler is the source of the problem. Can you easily > > recompile the compiler with your old libraries? We seem to have had some bootstrap > > barriers that require doing the libraries before the compiler and others the other > > way around, which makes having a general procedure problematic. > > Perhaps I should give up on upgrading this old 32-bit FreeBSD system and > just try to setup a current cm3 on another system at Elego. I just started > it because there seemed to be a still working version. > > It's probably not worth the efforts. > > Thanks for your help anyway; I'll try to download something newer for booting > from github. > > Olaf > > > Any ideas, Jay? > > > > On 11/19/2015 01:42 PM, Olaf Wagner wrote: > > > Anybody feels guilty? > > > Or do I just need an intermediate step now to upgrade from a compiler > > > from 2009? > > > > > > === package m3-sys/m3quake === > > > +++ cm3 -build -DROOT='/home/wagner/work/cm3-github-ssh' $RARGS && cm3 -ship $RARGS -DROOT='/home/wagner/work/cm3-github-ssh' +++ > > > --- building in FreeBSD4 --- > > > > > > ignoring ../src/m3overrides > > > > > > new source -> compiling Quake.i3 > > > new source -> compiling QCompiler.i3 > > > new source -> compiling QCode.i3 > > > new source -> compiling QValue.i3 > > > new source -> compiling QVSeq.i3 > > > new source -> compiling QVTbl.i3 > > > new source -> compiling QVal.i3 > > > new source -> compiling QPromise.i3 > > > new source -> compiling QPromiseSeq.i3 > > > new source -> compiling QMachine.i3 > > > new source -> compiling QToken.i3 > > > new source -> compiling QIdent.i3 > > > new source -> compiling Quake.m3 > > > new source -> compiling QToken.m3 > > > new source -> compiling QIdent.m3 > > > new source -> compiling QScanner.i3 > > > new source -> compiling QScanner.m3 > > > "../src/QScanner.m3", line 47: VAL: first argument must be an INTEGER > > > 1 error encountered > > > > > > Olaf > > > > > > > -- > > Rodney Bates > > rodney.m.bates at acm.org > > > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > 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 > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Nov 24 06:33:24 2015 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Nov 2015 05:33:24 +0000 Subject: [M3devel] 64-bit integer literals (v5.8.6, NT386) In-Reply-To: References: , , , Message-ID: > although for some reason it tries to ship the new binaries to the same location as the old compiler, which of course fails It is supposed to "wait" slightly, and then do exactly that. I'll have to find time again... - Jay Date: Fri, 16 Oct 2015 07:41:18 -0700 From: lists at darko.org To: jcchu at acm.org CC: m3devel at elegosoft.com Subject: Re: [M3devel] 64-bit integer literals (v5.8.6, NT386) I haven't used those scripts so I have no idea why it does that, but the work around would be to move or rename the old compiler and the use it manually to ship the new binaries. I think there's also been some discussion regarding that issue in the mailing list in the last couple of months. On Tue, Oct 13, 2015 at 11:43 PM, JC Chu wrote: I might have been doing it wrong. I can actually use upgrade.py to produce a working compiler without having to ?fudging? anything (except NT.common (the Quake script), since I have Visual Studio 2015, which now splits the C runtime into three parts ()), although for some reason it tries to ship the new binaries to the same location as the old compiler, which of course fails. Now I?m not really sure what to do from here. ? JC Chu _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Nov 19 20:42:05 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 19 Nov 2015 20:42:05 +0100 Subject: [M3devel] upgrade fails with compilation error in m3quake Message-ID: <20151119204205.0f728aaf2004e30402cc87e7@elegosoft.com> Anybody feels guilty? Or do I just need an intermediate step now to upgrade from a compiler from 2009? === package m3-sys/m3quake === +++ cm3 -build -DROOT='/home/wagner/work/cm3-github-ssh' $RARGS && cm3 -ship $RARGS -DROOT='/home/wagner/work/cm3-github-ssh' +++ --- building in FreeBSD4 --- ignoring ../src/m3overrides new source -> compiling Quake.i3 new source -> compiling QCompiler.i3 new source -> compiling QCode.i3 new source -> compiling QValue.i3 new source -> compiling QVSeq.i3 new source -> compiling QVTbl.i3 new source -> compiling QVal.i3 new source -> compiling QPromise.i3 new source -> compiling QPromiseSeq.i3 new source -> compiling QMachine.i3 new source -> compiling QToken.i3 new source -> compiling QIdent.i3 new source -> compiling Quake.m3 new source -> compiling QToken.m3 new source -> compiling QIdent.m3 new source -> compiling QScanner.i3 new source -> compiling QScanner.m3 "../src/QScanner.m3", line 47: VAL: first argument must be an INTEGER 1 error encountered Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com 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 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney_bates at lcwb.coop Thu Nov 19 22:03:00 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 19 Nov 2015 15:03:00 -0600 Subject: [M3devel] upgrade fails with compilation error in m3quake In-Reply-To: <20151119204205.0f728aaf2004e30402cc87e7@elegosoft.com> References: <20151119204205.0f728aaf2004e30402cc87e7@elegosoft.com> Message-ID: <564E3904.7080506@lcwb.coop> It looks like a bootstrap barrier. My installed compiler does not complain. The first argument has type LONGCARD, declared at m3-libs/libm3/src/os/Common/File.i3:34 This was changed from CARDINAL in 2010, no doubt to handle big files on 32-bit systems. The compiler was changed to allow this at similar time. I made changes to the failing code in QScanner in June of 2014, but it would have had the same failure even before. I'm not sure of the easiest way to proceed. Figuring out what the intermediate step would be could be tedious. You might consider just editing the type in File.i3 to CARDINAL temporarily, to build a compiler, then change it back and recompile with that. But then, there could possibly be other such problems. But in general, we should have an upgrade procedure that anybody can use, starting with the release compiler, and no such manual stuff. I suppose trying to compile the current libm3 before the current compiler is the source of the problem. Can you easily recompile the compiler with your old libraries? We seem to have had some bootstrap barriers that require doing the libraries before the compiler and others the other way around, which makes having a general procedure problematic. Any ideas, Jay? On 11/19/2015 01:42 PM, Olaf Wagner wrote: > Anybody feels guilty? > Or do I just need an intermediate step now to upgrade from a compiler > from 2009? > > === package m3-sys/m3quake === > +++ cm3 -build -DROOT='/home/wagner/work/cm3-github-ssh' $RARGS && cm3 -ship $RARGS -DROOT='/home/wagner/work/cm3-github-ssh' +++ > --- building in FreeBSD4 --- > > ignoring ../src/m3overrides > > new source -> compiling Quake.i3 > new source -> compiling QCompiler.i3 > new source -> compiling QCode.i3 > new source -> compiling QValue.i3 > new source -> compiling QVSeq.i3 > new source -> compiling QVTbl.i3 > new source -> compiling QVal.i3 > new source -> compiling QPromise.i3 > new source -> compiling QPromiseSeq.i3 > new source -> compiling QMachine.i3 > new source -> compiling QToken.i3 > new source -> compiling QIdent.i3 > new source -> compiling Quake.m3 > new source -> compiling QToken.m3 > new source -> compiling QIdent.m3 > new source -> compiling QScanner.i3 > new source -> compiling QScanner.m3 > "../src/QScanner.m3", line 47: VAL: first argument must be an INTEGER > 1 error encountered > > Olaf > -- Rodney Bates rodney.m.bates at acm.org From wagner at elegosoft.com Thu Nov 19 22:52:11 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 19 Nov 2015 22:52:11 +0100 Subject: [M3devel] upgrade fails with compilation error in m3quake In-Reply-To: <564E3904.7080506@lcwb.coop> References: <20151119204205.0f728aaf2004e30402cc87e7@elegosoft.com> <564E3904.7080506@lcwb.coop> Message-ID: <20151119225211.a9469a3932dd23289731ff3f@elegosoft.com> On Thu, 19 Nov 2015 15:03:00 -0600 "Rodney M. Bates" wrote: > It looks like a bootstrap barrier. My installed compiler does not complain. > The first argument has type LONGCARD, declared at m3-libs/libm3/src/os/Common/File.i3:34 > This was changed from CARDINAL in 2010, no doubt to handle big files on 32-bit systems. > The compiler was changed to allow this at similar time. > > I made changes to the failing code in QScanner in June of 2014, but it would have had > the same failure even before. > > I'm not sure of the easiest way to proceed. Figuring out what the intermediate step > would be could be tedious. You might consider just editing the type in File.i3 > to CARDINAL temporarily, to build a compiler, then change it back and recompile with > that. But then, there could possibly be other such problems. > > But in general, we should have an upgrade procedure that anybody can use, starting with > the release compiler, and no such manual stuff. I suppose trying to compile the > current libm3 before the current compiler is the source of the problem. Can you easily > recompile the compiler with your old libraries? We seem to have had some bootstrap > barriers that require doing the libraries before the compiler and others the other > way around, which makes having a general procedure problematic. Perhaps I should give up on upgrading this old 32-bit FreeBSD system and just try to setup a current cm3 on another system at Elego. I just started it because there seemed to be a still working version. It's probably not worth the efforts. Thanks for your help anyway; I'll try to download something newer for booting from github. Olaf > Any ideas, Jay? > > On 11/19/2015 01:42 PM, Olaf Wagner wrote: > > Anybody feels guilty? > > Or do I just need an intermediate step now to upgrade from a compiler > > from 2009? > > > > === package m3-sys/m3quake === > > +++ cm3 -build -DROOT='/home/wagner/work/cm3-github-ssh' $RARGS && cm3 -ship $RARGS -DROOT='/home/wagner/work/cm3-github-ssh' +++ > > --- building in FreeBSD4 --- > > > > ignoring ../src/m3overrides > > > > new source -> compiling Quake.i3 > > new source -> compiling QCompiler.i3 > > new source -> compiling QCode.i3 > > new source -> compiling QValue.i3 > > new source -> compiling QVSeq.i3 > > new source -> compiling QVTbl.i3 > > new source -> compiling QVal.i3 > > new source -> compiling QPromise.i3 > > new source -> compiling QPromiseSeq.i3 > > new source -> compiling QMachine.i3 > > new source -> compiling QToken.i3 > > new source -> compiling QIdent.i3 > > new source -> compiling Quake.m3 > > new source -> compiling QToken.m3 > > new source -> compiling QIdent.m3 > > new source -> compiling QScanner.i3 > > new source -> compiling QScanner.m3 > > "../src/QScanner.m3", line 47: VAL: first argument must be an INTEGER > > 1 error encountered > > > > Olaf > > > > -- > Rodney Bates > rodney.m.bates at acm.org -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com 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 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Nov 24 06:31:58 2015 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Nov 2015 05:31:58 +0000 Subject: [M3devel] upgrade fails with compilation error in m3quake In-Reply-To: <20151119225211.a9469a3932dd23289731ff3f@elegosoft.com> References: <20151119204205.0f728aaf2004e30402cc87e7@elegosoft.com>, <564E3904.7080506@lcwb.coop>, <20151119225211.a9469a3932dd23289731ff3f@elegosoft.com> Message-ID: I had written up something here. It is kind of embarassing, but there is also no perfect solution. The rest of the computing world has had 64bit integers and 64 bit file sizes on 32bit platforms for 20+ years. However, many 32bit platforms did make the same initial mistake of having 32bit file sizes. And when they fixed it, they generally left all source and binaries having the same meaning, and all sources continuing to compile. And existing 32bit code would possibly error on large files, or possibly work, depending on details. And what they often did is introduce parallel interfaces. For every: SetFilePositio(int32) and GetFileSize:int32, there is usually a SetFilePosition(int64) and GetFileSize:int64. Every one, and every wrapper library, gets to update their code. And every library keeps both sets of function calls. It is messy. I believe there used to be 16bit interfaces as we well. So what should we do? Introduce parallel interfaces? Tedious but compatible. Probably. Ignore large files on 32bit platforms? Tempting but also embararassing. I'll try to look & see how bad the problem is of having parallel interfaces, so that existing code works, and new code can use "long" or "64" everywhere. - Jay > Date: Thu, 19 Nov 2015 22:52:11 +0100 > From: wagner at elegosoft.com > To: rodney.m.bates at acm.org > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] upgrade fails with compilation error in m3quake > > On Thu, 19 Nov 2015 15:03:00 -0600 > "Rodney M. Bates" wrote: > > > It looks like a bootstrap barrier. My installed compiler does not complain. > > The first argument has type LONGCARD, declared at m3-libs/libm3/src/os/Common/File.i3:34 > > This was changed from CARDINAL in 2010, no doubt to handle big files on 32-bit systems. > > The compiler was changed to allow this at similar time. > > > > I made changes to the failing code in QScanner in June of 2014, but it would have had > > the same failure even before. > > > > I'm not sure of the easiest way to proceed. Figuring out what the intermediate step > > would be could be tedious. You might consider just editing the type in File.i3 > > to CARDINAL temporarily, to build a compiler, then change it back and recompile with > > that. But then, there could possibly be other such problems. > > > > But in general, we should have an upgrade procedure that anybody can use, starting with > > the release compiler, and no such manual stuff. I suppose trying to compile the > > current libm3 before the current compiler is the source of the problem. Can you easily > > recompile the compiler with your old libraries? We seem to have had some bootstrap > > barriers that require doing the libraries before the compiler and others the other > > way around, which makes having a general procedure problematic. > > Perhaps I should give up on upgrading this old 32-bit FreeBSD system and > just try to setup a current cm3 on another system at Elego. I just started > it because there seemed to be a still working version. > > It's probably not worth the efforts. > > Thanks for your help anyway; I'll try to download something newer for booting > from github. > > Olaf > > > Any ideas, Jay? > > > > On 11/19/2015 01:42 PM, Olaf Wagner wrote: > > > Anybody feels guilty? > > > Or do I just need an intermediate step now to upgrade from a compiler > > > from 2009? > > > > > > === package m3-sys/m3quake === > > > +++ cm3 -build -DROOT='/home/wagner/work/cm3-github-ssh' $RARGS && cm3 -ship $RARGS -DROOT='/home/wagner/work/cm3-github-ssh' +++ > > > --- building in FreeBSD4 --- > > > > > > ignoring ../src/m3overrides > > > > > > new source -> compiling Quake.i3 > > > new source -> compiling QCompiler.i3 > > > new source -> compiling QCode.i3 > > > new source -> compiling QValue.i3 > > > new source -> compiling QVSeq.i3 > > > new source -> compiling QVTbl.i3 > > > new source -> compiling QVal.i3 > > > new source -> compiling QPromise.i3 > > > new source -> compiling QPromiseSeq.i3 > > > new source -> compiling QMachine.i3 > > > new source -> compiling QToken.i3 > > > new source -> compiling QIdent.i3 > > > new source -> compiling Quake.m3 > > > new source -> compiling QToken.m3 > > > new source -> compiling QIdent.m3 > > > new source -> compiling QScanner.i3 > > > new source -> compiling QScanner.m3 > > > "../src/QScanner.m3", line 47: VAL: first argument must be an INTEGER > > > 1 error encountered > > > > > > Olaf > > > > > > > -- > > Rodney Bates > > rodney.m.bates at acm.org > > > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > 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 > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Nov 24 06:33:24 2015 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Nov 2015 05:33:24 +0000 Subject: [M3devel] 64-bit integer literals (v5.8.6, NT386) In-Reply-To: References: , , , Message-ID: > although for some reason it tries to ship the new binaries to the same location as the old compiler, which of course fails It is supposed to "wait" slightly, and then do exactly that. I'll have to find time again... - Jay Date: Fri, 16 Oct 2015 07:41:18 -0700 From: lists at darko.org To: jcchu at acm.org CC: m3devel at elegosoft.com Subject: Re: [M3devel] 64-bit integer literals (v5.8.6, NT386) I haven't used those scripts so I have no idea why it does that, but the work around would be to move or rename the old compiler and the use it manually to ship the new binaries. I think there's also been some discussion regarding that issue in the mailing list in the last couple of months. On Tue, Oct 13, 2015 at 11:43 PM, JC Chu wrote: I might have been doing it wrong. I can actually use upgrade.py to produce a working compiler without having to ?fudging? anything (except NT.common (the Quake script), since I have Visual Studio 2015, which now splits the C runtime into three parts ()), although for some reason it tries to ship the new binaries to the same location as the old compiler, which of course fails. Now I?m not really sure what to do from here. ? JC Chu _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Nov 19 20:42:05 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 19 Nov 2015 20:42:05 +0100 Subject: [M3devel] upgrade fails with compilation error in m3quake Message-ID: <20151119204205.0f728aaf2004e30402cc87e7@elegosoft.com> Anybody feels guilty? Or do I just need an intermediate step now to upgrade from a compiler from 2009? === package m3-sys/m3quake === +++ cm3 -build -DROOT='/home/wagner/work/cm3-github-ssh' $RARGS && cm3 -ship $RARGS -DROOT='/home/wagner/work/cm3-github-ssh' +++ --- building in FreeBSD4 --- ignoring ../src/m3overrides new source -> compiling Quake.i3 new source -> compiling QCompiler.i3 new source -> compiling QCode.i3 new source -> compiling QValue.i3 new source -> compiling QVSeq.i3 new source -> compiling QVTbl.i3 new source -> compiling QVal.i3 new source -> compiling QPromise.i3 new source -> compiling QPromiseSeq.i3 new source -> compiling QMachine.i3 new source -> compiling QToken.i3 new source -> compiling QIdent.i3 new source -> compiling Quake.m3 new source -> compiling QToken.m3 new source -> compiling QIdent.m3 new source -> compiling QScanner.i3 new source -> compiling QScanner.m3 "../src/QScanner.m3", line 47: VAL: first argument must be an INTEGER 1 error encountered Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com 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 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney_bates at lcwb.coop Thu Nov 19 22:03:00 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 19 Nov 2015 15:03:00 -0600 Subject: [M3devel] upgrade fails with compilation error in m3quake In-Reply-To: <20151119204205.0f728aaf2004e30402cc87e7@elegosoft.com> References: <20151119204205.0f728aaf2004e30402cc87e7@elegosoft.com> Message-ID: <564E3904.7080506@lcwb.coop> It looks like a bootstrap barrier. My installed compiler does not complain. The first argument has type LONGCARD, declared at m3-libs/libm3/src/os/Common/File.i3:34 This was changed from CARDINAL in 2010, no doubt to handle big files on 32-bit systems. The compiler was changed to allow this at similar time. I made changes to the failing code in QScanner in June of 2014, but it would have had the same failure even before. I'm not sure of the easiest way to proceed. Figuring out what the intermediate step would be could be tedious. You might consider just editing the type in File.i3 to CARDINAL temporarily, to build a compiler, then change it back and recompile with that. But then, there could possibly be other such problems. But in general, we should have an upgrade procedure that anybody can use, starting with the release compiler, and no such manual stuff. I suppose trying to compile the current libm3 before the current compiler is the source of the problem. Can you easily recompile the compiler with your old libraries? We seem to have had some bootstrap barriers that require doing the libraries before the compiler and others the other way around, which makes having a general procedure problematic. Any ideas, Jay? On 11/19/2015 01:42 PM, Olaf Wagner wrote: > Anybody feels guilty? > Or do I just need an intermediate step now to upgrade from a compiler > from 2009? > > === package m3-sys/m3quake === > +++ cm3 -build -DROOT='/home/wagner/work/cm3-github-ssh' $RARGS && cm3 -ship $RARGS -DROOT='/home/wagner/work/cm3-github-ssh' +++ > --- building in FreeBSD4 --- > > ignoring ../src/m3overrides > > new source -> compiling Quake.i3 > new source -> compiling QCompiler.i3 > new source -> compiling QCode.i3 > new source -> compiling QValue.i3 > new source -> compiling QVSeq.i3 > new source -> compiling QVTbl.i3 > new source -> compiling QVal.i3 > new source -> compiling QPromise.i3 > new source -> compiling QPromiseSeq.i3 > new source -> compiling QMachine.i3 > new source -> compiling QToken.i3 > new source -> compiling QIdent.i3 > new source -> compiling Quake.m3 > new source -> compiling QToken.m3 > new source -> compiling QIdent.m3 > new source -> compiling QScanner.i3 > new source -> compiling QScanner.m3 > "../src/QScanner.m3", line 47: VAL: first argument must be an INTEGER > 1 error encountered > > Olaf > -- Rodney Bates rodney.m.bates at acm.org From wagner at elegosoft.com Thu Nov 19 22:52:11 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 19 Nov 2015 22:52:11 +0100 Subject: [M3devel] upgrade fails with compilation error in m3quake In-Reply-To: <564E3904.7080506@lcwb.coop> References: <20151119204205.0f728aaf2004e30402cc87e7@elegosoft.com> <564E3904.7080506@lcwb.coop> Message-ID: <20151119225211.a9469a3932dd23289731ff3f@elegosoft.com> On Thu, 19 Nov 2015 15:03:00 -0600 "Rodney M. Bates" wrote: > It looks like a bootstrap barrier. My installed compiler does not complain. > The first argument has type LONGCARD, declared at m3-libs/libm3/src/os/Common/File.i3:34 > This was changed from CARDINAL in 2010, no doubt to handle big files on 32-bit systems. > The compiler was changed to allow this at similar time. > > I made changes to the failing code in QScanner in June of 2014, but it would have had > the same failure even before. > > I'm not sure of the easiest way to proceed. Figuring out what the intermediate step > would be could be tedious. You might consider just editing the type in File.i3 > to CARDINAL temporarily, to build a compiler, then change it back and recompile with > that. But then, there could possibly be other such problems. > > But in general, we should have an upgrade procedure that anybody can use, starting with > the release compiler, and no such manual stuff. I suppose trying to compile the > current libm3 before the current compiler is the source of the problem. Can you easily > recompile the compiler with your old libraries? We seem to have had some bootstrap > barriers that require doing the libraries before the compiler and others the other > way around, which makes having a general procedure problematic. Perhaps I should give up on upgrading this old 32-bit FreeBSD system and just try to setup a current cm3 on another system at Elego. I just started it because there seemed to be a still working version. It's probably not worth the efforts. Thanks for your help anyway; I'll try to download something newer for booting from github. Olaf > Any ideas, Jay? > > On 11/19/2015 01:42 PM, Olaf Wagner wrote: > > Anybody feels guilty? > > Or do I just need an intermediate step now to upgrade from a compiler > > from 2009? > > > > === package m3-sys/m3quake === > > +++ cm3 -build -DROOT='/home/wagner/work/cm3-github-ssh' $RARGS && cm3 -ship $RARGS -DROOT='/home/wagner/work/cm3-github-ssh' +++ > > --- building in FreeBSD4 --- > > > > ignoring ../src/m3overrides > > > > new source -> compiling Quake.i3 > > new source -> compiling QCompiler.i3 > > new source -> compiling QCode.i3 > > new source -> compiling QValue.i3 > > new source -> compiling QVSeq.i3 > > new source -> compiling QVTbl.i3 > > new source -> compiling QVal.i3 > > new source -> compiling QPromise.i3 > > new source -> compiling QPromiseSeq.i3 > > new source -> compiling QMachine.i3 > > new source -> compiling QToken.i3 > > new source -> compiling QIdent.i3 > > new source -> compiling Quake.m3 > > new source -> compiling QToken.m3 > > new source -> compiling QIdent.m3 > > new source -> compiling QScanner.i3 > > new source -> compiling QScanner.m3 > > "../src/QScanner.m3", line 47: VAL: first argument must be an INTEGER > > 1 error encountered > > > > Olaf > > > > -- > Rodney Bates > rodney.m.bates at acm.org -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com 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 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Nov 24 06:31:58 2015 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Nov 2015 05:31:58 +0000 Subject: [M3devel] upgrade fails with compilation error in m3quake In-Reply-To: <20151119225211.a9469a3932dd23289731ff3f@elegosoft.com> References: <20151119204205.0f728aaf2004e30402cc87e7@elegosoft.com>, <564E3904.7080506@lcwb.coop>, <20151119225211.a9469a3932dd23289731ff3f@elegosoft.com> Message-ID: I had written up something here. It is kind of embarassing, but there is also no perfect solution. The rest of the computing world has had 64bit integers and 64 bit file sizes on 32bit platforms for 20+ years. However, many 32bit platforms did make the same initial mistake of having 32bit file sizes. And when they fixed it, they generally left all source and binaries having the same meaning, and all sources continuing to compile. And existing 32bit code would possibly error on large files, or possibly work, depending on details. And what they often did is introduce parallel interfaces. For every: SetFilePositio(int32) and GetFileSize:int32, there is usually a SetFilePosition(int64) and GetFileSize:int64. Every one, and every wrapper library, gets to update their code. And every library keeps both sets of function calls. It is messy. I believe there used to be 16bit interfaces as we well. So what should we do? Introduce parallel interfaces? Tedious but compatible. Probably. Ignore large files on 32bit platforms? Tempting but also embararassing. I'll try to look & see how bad the problem is of having parallel interfaces, so that existing code works, and new code can use "long" or "64" everywhere. - Jay > Date: Thu, 19 Nov 2015 22:52:11 +0100 > From: wagner at elegosoft.com > To: rodney.m.bates at acm.org > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] upgrade fails with compilation error in m3quake > > On Thu, 19 Nov 2015 15:03:00 -0600 > "Rodney M. Bates" wrote: > > > It looks like a bootstrap barrier. My installed compiler does not complain. > > The first argument has type LONGCARD, declared at m3-libs/libm3/src/os/Common/File.i3:34 > > This was changed from CARDINAL in 2010, no doubt to handle big files on 32-bit systems. > > The compiler was changed to allow this at similar time. > > > > I made changes to the failing code in QScanner in June of 2014, but it would have had > > the same failure even before. > > > > I'm not sure of the easiest way to proceed. Figuring out what the intermediate step > > would be could be tedious. You might consider just editing the type in File.i3 > > to CARDINAL temporarily, to build a compiler, then change it back and recompile with > > that. But then, there could possibly be other such problems. > > > > But in general, we should have an upgrade procedure that anybody can use, starting with > > the release compiler, and no such manual stuff. I suppose trying to compile the > > current libm3 before the current compiler is the source of the problem. Can you easily > > recompile the compiler with your old libraries? We seem to have had some bootstrap > > barriers that require doing the libraries before the compiler and others the other > > way around, which makes having a general procedure problematic. > > Perhaps I should give up on upgrading this old 32-bit FreeBSD system and > just try to setup a current cm3 on another system at Elego. I just started > it because there seemed to be a still working version. > > It's probably not worth the efforts. > > Thanks for your help anyway; I'll try to download something newer for booting > from github. > > Olaf > > > Any ideas, Jay? > > > > On 11/19/2015 01:42 PM, Olaf Wagner wrote: > > > Anybody feels guilty? > > > Or do I just need an intermediate step now to upgrade from a compiler > > > from 2009? > > > > > > === package m3-sys/m3quake === > > > +++ cm3 -build -DROOT='/home/wagner/work/cm3-github-ssh' $RARGS && cm3 -ship $RARGS -DROOT='/home/wagner/work/cm3-github-ssh' +++ > > > --- building in FreeBSD4 --- > > > > > > ignoring ../src/m3overrides > > > > > > new source -> compiling Quake.i3 > > > new source -> compiling QCompiler.i3 > > > new source -> compiling QCode.i3 > > > new source -> compiling QValue.i3 > > > new source -> compiling QVSeq.i3 > > > new source -> compiling QVTbl.i3 > > > new source -> compiling QVal.i3 > > > new source -> compiling QPromise.i3 > > > new source -> compiling QPromiseSeq.i3 > > > new source -> compiling QMachine.i3 > > > new source -> compiling QToken.i3 > > > new source -> compiling QIdent.i3 > > > new source -> compiling Quake.m3 > > > new source -> compiling QToken.m3 > > > new source -> compiling QIdent.m3 > > > new source -> compiling QScanner.i3 > > > new source -> compiling QScanner.m3 > > > "../src/QScanner.m3", line 47: VAL: first argument must be an INTEGER > > > 1 error encountered > > > > > > Olaf > > > > > > > -- > > Rodney Bates > > rodney.m.bates at acm.org > > > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > 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 > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Nov 24 06:33:24 2015 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Nov 2015 05:33:24 +0000 Subject: [M3devel] 64-bit integer literals (v5.8.6, NT386) In-Reply-To: References: , , , Message-ID: > although for some reason it tries to ship the new binaries to the same location as the old compiler, which of course fails It is supposed to "wait" slightly, and then do exactly that. I'll have to find time again... - Jay Date: Fri, 16 Oct 2015 07:41:18 -0700 From: lists at darko.org To: jcchu at acm.org CC: m3devel at elegosoft.com Subject: Re: [M3devel] 64-bit integer literals (v5.8.6, NT386) I haven't used those scripts so I have no idea why it does that, but the work around would be to move or rename the old compiler and the use it manually to ship the new binaries. I think there's also been some discussion regarding that issue in the mailing list in the last couple of months. On Tue, Oct 13, 2015 at 11:43 PM, JC Chu wrote: I might have been doing it wrong. I can actually use upgrade.py to produce a working compiler without having to ?fudging? anything (except NT.common (the Quake script), since I have Visual Studio 2015, which now splits the C runtime into three parts ()), although for some reason it tries to ship the new binaries to the same location as the old compiler, which of course fails. Now I?m not really sure what to do from here. ? JC Chu _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: